首先,需要理解加载域与运行域的概念。加载域是代码存放的地址,运行域是代码运行时的地址。为什么会产生这2个概念?这2个概念的实质意义又是什么呢?
在一些场合,一些代码并不在储存这部分代码的地址上执行地址,比如说,放在norflash中的代码可能最终是放在RAM中运行,那么中norflash中的地址就是加载域,而在RAM中的地址就是运行域。
在汇编代码中我们常常会看到一些跳转指令,比如说b、bl等,这些指令后面是一个相对地址而不是绝对地址,比如说b main,这个指令应该怎么理解呢?main这里究竟是一个什么东西呢?这时候就需要涉及到链接地址的概念了,链接地址实际上就是链接器对代码中的变量名、函数名等东西进行一个地址的编排,赋予这些抽象的东西一个地址,然后在程序中访问这些变量名、函数名就是在访问一些地址。一般所说的链接地址都是指链接这些代码的起始地址,代码必须放在这个地址开始的地方才可以正常运行,否则的话当代码去访问、执行某个变量名、函数名对应地址上的代码时就会找不到,接着程序无疑就是跑飞。但是上面说的那个b main的情形有点特殊,b、bl等跳转指令并不是一个绝对跳转指令,而是一个相对跳转指令,什么意思呢?就是说,这个main标签最后得到的只并不是main被链接器编排后的绝对地址,而是main的绝对地址减去当前的这个指令的绝对地址所得到的值,也就是说b、bl访问到的是一个相对地址,不是绝对地址,因此,包括这个语句和main在内的代码段无论是否放在它的运行域这段代码都能正常运行。这就是所谓的位置无关代码。
由上面的论述可以得知,如果你的这段代码需要实现位置无关,那么你就不能使用绝对寻址指令,否则的话就是位置有关了。
接着,将结合uboot、vivi、linux中的PIC(position independent code)代码进行分析。
另外需要指出的是本文的分析基于mini2440的板子及配套代码,对于其他板子或者源代码代码或者会有差别。
Uboot部分:
在/u-boot-1.1.2/cpu/arm920t/start.S截取部分相关代码如下:
1 .globl _start
2 _start: b reset
3 ldr pc, _undefined_instruction
4 ldr pc, _software_interrupt
5 ldr pc, _irq
6 ldr pc, _fiq
7
8 reset:
9 mrs r0,cpsr
10 bic r0,r0,#0x1f
11 orr r0,r0,#0xd3
12 bl cpu_init_crit
12 relocate: /* relocate U-Boot to RAM */
13 adr r0, _start /* r0 <- current position of code */
14 ldr r1, _TEXT_BASE /* test if we run from flash or RAM */
15 cmp r0, r1 /* don't reloc during debug */
16 beq stack_setup
17 ldr r2, _armboot_start
18 ldr r3, _bss_start
19 sub r2, r3, r2 /* r2 <- size of armboot */
20 add r2, r0, r2 /* r2 <- source end address */
21
22 copy_loop:
23 ldmia r0!, {r3-r10} /* copy from source address [r0] */
24 stmia r1!, {r3-r10} /* copy to target address [r1] */
25 cmp r0, r2 /* until source end addreee [r2] */
26 ble copy_loop
27
28 /* Set up the stack */
29 stack_setup:
30 ldr r0, _TEXT_BASE /* upper 128 KiB: relocated uboot */
31 sub r0, r0, #CFG_MALLOC_LEN /* malloc area */
32 sub r0, r0, #CFG_GBL_DATA_SIZE /* bdinfo */
33 #ifdef CONFIG_USE_IRQ
34 sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)
35 #endif
36 sub sp, r0, #12 /* leave 3 words for abort-stack */
37 ldr pc, _start_armboot
假设(其实不是假设,一般都是)这段代码当前是在起始地址为0的norflash中储存,上电复位后CPU首先跳转到2运行,这句使用的是一个相对跳转指令b,这个指令将跳转到本地储存的reset例程中运行。接下来的所有语句中都没有通过绝对寻址来寻找某个变量或者函数,因此即使目前的加载域与运行域不一致也没有问题,因为运行域主要是设计绝对寻址的正确性,如果没有进行绝对寻址,不一致又能奈他何?
这里其实还有个细节需要点出,就是3~6这几句异常处理都是使用ldr进行绝对跳转的,因此使用的undefined_instruction等都是这些名称对应的链接地址,但是由下面的分析可知,这几个中断处理函数可能根本没有被复制到RAM中((uboot只是把第一个C语言开始的代码复制到RAM,但是这个结论尚未通过反汇编来验证),也就是这些函数没有被加载到运行域所以一旦发生reset以外的异常情况(比如说硬件中断)程序就会跑飞,由此也可以得到另一个结论:uboot不支持中断(至少当前分析的这个版本1.1.2是这样的,其他版本可能不一样)。
下一个重点是12开始的这段重定位代码,13中使用了一个很特别的指令adr, adr r0, _start 作用是获得 _start 的实际运行所在的地址值,其中adr r0, _start翻译成 add r0,(PC+#offset),offset 就是 adr r0, _start 指令到_start 的偏移量,值为负数,在链接时确定,这个偏移量是地址无关的,而pc为当前指令的地址的下一个地址值,由于CPU复位后pc的值从0开始增加,因此到这这里的值刚刚好能将offset抵消,所以最后r0的值就是0。
对于14,ldr r1, _TEXT_BASE 指令表示以程序相对偏移的方式加载数据,是索引偏移加载的另外一种形式,等同于ldr r1,[PC+#offset],offset 是 ldr r1, _TEXT_BASE 到 _TEXT_BASE 的偏移量, 因此最后r1得到的值就是TEXT_BASE,这个值在其他文件中已经定义(比如对smdk2410平台而言就是在~/board/smdk2410/config.mk文件中)
15的就是比较上面的r0、r1是否相等,如果相等那么证明程序现在的位置正是想要去的运行域,因此不需要做重定位就可以通过16语句跳转stack_setup,否则就需要继续执行17开始的代码做重定位。17是将start_armboot这个地址给r2,start_armboot是谁?就是uboot的第一个C语言函数,这个函数名在链接的时候已经被安排为某个地址,也就是运行域。18是将bss_start这个值付给r3,那bss_start又是谁呢?说到这里先看看u-boot/board/smdk2410下的u-boot.lds链接文本的内容:
1 ENTRY(_start)
2 SECTIONS
3 {
4 . = 0x00000000;
5 . = ALIGN(4);
6 .text :
7 {
8 cpu/arm920t/start.o (.text)
9 *(.text)
10 }
11 . = ALIGN(4);
12 .rodata : { *(.rodata) }
13 . = ALIGN(4);
14 .data : { *(.data) }
15 . = ALIGN(4);
16 .got : { *(.got) }
17 __u_boot_cmd_start = .;
18 .u_boot_cmd : { *(.u_boot_cmd) }
19 __u_boot_cmd_end = .;
20 . = ALIGN(4);
21 __bss_start = .;
22 .bss : { *(.bss) }
23 _end = .;
24 }
链接文本是链接器用来链接可执行文件所使用的脚本文件,链接器根据这个来决定编译器编译出来的一大堆.o文件如何组织成为一个可执行文件。其中ENTRY(_start)指定了这个可执行文件的入口点(或者通俗点说第一个执行的函数)。SECTIONS描述了代码在内存中的布局情况,4指定了内存的分布从0开始,但是实际上在uboot链接过程中使用了一个-Ttext选项,这个选项最后就替代了0而将.text的链接地址修改为0x33f80000,这个链接命令如下:
arm-linux-ld –Tu-boot-1.1.4/board/smdk2410/u-boot.lds –Ttext 0x33f80000
因此这个链接脚本实际上并不是最终的内存布局。另外需要额外说明的是,这个链接地址是一个虚拟地址,如果mmu没有打开的话(对于uboot就是这种情况,mmu一直都是处于关闭状态)那么这个虚地址就是物理地址。在linux中,对于ARM平台内核一般从0xC0004000开始链接,这个地址明显就是虚拟地址,在2410中一般把内核解压在0x30008000这个物理地址上,所以在内核打开mmu之前的代码必须是位置无关的,否则没有办法启动内核;在打开mmu后,可以使用mmu将0x30000000开始的64M的物理空间映射为0xC0000000开始的64M虚拟空间。
说了这么多的题外话后回到之前的话题,bss_start就是在链接脚本中指出的一个符号,用以得到一个地址给外部的程序使用,这个地址实际上就是uboot链接后的最高地址,后面的bss虽然也还是uboot可执行文件的范畴,但是这个段在链接的时候并不分配任何内存空间,因此可以认为可执行文件到bss_start就结束了。由此可以理解/u-boot-1.1.2/cpu/arm920t/start.S的17、18实际上是分别得到了uboot的第一个C语言函数地址和这个可执行文件的最后一个链接地址,之前运行的那段位置无关的汇编代码直接被忽略。
22~26这段就是实现将uboot从norflash复制到RAM,地址为TEXT_BASE。
29~36是设置堆栈空间和sp指针的值,为执行C语言程序做准备。
37是重点,作用是跳转到C语言的入口点start_armboot函数。
ldr pc, _start_armboot
这个语句使用的是ldr指令,这是一个绝对寻址指令,将start_armboot这个绝对地址加载到pc寄存器中,从而CPU转到start_armboot这个地址上开始运行,实现了从flash到RAM的跳转。
Uboot启动内核的过程:
1、 uboot对需要启动的映像文件有一定的格式要求,对于一个需要使用uboot引导的映像文件需要先使用uboot自带的mkimage工具对这个映像进行修改,添加结构为image_header头部。具体指令如下:
./mkimage -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
这样映像文件就增加了sizeof(image_header_t)个字节。为什么要增加一个这样的头部呢?关于这个文件头还是很有研究分量的,但是由于这里并不把这个作为重点,因此把这部分的分析写在了另一篇文章《uboot中关于mkimage指令的矛盾分析.doc》中。这里仅仅强调一下addr、ep这2个参数,前者是映像的下载地址,就是把这个映像复制到哪里(不包括上面说到的那个文件头,这部分在复制的时候被跳过),后者就是内核的入口,uboot就是从这点来找到并启动内核的。
2、按照文件头的参数将映像从flash或者RAM的其他位置复制到addr这里,其中文件头被直接忽略。如果是使用mkimage的时候使用了压缩选项那么就不是单纯的复制,而是解压到这个addr。
3、设置启动参数表。与vivi不一样,uboot对向内核传递参数时使用的是struct tag(标记列表,tagged list)方式。设置方式大概遵循如下步骤:
1 setup_start_tag (bd);
2 setup_memory_tags (bd);
3 setup_commandline_tag (bd, commandline);
4 setup_initrd_tag (bd, initrd_start, initrd_end);
5 setup_end_tag (bd);
其中,1是标记列表的开始,这个设置选项主要是指定这个启动参数表的存放位置,比如说一般会指定在SDRAM_BASE+0x100这个地方。2是设置内存标记,告诉内核这个硬件平台的RAM有多大、起始地址是多少等。3是设置命令行参数。4是设置initrd标记,如果并不使用initrd的话那么这个设置是不需要的。
4、关闭cache,禁止mmu,禁止中断,调用kernel函数跳转到内核,thekernel函数是如何定义的呢?这个过程是怎么实现的呢?
1 void (*theKernel)(int zero, int arch, uint params);
2 theKernel = (void (*)(int, int, uint))ntohl(hdr->ih_ep);
3 theKernel (0, bd->bi_arch_number, bd->bi_boot_params);
这是在armlinux.c文件截取do_bootm_linux函数(这是启动内核时调用的最后一个函数)的的几个相关语句,1是定义一个函数指针,2是把这个指针指向实际执行的函数地址,这个地址是谁呢?就是上面第一点说到的那个ep,就是内核的入口地址,或者说内核的第一个语句,这里还使用了(void (*)(int, int, uint))将这个地址强制转换为有3个参数的函数,为什么要这样做呢?因为在跳转到内核前需要设置好r0、r1、r2这3个寄存器的值,而在一般的C函数调用过程中,入口参数就是使用r0、r1、r2.。。。。。。。等来传递的,换言之,在3语句中调用theKernel函数时提供的3个入口参数最后将分别传给r0、r1、r2,这样就非常巧妙地通过C语言的特性来实现了r0、r1、r2的设置。
其中值得一提的是,r2的值在vivi中是设置为内核在RAM中的地址,但是在uboot中是设置为了uboot传递给linux的启动参数表在RAM中的位置。究竟谁是对的呢?从逻辑上看,vivi向内核传递内核所在的地址没有意义,因为内核要这个没用,但是内核需要启动参数表,因此设置这个参数表的位置有意义,由此可以认定vivi那样做是不对的。再者,vivi如果要将参数正确传递给linux,必须事先知道linux默认会去哪里找启动参数表,然后在这个位置上填好这个参数表,否则如果随便找个地方放这个表linux是没有办法找到的,这样的话内核将启动失败。
另外需要再次强调的是,uboot没有打开mmu,因此一直使用的地址都是直接对应在物理地址上,但是vivi为了实现更好的性能打开了cache和mmu,因此情况就相当不一样了,下面将说明vivi的情况。
Vivi部分:
Vivi的入口点在vivi/arch/s3c2440/head.S的start,在这个文件中截取部分相关代码进行分析:
1 ENTRY(_start)
2 b Reset
3 b HandleUndef
4 b HandleIRQ
5 b HandleFIQ
6 Reset:
7 @ disable watch dog timer
8 mov r1, #0x53000000
9 mov r2, #0x0
10 str r2, [r1]
11 @ disable all interrupts
12 mov r1, #INT_CTL_BASE
13 mov r2, #0xffffffff
14 str r2, [r1, #oINTMSK]
15 ldr r2, =0x7ff
16 str r2, [r1, #oINTSUBMSK]
17 @ initialise system clocks
18 mov r1, #CLK_CTL_BASE
19 bl memsetup
20 bl InitUART
21 # ifdef CONFIG_S3C2440_NAND_BOOT
22 bl copy_myself
23 @ jump to ram
24 ldr r1, =on_the_ram
25 add pc, r1, #0
26 nop
27 nop
28 1: b 1b @ infinite loop
29 on_the_ram:
30 #endif
31 @ get read to call C functions
32 ldr sp, DW_STACK_START @ setup stack pointer
33 mov fp, #0 @ no previous frame, so fp=0
34 mov a2, #0 @ set argv to NULL
35 bl main @ call main
36 mov pc, #FLASH_BASE @ otherwise, reboot
2~5都是使用b进行跳转,就是说对异常情况vivi能正常处理,但是在vivi的中还没发现有哪个驱动程序使用硬件中断。而在11也看到了vivi将硬件中断屏蔽掉,至于有没有在后面重新打开我没有进一步去求证。
7~18都是位置无关的,因为都没有对某个变量名、函数名进行绝对寻址,要注意的是CLK_CTL_BASE受雇一个直接数而不是一个变量名。
19、20、22都使用了一个bl进行相对跳转,跳到储存在本地的函数名中运行,这些函数的实现都放在了head.S文件中。但是这应该不是必须的,因为在copy_myself函数中就调用了一个C文件中的函数。下面分析一下这个copy_myself函数中重要的几个语句。
下面是从copy_myself截取出来的几个重要的语句:
1 @ get read to call C functions (for nand_read())
2 ldr sp, DW_STACK_START @ setup stack pointer
3 mov fp, #0 @ no previous frame, so fp=0
4
5 @ copy vivi to RAM
6 ldr r0, =VIVI_RAM_BASE
7 mov r1, #0x0
8 mov r2, #0x20000
9 bl nand_read_ll
上面已经说到,copy_myself将调用一个C语言函数nand_read_ll,C函数在运行之前必须设置好堆栈指针sp,1~3就是这样来的。
6~8是9中nand_read_ll函数的入口参数,分别代表了目标地址、源地址、复制的size,执行这个nand_read_ll以后vivi就玩玩整整地被复制一个副本到了VIVI_RAM_BASE开始的地方。为跳转到RAM中运行提供了前提条件。
说完了copy_myself函数继续回到之前的reset函数进行分析。23~25意图很明显,先是通过24将on_the_ram这个链接地址给r1,接着就将r1的值赋给pc从而跳转到这个地址上运行,当然也可以直接把on_the_ram赋给pc。这里用的指令是ldr,是一个绝对寻址指令,on_the_ram对应的链接地址被直接送进了r1,这一步已经是位置相关了,由于已经将vivi复制到RAM中的运行域所以这时on_the_ram对应的链接地址上已经真的放着相应的代码,所以这样执行是不会出任何问题的。
之后,32语句被执行,但是这个语句已经是在RAM中,和上一条语句的位置已经有天壤之别。这句就是设置堆栈指针sp以便35调用C语言函数main,但是在copy_myself中不是已经设置了吗?我也觉得在这里应该不需要再设置一次也能使程序正常运行。
35使用bl来相对寻址到main,这时的main也是在RAM中的那个,当然这里也可以使用绝对跳转指令。到了main后就进入了C语言环境了。
再返回上面提到的VIVI_RAM_BASE这个数值来展开讨论。Mini2440提供的vivi中,这个数值在vivi/include/platform/smdk440.h中定义,VIVI_RAM_BASE=0x33f00000。这个地址按道理应该和vivi的链接地址是一致的,那么到底是不是呢?查看链接文本vivi/arch/vivi.lds.in文件找到TEXTADDR,这个值在vivi/arch/makefile中相应地也定义为0x33f00000,因此是符合之前的猜测的。
说到这里本来就可以结束了,但是由于在vivi的main函数里面使用了mmu,因此情况一下子变得复杂起来。首先为什么vivi要打开MMU呢?在uboot里面这个一直是关闭的。原因也是比较简单的,就是追求系统运行的高效。因为s3c2410的Icache不受MMU的影响,而Dcache和write buffer则必须开启了MMU功能之后,才能使用。而使用Dcache和write buffer后,对系统运行速度的提高是非常明显的,后面还将通过实验来验证这一点。也就是说,在nand flash启动时,vivi使用了MMU,主要是为了获得Dcache和write buffer的使用权,借此提高系统运行的性能。(在《vivi开发笔记: MMU分析》一文中有关于这点的说明)。
接下来需要讨论一下mmu被开启后的代码运行情况。
在vivi/init/main.c的main函数中截取以下语句:
mem_map_init();
mmu_init();
第一句实际上是建立一个内存映射表,对于nand启动的内存映射完全是线性映射,就是将虚拟地址的0~4G映射为物理地址的0~4G,虚拟地址等于物理地址,实现语句如下:
static inline void mem_mapping_linear(void)
{
unsigned long pageoffset, sectionNumber;
for (sectionNumber = 0; sectionNumber < 4096; sectionNumber++)
{
pageoffset = (sectionNumber << 20);
*(mmu_tlb_base + (pageoffset >> 20)) = pageoffset | MMU_SECDESC;
}
for (pageoffset = DRAM_BASE; pageoffset < (DRAM_BASE+DRAM_SIZE); pageoffset += SZ_1M)
{
*(mmu_tlb_base + (pageoffset >> 20)) = pageoffset | MMU_SECDESC | MMU_CACHEABLE;
}
}
对于norflash则是先将norflash的物理地址映射到一个空闲的虚拟地址,把norflash原先占用的0开始的虚拟地址空间让出来;接着,将虚拟地址为0开始的1M空间映射到DRAM对应的物理地址上。这样的结果就是,虚拟地址为0开始的1M空间被映射到DRAM的物理地址,同时与DRAM物理地址相同的虚拟地址也映射到DRAM的物理地址上;物理地址为0开始的空间被映射到另一端空闲的虚拟地址空间;发生中断、寻址的时候CPU用的都是虚拟地址,CPU把虚拟地址发给MMU,由MMU通过映射表得到相应的虚拟地址并对物理地址进行寻址。在CPU地址总线上出现的就是物理地址。具体的实现语句这里不打算贴出来,可以看看源代码。
回到main函数中的mmu_init(),这个函数主要是使能MMU,并将上一步建立好的映射表地址告诉MMU,这样MMU就能使用已经建立好的映射表来进行内存映射。这个函数都是一些汇编指令,具体功能没有一条条语句去分许。
由上面的分析还可以得到一些额外的结论。中2410/2440在nand方式启动下,物理地址0开始的4K空间被映射为内部的4K SRAM,接着nand开始的4K代码(实际上vivi的start)就被复制到这个4K SRAM中开始运行,并在4K代码结束前就把自身复制到DRAM中并跳转到DRAM运行,发生异常的时候就跳转到SRAM中的异常入口表中执行;而vivi的中断跳转命令都用的是b,因此都是跳转到SRAM本地的相应处理例程。如果是以nor启动,那么物理地址0开始的地方映射在norflash,发生异常的时候都跳转到norflash中运行。还有一种情况就是上面所说的把物理地址0映射到了DRAM,这样在发生异常的情况的时候实际就跳转到DRAM的地址中运行。前2种情况对与uboot也是一样的,但是由于uboot没有启用MMU因此没有第三种情况。
Vivi启动内核的过程:
1、 把内核复制到合适的地址上。一般都是将linux内核从flash中复制到DRAM,具体将内核从哪个地址复制到哪个地址都是自定义的。
2、 设置传递给linux的启动参数。Bootloader在执行过程中必须设置和初始化 Linux 的内核启动参数。目前传递启动参数主要采用两种方式:即通过 struct param_struct 和struct tag(标记列表,tagged list)两种结构传递。struct param_struct 是一种比较老的参数传递方式,在 2.4 版本以前的内核中使用较多。从 2.4 版本以后 Linux 内核基本上采用标记列表的方式。但为了保持和以前版本的兼容性,它仍支持 struct param_struct 参数传递方式,只不过在内核启动过程中它将被转换成标记列表方式。
标记列表方式是种比较新的参数传递方式,它必须以 ATAG_CORE 开始,并以ATAG_NONE 结尾。中间可以根据需要加入其他列表。Linux内核在启动过程中会根据该启动参数进行相应的初始化工作。(参考《ARM Linux启动过程分析》一文)。Vivi中使用的就是param_struct方式,先是创建一个param_struct结构并进行填充,主要是填充以下几个域:
params->u1.s.page_size = LINUX_PAGE_SIZE;
params->u1.s.nr_pages = (DRAM_SIZE >> LINUX_PAGE_SHIFT);
memcpy(params->commandline, linux_cmd, strlen(linux_cmd) + 1);
第一个是指定linux内核的分页大小,第二个指定DRAM总共有多少个页。第三个就是指定命令行参数。填充完之后就将这个结构的内容复制到一个特定的地址上,这个地址在vivi中定义为param_base=DRAM+0x100。
3、关闭cache,禁止mmu,设置r0=0,r1=处理器类型,r2=内核在RAM中的地址,这个地址实际上就是bootloader复制内核时使用的那个地址。直接就使用mov pc, r2或者类似的指令将r2的值赋给pc,CPU就转到了linux内核中运行。
Linux部分:
Bootloader跳转到内核运行的入口点在linux/arch/arm/boot/compressed/Head.S文件中的start函数。怎么知道这里是内核的入口点呢?
首先需要了解linux内核的产生过程。首先是通过ld命令将编译好的各个.o文件链接成为linux/vmlinux可执行文件,同时产生system.map文件,这是一个非压缩的可执行文件,链接脚本为linux/arch/arm/kernel/vmlinux.lds.S,链接地址为TEXTADDR=0xC0008000,可以称之为真正的linux内核;接着通过objcopy工具将vmlinux复制为linux/arch/arm /boot/image,这时大小有变化,估计是格式已经发生了变化吧^_^;接下来在通过linux/arch/arm/boot/compressed/
makefile将image复制到本目录下并压缩成为piggy.gz,体积大大减少,这个是压缩后的内核;通过linux/arch/arm/boot/compressed/piggy.S文件将piggy.gz转换为数据段;通过linux/
arch/arm/boot/compressed下的makefile、vmlinux.lds.in将piggy.o、head.o、misc.o链接成vmlinux。Head.o、misc.o是什么呢?这是为了使用压缩内核而设计的一段解压缩代码,因为压缩内核没办法直接运行,只能解压后运行,所有在内核运转起来前必须先有一段代码将这个内核解压缩,这就是head.o、misc.o的作用了。在链接的时候piggy.o作为一个数据段链接到内核映像中,而不是作为一个程序的目标文件进行链接,head.o、misc.o则视为一般的目标文件进行链接,链接地址从0x00000000开始,这个链接后的vmlinux就是一个加上压缩代码后的压缩后内核;链接完vmlinux后就将这个文件使用objcopy转换为zImage等我们熟知的映像文件。
从上面的分析可知bootloader转移到内核运行的时候第一个运行的实际上还不是真内核的内容,而只是内核前面的那段解压缩代码,由linux/arch/arm/boot/compressed/vmlinux.lds.in的内容可知head.S中的start函数就是bootloader转到内核映像时第一个要被执行的函数。这部分代码是链接在0x00000000这个地方的(注意解压缩代码运行期间一直没有打开mmu),但是实际上却被复制在DRAM上运行,因此这部分代码必须是位置无关的。事实上通过查看这部分代码可以发现的确是这样的,在调用函数的时候也是通过b、bl等指令而不是一些绝对寻址指令。那么到底到什么时候PIC代码才结束呢?答案是,压缩代码解压完毕并跳转到真正内核入口运行,并在执行完一些初始化的工作后打开mmu,这时候才是PIC代码结束的时候。那为什么是这样呢?上面已经说到,内核是从0xC0008000开始链接的,但是代码实际上是放在0x30008000的地方,0xC0008000这段地址在s3c2410中又是保留的地址,不是实际的RAM,因此没有办法使用像uboot、vivi那样的重定位方式来解决运行域与加载域不一致的矛盾,只能通过虚拟内存映射的方法,将物理上的0x30008000映射为虚拟的0xC0008000,这样运行域就与加载域一致了。因此在使用mmu之前的代码必须是位置无关的,否则代码将无法运行。
这里还有一个细节需要提到一下,就是在查看system.map的时候会发现内核映像并不是从0xC0008000开始,而是从0xC0004000开始,那么是不是说链接地址应该是0xC0004000呢?不是的,0xC0004000开始的16K空间放在一个叫做初始化页表的东西,这个东西是在链接的时候静态添加到链接地址之前的16K开始的地方去的,实际上的链接地址就是0xC0008000。这个值可以在linux/arch/arm/mach-s3c2410/Makefile.boot中找到。
对于linux部分并没有对代码一句句分析,客观上是因为还有很多事情做,只能写这么多了,主观上,linux的开始的那些汇编代码好难懂=_=|||.所以就到此为止了。