关于xloader和uboot的几个初级问题

在看代码的过程中遇到的几个问题，发邮件问了xf，得到了满意的回答，对xf表示感谢。
这里将问题及答案记录下来，作为参考，蓝色的字体为xf给我的回答。

 一、为什么需要xloader，xloader所做的工作为什么不直接就让uboot做，而要单独的分出来呢？

我看了xloader的代码，非常短小，所做的工作也很简单，我说说我对代码的理解，不知道正不正确：
在最初始的时候xloader首先对系统进行了初始化（sys_init和ddr_init），然后就进入Xloader_Entry函数，从预定的flash地址(UBOOT_BASE_ADDRESS 0xF8010000)读取uboot image的header，然后比较读取的header中的magic number与预定的magic number（IH_MAGIC 0x27051956）是否相同，如果相同则说明在flash中存在uboot的image。在确定了uboot的存在之后，根据uboot image header中指定的内存地址loadaddress以及数据大小data_size将uboot载入内存，然后在执行了Program_Interconnection_Matrix之后，就跳转到loadaddress开始执行uboot的代码。

如果xloader仅仅完成了上述的功能的话，那为什么不能直接将xloader的功能就集成到uboot中呢。

xloader主要功能是：初始化系统时钟；初始化外部内存，对我们当前项目就是DDR；引导UBOOT
xloader的运行环境为内部内存sram；这部分是在chip内部，材料比较贵，都是很小一部分空间，不能够运行大的程序。
chip总是留这样一部分sram运行bootrom代码和xloader代码，对这两部分代码的大小进行了限制。所以xloader都很小
功能简单，独立于uboot，uboot功能较多，相当于小系统，代码较大，只能在外部内存运行。
启动顺序：bootrom（内部ram）-》xloader（内部ram）-》uboot（外部ram）-》kernel（外部ram）

二、从xloader跳转到uboot之后程序是怎么走的？

注意到在xloader中有以下几句代码：
loadaddress = ntohl(hdr->ih_load);
data_size = ntohl(hdr->ih_size);
memcpy(loadaddress, (UBOOT_BASE_ADDRESS + 64), data_size);

由此可见，xloader将uboot image中的data_size个字节拷贝到了loadaddress的内存区域内，并且拷贝的字节区域相对于UBOOT_BASE_ADDRESS（即uboot的烧写地址0xF8010000）的偏移为64个字节。
分析程序可知，在UBOOT_BASE_ADDRESS处是uboot image header，而image header结构的定义为
typedef struct image_header {
    uint32_t    ih_magic;
    uint32_t    ih_hcrc;
    uint32_t    ih_time;
    uint32_t    ih_size;
    ...
}  image_header_t;
也就是说，header偏移64个字节的地方正是header中的ih_time，也就是loadaddress内存区域开头处的内容为ih_time。

这样的话，一旦在xloader执行了Jump_To_UBoot(loadaddress)之后，程序将跳转到loadaddress出执行，而此时loadaddress处的内容却为ih_time，到这个地方，程序是怎么执行了呢？

这部分没明白啥意思，xloader装载uboot后，直接跳转到uboot执行就ok了

...

第二个问题我明白你的意思了，
uint32_t不是32个字节啊，
uboot前边的header总共64个字节

哦，我明白了，它也真是，直接写sizeof(image_head_t)不就行了吗，非得写64。不过也是我自己粗心大意了。

三、说了一大堆，其实我就是想在源代码级别上了解整个系统从一开始到linux内核成功引导的全过程。

对于第三个问题，由于不是一句两句就能够说清楚的，所以准备过几天亲自去找xf问清楚，但是在这之前，我需要先尽量看代码。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/ffee/archive/2008/10/10/3051797.aspx