am335x_SPL_学习总结

之前一直没有调过am335x上的uboot , 很偶然的机会，我们有板子出现卡死在SPL阶段了，然后就去学习了。

am335x的启动分为以下几个阶段:

RBL -> SPL -> uboot -> kernel -> rootfs

RBL是cpu出厂时就已经烧写好了，在开发中也不会对这部分进行操作。

SPL 也叫MLO，由uboot源码编译出来。它是由RBL引导过来启动的。SPL可以存储到nandflash上或者Micro sd卡上。SPL存储到nandflash上的前4个block中任意一块（及block0，block1，block2，block3都是为SPL预留的），一般是存在block0。（block0：0x0;  block1： 0x20000;  block2：0x40000;  block3：0x60000）

RBL默认会先尝试从nandflash的这四个block中依次查找SPL，如果nandflash中没有可用的SPL，然后再从sd卡查找（ti am335x的默认启动顺序）。

SPL会从block5，即0x80000查找uboot，并跳转到uboot阶段。

在这里只记录一下大概，详细的代码分析参考 http://blog.csdn.net/stephen_yu/article/details/39553561

然后最终发现出问题的板子是因为前面4个block里面有坏块， 而用于烧写的镜像的生成是： 将SPL写0x0，uboot写到0x80000，但是中间全部用0xff填充。这样当把这个镜像文件直接写到nandflash中时，因前4个块里有坏块，就跳过了，这样的结果是将uboot写道了block5中，但是SPL还是要从block4开始读取uboot的头信息，并加载uboot，这样就会出现SPL找不到uboot，因此也就卡死了。

####################################################################################################################################

另附uboot头信息解析 http://blog.csdn.net/cinberella/article/details/41247405

主要参考uboot源码中 头文件include/image.h