新聞中心

EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計(jì)應(yīng)用 > Android arm linux kernel啟動(dòng)流程

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

作者： 時(shí)間：2016-11-09 來源：網(wǎng)絡(luò) 收藏
雖然這里的Arm Linux kernel前面加上了Android，但實(shí)際上還是和普遍Arm linux kernel啟動(dòng)的過程一樣的，這里只是結(jié)合一下Android的Makefile，講一下bootimage生成的一個(gè)過程。這篇文檔主要描述 bootimage的構(gòu)造，以及kernel真正執(zhí)行前的解壓過程。

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

本文引用地址：http://butianyuan.cn/article/201611/317991.htm

1）ZTEXTADDR boot.img運(yùn)行時(shí)候zImage的起始地址，即kernel解壓代碼的地址。這里沒有虛擬地址的概念，因?yàn)闆]有開啟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)存上的物理地址。

下面我們首先來看看boot.img的構(gòu)造，了解其中的內(nèi)容對我們了解kernel的啟動(dòng)過程是很有幫助的。首先來看看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 plainprint?
  1. /*
  2. +-----------------+
  3. |bootheader|1page
  4. +-----------------+
  5. |kernel|npages
  6. +-----------------+
  7. |ramdisk|mpages
  8. +-----------------+
  9. |secondstage|opages
  10. +-----------------+
  12. n=(kernel_size+page_size-1)/page_size
  13. m=(ramdisk_size+page_size-1)/page_size
  14. o=(second_size+page_size-1)/page_size
  16. 0.allentitiesarepage_sizealignedinflash
  17. 1.kernelandramdiskarerequired(size!=0)
  18. 2.secondisoptional(second_size==0->nosecond)
  19. 3.loadeachelement(kernel,ramdisk,second)at
  20. thespecifiedphysicaladdress(kernel_addr,etc)
  21. 4.preparetagsattag_addr.kernel_args[]is
  22. appendedtothekernelcommandlineinthetags.
  23. 5.r0=0,r1=MACHINE_TYPE,r2=tags_addr
  24. 6.ifsecond_size!=0:jumptosecond_addr
  25. else:jumptokernel_addr
  26. */
/* +-----------------+ | 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里面，不同的芯片對應(yīng)vendor下不同的boardconfig，在這里我們的值分別是（分別是kernel/ramdis/tags載入ram的物理地址）：

view plainprint?
  1. #definePHYSICAL_DRAM_BASE0x00200000
  2. #defineKERNEL_ADDR(PHYSICAL_DRAM_BASE+0x00008000)
  3. #defineRAMDISK_ADDR(PHYSICAL_DRAM_BASE+0x01000000)
  4. #defineTAGS_ADDR(PHYSICAL_DRAM_BASE+0x00000100)
  5. #defineNEWTAGS_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)

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

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

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

view plainprint?
  1. $(obj)/Image:vmlinuxFORCE
  2. $(callif_changed,objcopy)
  3. @echoKernel:$@isready
  4. $(obj)/compressed/vmlinux:$(obj)/ImageFORCE
  5. $(Q)$(MAKE)$(build)=$(obj)/compressed$@
  6. $(obj)/zImage:$(obj)/compressed/vmlinuxFORCE
  7. $(callif_changed,objcopy)
  8. @echoKernel:$@isready
$(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

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

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

view plainprint?
  1. $(obj)/vmlinux:$(obj)/vmlinux.lds$(obj)/$(HEAD)$(obj)/piggy.o/
  2. $(addprefix$(obj)/,$(OBJS))FORCE
  3. $(callif_changed,ld)
  4. @:
  5. $(obj)/piggy.gz:$(obj)/../ImageFORCE
  6. $(callif_changed,gzip)
  7. $(obj)/piggy.o:$(obj)/piggy.gzFORCE
$(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

從這里我們就可以看出來實(shí)際上這個(gè)vmlinux就是將Image壓縮以后根據(jù)vmlinux.lds與解壓代碼head.o和misc.o鏈接以后生成的一個(gè)elf，而且用readelf或者objdump可以很明顯地看到解壓代碼是PIC的，所有的虛擬地址都是相對的，沒有絕對地址。這里的 vmlinx.lds可以對照著后面的head.s稍微看一下～得到壓縮以后的vmlinx以后再將這個(gè)vmlinx經(jīng)過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è)地址來執(zhí)行 kernel的啟動(dòng)。不過這里還有其他兩個(gè)PHYS，跟前面定義在boardconfig.h里面的值重復(fù)了，不知道這兩個(gè)值在這里定義跟前面的值是一種什么關(guān)系？？？

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

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

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

view plainprint?
  1. ENTRY(_start)
  2. SECTIONS
  3. {
  4. .=0;
  5. _text=.;
  6. .text:{
  7. _start=.;
  8. *(.start)
  9. *(.text)
  10. *(.text.*)
  11. *(.fixup)
  12. *(.gnu.warning)
  13. *(.rodata)
  14. *(.rodata.*)
  15. *(.glue_7)
  16. *(.glue_7t)
  17. *(.piggydata)
  18. .=ALIGN(4);
  19. }
ENTRY(_start) SECTIONS { . = 0; _text = .; .text : { _start = .; *(.start) *(.text) *(.text.*) *(.fixup) *(.gnu.warning) *(.rodata) *(.rodata.*) *(.glue_7) *(.glue_7t) *(.piggydata) . = ALIGN(4); }

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

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

view plainprint?
  1. 1:movr7,r1@savearchitectureID
  2. movr8,r2@saveatagspointer
  3. #ifndef__ARM_ARCH_2__
  4. /*
  5. *BootingfromAngel-needtoenterSVCmodeanddisable
  6. *FIQs/IRQs(numericdefinitionsfromangelarm.hsource).
  7. *Weonlydothisifwewereinusermodeonentry.
  8. */
  9. mrsr2,cpsr@getcurrentmode
  10. tstr2,#3@notuser?
  11. bnenot_angel@如果不是
  12. movr0,#0x17@angel_SWIreason_EnterSVC
  13. swi0x123456@angel_SWI_ARM
  14. not_angel:
  15. mrsr2,cpsr@turnoffinterruptsto
  16. orrr2,r2,#0xc0@preventangelfromrunning
  17. msrcpsr_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)入超級用戶模式，并關(guān)閉中斷。

view plainprint?
  1. .text
  2. adrr0,LC0
  3. ldmiar0,{r1,r2,r3,r4,r5,r6,ip,sp}
  4. subsr0,r0,r1@calculatethedeltaoffset
  5. @ifdeltaiszero,weare
  6. beqnot_relocated@runningattheaddresswe
  7. @werelinkedat.
.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)槲覀兛梢酝ㄟ^ objdump看到LC0的地址是0x00000138，是一個(gè)相對地址，然后adr r0, LC0 實(shí)際上就是將LC0當(dāng)前的運(yùn)行地址，而我們直接跳到ZTEXTADDR跑的，實(shí)際上PC里面現(xiàn)在的地址肯定是0x00208000以后的一個(gè)值，adr r0, LC0編譯之后實(shí)際上為addr0, pc, #208，這個(gè)208就是LC0到.text段頭部的偏移。

view plainprint?
  1. addr5,r5,r0
  2. addr6,r6,r0
  3. addip,ip,r0
add r5, r5, r0 add r6, r6, r0 add ip, ip, r0

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

view plainprint?
  1. not_relocated:movr0,#0
  2. 1:strr0,[r2],#4@clearbss
  3. strr0,[r2],#4
  4. strr0,[r2],#4
  5. strr0,[r2],#4
  6. cmpr2,r3
  7. blo1b
  8. /*
  9. *TheCruntimeenvironmentshouldnowbesetup
  10. *sufficiently.Turnthecacheon,setupsome
  11. *pointers,andstartdecompressing.
  12. */
  13. blcache_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

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

view plainprint?
  1. movr1,sp@mallocspaceabovestack
  2. addr2,sp,#0x10000@64kmax
mov r1, sp @ malloc space above stack add r2, sp, #0x10000 @ 64k max

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

view plainprint?
  1. /*
  2. *Checktoseeifwewilloverwriteourselves.
  3. *r4=finalkerneladdress
  4. *r5=startofthisimage
  5. *r2=endofmallocspace(andthereforethisimage)
  6. *Webasicallywant:
  7. *r4>=r2->OK
  8. *r4+imagelength<=r5->OK
  9. */
  10. cmpr4,r2
  11. bhswont_overwrite
  12. subr3,sp,r5@>compressedkernelsize
  13. addr0,r4,r3,lsl#2@allowfor4xexpansion
  14. cmpr0,r5
  15. blswont_overwrite
  16. movr5,r2@decompressaftermallocspace
  17. movr0,r5
  18. movr3,r7
  19. bldecompress_kernel
  20. addr0,r0,#127+128@alignment+stack
  21. bicr0,r0,#127@alignthekernellength
/* * 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è)過程是判斷我們解壓出的vmlinx會(huì)不會(huì)覆蓋原來的zImage，這里的final kernel address就是解壓后的kernel要存放的地址，而start of this image則是zImage在內(nèi)存中的地址。根據(jù)我們前面的分析，現(xiàn)在這兩個(gè)地址是重復(fù)的，即都是0x00208000。同樣r2是我們申請的一段內(nèi)存空間，因?yàn)樗窃趕p上申請的，而根據(jù)vmlinx.lds我們知道stack實(shí)際上處與vmlinx的最上面，所以r4>=r2是不可能的，這里首先計(jì)算zImage的大小，然后判斷r4+r3是不是比r5小，很明顯r4和r5的值是一樣的，所以這里先將r2的值賦給r0，經(jīng)kernel先解壓到s 申請的內(nèi)存空間上面，具體的解壓過程就不描述了，定義在misc.c里面。（這里我所說的上面是指內(nèi)存地址的高地址，默認(rèn)載入的時(shí)候從低地址往高地址寫，所以從內(nèi)存低地址開始運(yùn)行，stack處于最后面，所以成說是最上面）

view plainprint?
  1. *r0=decompressedkernellength
  2. *r1-r3=unused
  3. *r4=kernelexecutionaddress
  4. *r5=decompressedkernelstart
  5. *r6=processorID
  6. *r7=architectureID
  7. *r8=atagspointer
  8. *r9-r14=corrupted
  9. */
  10. addr1,r5,r0@endofdecompressedkernel
  11. adrr2,reloc_start
  12. ldrr3,LC1
  13. addr3,r2,r3
  14. :ldmiar2!,{r9-r14}@copyrelocationcode
  15. stmiar1!,{r9-r14}
  16. ldmiar2!,{r9-r14}
  17. stmiar1!,{r9-r14}
  18. cmpr2,r3
  19. blo1b
  20. addsp,r1,#128@relocatethestack
  21. blcache_clean_flush
  22. addpc,r5,r0@callrelocationcode
* 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)闆]有將kernel解壓在要求的地址，所以必須重定向，說穿了就是要將解壓的kernel拷貝到正確的地址，因?yàn)檎_的地址與zImage的地址是重合的，而要拷貝我們又要執(zhí)行zImage的重定位代碼，所以這里首先將重定位代碼reloc_start拷貝到vmlinx上面，然后再將vmlinx 拷貝到正確的地址并覆蓋掉zImage。這里首先計(jì)算出解壓后的vmlinux的高地址放在r1里面，r2存放著重定位代碼的首地址，r3存放著重定位代碼的size，這樣通過拷貝就將reloc_start移動(dòng)到vmlinx后面去了，然后跳轉(zhuǎn)到重定位代碼開始執(zhí)行。

view plainprint?
  1. /*
  2. *Allcodefollowingthislineisrelocatable.Itisrelocatedby
  3. *theabovecodetotheendofthedecompressedkernelimageand
  4. *executedthere.Duringthistime,wehavenostacks.
  5. *
  6. *r0=decompressedkernellength
  7. *r1-r3=unused
  8. *r4=kernelexecutionaddress
  9. *r5=decompressedkernelstart
  10. *r6=processorID
  11. *r7=architectureID
  12. *r8=atagspointer
  13. *r9-r14=corrupted
  14. */
  15. .align5
  16. reloc_start:addr9,r5,r0
  17. subr9,r9,#128@donotcopythestack
  18. debug_reloc_start
  19. movr1,r4
  20. 1:
  21. .rept4
  22. ldmiar5!,{r0,r2,r3,r10-r14}@relocatekernel
  23. stmiar1!,{r0,r2,r3,r10-r14}
  24. .endr
  25. cmpr5,r9
  26. blo1b
  27. addsp,r1,#128@relocatethestack
  28. debug_reloc_end
  29. call_kernel:blcache_clean_flush
  30. blcache_off
  31. movr0,#0@mustbezero
  32. movr1,r7@restorearchitecturenumber
  33. movr2,r8@restoreatagspointer
  34. movpc,r4@callkernel
/* * 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)的過程～～

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

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

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

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

寫這個(gè)總結(jié)的時(shí)候咱的心情是沉重的，因?yàn)檫€有好多東西沒弄明白。。。感嘆自己的知識(shí)還是淺薄得很，前途錢途漫漫阿～～不過基本脈絡(luò)是清楚的，具體的細(xì)節(jié)只能留在以后有時(shí)間再啃了。這里的第二部分啟動(dòng)流程指的是解壓后kernel開始執(zhí)行的一部分代碼，這部分代碼和ARM體系結(jié)構(gòu)是緊密聯(lián)系在一起的，所以最好是將ARM ARCHITECTURE REFERENCE MANUL仔細(xì)讀讀，尤其里面關(guān)于控制寄存器啊，MMU方面的內(nèi)容～

前面說過解壓以后，代碼會(huì)跳到解壓完成以后的vmlinux開始執(zhí)行，具體從什么地方開始執(zhí)行我們可以看看生成的vmlinux.lds(arch/arm/kernel/)這個(gè)文件：

view plainprint?
  1. OUTPUT_ARCH(arm)
  2. ENTRY(stext)
  3. jiffies=jiffies_64;
  4. SECTIONS
  5. {
  6. .=0x80000000+0x00008000;
  7. .text.head:{
  8. _stext=.;
  9. _sinittext=.;
  10. *(.text.h
OUTPUT_ARCH(arm) ENTRY(stext) jiffies = jiffies_64; SECTIONS { . = 0x80000000 + 0x00008000; .text.head : { _stext = .; _sinittext = .; *(.text.h

很明顯我們的vmlinx最開頭的section是.text.head，這里我們不能看ENTRY的內(nèi)容，以為這時(shí)候我們沒有操作系統(tǒng)，根本不知道如何來解析這里的入口地址，我們只能來分析他的section(不過一般來說這里的ENTRY和我們從seciton分析的結(jié)果是一樣的)，這里的.text.head section我們很容易就能在arch/arm/kernel/head.S里面找到，而且它里面的第一個(gè)符號(hào)就是我們的stext：

view plainprint?
  1. .section".text.head","ax"
  2. Y(stext)
  3. msrcpsr_c,#PSR_F_BIT|PSR_I_BIT|SVC_MODE@ensuresvcmode
  4. @andirqsdisabled
  5. mrcp15,0,r9,c0,c0@getprocessorid
  6. bl__lookup_processor_type@r5=procinfor9=cpuid
.section ".text.head", "ax" ENTRY(stext) msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode @ and irqs disabled mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid

這里的ENTRY這個(gè)宏實(shí)際我們可以在include/linux/linkage.h里面找到，可以看到他實(shí)際上就是聲明一個(gè)GLOBAL Symbol，后面的ENDPROC和END唯一的區(qū)別是前面的聲明了一個(gè)函數(shù)，可以在c里面被調(diào)用。

view plainprint?
  1. #ifndefENTRY
  2. #defineENTRY(name)/
  3. .globlname;/
  4. ALIGN;/
  5. name:
  6. #endif
  7. #ifndefWEAK
  8. #defineWEAK(name)/
  9. .weakname;/
  10. name:
  11. #endif
  12. #ifndefEND
  13. #defineEND(name)/
  14. .sizename,.-name
  15. #endif
  16. /*Ifsymbolnameistreatedasasubroutine(getscalled,andreturns)
  17. *thenpleaseuseENDPROCtomarknameasSTT_FUNCforthebenefitof
  18. *staticanalysistoolssuchasstackdepthanalyzer.
  19. */
  20. #ifndefENDPROC
  21. #defineENDPROC(name)/
  22. .typename,@function;/
  23. END(name)
  24. #endif
#ifndef ENTRY #define ENTRY(name) / .globl name; / ALIGN; / name: #endif #ifndef WEAK #define WEAK(name) / .weak name; / name: #endif #ifndef END #define END(name) / .size name, .-name #endif /* If symbol name is treated as a subroutine (gets called, and returns) * then please use ENDPROC to mark name as STT_FUNC for the benefit of * static analysis tools such as stack depth analyzer. */ #ifndef ENDPROC #define ENDPROC(name) / .type name, @function; / END(name) #endif

找到了vmlinux的起始代碼我們就來進(jìn)行分析了，先總體概括一下這部分代碼所完成的功能，head.S會(huì)首先檢查proc和arch以及atag的有效性，然后會(huì)建立初始化頁表，并進(jìn)行CPU必要的處理以后打開MMU，并跳轉(zhuǎn)到start_kernel這個(gè)symbol開始執(zhí)行后面的C代碼。這里有很多變量都是我們進(jìn)行kernel移植時(shí)需要特別注意的，下面會(huì)一一講到。

在這里我們首先看看這段匯編開始跑的時(shí)候的寄存器信息，這里的寄存器內(nèi)容實(shí)際上是同bootloader跳轉(zhuǎn)到解壓代碼是一樣的，就是r1=arch r2=atag addr。下面我們就具體來看看這個(gè)head.S跑的過程：

view plainprint?
  1. msrcpsr_c,#PSR_F_BIT|PSR_I_BIT|SVC_MODE@ensuresvcmode
  2. @andirqsdisabled
  3. mrcp15,0,r9,c0,c0@getprocessorid
msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode @ and irqs disabled mrc p15, 0, r9, c0, c0 @ get processor id

首先進(jìn)入SVC模式并關(guān)閉所有中斷，并從arm協(xié)處理器里面讀到CPU ID，這里的CPU主要是指arm架構(gòu)相關(guān)的CPU型號(hào)，比如ARM9，ARM11等等。

view plainprint?

然后跳轉(zhuǎn)到__lookup_processor_type，這個(gè)函數(shù)定義在head-common.S里面，這里的bl指令會(huì)保存當(dāng)前的pc在lr里面，最后__lookup_processor_type會(huì)從這個(gè)函數(shù)返回，我們具體看看這個(gè)函數(shù)：

view plainprint?
  1. __lookup_processor_type:
  2. adrr3,3f
  3. ldmdar3,{r5-r7}
  4. subr3,r3,r7@getoffsetbetweenvirt&phys
  5. addr5,r5,r3@convertvirtaddressesto
  6. addr6,r6,r3@physicaladdressspace
  7. 1:ldmiar5,{r3,r4}@value,mask
  8. andr4,r4,r9@maskwantedbits
  9. teqr3,r4
  10. beq2f
  11. addr5,r5,#PROC_INFO_SZ@sizeof(proc_info_list)
  12. cmpr5,r6
  13. blo1b
  14. movr5,#0@unknownprocessor
  15. 2:movpc,lr
  16. ENDPROC(__lookup_processor_type)
__lookup_processor_type: adr r3, 3f ldmda r3, {r5 - r7} sub r3, r3, r7 @ get offset between virt&phys add r5, r5, r3 @ convert virt addresses to add r6, r6, r3 @ physical address space 1: ldmia r5, {r3, r4} @ value, mask and r4, r4, r9 @ mask wanted bits teq r3, r4 beq 2f add r5, r5, #PROC_INFO_SZ @ sizeof(proc_info_list) cmp r5, r6 blo 1b mov r5, #0 @ unknown processor 2: mov pc, lr ENDPROC(__lookup_processor_type)

他這里的執(zhí)行過程其實(shí)比較簡單就是在__proc_info_begin和__proc_info_end這個(gè)段里面里面去讀取我們注冊在里面的 proc_info_list這個(gè)結(jié)構(gòu)體，這個(gè)結(jié)構(gòu)體的定義在arch/arm/include/asm/procinfo.h，具體實(shí)現(xiàn)根據(jù)你使用的 cpu的架構(gòu)在arch/arm/mm/里面找到具體的實(shí)現(xiàn)，這里我們使用的ARM11是proc-v6.S，我們可以看看這個(gè)結(jié)構(gòu)體：

view plainprint?
  1. .section".proc.info.init",#alloc,#execinstr
  2. /*
  3. *MatchanyARMv6processorcore.
  4. */
  5. .type__v6_proc_info,#object
  6. _proc_info:
  7. .long0x0007b000
  8. .long0x0007f000
  9. .longPMD_TYPE_SECT|/
  10. PMD_SECT_BUFFERABLE|/
  11. PMD_SECT_CACHEABLE|/
  12. PMD_SECT_AP_WRITE|/
  13. PMD_SECT_AP_READ
  14. .longPMD_TYPE_SECT|/
  15. PMD_SECT_XN|/
  16. PMD_SECT_AP_WRITE|/
  17. PMD_SECT_AP_READ
  18. b__v6_setup
  19. .longcpu_arch_name
  20. .longcpu_elf_name
  21. .longHWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA
  22. .longcpu_v6_name
  23. .longv6_processor_functions
  24. .longv6wbi_tlb_fns
  25. .longv6_user_fns
  26. .longv6_cache_fns
  27. .size__v6_proc_info,.-__v6_proc_info
.section ".proc.info.init", #alloc, #execinstr /* * Match any ARMv6 processor core. */ .type __v6_proc_info, #object __v6_proc_info: .long 0x0007b000 .long 0x0007f000 .long PMD_TYPE_SECT | / PMD_SECT_BUFFERABLE | / PMD_SECT_CACHEABLE | / PMD_SECT_AP_WRITE | / PMD_SECT_AP_READ .long PMD_TYPE_SECT | / PMD_SECT_XN | / PMD_SECT_AP_WRITE | / PMD_SECT_AP_READ b __v6_setup .long cpu_arch_name .long cpu_elf_name .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA .long cpu_v6_name .long v6_processor_functions .long v6wbi_tlb_fns .long v6_user_fns .long v6_cache_fns .size __v6_proc_info, . - __v6_proc_info

對著.h我們就知道各個(gè)成員變量的含義了，他這里lookup的過程實(shí)際上是先求出這個(gè)proc_info_list的實(shí)際物理地址，并將其內(nèi)容讀出，然后將其中的mask也就是我們這里的0x007f000與寄存器與之后與0x007b00進(jìn)行比較，如果一樣的話呢就校驗(yàn)成功了，如果不一樣呢就會(huì)讀下一個(gè)proc_info的信息，因?yàn)閜roc一般都是只有一個(gè)的，所以這里一般不會(huì)循環(huán)，如果檢測正確寄存器就會(huì)將正確的proc_info_list的物理地址賦給寄存器，如果檢測不到就會(huì)將寄存器值賦0，然后通過LR返回。

view plainprint?
  1. bl__lookup_machine_type@r5=machinfo
  2. movsr8,r5@invalidmachine(r5=0)?
  3. beq__error_a@yes,errora
bl __lookup_machine_type @ r5=machinfo movs r8, r5 @ invalid machine (r5=0)? beq __error_a @ yes, error a

檢測完proc_info_list以后就開始檢測machine_type了，這個(gè)函數(shù)的實(shí)現(xiàn)也在head－common.S里面，我們看看它具體的實(shí)現(xiàn)：

view plainprint?
  1. __lookup_machine_type:
  2. adrr3,3b
  3. ldmiar3,{r4,r5,r6}
  4. subr3,r3,r4@getoffsetbetweenvirt&phys
  5. addr5,r5,r3@convertvirtaddressesto
  6. addr6,r6,r3@physicaladdressspace
  7. 1:ldrr3,[r5,#MACHINFO_TYPE]@getmachinetype
  8. teqr3,r1@matchesloadernumber?
  9. beq2f@found
  10. addr5,r5,#SIZEOF_MACHINE_DESC@nextmachine_desc
  11. cmpr5,r6
  12. blo1b
  13. movr5,#0@unknownmachine
  14. 2:movpc,lr
  15. ENDPROC(__lookup_machine_type)
__lookup_machine_type: adr r3, 3b ldmia r3, {r4, r5, r6} sub r3, r3, r4 @ get offset between virt&phys add r5, r5, r3 @ convert virt addresses to add r6, r6, r3 @ physical address space 1: ldr r3, [r5, #MACHINFO_TYPE] @ get machine type teq r3, r1 @ matches loader number? beq 2f @ found add r5, r5, #SIZEOF_MACHINE_DESC @ next machine_desc cmp r5, r6 blo 1b mov r5, #0 @ unknown machine 2: mov pc, lr ENDPROC(__lookup_machine_type)

這里的過程基本上是同proc的檢查是一樣的，這里主要檢查芯片的類型，比如我們現(xiàn)在的芯片是MSM7X27FFA，這也是一個(gè)結(jié)構(gòu)體，它的頭文件在 arch/arm/include/asm/arch/arch.h里面(machine_desc)，它具體的實(shí)現(xiàn)根據(jù)你對芯片類型的選擇而不同，這里我們使用的是高通的7x27,具體實(shí)現(xiàn)在arch/arm/mach-msm/board-msm7x27.c里面，這些結(jié)構(gòu)體最后都會(huì)注冊到 _arch_info_begin和_arch_info_end段里面，具體的大家可以看看vmlinux.lds或者system.map，這里的 lookup會(huì)根據(jù)bootloader傳過來的nr來在__arch_info里面的相匹配的類型，沒有的話就尋找下一個(gè)machin_desk結(jié)構(gòu)體，直到找到相應(yīng)的結(jié)構(gòu)體，并會(huì)將結(jié)構(gòu)體的地址賦值給寄存器，如果沒有的話就會(huì)賦值為0的。一般來說這里的machine_type會(huì)有好幾個(gè)，因?yàn)椴煌男酒愋涂赡苁褂玫亩际峭粋€(gè)cpu架構(gòu)。

對processor和machine的檢查完以后就會(huì)檢查atags parameter的有效性，關(guān)于這個(gè)atag具體的定義我們可以在./include/asm/setup.h里面看到，它實(shí)際是一個(gè)結(jié)構(gòu)體和一個(gè)聯(lián)合體構(gòu)成的結(jié)合體，里面的size都是以字來計(jì)算的。這里的atags param是bootloader創(chuàng)建的，里面包含了ramdisk以及其他memory分配的一些信息，存儲(chǔ)在boot.img頭部結(jié)構(gòu)體定義的地址中，具體的大家可以看咱以后對bootloader的分析～

view plainprint?
  1. __vet_atags:
  2. tstr2,#0x3@aligned?
  3. bne1f
  4. ldrr5,[r2,#0]@isfirsttagATAG_CORE?
  5. cmpr5,#ATAG_CORE_SIZE
  6. cmpner5,#ATAG_CORE_SIZE_EMPTY
  7. bne1f
  8. ldrr5,[r2,#4]
  9. ldrr6,=ATAG_CORE
  10. cmpr5,r6
  11. bne1f
  12. movpc,lr@atagpointerisok
  13. 1:movr2,#0
  14. movpc,lr
  15. ENDPROC(__vet_atags)
__vet_atags: tst r2, #0x3 @ aligned? bne 1f ldr r5, [r2, #0] @ is first tag ATAG_CORE? cmp r5, #ATAG_CORE_SIZE cmpne r5, #ATAG_CORE_SIZE_EMPTY bne 1f ldr r5, [r2, #4] ldr r6, =ATAG_CORE cmp r5, r6 bne 1f mov pc, lr @ atag pointer is ok 1: mov r2, #0 mov pc, lr ENDPROC(__vet_atags)

這里對atag的檢查主要檢查其是不是以ATAG_CORE開頭，size對不對，基本沒什么好分析的，代碼也比較好看～ 下面我們來看后面一個(gè)重頭戲，就是創(chuàng)建初始化頁表，說實(shí)話這段內(nèi)容我沒弄清楚，它需要對ARM VIRT MMU具有相當(dāng)?shù)睦斫?，這里我沒有太多的時(shí)間去分析spec，只是粗略了翻了ARM V7的manu，知道這里建立的頁表是arm的secition頁表，完成內(nèi)存開始1m內(nèi)存的映射，這個(gè)頁表建立在kernel和atag paramert之間，一般是4000-8000之間～具體的代碼和過程我這里就不貼了，大家可以看看參考的鏈接，看看其他大蝦的分析，我還沒怎么看明白，等以后仔細(xì)研究ARM MMU的時(shí)候再回頭來仔細(xì)研究了，不過代碼雖然不分析，這里有幾個(gè)重要的地址需要特別分析下～

這幾個(gè)地址都定義在arch/arm/include/asm/memory.h，我們來稍微分析下這個(gè)頭文件，首先它包含了arch /memory.h，我們來看看arch/arm/mach-msm/include/mach/memory.h，在這個(gè)里面定義了#define PHYS_OFFSET UL(0x00200000) 這個(gè)實(shí)際上是memory的物理內(nèi)存初始地址，這個(gè)地址和我們以前在boardconfig.h里面定義的是一致的。然后我們再看 asm/memory.h，他里面定義了我們的memory虛擬地址的首地址#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)。

另外我們在head.S里面看到kernel的物理或者虛擬地址的定義都有一個(gè)偏移，這個(gè)偏移又是從哪來的呢，實(shí)際我們可以從arch/arm /Makefile里面找到：textofs-y := 0x00008000 TEXT_OFFSET := $(textofs-y)這樣我們再看kernel啟動(dòng)時(shí)候的物理地址和鏈接地址，實(shí)際上它和我們前面在boardconfig.h和 Makefile.boot里面定義的都是一致的～

建立初始化頁表以后，會(huì)首先將__switch_data這個(gè)symbol的鏈接地址放在sp里面，然后獲得__enable_mmu的物理地址，然后會(huì)跳到__proc_info_list里面的INITFUNC執(zhí)行，這個(gè)偏移是定義在arch/arm/kernel/asm-offset.c里面，實(shí)際上就是取得__proc_info_list里面的__cpu_flush這個(gè)函數(shù)執(zhí)行。

view plainprint?
  1. ldrr13,__switch_data@addresstojumptoafter
  2. @mmuhasbeenenabled
  3. adrlr,__enable_mmu@return(PIC)address
  4. addpc,r10,#PROCINFO_INITFUNC
ldr r13, __switch_data @ address to jump to after @ mmu has been enabled adr lr, __enable_mmu @ return (PIC) address add pc, r10, #PROCINFO_INITFUNC

這個(gè)__cpu_flush在這里就是我們proc-v6.S里面的__v6_setup函數(shù)了，具體它的實(shí)現(xiàn)我就不分析了，都是對arm控制寄存器的操作，這里轉(zhuǎn)一下它對這部分操作的注釋，看完之后就基本知道它完成的功能了。

/*

* __v6_setup

*

* Initialise TLB, Caches, and MMU state ready to switch the MMU

* on. Return in r0 the new CP15 C1 control register setting.

*

* We automatically detect if we have a Harvard cache, and use the

* Harvard cache control instructions insead of the unified cache

* control instructions.

*

* This should be able to cover all ARMv6 cores.

*

* It is assumed that:

* - cache type register is implemented

*/

完成這部分關(guān)于CPU的操作以后，下面就是打開MMU了，這部分內(nèi)容也沒什么好說的，也是對arm控制寄存器的操作，打開MMU以后我們就可以使用虛擬地址了，而不需要我們自己來進(jìn)行地址的重定位，ARM硬件會(huì)完成這部分的工作。打開MMU以后，會(huì)將SP的值賦給PC，這樣代碼就會(huì)跳到 __switch_data來運(yùn)行，這個(gè)__switch_data是一個(gè)定義在head-common.S里面的結(jié)構(gòu)體，我們實(shí)際上是跳到它地一個(gè)函數(shù)指針__mmap_switched處執(zhí)行的。

這個(gè)switch的執(zhí)行過程我們只是簡單看一下，前面的copy data_loc段以及清空.bss段就不用說了，它后面會(huì)將proc的信息和machine的信息保存在__switch_data這個(gè)結(jié)構(gòu)體里面，而這個(gè)結(jié)構(gòu)體將來會(huì)在start_kernel的setup_arch里面被使用到。這個(gè)在后面的對start_kernel的詳細(xì)分析中會(huì)講到。另外這個(gè) switch還涉及到控制寄存器的一些操作，這里我不沒仔細(xì)研究spec，不懂也就不說了～

好啦，switch操作完成以后就會(huì)b start_kernel了～ 這樣就進(jìn)入了c代碼的運(yùn)行了，下一篇文章仔細(xì)研究這個(gè)start_kernel的函數(shù)～～

Ref:

http://linux.chinaunix.net/bbs/thread-1021226-1-1.html

http://blog.csdn.net/yhmhappy2006/archive/2008/08/06/2775239.aspx

http://blog.csdn.net/sustzombie/archive/2010/06/12/5667607.aspx

評論


技術(shù)專區(qū)

關(guān)閉