Android arm linux kernel啟動(dòng)流程一

在了解這些之前我們首先需要了解幾個(gè)名詞，這些名詞定義在/Documentation/arm/Porting里面，這里首先提到其中的幾個(gè)，其余幾個(gè)會(huì)在后面kernel的執(zhí)行過(guò)程中講述：

1）ZTEXTADDR boot.img運(yùn)行時(shí)候zImage的起始地址，即kernel解壓代碼的地址。這里沒(méi)有虛擬地址的概念，因?yàn)闆](méi)有開(kāi)啟MMU，所以這個(gè)地址是物理內(nèi)存的地址。解壓代碼不一定需要載入RAM才能運(yùn)行，在FLASH或者其他可尋址的媒體上都可以運(yùn)行。

2）ZBSSADDR 解壓代碼的BSS段的地址，這里也是物理地址。

3）ZRELADDR 這個(gè)是kernel解壓以后存放的內(nèi)存物理地址，解壓代碼執(zhí)行完成以后會(huì)跳到這個(gè)地址執(zhí)行kernel的啟動(dòng)，這個(gè)地址和后面kernel運(yùn)行時(shí)候的虛擬地址滿足：__virt_to_phys(TEXTADDR) = ZRELADDR。

4）INITRD_PHYS Initial Ram Disk存放在內(nèi)存中的物理地址，這里就是我們的ramdisk.img。

5）INITRD_VIRT Initial Ram Disk運(yùn)行時(shí)候虛擬地址。

6）PARAMS_PHYS 內(nèi)核啟動(dòng)的初始化參數(shù)在內(nèi)存上的物理地址。

下面我們首先來(lái)看看boot.img的構(gòu)造，了解其中的內(nèi)容對(duì)我們了解kernel的啟動(dòng)過(guò)程是很有幫助的。首先來(lái)看看Makefile是如何產(chǎn)生我們的boot.img的：

out/host/linux-x86/bin/mkbootimg-msm7627_ffa --kernel out/target/product/msm7627_ffa/kernel --ramdisk out/target/product/msm7627_ffa/ramdisk.img --cmdline "mem=203M console=ttyMSM2,115200n8 androidboot.hardware=qcom" --output out/target/product/msm7627_ffa/boot.img

根據(jù)上面的命令我們可以首先看看mkbootimg-msm7627ffa這個(gè)工具的源文件：system/core/mkbootimg.c?？赐曛笪覀兙湍芎芮逦乜吹絙oot.img的內(nèi)部構(gòu)造，它是由boot header /kernel /ramdisk /second stage構(gòu)成的，其中前3項(xiàng)是必須的，最后一項(xiàng)是可選的。

view plaincopy to clipboardprint?
/*
+-----------------+
| boot header | 1 page
+-----------------+
| kernel | n pages
+-----------------+
| ramdisk | m pages
+-----------------+
| second stage | o pages
+-----------------+

n = (kernel_size + page_size - 1) / page_size
m = (ramdisk_size + page_size - 1) / page_size
o = (second_size + page_size - 1) / page_size

0. all entities are page_size aligned in flash
1. kernel and ramdisk are required (size != 0)
2. second is optional (second_size == 0 -> no second)
3. load each element (kernel, ramdisk, second) at
the specified physical address (kernel_addr, etc)
4. prepare tags at tag_addr. kernel_args[] is
appended to the kernel commandline in the tags.
5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
6. if second_size != 0: jump to second_addr
else: jump to kernel_addr
*/
/*
+-----------------+
| boot header | 1 page
+-----------------+
| kernel | n pages
+-----------------+
| ramdisk | m pages
+-----------------+
| second stage | o pages
+-----------------+

n = (kernel_size + page_size - 1) / page_size
m = (ramdisk_size + page_size - 1) / page_size
o = (second_size + page_size - 1) / page_size

0. all entities are page_size aligned in flash
1. kernel and ramdisk are required (size != 0)
2. second is optional (second_size == 0 -> no second)
3. load each element (kernel, ramdisk, second) at
the specified physical address (kernel_addr, etc)
4. prepare tags at tag_addr. kernel_args[] is
appended to the kernel commandline in the tags.
5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
6. if second_size != 0: jump to second_addr
else: jump to kernel_addr
*/

關(guān)于boot header這個(gè)數(shù)據(jù)結(jié)構(gòu)我們需要重點(diǎn)注意，在這里我們關(guān)注其中幾個(gè)比較重要的值，這些值定義在boot/boardconfig.h里面，不同的芯片對(duì)應(yīng)vendor下不同的boardconfig，在這里我們的值分別是（分別是kernel/ramdis/tags載入ram的物理地址）：

view plaincopy to clipboardprint?
#define PHYSICAL_DRAM_BASE 0x00200000
#define KERNEL_ADDR (PHYSICAL_DRAM_BASE + 0x00008000)
#define RAMDISK_ADDR (PHYSICAL_DRAM_BASE + 0x01000000)
#define TAGS_ADDR (PHYSICAL_DRAM_BASE + 0x00000100)
#define NEWTAGS_ADDR (PHYSICAL_DRAM_BASE + 0x00004000)
#define PHYSICAL_DRAM_BASE 0x00200000
#define KERNEL_ADDR (PHYSICAL_DRAM_BASE + 0x00008000)
#define RAMDISK_ADDR (PHYSICAL_DRAM_BASE + 0x01000000)
#define TAGS_ADDR (PHYSICAL_DRAM_BASE + 0x00000100)
#define NEWTAGS_ADDR (PHYSICAL_DRAM_BASE + 0x00004000)

上面這些值分別和我們開(kāi)篇時(shí)候提到的那幾個(gè)名詞相對(duì)應(yīng)，比如kernel_addr就是ZTEXTADDR，RAMDISK_ADDR就是INITRD_PHYS,而TAGS_ADDR就是PARAMS_PHYS。bootloader會(huì)從boot.img的分區(qū)中將kernel和ramdisk分別讀入RAM上面定義的地址中，然后就會(huì)跳到ZTEXTADDR開(kāi)始執(zhí)行。

基本了解boot.img的內(nèi)容之后我們來(lái)分別看看里面的ramdisk.img和kernel又是如何產(chǎn)生的，以及其包含的內(nèi)容。從簡(jiǎn)單的說(shuō)起，我們先看看ramdisk.img，這里首先要強(qiáng)調(diào)一下這個(gè)ramdisk.img在arm linux中的作用。它在kernel啟動(dòng)過(guò)程中充當(dāng)著第一階段的文件系統(tǒng)，是一個(gè)CPIO格式打成的包。通俗上來(lái)講他就是我們將生成的root目錄，用CPIO方式進(jìn)行了打包，然后在kernel啟動(dòng)過(guò)程中會(huì)被mount作為文件系統(tǒng)，當(dāng)kernel啟動(dòng)完成以后會(huì)執(zhí)行init，然后將system.img再mount進(jìn)來(lái)作為Android的文件系統(tǒng)。在這里稍微解釋下這個(gè)mount的概念，所謂mount實(shí)際上就是告訴linux虛擬文件系統(tǒng)它的根目錄在哪，就是說(shuō)我這個(gè)虛擬文件系統(tǒng)需要操作的那塊區(qū)域在哪，比如說(shuō)ramdisk實(shí)際上是我們?cè)趦?nèi)存中的一塊區(qū)域，把它作為文件系統(tǒng)的意思實(shí)際上就是告訴虛擬文件系統(tǒng)你的根目錄就在我這里，我的起始地址賦給你，你以后就能對(duì)我進(jìn)行操作了。實(shí)際上我們也可以使用rom上的一塊區(qū)域作為根文件系統(tǒng)，但是rom相對(duì)ram慢，所以這里使用ramdisk。然后我們?cè)诎裺ystem.img mount到ramdisk的system目錄，實(shí)際上就是將system.img的地址給了虛擬文件系統(tǒng)，然后虛擬文件系統(tǒng)訪問(wèn)system目錄的時(shí)候會(huì)重新定位到對(duì)system.img的訪問(wèn)。我們可以看看makefile是如何生成它的：

out/host/linux-x86/bin/mkbootfs out/target/product/msm7627_ffa/root | out/host/linux-x86/bin/minigzip > out/target/product/msm7627_ffa/ramdisk.img

下面我們來(lái)看看kernel產(chǎn)生的過(guò)程，老方法，從Makefile開(kāi)始/arch/arm/boot/Makefile ～

view plaincopy to clipboardprint?
$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
@echo Kernel: $@ is ready
$(obj)/compressed/vmlinux: $(obj)/Image FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed $@
$(obj)/zImage: $(obj)/compressed/vmlinux FORCE
$(call if_changed,objcopy)
@echo Kernel: $@ is ready
$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
@echo Kernel: $@ is ready
$(obj)/compressed/vmlinux: $(obj)/Image FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed $@
$(obj)/zImage: $(obj)/compressed/vmlinux FORCE
$(call if_changed,objcopy)
@echo Kernel: $@ is ready

我們分解地來(lái)看各個(gè)步驟，第一個(gè)是將vmlinux經(jīng)過(guò)objcopy后生成一個(gè)未經(jīng)壓縮的raw binary(Image 4M左右)，這里的vmlinux是我們編譯鏈接以后生成的vmlinx，大概60多M。這里稍微說(shuō)一下這個(gè)objcopy，在啟動(dòng)的時(shí)候ELF格式是沒(méi)法執(zhí)行的，ELF格式的解析是在kernel啟動(dòng)以后有了操作系統(tǒng)之后才能進(jìn)行的。因?yàn)殡m然我們編出的img雖然被編成ELF格式，但要想啟動(dòng)起來(lái)必須將其轉(zhuǎn)化成原始的二進(jìn)制格式，我們可以多照著man objcopy和OBJCOPYFLAGS :=-O binary -R .note -R .note.gnu.build-id -R .comment -S(arch/arm/Makefile)來(lái)看看這些objcopy具體做了什么事情 ～

得到Image以后，再將這個(gè)Image跟解壓代碼合成一個(gè)vmlinux，具體的我們可以看看arch/arm/boot/compressed/Makefile：

view plaincopy to clipboardprint?
$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o /
$(addprefix $(obj)/, $(OBJS)) FORCE
$(call if_changed,ld)
@:
$(obj)/piggy.gz: $(obj)/../Image FORCE
$(call if_changed,gzip)
$(obj)/piggy.o: $(obj)/piggy.gz FORCE
$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o /
$(addprefix $(obj)/, $(OBJS)) FORCE
$(call if_changed,ld)
@:
$(obj)/piggy.gz: $(obj)/../Image FORCE
$(call if_changed,gzip)
$(obj)/piggy.o: $(obj)/piggy.gz FORCE

從這里我們就可以看出來(lái)實(shí)際上這個(gè)vmlinux就是將Image壓縮以后根據(jù)vmlinux.lds與解壓代碼head.o和misc.o鏈接以后生成的一個(gè)elf，而且用readelf或者objdump可以很明顯地看到解壓代碼是PIC的，所有的虛擬地址都是相對(duì)的，沒(méi)有絕對(duì)地址。這里的vmlinx.lds可以對(duì)照著后面的head.s稍微看一下～得到壓縮以后的vmlinx以后再將這個(gè)vmlinx經(jīng)過(guò)objcopy以后就得到我們的zImage了，然后拷貝到out目錄下就是我們的kernel了～～

在這里要強(qiáng)調(diào)幾個(gè)地址，這些地址定義在arch/arm/mach-msm/makefile.boot里面，被arch/arm/boot/Makefile調(diào)用，其中zreladdr-y就是我們的kernel被解壓以后要釋放的地址了，解壓代碼跑完以后就會(huì)跳到這個(gè)地址來(lái)執(zhí)行kernel的啟動(dòng)。不過(guò)這里還有其他兩個(gè)PHYS，跟前面定義在boardconfig.h里面的值重復(fù)了，不知道這兩個(gè)值在這里定義跟前面的值是一種什么關(guān)系？？？

好啦，講到這里我們基本就知道boot.img的構(gòu)成了，下面我們就從解壓的代碼開(kāi)始看看arm linux kernel啟動(dòng)的一個(gè)過(guò)程，這個(gè)解壓的source就是/arch/arm/boot/compressed/head.S。要看懂這個(gè)匯編需要了解GNU ASM以及ARM匯編指令，ARM指令就不說(shuō)了，ARM RVCT里面的文檔有得下，至于GNU ASM，不需要消息了解的話主要是看一下一些偽指令的含義（http://sources.redhat.com/binutils/docs-2.12/as.info/Pseudo-Ops.html#Pseudo%20Ops）

那么我們現(xiàn)在就開(kāi)始分析這個(gè)解壓的過(guò)程：

1）bootloader會(huì)傳遞2個(gè)參數(shù)過(guò)來(lái)，分別是r1=architecture ID, r2=atags pointer。head.S從哪部分開(kāi)始執(zhí)行呢，這個(gè)我們可以看看vmlinx.lds：

view plaincopy to clipboardprint?
ENTRY(_start)
SECTIONS
{
. = 0;
_text = .;
.text : {
_start = .;
*(.start)
*(.text)
*(.text.*)
*(.fixup)
*(.gnu.warning)
*(.rodata)
*(.rodata.*)
*(.glue_7)
*(.glue_7t)
*(.piggydata)
. = ALIGN(4);
}
ENTRY(_start)
SECTIONS
{
. = 0;
_text = .;
.text : {
_start = .;
*(.start)
*(.text)
*(.text.*)
*(.fixup)
*(.gnu.warning)
*(.rodata)
*(.rodata.*)
*(.glue_7)
*(.glue_7t)
*(.piggydata)
. = ALIGN(4);
}

可以看到我們最開(kāi)始的section就是.start，所以我們是從start段開(kāi)始執(zhí)行的。ELF對(duì)程序的入口地址是有定義的，這可以參照*.lds的語(yǔ)法規(guī)則里面有描述，分別是GNU LD的-E ---> *.lds里面的ENTRY定義 ---> start Symbol ---> .text section --->0。在這里是沒(méi)有這些判斷的，因?yàn)檫€沒(méi)有操作系統(tǒng)，bootloader會(huì)直接跳到這個(gè)start的地址開(kāi)始執(zhí)行。

在這里稍微帶一句，如果覺(jué)得head.S看的不太舒服的話，比如有些跳轉(zhuǎn)并不知道意思，可以直接objdump vmlinx來(lái)看，dump出來(lái)的匯編的流程就比較清晰了。

view plaincopy to clipboardprint?
1: mov r7, r1 @ save architecture ID
mov r8, r2 @ save atags pointer
#ifndef __ARM_ARCH_2__
/*
* Booting from Angel - need to enter SVC mode and disable
* FIQs/IRQs (numeric definitions from angel arm.h source).
* We only do this if we were in user mode on entry.
*/
mrs r2, cpsr @ get current mode
tst r2, #3 @ not user?
bne not_angel @ 如果不是
mov r0, #0x17 @ angel_SWIreason_EnterSVC
swi 0x123456 @ angel_SWI_ARM
not_angel:
mrs r2, cpsr @ turn off interrupts to
orr r2, r2, #0xc0 @ prevent angel from running
msr cpsr_c, r2
1: mov r7, r1 @ save architecture ID
mov r8, r2 @ save atags pointer
#ifndef __ARM_ARCH_2__
/*
* Booting from Angel - need to enter SVC mode and disable
* FIQs/IRQs (numeric definitions from angel arm.h source).
* We only do this if we were in user mode on entry.
*/
mrs r2, cpsr @ get current mode
tst r2, #3 @ not user?
bne not_angel @ 如果不是
mov r0, #0x17 @ angel_SWIreason_EnterSVC
swi 0x123456 @ angel_SWI_ARM
not_angel:
mrs r2, cpsr @ turn off interrupts to
orr r2, r2, #0xc0 @ prevent angel from running
msr cpsr_c, r2

上面首先保存r1和r2的值，然后進(jìn)入超級(jí)用戶模式，并關(guān)閉中斷。

view plaincopy to clipboardprint?
.text
adr r0, LC0
ldmia r0, {r1, r2, r3, r4, r5, r6, ip, sp}
subs r0, r0, r1 @ calculate the delta offset
@ if delta is zero, we are
beq not_relocated @ running at the address we
@ were linked at.
.text
adr r0, LC0
ldmia r0, {r1, r2, r3, r4, r5, r6, ip, sp}
subs r0, r0, r1 @ calculate the delta offset
@ if delta is zero, we are
beq not_relocated @ running at the address we
@ were linked at.

這里首先判斷LC0當(dāng)前的運(yùn)行地址和鏈接地址是否一樣，如果一樣就不需要重定位，如果不一樣則需要進(jìn)行重定位。這里肯定是不相等的，因?yàn)槲覀兛梢酝ㄟ^(guò)objdump看到LC0的地址是0x00000138，是一個(gè)相對(duì)地址，然后adr r0, LC0 實(shí)際上就是將LC0當(dāng)前的運(yùn)行地址，而我們直接跳到ZTEXTADDR跑的，實(shí)際上PC里面現(xiàn)在的地址肯定是0x00208000以后的一個(gè)值，adr r0, LC0編譯之后實(shí)際上為add r0, pc, #208，這個(gè)208就是LC0到.text段頭部的偏移。

view plaincopy to clipboardprint?
add r5, r5, r0
add r6, r6, r0
add ip, ip, r0
add r5, r5, r0
add r6, r6, r0
add ip, ip, r0

然后就是重定位了，即都加上一個(gè)偏移，經(jīng)過(guò)重定位以后就都是絕對(duì)地址了。

view plaincopy to clipboardprint?
not_relocated: mov r0, #0
1: str r0, [r2], #4 @ clear bss
str r0, [r2], #4
str r0, [r2], #4
str r0, [r2], #4
cmp r2, r3
blo 1b
/*
* The C runtime environment should now be setup
* sufficiently. Turn the cache on, set up some
* pointers, and start decompressing.
*/
bl cache_on
not_relocated: mov r0, #0
1: str r0, [r2], #4 @ clear bss
str r0, [r2], #4
str r0, [r2], #4
str r0, [r2], #4
cmp r2, r3
blo 1b
/*
* The C runtime environment should now be setup
* sufficiently. Turn the cache on, set up some
* pointers, and start decompressing.
*/
bl cache_on

重定位完成以后打開(kāi)cache，具體這個(gè)打開(kāi)cache的過(guò)程咱沒(méi)仔細(xì)研究過(guò)，大致過(guò)程是先從C0里面讀到processor ID，然后根據(jù)ID來(lái)進(jìn)行cache_on。

view plaincopy to clipboardprint?
mov r1, sp @ malloc space above stack
add r2, sp, #0x10000 @ 64k max
mov r1, sp @ malloc space above stack
add r2, sp, #0x10000 @ 64k max

解壓的過(guò)程首先是在堆棧之上申請(qǐng)一個(gè)空間

view plaincopy to clipboardprint?
/*
* Check to see if we will overwrite ourselves.
* r4 = final kernel address
* r5 = start of this image
* r2 = end of malloc space (and therefore this image)
* We basically want:
* r4 >= r2 -> OK
* r4 + image length <= r5 -> OK
*/
cmp r4, r2
bhs wont_overwrite
sub r3, sp, r5 @ > compressed kernel size
add r0, r4, r3, lsl #2 @ allow for 4x expansion
cmp r0, r5
bls wont_overwrite
mov r5, r2 @ decompress after malloc space
mov r0, r5
mov r3, r7
bl decompress_kernel
add r0, r0, #127 + 128 @ alignment + stack
bic r0, r0, #127 @ align the kernel length
/*
* Check to see if we will overwrite ourselves.
* r4 = final kernel address
* r5 = start of this image
* r2 = end of malloc space (and therefore this image)
* We basically want:
* r4 >= r2 -> OK
* r4 + image length <= r5 -> OK
*/
cmp r4, r2
bhs wont_overwrite
sub r3, sp, r5 @ > compressed kernel size
add r0, r4, r3, lsl #2 @ allow for 4x expansion
cmp r0, r5
bls wont_overwrite
mov r5, r2 @ decompress after malloc space
mov r0, r5
mov r3, r7
bl decompress_kernel
add r0, r0, #127 + 128 @ alignment + stack
bic r0, r0, #127 @ align the kernel length

這個(gè)過(guò)程是判斷我們解壓出的vmlinx會(huì)不會(huì)覆蓋原來(lái)的zImage，這里的final kernel address就是解壓后的kernel要存放的地址，而start of this image則是zImage在內(nèi)存中的地址。根據(jù)我們前面的分析，現(xiàn)在這兩個(gè)地址是重復(fù)的，即都是0x00208000。同樣r2是我們申請(qǐng)的一段內(nèi)存空間，因?yàn)樗窃趕p上申請(qǐng)的，而根據(jù)vmlinx.lds我們知道stack實(shí)際上處與vmlinx的最上面，所以r4>=r2是不可能的，這里首先計(jì)算zImage的大小，然后判斷r4+r3是不是比r5小，很明顯r4和r5的值是一樣的，所以這里先將r2的值賦給r0，經(jīng)kernel先解壓到s申請(qǐng)的內(nèi)存空間上面，具體的解壓過(guò)程就不描述了，定義在misc.c里面。（這里我所說(shuō)的上面是指內(nèi)存地址的高地址，默認(rèn)載入的時(shí)候從低地址往高地址寫(xiě)，所以從內(nèi)存低地址開(kāi)始運(yùn)行，stack處于最后面，所以成說(shuō)是最上面）

view plaincopy to clipboardprint?
* r0 = decompressed kernel length
* r1-r3 = unused
* r4 = kernel execution address
* r5 = decompressed kernel start
* r6 = processor ID
* r7 = architecture ID
* r8 = atags pointer
* r9-r14 = corrupted
*/
add r1, r5, r0 @ end of decompressed kernel
adr r2, reloc_start
ldr r3, LC1
add r3, r2, r3
: ldmia r2!, {r9 - r14} @ copy relocation code
stmia r1!, {r9 - r14}
ldmia r2!, {r9 - r14}
stmia r1!, {r9 - r14}
cmp r2, r3
blo 1b
add sp, r1, #128 @ relocate the stack
bl cache_clean_flush
add pc, r5, r0 @ call relocation code
* r0 = decompressed kernel length
* r1-r3 = unused
* r4 = kernel execution address
* r5 = decompressed kernel start
* r6 = processor ID
* r7 = architecture ID
* r8 = atags pointer
* r9-r14 = corrupted
*/
add r1, r5, r0 @ end of decompressed kernel
adr r2, reloc_start
ldr r3, LC1
add r3, r2, r3
1: ldmia r2!, {r9 - r14} @ copy relocation code
stmia r1!, {r9 - r14}
ldmia r2!, {r9 - r14}
stmia r1!, {r9 - r14}
cmp r2, r3
blo 1b
add sp, r1, #128 @ relocate the stack
bl cache_clean_flush
add pc, r5, r0 @ call relocation code

因?yàn)闆](méi)有將kernel解壓在要求的地址，所以必須重定向，說(shuō)穿了就是要將解壓的kernel拷貝到正確的地址，因?yàn)檎_的地址與zImage的地址是重合的，而要拷貝我們又要執(zhí)行zImage的重定位代碼，所以這里首先將重定位代碼reloc_start拷貝到vmlinx上面，然后再將vmlinx拷貝到正確的地址并覆蓋掉zImage。這里首先計(jì)算出解壓后的vmlinux的高地址放在r1里面，r2存放著重定位代碼的首地址，r3存放著重定位代碼的size，這樣通過(guò)拷貝就將reloc_start移動(dòng)到vmlinx后面去了，然后跳轉(zhuǎn)到重定位代碼開(kāi)始執(zhí)行。

view plaincopy to clipboardprint?
/*
* All code following this line is relocatable. It is relocated by
* the above code to the end of the decompressed kernel image and
* executed there. During this time, we have no stacks.
*
* r0 = decompressed kernel length
* r1-r3 = unused
* r4 = kernel execution address
* r5 = decompressed kernel start
* r6 = processor ID
* r7 = architecture ID
* r8 = atags pointer
* r9-r14 = corrupted
*/
.align 5
reloc_start: add r9, r5, r0
sub r9, r9, #128 @ do not copy the stack
debug_reloc_start
mov r1, r4
1:
.rept 4
ldmia r5!, {r0, r2, r3, r10 - r14} @ relocate kernel
stmia r1!, {r0, r2, r3, r10 - r14}
.endr
cmp r5, r9
blo 1b
add sp, r1, #128 @ relocate the stack
debug_reloc_end
call_kernel: bl cache_clean_flush
bl cache_off
mov r0, #0 @ must be zero
mov r1, r7 @ restore architecture number
mov r2, r8 @ restore atags pointer
mov pc, r4 @ call kernel
/*
* All code following this line is relocatable. It is relocated by
* the above code to the end of the decompressed kernel image and
* executed there. During this time, we have no stacks.
*
* r0 = decompressed kernel length
* r1-r3 = unused
* r4 = kernel execution address
* r5 = decompressed kernel start
* r6 = processor ID
* r7 = architecture ID
* r8 = atags pointer
* r9-r14 = corrupted
*/
.align 5
reloc_start: add r9, r5, r0
sub r9, r9, #128 @ do not copy the stack
debug_reloc_start
mov r1, r4
1:
.rept 4
ldmia r5!, {r0, r2, r3, r10 - r14} @ relocate kernel
stmia r1!, {r0, r2, r3, r10 - r14}
.endr
cmp r5, r9
blo 1b
add sp, r1, #128 @ relocate the stack
debug_reloc_end
call_kernel: bl cache_clean_flush
bl cache_off
mov r0, #0 @ must be zero
mov r1, r7 @ restore architecture number
mov r2, r8 @ restore atags pointer
mov pc, r4 @ call kernel

這里就是將vmlinx拷貝到正確的地址了，拷貝到正確的位置以后，就將kernel的首地址賦給PC，然后就跳轉(zhuǎn)到真正kernel啟動(dòng)的過(guò)程～～

最后我們來(lái)總結(jié)一下一個(gè)基本的過(guò)程：

1）當(dāng)bootloader要從分區(qū)中數(shù)據(jù)讀到內(nèi)存中來(lái)的時(shí)候，這里涉及最重要的兩個(gè)地址，一個(gè)就是ZTEXTADDR還有一個(gè)是INITRD_PHYS。不管用什么方式來(lái)生成IMG都要讓bootloader有方法知道這些參數(shù)，不然就不知道應(yīng)該將數(shù)據(jù)從FLASH讀入以后放在什么地方，下一步也不知道從哪個(gè)地方開(kāi)始執(zhí)行了；

2）bootloader將IMG載入RAM以后，并跳到zImage的地址開(kāi)始解壓的時(shí)候，這里就涉及到另外一個(gè)重要的參數(shù)，那就是ZRELADDR，就是解壓后的kernel應(yīng)該放在哪。這個(gè)參數(shù)一般都是arch/arm/mach-xxx下面的Makefile.boot來(lái)提供的；

3）另外現(xiàn)在解壓的代碼head.S和misc.c一般都會(huì)以PIC的方式來(lái)編譯，這樣載入RAM在任何地方都可以運(yùn)行，這里涉及到兩次沖定位的過(guò)程，基本上這個(gè)重定位的過(guò)程在ARM上都是差不多一樣的。