新聞中心
        
	
        
	
        
	
        EEPW首頁 
	 > 嵌入式系統 > 設計應用 > Android arm linux kernel啟動流程
        
    
        

        

        


	
	
	

        
	
        
		
        
			
        Android arm linux kernel啟動流程
        
						
        
				作者：
				時間：2016-11-09
				來源：網絡

							
				
				
				
				收藏
			
        

			
        
				
				
			
        

			
        
			
			
        
			
			
        
				
				
			
        
                
			雖然這里的Arm Linux kernel前面加上了Android，但實際上還是和普遍Arm linux kernel啟動的過程一樣的，這里只是結合一下Android的Makefile，講一下bootimage生成的一個過程。這篇文檔主要描述 bootimage的構造，以及kernel真正執行前的解壓過程。
          在了解這些之前我們首先需要了解幾個名詞，這些名詞定義在/Documentation/arm/Porting里面，這里首先提到其中的幾個，其余幾個會在后面kernel的執行過程中講述：
        本文引用地址：http://www.104case.com/article/201611/317991.htm
          1）ZTEXTADDR boot.img運行時候zImage的起始地址，即kernel解壓代碼的地址。這里沒有虛擬地址的概念，因為沒有開啟MMU，所以這個地址是物理內存的地址。解壓代碼不一定需要載入RAM才能運行，在FLASH或者其他可尋址的媒體上都可以運行。
          2）ZBSSADDR 解壓代碼的BSS段的地址，這里也是物理地址。
          3）ZRELADDR 這個是kernel解壓以后存放的內存物理地址，解壓代碼執行完成以后會跳到這個地址執行kernel的啟動，這個地址和后面kernel運行時候的虛擬地址滿足：__virt_to_phys(TEXTADDR) = ZRELADDR。
          4）INITRD_PHYS Initial Ram Disk存放在內存中的物理地址，這里就是我們的ramdisk.img。
          5）INITRD_VIRT Initial Ram Disk運行時候虛擬地址。
          6）PARAMS_PHYS 內核啟動的初始化參數在內存上的物理地址。
          下面我們首先來看看boot.img的構造，了解其中的內容對我們了解kernel的啟動過程是很有幫助的。首先來看看Makefile是如何產生我們的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
          根據上面的命令我們可以首先看看mkbootimg-msm7627ffa這個工具的源文件：system/core/mkbootimg.c。看完之后我們就能很清晰地看到boot.img的內部構造，它是由boot header /kernel /ramdisk /second stage構成的，其中前3項是必須的，最后一項是可選的。
          
        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 */ 
          關于boot header這個數據結構我們需要重點注意，在這里我們關注其中幾個比較重要的值，這些值定義在boot/boardconfig.h里面，不同的芯片對應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) 
          上面這些值分別和我們開篇時候提到的那幾個名詞相對應，比如kernel_addr就是ZTEXTADDR，RAMDISK_ADDR就是 INITRD_PHYS,而TAGS_ADDR就是PARAMS_PHYS。bootloader會從boot.img的分區中將kernel和 ramdisk分別讀入RAM上面定義的地址中，然后就會跳到ZTEXTADDR開始執行。
          基本了解boot.img的內容之后我們來分別看看里面的ramdisk.img和kernel又是如何產生的，以及其包含的內容。從簡單的說起，我們先看看ramdisk.img，這里首先要強調一下這個ramdisk.img在arm linux中的作用。它在kernel啟動過程中充當著第一階段的文件系統，是一個CPIO格式打成的包。通俗上來講他就是我們將生成的root目錄，用 CPIO方式進行了打包，然后在kernel啟動過程中會被mount作為文件系統，當kernel啟動完成以后會執行init，然后將 system.img再mount進來作為Android的文件系統。在這里稍微解釋下這個mount的概念，所謂mount實際上就是告訴linux虛擬文件系統它的根目錄在哪，就是說我這個虛擬文件系統需要操作的那塊區域在哪，比如說ramdisk實際上是我們在內存中的一塊區域，把它作為文件系統的意思實際上就是告訴虛擬文件系統你的根目錄就在我這里，我的起始地址賦給你，你以后就能對我進行操作了。實際上我們也可以使用rom上的一塊區域作為根文件系統，但是rom相對ram慢，所以這里使用ramdisk。然后我們在把system.img mount到ramdisk的system目錄，實際上就是將system.img的地址給了虛擬文件系統，然后虛擬文件系統訪問system目錄的時候會重新定位到對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產生的過程，老方法，從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   
          我們分解地來看各個步驟，第一個是將vmlinux經過objcopy后生成一個未經壓縮的raw binary(Image 4M左右)，這里的vmlinux是我們編譯鏈接以后生成的vmlinx，大概60多M。這里稍微說一下這個objcopy，在啟動的時候ELF格式是沒法執行的，ELF格式的解析是在kernel啟動以后有了操作系統之后才能進行的。因為雖然我們編出的img雖然被編成ELF格式，但要想啟動起來必須將其轉化成原始的二進制格式，我們可以多照著man objcopy和OBJCOPYFLAGS  :=-O binary -R .note -R .note.gnu.build-id -R .comment -S(arch/arm/Makefile)來看看這些objcopy具體做了什么事情 ～
          得到Image以后，再將這個Image跟解壓代碼合成一個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 
          從這里我們就可以看出來實際上這個vmlinux就是將Image壓縮以后根據vmlinux.lds與解壓代碼head.o和misc.o鏈接以后生成的一個elf，而且用readelf或者objdump可以很明顯地看到解壓代碼是PIC的，所有的虛擬地址都是相對的，沒有絕對地址。這里的 vmlinx.lds可以對照著后面的head.s稍微看一下～得到壓縮以后的vmlinx以后再將這個vmlinx經過objcopy以后就得到我們的 zImage了，然后拷貝到out目錄下就是我們的kernel了～～
          在這里要強調幾個地址，這些地址定義在arch/arm/mach-msm/makefile.boot里面，被arch/arm/boot /Makefile調用，其中zreladdr-y就是我們的kernel被解壓以后要釋放的地址了，解壓代碼跑完以后就會跳到這個地址來執行 kernel的啟動。不過這里還有其他兩個PHYS，跟前面定義在boardconfig.h里面的值重復了，不知道這兩個值在這里定義跟前面的值是一種什么關系？？？
           好啦，講到這里我們基本就知道boot.img的構成了，下面我們就從解壓的代碼開始看看arm linux kernel啟動的一個過程，這個解壓的source就是/arch/arm/boot/compressed/head.S。要看懂這個匯編需要了解 GNU ASM以及ARM匯編指令，ARM指令就不說了，ARM RVCT里面的文檔有得下，至于GNU ASM，不需要消息了解的話主要是看一下一些偽指令的含義（http://sources.redhat.com/binutils/docs-2.12 /as.info/Pseudo-Ops.html#Pseudo%20Ops）
           那么我們現在就開始分析這個解壓的過程：
           1）bootloader會傳遞2個參數過來，分別是r1=architecture ID, r2=atags pointer。head.S從哪部分開始執行呢，這個我們可以看看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段開始執行的。ELF對程序的入口地址是有定義的，這可以參照*.lds 的語法規則里面有描述，分別是GNU LD的-E ---> *.lds里面的ENTRY定義 ---> start Symbol ---> .text section --->0。在這里是沒有這些判斷的，因為還沒有操作系統，bootloader會直接跳到這個start的地址開始執行。
           在這里稍微帶一句，如果覺得head.S看的不太舒服的話，比如有些跳轉并不知道意思，可以直接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的值，然后進入超級用戶模式，并關閉中斷。
           
        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當前的運行地址和鏈接地址是否一樣，如果一樣就不需要重定位，如果不一樣則需要進行重定位。這里肯定是不相等的，因為我們可以通過 objdump看到LC0的地址是0x00000138，是一個相對地址，然后adr r0, LC0 實際上就是將LC0當前的運行地址，而我們直接跳到ZTEXTADDR跑的，實際上PC里面現在的地址肯定是0x00208000以后的一個值，adr r0, LC0編譯之后實際上為addr0, pc, #208，這個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 
          然后就是重定位了，即都加上一個偏移，經過重定位以后就都是絕對地址了。
          
        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，具體這個打開cache的過程咱沒仔細研究過，大致過程是先從C0里面讀到processor ID，然后根據ID來進行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
           解壓的過程首先是在堆棧之上申請一個空間
          
        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 
           這個過程是判斷我們解壓出的vmlinx會不會覆蓋原來的zImage，這里的final kernel address就是解壓后的kernel要存放的地址，而start of this image則是zImage在內存中的地址。根據我們前面的分析，現在這兩個地址是重復的，即都是0x00208000。同樣r2是我們申請的一段內存空間，因為他是在sp上申請的，而根據vmlinx.lds我們知道stack實際上處與vmlinx的最上面，所以r4>=r2是不可能的，這里首先計算zImage的大小，然后判斷r4+r3是不是比r5小，很明顯r4和r5的值是一樣的，所以這里先將r2的值賦給r0，經kernel先解壓到s 申請的內存空間上面，具體的解壓過程就不描述了，定義在misc.c里面。（這里我所說的上面是指內存地址的高地址，默認載入的時候從低地址往高地址寫，所以從內存低地址開始運行，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 
          因為沒有將kernel解壓在要求的地址，所以必須重定向，說穿了就是要將解壓的kernel拷貝到正確的地址，因為正確的地址與zImage的地址是重合的，而要拷貝我們又要執行zImage的重定位代碼，所以這里首先將重定位代碼reloc_start拷貝到vmlinx上面，然后再將vmlinx 拷貝到正確的地址并覆蓋掉zImage。這里首先計算出解壓后的vmlinux的高地址放在r1里面，r2存放著重定位代碼的首地址，r3存放著重定位代碼的size，這樣通過拷貝就將reloc_start移動到vmlinx后面去了，然后跳轉到重定位代碼開始執行。
          
        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，然后就跳轉到真正kernel啟動的過程～～
          最后我們來總結一下一個基本的過程：
          1）當bootloader要從分區中數據讀到內存中來的時候，這里涉及最重要的兩個地址，一個就是ZTEXTADDR還有一個是 INITRD_PHYS。不管用什么方式來生成IMG都要讓bootloader有方法知道這些參數，不然就不知道應該將數據從FLASH讀入以后放在什么地方，下一步也不知道從哪個地方開始執行了；
          2）bootloader將IMG載入RAM以后，并跳到zImage的地址開始解壓的時候，這里就涉及到另外一個重要的參數，那就是 ZRELADDR，就是解壓后的kernel應該放在哪。這個參數一般都是arch/arm/mach-xxx下面的Makefile.boot來提供的；
          3）另外現在解壓的代碼head.S和misc.c一般都會以PIC的方式來編譯，這樣載入RAM在任何地方都可以運行，這里涉及到兩次沖定位的過程，基本上這個重定位的過程在ARM上都是差不多一樣的。
        寫這個總結的時候咱的心情是沉重的，因為還有好多東西沒弄明白。。。感嘆自己的知識還是淺薄得很，前途錢途漫漫阿～～不過基本脈絡是清楚的，具體的細節只能留在以后有時間再啃了。這里的第二部分啟動流程指的是解壓后kernel開始執行的一部分代碼，這部分代碼和ARM體系結構是緊密聯系在一起的，所以最好是將ARM ARCHITECTURE REFERENCE MANUL仔細讀讀，尤其里面關于控制寄存器啊，MMU方面的內容～
         前面說過解壓以后，代碼會跳到解壓完成以后的vmlinux開始執行，具體從什么地方開始執行我們可以看看生成的vmlinux.lds(arch/arm/kernel/)這個文件：
          
        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的內容，以為這時候我們沒有操作系統，根本不知道如何來解析這里的入口地址，我們只能來分析他的section(不過一般來說這里的ENTRY和我們從seciton分析的結果是一樣的)，這里的.text.head section我們很容易就能在arch/arm/kernel/head.S里面找到，而且它里面的第一個符號就是我們的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這個宏實際我們可以在include/linux/linkage.h里面找到，可以看到他實際上就是聲明一個GLOBAL Symbol，后面的ENDPROC和END唯一的區別是前面的聲明了一個函數，可以在c里面被調用。
          
        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的起始代碼我們就來進行分析了，先總體概括一下這部分代碼所完成的功能，head.S會首先檢查proc和arch以及atag的有效性，然后會建立初始化頁表，并進行CPU必要的處理以后打開MMU，并跳轉到start_kernel這個symbol開始執行后面的C代碼。這里有很多變量都是我們進行kernel移植時需要特別注意的，下面會一一講到。
          在這里我們首先看看這段匯編開始跑的時候的寄存器信息，這里的寄存器內容實際上是同bootloader跳轉到解壓代碼是一樣的，就是r1=arch r2=atag addr。下面我們就具體來看看這個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 
          首先進入SVC模式并關閉所有中斷，并從arm協處理器里面讀到CPU ID，這里的CPU主要是指arm架構相關的CPU型號，比如ARM9，ARM11等等。
          
        view plainprint?
           然后跳轉到__lookup_processor_type，這個函數定義在head-common.S里面，這里的bl指令會保存當前的pc在lr里面，最后__lookup_processor_type會從這個函數返回，我們具體看看這個函數：  
          
        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) 
           他這里的執行過程其實比較簡單就是在__proc_info_begin和__proc_info_end這個段里面里面去讀取我們注冊在里面的 proc_info_list這個結構體，這個結構體的定義在arch/arm/include/asm/procinfo.h，具體實現根據你使用的 cpu的架構在arch/arm/mm/里面找到具體的實現，這里我們使用的ARM11是proc-v6.S，我們可以看看這個結構體：
          
        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我們就知道各個成員變量的含義了，他這里lookup的過程實際上是先求出這個proc_info_list的實際物理地址，并將其內容讀出，然后將其中的mask也就是我們這里的0x007f000與寄存器與之后與0x007b00進行比較，如果一樣的話呢就校驗成功了，如果不一樣呢就會讀下一個proc_info的信息，因為proc一般都是只有一個的，所以這里一般不會循環，如果檢測正確寄存器就會將正確的proc_info_list的物理地址賦給寄存器，如果檢測不到就會將寄存器值賦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了，這個函數的實現也在head－common.S里面，我們看看它具體的實現：
           
        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的檢查是一樣的，這里主要檢查芯片的類型，比如我們現在的芯片是MSM7X27FFA，這也是一個結構體，它的頭文件在 arch/arm/include/asm/arch/arch.h里面(machine_desc)，它具體的實現根據你對芯片類型的選擇而不同，這里我們使用的是高通的7x27,具體實現在arch/arm/mach-msm/board-msm7x27.c里面，這些結構體最后都會注冊到 _arch_info_begin和_arch_info_end段里面，具體的大家可以看看vmlinux.lds或者system.map，這里的 lookup會根據bootloader傳過來的nr來在__arch_info里面的相匹配的類型，沒有的話就尋找下一個machin_desk結構體，直到找到相應的結構體，并會將結構體的地址賦值給寄存器，如果沒有的話就會賦值為0的。一般來說這里的machine_type會有好幾個，因為不同的芯片類型可能使用的都是同一個cpu架構。
           對processor和machine的檢查完以后就會檢查atags parameter的有效性，關于這個atag具體的定義我們可以在./include/asm/setup.h里面看到，它實際是一個結構體和一個聯合體構成的結合體，里面的size都是以字來計算的。這里的atags param是bootloader創建的，里面包含了ramdisk以及其他memory分配的一些信息，存儲在boot.img頭部結構體定義的地址中，具體的大家可以看咱以后對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對不對，基本沒什么好分析的，代碼也比較好看～ 下面我們來看后面一個重頭戲，就是創建初始化頁表，說實話這段內容我沒弄清楚，它需要對ARM VIRT MMU具有相當的理解，這里我沒有太多的時間去分析spec，只是粗略了翻了ARM V7的manu，知道這里建立的頁表是arm的secition頁表，完成內存開始1m內存的映射，這個頁表建立在kernel和atag paramert之間，一般是4000-8000之間～具體的代碼和過程我這里就不貼了，大家可以看看參考的鏈接，看看其他大蝦的分析，我還沒怎么看明白，等以后仔細研究ARM MMU的時候再回頭來仔細研究了，不過代碼雖然不分析，這里有幾個重要的地址需要特別分析下～
          這幾個地址都定義在arch/arm/include/asm/memory.h，我們來稍微分析下這個頭文件，首先它包含了arch /memory.h，我們來看看arch/arm/mach-msm/include/mach/memory.h，在這個里面定義了#define PHYS_OFFSET   UL(0x00200000) 這個實際上是memory的物理內存初始地址，這個地址和我們以前在boardconfig.h里面定義的是一致的。然后我們再看 asm/memory.h，他里面定義了我們的memory虛擬地址的首地址#define PAGE_OFFSET   UL(CONFIG_PAGE_OFFSET)。  
          另外我們在head.S里面看到kernel的物理或者虛擬地址的定義都有一個偏移，這個偏移又是從哪來的呢，實際我們可以從arch/arm /Makefile里面找到：textofs-y  := 0x00008000  TEXT_OFFSET := $(textofs-y)這樣我們再看kernel啟動時候的物理地址和鏈接地址，實際上它和我們前面在boardconfig.h和 Makefile.boot里面定義的都是一致的～
          建立初始化頁表以后，會首先將__switch_data這個symbol的鏈接地址放在sp里面，然后獲得__enable_mmu的物理地址，然后會跳到__proc_info_list里面的INITFUNC執行，這個偏移是定義在arch/arm/kernel/asm-offset.c里面，實際上就是取得__proc_info_list里面的__cpu_flush這個函數執行。
          
        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 
          這個__cpu_flush在這里就是我們proc-v6.S里面的__v6_setup函數了，具體它的實現我就不分析了，都是對arm控制寄存器的操作，這里轉一下它對這部分操作的注釋，看完之后就基本知道它完成的功能了。
        /*
        * __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
        */  
           完成這部分關于CPU的操作以后，下面就是打開MMU了，這部分內容也沒什么好說的，也是對arm控制寄存器的操作，打開MMU以后我們就可以使用虛擬地址了，而不需要我們自己來進行地址的重定位，ARM硬件會完成這部分的工作。打開MMU以后，會將SP的值賦給PC，這樣代碼就會跳到 __switch_data來運行，這個__switch_data是一個定義在head-common.S里面的結構體，我們實際上是跳到它地一個函數指針__mmap_switched處執行的。
           這個switch的執行過程我們只是簡單看一下，前面的copy data_loc段以及清空.bss段就不用說了，它后面會將proc的信息和machine的信息保存在__switch_data這個結構體里面，而這個結構體將來會在start_kernel的setup_arch里面被使用到。這個在后面的對start_kernel的詳細分析中會講到。另外這個 switch還涉及到控制寄存器的一些操作，這里我不沒仔細研究spec，不懂也就不說了～
           好啦，switch操作完成以后就會b start_kernel了～ 這樣就進入了c代碼的運行了，下一篇文章仔細研究這個start_kernel的函數～～
        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

        
				
            
                
			
							
        
                
			              
              
            
        
		
        
		
        
		
        
		
        
		
        
			
          
				
        • 
					
					
			  	
          • 
			  	
        • 
					
					
			  	
          • 
			  	
        • 
					
					
			  	
          • 
				
        • 
					
					
				
          • 
				
        • 
					
					
				
          • 
			
        
			
        
		
        
		
		
        
		
        
			
			
		
        
        
			
		

	

        
	
	
        
		
        
			
        評論
        					
		
        
		
        
			
        
			
				
        
					
					
        
						
                        
					
        
				
        
                		
						
						
			
        
		
        
		
        
		
        
            
			
            
		
        
	
        
	
        
	
        
		
		

        


	
        
	
        
		
		
	
        


    
        
        
        技術專區
        
      
        
      
        
			
      
         
       

        

   











        
	
        
	    關閉
	
        
	
	

        














	
	



        




        





主站蜘蛛池模板：
佛教|
海门市|
高安市|
长宁县|
教育|
楚雄市|
五大连池市|
余庆县|
乌审旗|
聊城市|
南澳县|
顺义区|
泽州县|
云安县|
湖南省|
卓尼县|
赤城县|
沙河市|
同仁县|
抚顺县|
金平|
儋州市|
宜城市|
丰镇市|
唐山市|
阳朔县|
靖江市|
平昌县|
安徽省|
定日县|
桐柏县|
九龙城区|
腾冲县|
嘉荫县|
页游|
盘山县|
永州市|
长武县|
新营市|
呼伦贝尔市|
成安县|