本文以盛行的Samsung公司的S3C2410，openmoko渠道和linux-2.6.24为例，介绍如安在ZIX嵌入式开发环境下探究linux内核发动进程。
Linux内核发动一般由外部的bootloader引导，也能够在内核头部嵌入一个loader，实践的运用中这两种方法都会常常遇到。所以要了 解内核发动最开端的进程，有必要对bootloader怎么引导内核有所了解。下面咱们从u-boot加载linux内核的代码开端剖析（关于u-boot 本身的发动流程，请参阅u-boot 发动进程 —— 依据S3C2410）。
在u-boot的do_bootm_linux函数里，完结了处理器架构相关的linux内核加载代码，特别是tags传递。
该函数中，在lib_arm/bootm.c的76行调用了getenv将bootargs环境变量保存在commandline
char*commandline =getenv(“bootargs”);
然后解析uImage文件头，而且依照头中的界说分化和加载uImage。所以这部分代码的运转取决于uImage文件是怎么生成的，本文不做过多叙说，可参阅另文了解u-boot运用。接下来进行tags设置作业，别离调用了
- setup_start_tag()
- setup_memory_tag()
- setup_commandline_tag()
- setup_initrd_tag()
- setup_end_tag()
然后对TLB、cache等进行ivalid操作，这是经过在lib_arm/bootm.c的156行调用cleanup_before_linux()完结，然后即可跳入从uImage平分化出来的内核Image或zImage进口
cleanup_before_linux (); theKernel (0, machid, bd->bi_boot_params); /* does not return */return;
在s3c2410渠道上，该进口theKernel一般是物理地址0x30008000。假如咱们运用zImage自解压内核映像，对应的代码正是 自解压头，方位在内核源码linux-2.6.24-moko-linuxbj的arch/arm/boot/compressed/start.S第 114行的start符号
start: .type start,#function .rept 8 mov r0, r0 .endr b 1f .word 0x016f2818 @ Magic numbers to help the loader .word start @ absolute load/run zImage address .word _edata @ zImage end address 1: mov r7, r1 @ save architecture ID mov r8, r2 @ save atags pointer
这也标志着u-boot将体系彻底的交给了OS，bootloader生命停止。之后代码在133行会读取cpsr并判别是否处理器处于supervisor形式——从u-boot进入kernel，体系现已处于SVC32形式；而运用angel进入则处于user形式，还需求额定两条指令。之后是再次承认中止封闭，并完结cpsr写入
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
然后在LC0地址处将分段信息导入r0-r6、ip、sp等寄存器，并查看代码是否运转在与链接时相同的方针地址，以决议是否进行处理。因为现在很少有人不运用loader和tags，将zImage烧写到rom直接从0x0方位履行，所以这个处理是有必要的（可是zImage的头现在也保留了不必loader也可发动的才能）。arm架构下自解压头一般是链接在0x0地址而被加载到0x30008000运转，所以要批改这个改变。涉及到
- r5寄存器寄存的zImage基地址
- r6和r12（即ip寄存器）寄存的got（global offset table）
- r2和r3寄存的bss段起止地址
- sp栈指针地址
很简单，这些寄存器通通被加上一个你也能猜到的偏移地址 0x30008000。该地址是s3c2410相关的，其他的ARM处理器能够参阅下表
- PXA2xx是0xa0008000
- IXP2x00和IXP4xx是0x00008000
- Freescale i.MX31/37是0x80008000
- TI davinci DM64xx是0x80008000
- TI omap系列是0x80008000
- AT91RM/SAM92xx系列是0x20008000
- Cirrus EP93xx是0x00008000
这些操作发生在代码172行开端的当地，下面只张贴一部分
add r5, r5, r0 add r6, r6, r0 add ip, ip, r0
后边在211跋涉行bss段的清零作业
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
然后224行，翻开cache，并为后边解紧缩设置64KB的暂时malloc空间
bl cache_on mov r1, sp @ malloc space above stack add r2, sp, #0x10000 @ 64k max
接下来238跋涉行查看，确认内核解紧缩后的Image方针地址是否会掩盖到zImage头，假如是则预备将zImage头转移到解压出来的内核后边
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
真实情况——在大多数的运用中，内核编译都会把紧缩的zImage和非紧缩的Image链接到相同的地址，s3c2410渠道下便是0x30008000。这样做的优点是，人们不必关怀内核是Image仍是zImage，放到这个方位履行就OK，所以在解紧缩后zImage头有必要为真实的内核让路。
在250行解压完毕，内核长度回来值寄存在r0寄存器里。在内核结尾空出128字节的栈空间用，而且使其长度128字节对齐。
add r0, r0, #127 + 128 @ alignment + stack bic r0, r0, #127 @ align the kernel length
算出搬移代码的参数：核算内核结尾地址并寄存于r1寄存器，需求搬移代码本来地址放在r2，需求搬移的长度放在r3。然后履行搬移，并设置好sp指针指向新的栈（本来的栈也会被内核掩盖掉）
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
搬移完结后改写cache，因为代码地址改变了不能让cache再命中被内核掩盖的老地址。然后跳转到新的地址持续履行
bl cache_clean_flush add pc, r5, r0 @ call relocation code
留意——zImage在解压后的搬移和跳转会给gdb调试内核带来费事。因为用来调试的符号表是在编译是生成的，并不知道今后会被搬移到何处去，只要在内核解紧缩完结之后，依据核算出来的参数“告知”调试器这个改变。以编撰本文时运用的zImage为例，内核自解压头重定向后，reloc_start地址由0x30008360变为0x30533e60。故咱们要把vmlinux的符号表也相应的从0x30008000后移到0x30533b00开端，这样gdb就能够正确的对应源代码和机器指令。
跟着头部代码移动到新的方位，不会再和内核的方针地址抵触，能够开端内核本身的搬移了。此刻r0寄存器寄存的是内核长度（严厉的说是长度外加128Byte的栈），r4寄存的是内核的意图地址0x30008000，r5是现在内核寄存地址，r6是CPU ID，r7是machine ID，r8是atags地址。代码从501行开端
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
接下来在516行铲除并封闭cache，清零r0，将machine ID存入r1，atags指针存入r2，再跳入0x30008000履行真实的内核Image
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
zImage自解压进程完毕。
从zImage头跳转进来，此刻的状况
- MMU为off
- D-cache为off
- I-cache为dont care，on或off没有关系
- r0为0
- r1为machine ID
- r2为atags指针
内核代码进口在linux-2.6.24-moko-linuxbj/arch/arm/kernel/head.S文件的83行。首要进入SVC32形式，并查询CPU ID，查看合法性
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 movs r10, r5 @ invalid processor (r5=0)? beq __error_p @ yes, error p
接着在87跋涉一步查询machine ID并查看合法性
bl __lookup_machine_type @ r5=machinfo movs r8, r5 @ invalid machine (r5=0)? beq __error_a @ yes, error a
其间__lookup_processor_type在linux-2.6.24-moko-linuxbj/arch/arm/kernel/head-common.S文件的149行，该函数首将标号3的实践地址加载到r3，然后将编译时生成的__proc_info_begin虚拟地址载入到r5，__proc_info_end虚拟地址载入到r6，标号3的虚拟地址载入到r7。因为adr伪指令和标号3的运用，以及__proc_info_begin等符号在linux-2.6.24-moko-linuxbj/arch/arm/kernel/vmlinux.lds而不是代码中被界说，此处代码不是十分直观，想弄清楚代码缘由的读者请耐性阅览这两个文件和adr伪指令的阐明。
r3和r7别离存储的是同一方位标号3的物理地址（因为没有启用mmu，所以当时肯定是物理地址）和虚拟地址，所以儿者相减即得到虚拟地址和物理地址之间的offset。运用此offset，将r5和r6中保存的虚拟地址改变为物理地址
__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
然后从proc_info中读出内核编译时写入的processor ID和之前从cpsr中读到的processor ID比照，查看代码和CPU硬件是否匹配（想在arm920t上运转为cortex-a8编译的内核？不让！）。假如编译了多种处理器支撑，如versatile板，则会循环每种type顺次查验，假如硬件读出的ID在内核中找不到匹配，则r5置0回来
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
__lookup_machine_type在linux-2.6.24-moko-linuxbj/arch/arm/kernel/head-common.S文件的197行，编码方法与查看processor ID彻底相同，请参阅前段
__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
代码回到head.S第92行，查看atags合法性，然后创立初始页表
bl __vet_atags bl __create_page_tables
创立页表的代码在218行，首要将内核开端地址-0x4000到内核开端地址之间的16K存储器清0
__create_page_tables: pgtbl r4 @ page table address /* * Clear the 16K level 1 swapper page table */ mov r0, r4 mov r3, #0 add r6, r0, #0x4000 1: str r3, [r0], #4 str r3, [r0], #4 str r3, [r0], #4 str r3, [r0], #4 teq r0, r6 bne 1b
然后在234即将proc_info中的mmu_flags加载到r7
ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags
在242即将PC指针右移20位，得到内核第一个1MB空间的段地址存入r6，在s3c2410渠道该值是0x300。接着依据此值存入映射标识
mov r6, pc, lsr #20 @ start of kernel section orr r3, r7, r6, lsl #20 @ flags + kernel base str r3, [r4, r6, lsl #2] @ identity mapping
完结页表设置后回到102行，为翻开虚拟地址映射作预备。设置sp指针，函数回来地址lr指向__enable_mmu，并跳转到linux-2.6.24-moko-linuxbj/arch/arm/mm/proc-arm920.S的386行，铲除I-cache、D-cache、write buffer和TLB
__arm920_setup: mov r0, #0 mcr p15, 0, r0, c7, c7 @ invalidate I,D caches on v4 mcr p15, 0, r0, c7, c10, 4 @ drain write buffer on v4 #ifdef CONFIG_MMU mcr p15, 0, r0, c8, c7 @ invalidate I,D TLBs on v4 #endif
然后回来head.S的158行，加载domain和页表，跳转到__turn_mmu_on
__enable_mmu: #ifdef CONFIG_ALIGNMENT_TRAP orr r0, r0, #CR_A #else bic r0, r0, #CR_A #endif #ifdef CONFIG_CPU_DCACHE_DISABLE bic r0, r0, #CR_C #endif #ifdef CONFIG_CPU_BPREDICT_DISABLE bic r0, r0, #CR_Z #endif #ifdef CONFIG_CPU_%&&&&&%ACHE_DISABLE bic r0, r0, #CR_I #endif mov r5, #(domain_val(DOMAIN_USER, DOMAIN_MANAGER) | / domain_val(DOMAIN_KERNEL, DOMAIN_MANAGER) | / domain_val(DOMAIN_TABLE, DOMAIN_MANAGER) | / domain_val(DOMAIN_IO, DOMAIN_CLIENT)) mcr p15, 0, r5, c3, c0, 0 @ load domain access register mcr p15, 0, r4, c2, c0, 0 @ load page table pointer b __turn_mmu_on
在194行把mmu使能位写入mmu，激活虚拟地址。然后将本来保存在sp中的地址载入pc，跳转到head-common.S的__mmap_switched，至此代码进入虚拟地址的国际
mov r0, r0 mcr p15, 0, r0, c1, c0, 0 @ write control reg mrc p15, 0, r3, c0, c0, 0 @ read id reg mov r3, r3 mov r3, r3 mov pc, r13
在head-common.S的37行开端铲除内核bss段，processor ID保存在r9，machine ID报存在r1，atags地址保存在r2，并将操控寄存器保存到r7界说的内存地址。接下来跳入linux-2.6.24-moko-linuxbj/init/main.c的507行，start_kernel函数。这儿只张贴部分代码
__mmap_switched: adr r3, __switch_data + 4 ldmia r3!, {r4, r5, r6, r7} cmp r4, r5 @ Copy data segment if needed 1: cmpne r5, r6 ldrne fp, [r4], #4 strne fp, [r5], #4 bne 1b
在main.c第507行，是硬件无关的C初始化代码
asmlinkage void __init start_kernel(void) { char * command_line; extern struct kernel_param __start___param[], __stop___param[]; smp_setup_processor_id();
s3c2410渠道linux-2.6.24内核前期的汇编初始化到这儿就完毕了
调试技巧：
运用gdb调试内核Image发动流程是一种很好的剖析手法，要运用好这种手法有一个问题需求处理——内核地址映射问题
- 代码履行的前期是处于mmu封闭的状况下，软件直接运用硬件相关的物理地址（s3c2410的ram从0x30000000开端）；
- 后来启用mmu并树立映射之后，软件运用虚拟地址。在3G用户空间装备下（大多数32位嵌入式体系都是此装备），内核运用的PAGE_OFFSET为0xc0000000，与硬件无关，中心虚拟地址变为从0xc0000000开端；
调试器无法主动承受这样的地址改变，需求运用上文介绍的窍门，手艺“告知”调试器该怎么做。
对内核编译发生的vmlinux文件运用objdump东西
$ /usr/local/linuxbj/eabi-glibc/arm/bin/arm-linuxbj-linux-gnueabi-objdump -t vmlinux|more vmlinux: file format elf32-littlearm SYMBOL TABLE: c0008000 l d .text.head 00000000 .text.head c0008240 l d .init 00000000 .init c0027000 l d .text 00000000 .text c03377ec l d .notes 00000000 .notes c0338000 l d __ksymtab 00000000 __ksymtab c033ca40 l d __ksymtab_gpl 00000000 __ksymtab_gpl c033e2d0 l d __ksymtab_gpl_future 00000000 __ksymtab_gpl_future c033e2e8 l d __ksymtab_strings 00000000 __ksymtab_strings c034c9ec l d __param 00000000 __param c034e000 l d .data 00000000 .data c0373e20 l d .bss 00000000 .bss
能够看到内核符号表的.text链接虚拟地址是0xc0027000，所以在mmu处于封闭的阶段中，应该将内核符号表在调试器里加载到0x30027000地址。使得head.S进口.text.head正好是0x30008000，与实践的内存共同。
