bootloader與linux中位置無關(guān)代碼（PIC）的分析理解

fg8181

首先，需要理解加載域與運(yùn)行域的概念。加載域是代碼存放的地址，運(yùn)行域是代碼運(yùn)行時(shí)的地址。為什么會(huì)產(chǎn)生這2個(gè)概念？這2個(gè)概念的實(shí)質(zhì)意義又是什么呢？
在一些場合，一些代碼并不在儲(chǔ)存這部分代碼的地址上執(zhí)行地址，比如說，放在norflash中的代碼可能最終是放在RAM中運(yùn)行，那么中norflash中的地址就是加載域，而在RAM中的地址就是運(yùn)行域。
在匯編代碼中我們常常會(huì)看到一些跳轉(zhuǎn)指令，比如說b、bl等，這些指令后面是一個(gè)相對(duì)地址而不是絕對(duì)地址，比如說b main，這個(gè)指令應(yīng)該怎么理解呢？main這里究竟是一個(gè)什么東西呢？這時(shí)候就需要涉及到鏈接地址的概念了，鏈接地址實(shí)際上就是鏈接器對(duì)代碼中的變量名、函數(shù)名等東西進(jìn)行一個(gè)地址的編排，賦予這些抽象的東西一個(gè)地址，然后在程序中訪問這些變量名、函數(shù)名就是在訪問一些地址。一般所說的鏈接地址都是指鏈接這些代碼的起始地址，代碼必須放在這個(gè)地址開始的地方才可以正常運(yùn)行，否則的話當(dāng)代碼去訪問、執(zhí)行某個(gè)變量名、函數(shù)名對(duì)應(yīng)地址上的代碼時(shí)就會(huì)找不到，接著程序無疑就是跑飛。但是上面說的那個(gè)b main的情形有點(diǎn)特殊，b、bl等跳轉(zhuǎn)指令并不是一個(gè)絕對(duì)跳轉(zhuǎn)指令，而是一個(gè)相對(duì)跳轉(zhuǎn)指令，什么意思呢？就是說，這個(gè)main標(biāo)簽最后得到的只并不是main被鏈接器編排后的絕對(duì)地址，而是main的絕對(duì)地址減去當(dāng)前的這個(gè)指令的絕對(duì)地址所得到的值，也就是說b、bl訪問到的是一個(gè)相對(duì)地址，不是絕對(duì)地址，因此，包括這個(gè)語句和main在內(nèi)的代碼段無論是否放在它的運(yùn)行域這段代碼都能正常運(yùn)行。這就是所謂的位置無關(guān)代碼。
由上面的論述可以得知，如果你的這段代碼需要實(shí)現(xiàn)位置無關(guān)，那么你就不能使用絕對(duì)尋址指令，否則的話就是位置有關(guān)了。

接著，將結(jié)合uboot、vivi、linux中的PIC（position independent code）代碼進(jìn)行分析。
另外需要指出的是本文的分析基于mini2440的板子及配套代碼，對(duì)于其他板子或者源代碼代碼或者會(huì)有差別。

一.Uboot部分：

在\u-boot-1.1.2\cpu\arm920t\start.S截取部分相關(guān)代碼如下：
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
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
20  add r2, r0, r2      /* r2
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

假設(shè)（其實(shí)不是假設(shè)，一般都是）這段代碼當(dāng)前是在起始地址為0的norflash中儲(chǔ)存，上電復(fù)位后CPU首先跳轉(zhuǎn)到2運(yùn)行，這句使用的是一個(gè)相對(duì)跳轉(zhuǎn)指令b，這個(gè)指令將跳轉(zhuǎn)到本地儲(chǔ)存的reset例程中運(yùn)行。接下來的所有語句中都沒有通過絕對(duì)尋址來尋找某個(gè)變量或者函數(shù)，因此即使目前的加載域與運(yùn)行域不一致也沒有問題，因?yàn)檫\(yùn)行域主要是設(shè)計(jì)絕對(duì)尋址的正確性，如果沒有進(jìn)行絕對(duì)尋址，不一致又能奈他何？
這里其實(shí)還有個(gè)細(xì)節(jié)需要點(diǎn)出，就是3~6這幾句異常處理都是使用ldr進(jìn)行絕對(duì)跳轉(zhuǎn)的，因此使用的undefined_instruction等都是這些名稱對(duì)應(yīng)的鏈接地址，但是由下面的分析可知，這幾個(gè)中斷處理函數(shù)可能根本沒有被復(fù)制到RAM中（（uboot只是把第一個(gè)C語言開始的代碼復(fù)制到RAM，但是這個(gè)結(jié)論尚未通過反匯編來驗(yàn)證），也就是這些函數(shù)沒有被加載到運(yùn)行域所以一旦發(fā)生reset以外的異常情況（比如說硬件中斷）程序就會(huì)跑飛，由此也可以得到另一個(gè)結(jié)論：uboot不支持中斷（至少當(dāng)前分析的這個(gè)版本1.1.2是這樣的，其他版本可能不一樣）。
       下一個(gè)重點(diǎn)是12開始的這段重定位代碼，13中使用了一個(gè)很特別的指令adr， adr r0, _start 作用是獲得 _start 的實(shí)際運(yùn)行所在的地址值，其中adr r0, _start翻譯成 add r0,(PC+#offset)，offset 就是 adr r0, _start 指令到_start 的偏移量，值為負(fù)數(shù)，在鏈接時(shí)確定，這個(gè)偏移量是地址無關(guān)的，而pc為當(dāng)前指令的地址的下一個(gè)地址值，由于CPU復(fù)位后pc的值從0開始增加，因此到這這里的值剛剛好能將offset抵消，所以最后r0的值就是0。
對(duì)于14，ldr r1, _TEXT_BASE 指令表示以程序相對(duì)偏移的方式加載數(shù)據(jù)，是索引偏移加載的另外一種形式，等同于ldr r1,[PC+#offset]，offset 是 ldr r1, _TEXT_BASE 到 _TEXT_BASE 的偏移量, 因此最后r1得到的值就是TEXT_BASE，這個(gè)值在其他文件中已經(jīng)定義（比如對(duì)smdk2410平臺(tái)而言就是在~/board/smdk2410/config.mk文件中）
15的就是比較上面的r0、r1是否相等，如果相等那么證明程序現(xiàn)在的位置正是想要去的運(yùn)行域，因此不需要做重定位就可以通過16語句跳轉(zhuǎn)stack_setup，否則就需要繼續(xù)執(zhí)行17開始的代碼做重定位。17是將start_armboot這個(gè)地址給r2，start_armboot是誰？就是uboot的第一個(gè)C語言函數(shù)，這個(gè)函數(shù)名在鏈接的時(shí)候已經(jīng)被安排為某個(gè)地址，也就是運(yùn)行域。18是將bss_start這個(gè)值付給r3，那bss_start又是誰呢？說到這里先看看u-boot\board\smdk2410下的u-boot.lds鏈接文本的內(nèi)容：
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 }
鏈接文本是鏈接器用來鏈接可執(zhí)行文件所使用的腳本文件，鏈接器根據(jù)這個(gè)來決定編譯器編譯出來的一大堆.o文件如何組織成為一個(gè)可執(zhí)行文件。其中ENTRY(_start)指定了這個(gè)可執(zhí)行文件的入口點(diǎn)（或者通俗點(diǎn)說第一個(gè)執(zhí)行的函數(shù)）。SECTIONS描述了代碼在內(nèi)存中的布局情況，4指定了內(nèi)存的分布從0開始，但是實(shí)際上在uboot鏈接過程中使用了一個(gè)-Ttext選項(xiàng)，這個(gè)選項(xiàng)最后就替代了0而將.text的鏈接地址修改為0x33f80000，這個(gè)鏈接命令如下：
arm-linux-ld –Tu-boot-1.1.4\board\smdk2410\u-boot.lds –Ttext 0x33f80000
因此這個(gè)鏈接腳本實(shí)際上并不是最終的內(nèi)存布局。另外需要額外說明的是，這個(gè)鏈接地址是一個(gè)虛擬地址，如果mmu沒有打開的話（對(duì)于uboot就是這種情況，mmu一直都是處于關(guān)閉狀態(tài)）那么這個(gè)虛地址就是物理地址。在linux中，對(duì)于ARM平臺(tái)內(nèi)核一般從0xC0004000開始鏈接，這個(gè)地址明顯就是虛擬地址，在2410中一般把內(nèi)核解壓在0x30008000這個(gè)物理地址上，所以在內(nèi)核打開mmu之前的代碼必須是位置無關(guān)的，否則沒有辦法啟動(dòng)內(nèi)核；在打開mmu后，可以使用mmu將0x30000000開始的64M的物理空間映射為0xC0000000開始的64M虛擬空間。
說了這么多的題外話后回到之前的話題，bss_start就是在鏈接腳本中指出的一個(gè)符號(hào)，用以得到一個(gè)地址給外部的程序使用，這個(gè)地址實(shí)際上就是uboot鏈接后的最高地址，后面的bss雖然也還是uboot可執(zhí)行文件的范疇，但是這個(gè)段在鏈接的時(shí)候并不分配任何內(nèi)存空間，因此可以認(rèn)為可執(zhí)行文件到bss_start就結(jié)束了。由此可以理解\u-boot-1.1.2\cpu\arm920t\start.S的17、18實(shí)際上是分別得到了uboot的第一個(gè)C語言函數(shù)地址和這個(gè)可執(zhí)行文件的最后一個(gè)鏈接地址，之前運(yùn)行的那段位置無關(guān)的匯編代碼直接被忽略。
22~26這段就是實(shí)現(xiàn)將uboot從norflash復(fù)制到RAM，地址為TEXT_BASE。
29~36是設(shè)置堆�？臻g和sp指針的值，為執(zhí)行C語言程序做準(zhǔn)備。
37是重點(diǎn)，作用是跳轉(zhuǎn)到C語言的入口點(diǎn)start_armboot函數(shù)。
ldr   pc, _start_armboot
這個(gè)語句使用的是ldr指令，這是一個(gè)絕對(duì)尋址指令，將start_armboot這個(gè)絕對(duì)地址加載到pc寄存器中，從而CPU轉(zhuǎn)到start_armboot這個(gè)地址上開始運(yùn)行，實(shí)現(xiàn)了從flash到RAM的跳轉(zhuǎn)。

Uboot啟動(dòng)內(nèi)核的過程：
1、  uboot對(duì)需要啟動(dòng)的映像文件有一定的格式要求，對(duì)于一個(gè)需要使用uboot引導(dǎo)的映像文件需要先使用uboot自帶的mkimage工具對(duì)這個(gè)映像進(jìn)行修改，添加結(jié)構(gòu)為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)個(gè)字節(jié)。為什么要增加一個(gè)這樣的頭部呢？關(guān)于這個(gè)文件頭還是很有研究分量的，但是由于這里并不把這個(gè)作為重點(diǎn)，因此把這部分的分析寫在了另一篇文章《uboot中關(guān)于mkimage指令的矛盾分析.doc》中。這里僅僅強(qiáng)調(diào)一下addr、ep這2個(gè)參數(shù)，前者是映像的下載地址，就是把這個(gè)映像復(fù)制到哪里（不包括上面說到的那個(gè)文件頭，這部分在復(fù)制的時(shí)候被跳過），后者就是內(nèi)核的入口，uboot就是從這點(diǎn)來找到并啟動(dòng)內(nèi)核的。
2、按照文件頭的參數(shù)將映像從flash或者RAM的其他位置復(fù)制到addr這里，其中文件頭被直接忽略。如果是使用mkimage的時(shí)候使用了壓縮選項(xiàng)那么就不是單純的復(fù)制，而是解壓到這個(gè)addr。
3、設(shè)置啟動(dòng)參數(shù)表。與vivi不一樣，uboot對(duì)向內(nèi)核傳遞參數(shù)時(shí)使用的是struct tag（標(biāo)記列表，tagged list）方式。設(shè)置方式大概遵循如下步驟：
       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是標(biāo)記列表的開始，這個(gè)設(shè)置選項(xiàng)主要是指定這個(gè)啟動(dòng)參數(shù)表的存放位置，比如說一般會(huì)指定在SDRAM_BASE+0x100這個(gè)地方。2是設(shè)置內(nèi)存標(biāo)記，告訴內(nèi)核這個(gè)硬件平臺(tái)的RAM有多大、起始地址是多少等。3是設(shè)置命令行參數(shù)。4是設(shè)置initrd標(biāo)記，如果并不使用initrd的話那么這個(gè)設(shè)置是不需要的。
4、關(guān)閉cache，禁止mmu，禁止中斷，調(diào)用kernel函數(shù)跳轉(zhuǎn)到內(nèi)核，thekernel函數(shù)是如何定義的呢？這個(gè)過程是怎么實(shí)現(xiàn)的呢？
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函數(shù)（這是啟動(dòng)內(nèi)核時(shí)調(diào)用的最后一個(gè)函數(shù)）的的幾個(gè)相關(guān)語句，1是定義一個(gè)函數(shù)指針，2是把這個(gè)指針指向?qū)嶋H執(zhí)行的函數(shù)地址，這個(gè)地址是誰呢？就是上面第一點(diǎn)說到的那個(gè)ep，就是內(nèi)核的入口地址，或者說內(nèi)核的第一個(gè)語句，這里還使用了(void (*)(int, int, uint))將這個(gè)地址強(qiáng)制轉(zhuǎn)換為有3個(gè)參數(shù)的函數(shù)，為什么要這樣做呢？因?yàn)樵谔�轉(zhuǎn)到內(nèi)核前需要設(shè)置好r0、r1、r2這3個(gè)寄存器的值，而在一般的C函數(shù)調(diào)用過程中，入口參數(shù)就是使用r0、r1、r2.。。。。。。。等來傳遞的，換言之，在3語句中調(diào)用theKernel函數(shù)時(shí)提供的3個(gè)入口參數(shù)最后將分別傳給r0、r1、r2，這樣就非常巧妙地通過C語言的特性來實(shí)現(xiàn)了r0、r1、r2的設(shè)置。
       其中值得一提的是，r2的值在vivi中是設(shè)置為內(nèi)核在RAM中的地址，但是在uboot中是設(shè)置為了uboot傳遞給linux的啟動(dòng)參數(shù)表在RAM中的位置。究竟誰是對(duì)的呢？從邏輯上看，vivi向內(nèi)核傳遞內(nèi)核所在的地址沒有意義，因?yàn)閮?nèi)核要這個(gè)沒用，但是內(nèi)核需要啟動(dòng)參數(shù)表，因此設(shè)置這個(gè)參數(shù)表的位置有意義，由此可以認(rèn)定vivi那樣做是不對(duì)的。再者，vivi如果要將參數(shù)正確傳遞給linux，必須事先知道linux默認(rèn)會(huì)去哪里找啟動(dòng)參數(shù)表，然后在這個(gè)位置上填好這個(gè)參數(shù)表，否則如果隨便找個(gè)地方放這個(gè)表linux是沒有辦法找到的，這樣的話內(nèi)核將啟動(dòng)失敗。

另外需要再次強(qiáng)調(diào)的是，uboot沒有打開mmu，因此一直使用的地址都是直接對(duì)應(yīng)在物理地址上，但是vivi為了實(shí)現(xiàn)更好的性能打開了cache和mmu，因此情況就相當(dāng)不一樣了，下面將說明vivi的情況。

二.Vivi部分：

Vivi的入口點(diǎn)在vivi\arch\s3c2440\head.S的start，在這個(gè)文件中截取部分相關(guān)代碼進(jìn)行分析：
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進(jìn)行跳轉(zhuǎn)，就是說對(duì)異常情況vivi能正常處理，但是在vivi的中還沒發(fā)現(xiàn)有哪個(gè)驅(qū)動(dòng)程序使用硬件中斷。而在11也看到了vivi將硬件中斷屏蔽掉，至于有沒有在后面重新打開我沒有進(jìn)一步去求證。
7~18都是位置無關(guān)的，因?yàn)槎紱]有對(duì)某個(gè)變量名、函數(shù)名進(jìn)行絕對(duì)尋址，要注意的是CLK_CTL_BASE受雇一個(gè)直接數(shù)而不是一個(gè)變量名。
19、20、22都使用了一個(gè)bl進(jìn)行相對(duì)跳轉(zhuǎn)，跳到儲(chǔ)存在本地的函數(shù)名中運(yùn)行，這些函數(shù)的實(shí)現(xiàn)都放在了head.S文件中。但是這應(yīng)該不是必須的，因?yàn)樵赾opy_myself函數(shù)中就調(diào)用了一個(gè)C文件中的函數(shù)。下面分析一下這個(gè)copy_myself函數(shù)中重要的幾個(gè)語句。
    下面是從copy_myself截取出來的幾個(gè)重要的語句：
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
上面已經(jīng)說到，copy_myself將調(diào)用一個(gè)C語言函數(shù)nand_read_ll，C函數(shù)在運(yùn)行之前必須設(shè)置好堆棧指針sp，1~3就是這樣來的。
6~8是9中nand_read_ll函數(shù)的入口參數(shù)，分別代表了目標(biāo)地址、源地址、復(fù)制的size，執(zhí)行這個(gè)nand_read_ll以后vivi就玩玩整整地被復(fù)制一個(gè)副本到了VIVI_RAM_BASE開始的地方。為跳轉(zhuǎn)到RAM中運(yùn)行提供了前提條件。
說完了copy_myself函數(shù)繼續(xù)回到之前的reset函數(shù)進(jìn)行分析。23~25意圖很明顯，先是通過24將on_the_ram這個(gè)鏈接地址給r1，接著就將r1的值賦給pc從而跳轉(zhuǎn)到這個(gè)地址上運(yùn)行，當(dāng)然也可以直接把on_the_ram賦給pc。這里用的指令是ldr，是一個(gè)絕對(duì)尋址指令，on_the_ram對(duì)應(yīng)的鏈接地址被直接送進(jìn)了r1，這一步已經(jīng)是位置相關(guān)了，由于已經(jīng)將vivi復(fù)制到RAM中的運(yùn)行域所以這時(shí)on_the_ram對(duì)應(yīng)的鏈接地址上已經(jīng)真的放著相應(yīng)的代碼，所以這樣執(zhí)行是不會(huì)出任何問題的。
之后，32語句被執(zhí)行，但是這個(gè)語句已經(jīng)是在RAM中，和上一條語句的位置已經(jīng)有天壤之別。這句就是設(shè)置堆棧指針sp以便35調(diào)用C語言函數(shù)main，但是在copy_myself中不是已經(jīng)設(shè)置了嗎？我也覺得在這里應(yīng)該不需要再設(shè)置一次也能使程序正常運(yùn)行。
35使用bl來相對(duì)尋址到main，這時(shí)的main也是在RAM中的那個(gè)，當(dāng)然這里也可以使用絕對(duì)跳轉(zhuǎn)指令。到了main后就進(jìn)入了C語言環(huán)境了。
再返回上面提到的VIVI_RAM_BASE這個(gè)數(shù)值來展開討論。Mini2440提供的vivi中，這個(gè)數(shù)值在vivi\include\platform\smdk440.h中定義，VIVI_RAM_BASE=0x33f00000。這個(gè)地址按道理應(yīng)該和vivi的鏈接地址是一致的，那么到底是不是呢？查看鏈接文本vivi\arch\vivi.lds.in文件找到TEXTADDR，這個(gè)值在vivi\arch\makefile中相應(yīng)地也定義為0x33f00000，因此是符合之前的猜測的。
說到這里本來就可以結(jié)束了，但是由于在vivi的main函數(shù)里面使用了mmu，因此情況一下子變得復(fù)雜起來。首先為什么vivi要打開MMU呢？在uboot里面這個(gè)一直是關(guān)閉的。原因也是比較簡單的，就是追求系統(tǒng)運(yùn)行的高效。因?yàn)閟3c2410的Icache不受MMU的影響，而Dcache和write buffer則必須開啟了MMU功能之后，才能使用。而使用Dcache和write buffer后，對(duì)系統(tǒng)運(yùn)行速度的提高是非常明顯的，后面還將通過實(shí)驗(yàn)來驗(yàn)證這一點(diǎn)。也就是說，在nand flash啟動(dòng)時(shí)，vivi使用了MMU，主要是為了獲得Dcache和write buffer的使用權(quán)，借此提高系統(tǒng)運(yùn)行的性能。（在《vivi開發(fā)筆記: MMU分析》一文中有關(guān)于這點(diǎn)的說明）。
接下來需要討論一下mmu被開啟后的代碼運(yùn)行情況。
在vivi\init\main.c的main函數(shù)中截取以下語句：
    mem_map_init();
    mmu_init();
第一句實(shí)際上是建立一個(gè)內(nèi)存映射表，對(duì)于nand啟動(dòng)的內(nèi)存映射完全是線性映射，就是將虛擬地址的0~4G映射為物理地址的0~4G，虛擬地址等于物理地址，實(shí)現(xiàn)語句如下：
static inline void mem_mapping_linear(void)
{
    unsigned long pageoffset, sectionNumber;
    for (sectionNumber = 0; sectionNumber
    {
        pageoffset = (sectionNumber
        *(mmu_tlb_base + (pageoffset >> 20)) = pageoffset | MMU_SECDESC;
    }
    for (pageoffset = DRAM_BASE; pageoffset
{
        *(mmu_tlb_base + (pageoffset >> 20)) = pageoffset | MMU_SECDESC | MMU_CACHEABLE;
}
}
    對(duì)于norflash則是先將norflash的物理地址映射到一個(gè)空閑的虛擬地址，把norflash原先占用的0開始的虛擬地址空間讓出來；接著，將虛擬地址為0開始的1M空間映射到DRAM對(duì)應(yīng)的物理地址上。這樣的結(jié)果就是，虛擬地址為0開始的1M空間被映射到DRAM的物理地址，同時(shí)與DRAM物理地址相同的虛擬地址也映射到DRAM的物理地址上；物理地址為0開始的空間被映射到另一端空閑的虛擬地址空間；發(fā)生中斷、尋址的時(shí)候CPU用的都是虛擬地址，CPU把虛擬地址發(fā)給MMU，由MMU通過映射表得到相應(yīng)的虛擬地址并對(duì)物理地址進(jìn)行尋址。在CPU地址總線上出現(xiàn)的就是物理地址。具體的實(shí)現(xiàn)語句這里不打算貼出來，可以看看源代碼。
回到main函數(shù)中的mmu_init()，這個(gè)函數(shù)主要是使能MMU，并將上一步建立好的映射表地址告訴MMU，這樣MMU就能使用已經(jīng)建立好的映射表來進(jìn)行內(nèi)存映射。這個(gè)函數(shù)都是一些匯編指令，具體功能沒有一條條語句去分許。
    由上面的分析還可以得到一些額外的結(jié)論。中2410/2440在nand方式啟動(dòng)下，物理地址0開始的4K空間被映射為內(nèi)部的4K SRAM，接著nand開始的4K代碼（實(shí)際上vivi的start）就被復(fù)制到這個(gè)4K SRAM中開始運(yùn)行，并在4K代碼結(jié)束前就把自身復(fù)制到DRAM中并跳轉(zhuǎn)到DRAM運(yùn)行，發(fā)生異常的時(shí)候就跳轉(zhuǎn)到SRAM中的異常入口表中執(zhí)行；而vivi的中斷跳轉(zhuǎn)命令都用的是b，因此都是跳轉(zhuǎn)到SRAM本地的相應(yīng)處理例程。如果是以nor啟動(dòng)，那么物理地址0開始的地方映射在norflash，發(fā)生異常的時(shí)候都跳轉(zhuǎn)到norflash中運(yùn)行。還有一種情況就是上面所說的把物理地址0映射到了DRAM，這樣在發(fā)生異常的情況的時(shí)候?qū)嶋H就跳轉(zhuǎn)到DRAM的地址中運(yùn)行。前2種情況對(duì)與uboot也是一樣的，但是由于uboot沒有啟用MMU因此沒有第三種情況。
      
三. Vivi啟動(dòng)內(nèi)核的過程：
1、    把內(nèi)核復(fù)制到合適的地址上。一般都是將linux內(nèi)核從flash中復(fù)制到DRAM，具體將內(nèi)核從哪個(gè)地址復(fù)制到哪個(gè)地址都是自定義的。
2、    設(shè)置傳遞給linux的啟動(dòng)參數(shù)。Bootloader在執(zhí)行過程中必須設(shè)置和初始化 Linux 的內(nèi)核啟動(dòng)參數(shù)。目前傳遞啟動(dòng)參數(shù)主要采用兩種方式：即通過 struct param_struct 和struct tag（標(biāo)記列表，tagged list）兩種結(jié)構(gòu)傳遞。struct param_struct 是一種比較老的參數(shù)傳遞方式，在 2.4 版本以前的內(nèi)核中使用較多。從 2.4 版本以后 Linux 內(nèi)核基本上采用標(biāo)記列表的方式。但為了保持和以前版本的兼容性，它仍支持 struct param_struct 參數(shù)傳遞方式，只不過在內(nèi)核啟動(dòng)過程中它將被轉(zhuǎn)換成標(biāo)記列表方式。
標(biāo)記列表方式是種比較新的參數(shù)傳遞方式，它必須以 ATAG_CORE 開始，并以ATAG_NONE 結(jié)尾。中間可以根據(jù)需要加入其他列表。Linux內(nèi)核在啟動(dòng)過程中會(huì)根據(jù)該啟動(dòng)參數(shù)進(jìn)行相應(yīng)的初始化工作。（參考《ARM Linux啟動(dòng)過程分析》一文）。Vivi中使用的就是param_struct方式，先是創(chuàng)建一個(gè)param_struct結(jié)構(gòu)并進(jìn)行填充，主要是填充以下幾個(gè)域：
    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);
第一個(gè)是指定linux內(nèi)核的分頁大小，第二個(gè)指定DRAM總共有多少個(gè)頁。第三個(gè)就是指定命令行參數(shù)。填充完之后就將這個(gè)結(jié)構(gòu)的內(nèi)容復(fù)制到一個(gè)特定的地址上，這個(gè)地址在vivi中定義為param_base=DRAM+0x100。
    3、關(guān)閉cache，禁止mmu，設(shè)置r0＝0，r1＝處理器類型，r2＝內(nèi)核在RAM中的地址，這個(gè)地址實(shí)際上就是bootloader復(fù)制內(nèi)核時(shí)使用的那個(gè)地址。直接就使用mov   pc, r2或者類似的指令將r2的值賦給pc，CPU就轉(zhuǎn)到了linux內(nèi)核中運(yùn)行。

四.Linux部分：

    Bootloader跳轉(zhuǎn)到內(nèi)核運(yùn)行的入口點(diǎn)在linux\arch\arm\boot\compressed\Head.S文件中的start函數(shù)。怎么知道這里是內(nèi)核的入口點(diǎn)呢？
首先需要了解linux內(nèi)核的產(chǎn)生過程。首先是通過ld命令將編譯好的各個(gè).o文件鏈接成為linux\vmlinux可執(zhí)行文件，同時(shí)產(chǎn)生system.map文件，這是一個(gè)非壓縮的可執(zhí)行文件，鏈接腳本為linux/arch/arm/kernel/vmlinux.lds.S,鏈接地址為TEXTADDR=0xC0008000，可以稱之為真正的linux內(nèi)核；接著通過objcopy工具將vmlinux復(fù)制為linux/arch/arm /boot/image，這時(shí)大小有變化，估計(jì)是格式已經(jīng)發(fā)生了變化吧^_^；接下來在通過linux/arch/arm/boot/compressed/
makefile將image復(fù)制到本目錄下并壓縮成為piggy.gz，體積大大減少，這個(gè)是壓縮后的內(nèi)核；通過linux/arch/arm/boot/compressed/piggy.S文件將piggy.gz轉(zhuǎn)換為數(shù)據(jù)段；通過linux/
arch/arm/boot/compressed下的makefile、vmlinux.lds.in將piggy.o、head.o、misc.o鏈接成vmlinux。Head.o、misc.o是什么呢？這是為了使用壓縮內(nèi)核而設(shè)計(jì)的一段解壓縮代碼，因?yàn)閴嚎s內(nèi)核沒辦法直接運(yùn)行，只能解壓后運(yùn)行，所有在內(nèi)核運(yùn)轉(zhuǎn)起來前必須先有一段代碼將這個(gè)內(nèi)核解壓縮，這就是head.o、misc.o的作用了。在鏈接的時(shí)候piggy.o作為一個(gè)數(shù)據(jù)段鏈接到內(nèi)核映像中，而不是作為一個(gè)程序的目標(biāo)文件進(jìn)行鏈接，head.o、misc.o則視為一般的目標(biāo)文件進(jìn)行鏈接，鏈接地址從0x00000000開始，這個(gè)鏈接后的vmlinux就是一個(gè)加上壓縮代碼后的壓縮后內(nèi)核；鏈接完vmlinux后就將這個(gè)文件使用objcopy轉(zhuǎn)換為zImage等我們熟知的映像文件。
    從上面的分析可知bootloader轉(zhuǎn)移到內(nèi)核運(yùn)行的時(shí)候第一個(gè)運(yùn)行的實(shí)際上還不是真內(nèi)核的內(nèi)容，而只是內(nèi)核前面的那段解壓縮代碼，由linux/arch/arm/boot/compressed/vmlinux.lds.in的內(nèi)容可知head.S中的start函數(shù)就是bootloader轉(zhuǎn)到內(nèi)核映像時(shí)第一個(gè)要被執(zhí)行的函數(shù)。這部分代碼是鏈接在0x00000000這個(gè)地方的（注意解壓縮代碼運(yùn)行期間一直沒有打開mmu），但是實(shí)際上卻被復(fù)制在DRAM上運(yùn)行，因此這部分代碼必須是位置無關(guān)的。事實(shí)上通過查看這部分代碼可以發(fā)現(xiàn)的確是這樣的，在調(diào)用函數(shù)的時(shí)候也是通過b、bl等指令而不是一些絕對(duì)尋址指令。那么到底到什么時(shí)候PIC代碼才結(jié)束呢？答案是，壓縮代碼解壓完畢并跳轉(zhuǎn)到真正內(nèi)核入口運(yùn)行，并在執(zhí)行完一些初始化的工作后打開mmu，這時(shí)候才是PIC代碼結(jié)束的時(shí)候。那為什么是這樣呢？上面已經(jīng)說到，內(nèi)核是從0xC0008000開始鏈接的，但是代碼實(shí)際上是放在0x30008000的地方，0xC0008000這段地址在s3c2410中又是保留的地址，不是實(shí)際的RAM，因此沒有辦法使用像uboot、vivi那樣的重定位方式來解決運(yùn)行域與加載域不一致的矛盾，只能通過虛擬內(nèi)存映射的方法，將物理上的0x30008000映射為虛擬的0xC0008000，這樣運(yùn)行域就與加載域一致了。因此在使用mmu之前的代碼必須是位置無關(guān)的，否則代碼將無法運(yùn)行。
    這里還有一個(gè)細(xì)節(jié)需要提到一下，就是在查看system.map的時(shí)候會(huì)發(fā)現(xiàn)內(nèi)核映像并不是從0xC0008000開始，而是從0xC0004000開始，那么是不是說鏈接地址應(yīng)該是0xC0004000呢？不是的，0xC0004000開始的16K空間放在一個(gè)叫做初始化頁表的東西，這個(gè)東西是在鏈接的時(shí)候靜態(tài)添加到鏈接地址之前的16K開始的地方去的，實(shí)際上的鏈接地址就是0xC0008000。這個(gè)值可以在linux/arch/arm/mach-s3c2410/Makefile.boot中找到。
    對(duì)于linux部分并沒有對(duì)代碼一句句分析，客觀上是因?yàn)檫�有很多事情做，只能寫這么多了，主觀上，linux的開始的那些匯編代碼好難懂=_=|||.所以就到此為止了。


本文來自ChinaUnix博客，如果查看原文請(qǐng)點(diǎn)：http://blog.chinaunix.net/u1/55352/showart_2007247.html