从裸跑开始

  一直忙着上课，项目已经落下了很多了。上个月刚拿到新的开发板，看了看，资料太少，门槛太高，有点心寒了。

  真的很怀念用51单片机的时候，一起都可以自由的控制。而现在，加了操作系统这一层，问题反而多了起来。本想先把ARM当个高速单片机来学的，现在完全摸不到硬件层，真是郁闷。

  好了，现在想研究研究X-load的源码，一定先让3530裸跑起来，看看硬件层。。。

x-load本质是一个U-BOOT的精简版。为什么需要x-load这个玩意呢，而不是直接用u-boot呢？那是因为U-boot太大了，塞不进内部的RAM？那为啥要把X-LOAD塞进内部的RAM，而不是load到外部的RAM呢？

问题就在这里了。当OMAP3530上电的时候，memory controller还没有初始化，怎么去读写外部的RAM呢？必须要有人能先初始化memory controller啊。任务就交给x-Load了。它必须负责初始化外部的RAM控制器，把u-boot从NAND或者MMC中读出到外部RAM，然后跳到u-boot的入口处执行。

问题又来了，那么x-load又是由谁来load的呢？OMAP3530里面带了一个内部RAM，大小为64K。当OMAP3530上电后，会从NAND Flash或者MMC中读取x-load到内部的RAM。然后执行x-load，x-load然后执行上面所说的任务，最后把控制入口交给u-boot。

要编译x-load，先安装toolchain。然后

In file include/configs/omap3530beagle.h

/* For X-loader to be flashed on to NAND disable the below macro */
//#define CFG_CMD_MMC

Comiple the x-loader as shown below

make CROSS_COMPILE=arm-none-linux-gnueabi- distclean
make CROSS_COMPILE=arm-none-linux-gnueabi- omap3530beagle_config
make CROSS_COMPILE=arm-none-linux-gnueabi-

会生成x-loader.bin。然后用SignGP工具生成可以被OMAP3530 load的bin 文件。

./singGP x-load.bin

生成x-load.bin.ift。

这个文件和x-load.bin的区别在于增加了一个4个字节的header。header的内容是4个字节的x-loader的长度和x-load被load到什么地方的地址(4个字节)。