尽管这儿的Arm Linux kernel前面加上了Android，但实践上仍是和遍及Arm linux kernel发动的进程相同的，这儿仅仅结合一下Android的Makefile，讲一下bootimage生成的一个进程。这篇文档首要描绘 bootimage的结构，以及kernel真实履行前的解压进程。
在了解这些之前咱们首要需求了解几个名词，这些名词界说在/Documentation/arm/Porting里边，这儿首要说到其间的几个，其他几个会在后边kernel的履行进程中叙述：
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项是有必要的，最终一项是可选的。
- /*
- +—————–+
- |bootheader|1page
- +—————–+
- |kernel|npages
- +—————–+
- |ramdisk|mpages
- +—————–+
- |secondstage|opages
- +—————–+
- 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.allentitiesarepage_sizealignedinflash
- 1.kernelandramdiskarerequired(size!=0)
- 2.secondisoptional(second_size==0->nosecond)
- 3.loadeachelement(kernel,ramdisk,second)at
- thespecifiedphysicaladdress(kernel_addr,etc)
- 4.preparetagsattag_addr.kernel_args[]is
- appendedtothekernelcommandlineinthetags.
- 5.r0=0,r1=MACHINE_TYPE,r2=tags_addr
- 6.ifsecond_size!=0:jumptosecond_addr
- else:jumptokernel_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 */
关于boot header这个数据结构咱们需求要点留意，在这儿咱们重视其间几个比较重要的值，这些值界说在boot/boardconfig.h里边，不同的芯片对应vendor下不同的boardconfig，在这儿咱们的值别离是（别离是kernel/ramdis/tags载入ram的物理地址）：
#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 ～
- $(obj)/Image:vmlinuxFORCE
- $(callif_changed,objcopy)
- @echoKernel:$@isready
- $(obj)/compressed/vmlinux:$(obj)/ImageFORCE
- $(Q)$(MAKE)$(build)=$(obj)/compressed$@
- $(obj)/zImage:$(obj)/compressed/vmlinuxFORCE
- $(callif_changed,objcopy)
- @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：
- $(obj)/vmlinux:$(obj)/vmlinux.lds$(obj)/$(HEAD)$(obj)/piggy.o/
- $(addprefix$(obj)/,$(OBJS))FORCE
- $(callif_changed,ld)
- @:
- $(obj)/piggy.gz:$(obj)/../ImageFORCE
- $(callif_changed,gzip)
- $(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：
- 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); }
能够看到咱们最开端的section便是.start，所以咱们是从start段开端履行的。ELF对程序的进口地址是有界说的，这能够参照*.lds 的语法规矩里边有描绘，别离是GNU LD的-E —> *.lds里边的ENTRY界说 —> start Symbol —> .text section —>0。在这儿是没有这些判别的，由于还没有操作体系，bootloader会直接跳到这个start的地址开端履行。
在这儿略微带一句，假如觉得head.S看的不太舒畅的话，比方有些跳转并不知道意思，能够直接objdump vmlinx来看，dump出来的汇编的流程就比较明晰了。
- 1:movr7,r1@savearchitectureID
- movr8,r2@saveatagspointer
- #ifndef__ARM_ARCH_2__
- /*
- *BootingfromAngel-needtoenterSVCmodeanddisable
- *FIQs/IRQs(numericdefinitionsfromangelarm.hsource).
- *Weonlydothisifwewereinusermodeonentry.
- */
- mrsr2,cpsr@getcurrentmode
- tstr2,#3@notuser?
- bnenot_angel@假如不是
- movr0,#0x17@angel_SWIreason_EnterSVC
- swi0x123456@angel_SWI_ARM
- not_angel:
- mrsr2,cpsr@turnoffinterruptsto
- orrr2,r2,#0xc0@preventangelfromrunning
- 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的值，然后进入超级用户形式，并封闭中止。
- .text
- adrr0,LC0
- ldmiar0,{r1,r2,r3,r4,r5,r6,ip,sp}
- subsr0,r0,r1@calculatethedeltaoffset
- @ifdeltaiszero,weare
- beqnot_relocated@runningattheaddresswe
- @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段头部的偏移。
- addr5,r5,r0
- addr6,r6,r0
- addip,ip,r0
add r5, r5, r0 add r6, r6, r0 add ip, ip, r0
然后便是重定位了，即都加上一个偏移，经过重定位今后就都是肯定地址了。
- not_relocated:movr0,#0
- 1:strr0,[r2],#4@clearbss
- strr0,[r2],#4
- strr0,[r2],#4
- strr0,[r2],#4
- cmpr2,r3
- blo1b
- /*
- *TheCruntimeenvironmentshouldnowbesetup
- *sufficiently.Turnthecacheon,setupsome
- *pointers,andstartdecompressing.
- */
- 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。
- movr1,sp@mallocspaceabovestack
- addr2,sp,#0x10000@64kmax
mov r1, sp @ malloc space above stack add r2, sp, #0x10000 @ 64k max
解压的进程首要是在仓库之上请求一个空间
- /*
- *Checktoseeifwewilloverwriteourselves.
- *r4=finalkerneladdress
- *r5=startofthisimage
- *r2=endofmallocspace(andthereforethisimage)
- *Webasicallywant:
- *r4>=r2->OK
- *r4+imagelength<=r5->OK
- */
- cmpr4,r2
- bhswont_overwrite
- subr3,sp,r5@>compressedkernelsize
- addr0,r4,r3,lsl#2@allowfor4xexpansion
- cmpr0,r5
- blswont_overwrite
- movr5,r2@decompressaftermallocspace
- movr0,r5
- movr3,r7
- bldecompress_kernel
- addr0,r0,#127+128@alignment+stack
- 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处于最终边，所以成说是最上面）
- *r0=decompressedkernellength
- *r1-r3=unused
- *r4=kernelexecutionaddress
- *r5=decompressedkernelstart
- *r6=processorID
- *r7=architectureID
- *r8=atagspointer
- *r9-r14=corrupted
- */
- addr1,r5,r0@endofdecompressedkernel
- adrr2,reloc_start
- ldrr3,LC1
- addr3,r2,r3
- :ldmiar2!,{r9-r14}@copyrelocationcode
- stmiar1!,{r9-r14}
- ldmiar2!,{r9-r14}
- stmiar1!,{r9-r14}
- cmpr2,r3
- blo1b
- addsp,r1,#128@relocatethestack
- blcache_clean_flush
- 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后边去了，然后跳转到重定位代码开端履行。
- /*
- *Allcodefollowingthislineisrelocatable.Itisrelocatedby
- *theabovecodetotheendofthedecompressedkernelimageand
- *executedthere.Duringthistime,wehavenostacks.
- *
- *r0=decompressedkernellength
- *r1-r3=unused
- *r4=kernelexecutionaddress
- *r5=decompressedkernelstart
- *r6=processorID
- *r7=architectureID
- *r8=atagspointer
- *r9-r14=corrupted
- */
- .align5
- reloc_start:addr9,r5,r0
- subr9,r9,#128@donotcopythestack
- debug_reloc_start
- movr1,r4
- 1:
- .rept4
- ldmiar5!,{r0,r2,r3,r10-r14}@relocatekernel
- stmiar1!,{r0,r2,r3,r10-r14}
- .endr
- cmpr5,r9
- blo1b
- addsp,r1,#128@relocatethestack
- debug_reloc_end
- call_kernel:blcache_clean_flush
- blcache_off
- movr0,#0@mustbezero
- movr1,r7@restorearchitecturenumber
- movr2,r8@restoreatagspointer
- 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上都是差不多相同的。
前面说过解压今后，代码会跳到解压完结今后的vmlinux开端履行，详细从什么当地开端履行咱们能够看看生成的vmlinux.lds(arch/arm/kernel/)这个文件：
- OUTPUT_ARCH(arm)
- ENTRY(stext)
- jiffies=jiffies_64;
- SECTIONS
- {
- .=0x80000000+0x00008000;
- .text.head:{
- _stext=.;
- _sinittext=.;
- *(.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：
- .section”.text.head”,”ax”
- Y(stext)
- msrcpsr_c,#PSR_F_BIT|PSR_I_BIT|SVC_MODE@ensuresvcmode
- @andirqsdisabled
- mrcp15,0,r9,c0,c0@getprocessorid
- 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里边被调用。
- #ifndefENTRY
- #defineENTRY(name)/
- .globlname;/
- ALIGN;/
- name:
- #endif
- #ifndefWEAK
- #defineWEAK(name)/
- .weakname;/
- name:
- #endif
- #ifndefEND
- #defineEND(name)/
- .sizename,.-name
- #endif
- /*Ifsymbolnameistreatedasasubroutine(getscalled,andreturns)
- *thenpleaseuseENDPROCtomarknameasSTT_FUNCforthebenefitof
- *staticanalysistoolssuchasstackdepthanalyzer.
- */
- #ifndefENDPROC
- #defineENDPROC(name)/
- .typename,@function;/
- END(name)
- #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跑的进程：
- msrcpsr_c,#PSR_F_BIT|PSR_I_BIT|SVC_MODE@ensuresvcmode
- @andirqsdisabled
- 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等等。
然后跳转到__lookup_processor_type，这个函数界说在head-common.S里边，这儿的bl指令会保存当时的pc在lr里边，最终__lookup_processor_type会从这个函数回来，咱们详细看看这个函数：
- __lookup_processor_type:
- adrr3,3f
- ldmdar3,{r5-r7}
- subr3,r3,r7@getoffsetbetweenvirt&phys
- addr5,r5,r3@convertvirtaddressesto
- addr6,r6,r3@physicaladdressspace
- 1:ldmiar5,{r3,r4}@value,mask
- andr4,r4,r9@maskwantedbits
- teqr3,r4
- beq2f
- addr5,r5,#PROC_INFO_SZ@sizeof(proc_info_list)
- cmpr5,r6
- blo1b
- movr5,#0@unknownprocessor
- 2:movpc,lr
- 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，咱们能够看看这个结构体：
- .section”.proc.info.init”,#alloc,#execinstr
- /*
- *MatchanyARMv6processorcore.
- */
- .type__v6_proc_info,#object
- _proc_info:
- .long0x0007b000
- .long0x0007f000
- .longPMD_TYPE_SECT|/
- PMD_SECT_BUFFERABLE|/
- PMD_SECT_CACHEABLE|/
- PMD_SECT_AP_WRITE|/
- PMD_SECT_AP_READ
- .longPMD_TYPE_SECT|/
- PMD_SECT_XN|/
- PMD_SECT_AP_WRITE|/
- PMD_SECT_AP_READ
- b__v6_setup
- .longcpu_arch_name
- .longcpu_elf_name
- .longHWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA
- .longcpu_v6_name
- .longv6_processor_functions
- .longv6wbi_tlb_fns
- .longv6_user_fns
- .longv6_cache_fns
- .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回来。
- bl__lookup_machine_type@r5=machinfo
- movsr8,r5@invalidmachine(r5=0)?
- 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里边，咱们看看它详细的完结：
- __lookup_machine_type:
- adrr3,3b
- ldmiar3,{r4,r5,r6}
- subr3,r3,r4@getoffsetbetweenvirt&phys
- addr5,r5,r3@convertvirtaddressesto
- addr6,r6,r3@physicaladdressspace
- 1:ldrr3,[r5,#MACHINFO_TYPE]@getmachinetype
- teqr3,r1@matchesloadernumber?
- beq2f@found
- addr5,r5,#SIZEOF_MACHINE_DESC@nextmachine_desc
- cmpr5,r6
- blo1b
- movr5,#0@unknownmachine
- 2:movpc,lr
- 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)，它详细的完结依据你对芯片类型的挑选而不同，这儿咱们运用的是高通的7×27,详细完结在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的剖析～
- __vet_atags:
- tstr2,#0x3@aligned?
- bne1f
- ldrr5,[r2,#0]@isfirsttagATAG_CORE?
- cmpr5,#ATAG_CORE_SIZE
- cmpner5,#ATAG_CORE_SIZE_EMPTY
- bne1f
- ldrr5,[r2,#4]
- ldrr6,=ATAG_CORE
- cmpr5,r6
- bne1f
- movpc,lr@atagpointerisok
- 1:movr2,#0
- movpc,lr
- 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这个函数履行。
- ldrr13,__switch_data@addresstojumptoafter
- @mmuhasbeenenabled
- adrlr,__enable_mmu@return(PIC)address
- 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
