S5PV210 uboot启动过程

按照三星《S5PV210_UM_REV1.1》手册上说明的启动流程，S5PV210上电将从IROM处执行固化的启动代码，对时钟等初始化、对启动设备进行判断，并从启动设备中复制BL1（最大16KB）到IRAM（0xd002_0000处，其中0xd002_0010之前的16个字节储存的BL1的校验信息和BL1尺寸）中，并对BL1进行校验，校验OK转入BL1进行执行；BL1继续初始化，并将BL2复制到IRAM中并对其校验，OK后转入BL2；BL2则要进行比较复杂的初始化，包括DRAM的初始化，完成后将OS代码复制到DRAM中，并转入到OS中执行并完成启动引导。
但是，上述的IRAM只有96K大小，对于日益复杂的uboot来说，肯定是不够的，所以使用UBOOT启动引导的时候，也没全按三星手册上说的执行，具体如下：

首先解释一下我认为的BL0、BL1、BL2：

BL0：是指S5PV210的IROM中固化的启动代码；

BL1：是指在IRAM中执行的UBOOT的部分代码；

BL2：是指在内存中执行的的UBOOT的完整代码；

此版本的UBOOT，其实会编译两个UBOOT.bin，即最终生成的tiny210-uboot.bin包括两部分，前段是spl（重用u-boot中既有的驱动,来生成更小的secondaryprogramloader）文件夹内的tiny210-spl.bin，后段是用于在RAM中执行的完整UBOOT代码。所以学习UBOOT代码是也要两个部分来看。

1、第一步与三星手册上一致，执行IROM内固化的代码，即BL0，BL0会将存储于启动设备的UBOOT代码的前16KB：tiny210-spl.bin复制到IRAM。（tiny210-spl.bin设置为24KB了，但实际绝不会超过16KB，后面全填充的0，所以拷不完也OK。这里是liukun321为了统一MMC与NAND启动而作的修改，也许改成16K就应该OK了，应为IROM里的代码最多拷贝16K进IRAM嘛，一会改改试试。所以呢实际上执行BL1就是执行tiny210-spl.bin。在UBOOT的代码中并不会看到tiny210-spl.bin和完整的UBOOT代码分开两套文件进行编写，都在同样的文件中，只是通过宏定义来控制执行流程，SPL文件夹内由自己的Makefile文件。

2、第一步入口程序是/arch/arm/cpu/armv7/start.S中的_start，设置异常向量地址（地址由ARM 架构决定，不能改变），执行reset，进入SVC32模式，并调用cpu_init_crit对ARM的CP15寄存器进行设置，如清空TLB，关闭MMU等，进入/board/samsung/tiny210/lowlevel_init.S中的lowlevel_init中，进行低级初始化，主要是对时钟、内存、串口、nand等进行初始化，为下一步的代码拷贝做准备。

3、从lowlevel_init出来之后执行call_board_init_f，通过读取OMR_OFFSET寄存器的值，对启动设备进行判断，看看是从mmc启动还是nand启动，判断好后跳入mmc_boot.c或nand_cp.c中，将UBOOT代码拷贝到内存中，地址为_TEXT_BASE:在tiny210.h中定义为0x23e0_0000，换成别的地方也可以,比如3000_0000（注：在跳转到内存中执行之前，所有的语句都是基于PC寻址的，也就是说和代码具体存放的地址没有关系，进行跳转的时候都会计算出跳转目标相对与PC的位置，在跳转过去。）。这里有一个很大的问题，稍后讨论。拷贝完成后直接冲0x23e0_0000出开始执行。那么执行的是什么呢，那先看看拷贝的是什么吧！

a.nand启动

在/arch/arm/cpu/armv7/s5pc1xx/nand_cp.c中，第105行：

for(i = (0x6000>>page_shift); i < (size>>page_shift);i++, buf+=(1<<page_shift)) {

nandll_read_page(buf,i, large_block);

}

指定了拷贝的起始page是nand起始24K之后的第一个PAGE，偏移0x6000的位置，该地址上存储的是完整的UBOOT在RAM中执行的完整启动代码；

b.mmc启动

在/arch/arm/cpu/armv7/s5pc1xx/mmc_boot.c中，第49行：

#defineMOVI_BL2_POS ((eFUSE_SIZE / MOVI_BLKSIZE) +MOVI_BL1_BLKCNT + MOVI_ENV_BLKCNT)

经计算MOVI_BL2_POS位于第24.5K的位置，也即第49个block，偏移0x6200的位置，该地址上存储的同样是UBOOT在RAM中执行的完整启动代码；

注：针对第一点提出的将24K偏移改成16K，经过验证：改成16KB并不可行，其实这里不仅仅是BL1的容量的问题，UBOOT_SPL.BIN实际上只有4K不到，所以对于nand启动来说4KB就足够了，但是对于MMC启动来说却不行，因为SD卡的布局并不一样，它在BL1与BL2之间还插入了16KB的ENV区，所以只能是24K，而对NAND的ENV区在BL2之后了。

所以，无论是MMC启动还是NAND启动，将代码copy到DRAM中并跳转之后，执行的是DRAM中的_start入口函数，重新执行一遍UBOOT，但是一些宏定义已经发生变化，如CONFIG_SPL_BUILD被取消定义，相应的代码也不会执行。

4、因为第一编执行UBOOT的时候ARM的状态都已经初始化OK了，包括时钟，内存等，第二遍执行时只是跳转到内存中执行了，所以这里判断是否在DRAM中执行，如果在内存中执行，则可以直接跳到call_board_init_f去进行班级初始化。当然，源码并不是这样执行的，而是重新执行RESET、LOWLEVEL_INIT等函数，但我验证过，可以不用执行。有兴趣的同志也可以验证一下。

5 、进入board_init_f以后将： a、对gd_t数据结构(include/asm/global_data.h中定义)进行初始化，并填入相关数据，如内存大小、UBOOT镜像长度等；
b、对打印CPU信息、UBOOT版本信息等，并对串口、console进一步初始化，输出nand信息，对内存大小进行计算，并打印出来。 c、为UBOOT的重定向设置物理地址，重定向后UBOOT可使用的end地址为0x3fff_0000,

UBOOT镜像起始地址为0x3ff8_5000。

打印调试信息：

TLBtable at: 3fff0000

Topof RAM usable for U-Boot at: 3fff0000

Reserving424k for U-Boot at: 3ff85000

Reserving928k for malloc() at: 3fe9d000

Reserving24 Bytes for Board Info at: 3fe9cfe8

Reserving120 Bytes for Global Data at: 3fe9cf70