http://blog.csdn.net/ffee/article/details/3051797
关于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问清楚,但是在这之前,我需要先尽量看代码。
这里将问题及答案记录下来,作为参考,蓝色的字体为xf给我的回答。
一、为什么需要xloader,xloader所做的工作为什么不直接就让uboot做,而要单独的分出来呢?
我看了xloader的代码,非常短小,所做的工作也很简单,
在最初始的时候xloader首先对系统进行了初始化(sys_
如果xloader仅仅完成了上述的功能的话,
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_
分析程序可知,在UBOOT_BASE_
typedef struct image_header {
uint32_t ih_magic;
uint32_t ih_hcrc;
uint32_t ih_time;
uint32_t ih_size;
...
} image_header_t;
也就是说,
这样的话,一旦在xloader执行了Jump_To_
这部分没明白啥意思,xloader装载uboot后,直接跳转到uboot执行就ok了
...
第二个问题我明白你的意思了,
uint32_t不是32个字节啊,
uboot前边的header总共64个字节
哦,我明白了,它也真是,直接写sizeof(image_ head_t)不就行了吗,非得写64。 不过也是我自己粗心大意了。
三、说了一大堆,
对于第三个问题,由于不是一句两句就能够说清楚的,所以准备过几天亲自去找xf问清楚,但是在这之前,我需要先尽量看代码。