arm-linux内核启动学习笔记(一)

文章来源：http://blog.csdn.net/lidan113lidan/article/details/45043155

arm-linux 内核的启动

• 这里的分析是从./arch/arm/boot/compressed/head.S:start开始的，这个start标签是zImage的入口代码。 ./arch/arm/kernel里也有个head.S，这个head.S中的stext标签，就是zImage中decompress_kernel之后要跳转的地址，即Image的入口代码（见arm-linux内核编译过程小结）。
• arm启动后执行的第一条指令并不是head.S：start，在此之前一般都会有一个平台相关的bootloader(如mt6582的代码就是平台相关的代码，在mtk平台上bootloader分为preloader和lk两部分)来初始化一些平台相关的信息，然后再跳转到start标签，来执行体系结构相关的代码（如arm的代码就是体系结构相关的代码)。
• bootloader部分（如mtk平台中preloader和lk部分)的代码会完成对硬件的默认初始化，准备start的结构ID和atags两个参数。

---

Part1: [start ,cache_on]

这部分组要是找到平台相关的cache_on函数，然后调用之。cache_on函数的左右就是开启缓存，
一般需要通过初始化页表并使能mmu来实现。

//部分关系不大代码已省略
start:
//指定start这个符号是函数类型
        .type   start,#function
//.rept count .endr 把rept和endr之间的指令重复count次
//mov r0,r0 实际上就是nop指令，这里的意思应该是是清空指令流水线
        .rept   7
        mov r0, r0
        .endr
        ARM(mov r0, r0)
//跳到前面(下面的1)
        ARM(b   1f)

//这个魔数是在bootloader中用于判断zImage存在的，是内核和bootloader约定好的(mtk中参见lk代码)
        .word   0x016f2818      
//这里存的是start的默认加载地址，这个地址是编译时确定的，与代码最终加载到哪里无关，
//但如果start最终加载的物理地址（zImage这会没开mmu，所以物理地址）
//不是这个编译地址的话，可能需要重定位。
        .word   start           
//zImage的结束地址，也是编译地址，这个值是在连接的时候确定的，其定义在vmlinux.lds中
        .word   _edata          @ zImage end address
//THUMB宏在这里没有定义的，所以这里没啥用，如果定义了,.thumb表示往下都是用thumb指令集。
        THUMB(.thumb)

//r1, r2分别存着bootloader传递过来的结构ID和atags
1:      mov r7, r1          @ save architecture ID
        mov r8, r2          @ save atags pointer

//关中断
#ifndef __ARM_ARCH_2__
//__ARM_ARCH_2__下的关中断方式，goldfish中也是这种方式
        mrs r2, cpsr        @ get current mode
        tst r2, #3          @ not user?
        bne not_angel
        mov r0, #0x17       @ angel_SWIreason_EnterSVC
        ARM(swi 0x123456)   @ angel_SWI_ARM
        THUMB(svc 0xab)     @ angel_SWI_THUMB
not_angel:
        mrs r2, cpsr        @ turn off interrupts to
        orr r2, r2, #0xc0   @ prevent angel from runing
        msr cpsr_c, r2
#else
//arm 版本2,3的核心的关中断方式
        teqp    pc, #0x0c000003     @ turn off interrupts
#endif
        .text
#ifdef CONFIG_AUTO_ZRELADDR
        @ determine final kernel image address
        mov r4, pc
        and r4, r4, #0xf8000000
        add r4, r4, #TEXT_OFFSET
#else
//我的内核配置了zreladdr，将其加载到r4，这是Image的加载地址
        ldr r4, =zreladdr
#endif
        bl  cache_on

反汇编后的代码:

ROM:00000000                 AREA ROM, CODE, READWRITE, ALIGN=0
ROM:00000000                 CODE32
; mov r0, r0 被解释成了nop指令，这里应该是用来清空指令流水的
ROM:00000000                 NOP                     
ROM:00000004                 NOP                     
ROM:00000008                 NOP
ROM:0000000C                 NOP
ROM:00000010                 NOP
ROM:00000014                 NOP
ROM:00000018                 NOP
ROM:0000001C                 NOP
ROM:00000020                 B close_IRQ
ROM:00000020 ; ----------------------------------------
; zImage魔数
ROM:00000024                 DCD 0x16F2818      
; start 标签的编译地址，这里编译地址就是0，也就是说zImage默认被加载到0地址     
ROM:00000028                 DCD 0                   
; 这个数与 ll zImage的大小完全一样，也是zImage编译的结束地址。
ROM:0000002C                 DCD 0x27A1F8           
ROM:00000030 ; ----------------------------------------
ROM:00000030
ROM:00000030 close_IRQ      ; CODE XREF: ROM:00000020j
ROM:00000030                 MOV             R7, R1
ROM:00000034                 MOV             R8, R2
ROM:00000038                 MRS             R2, CPSR
ROM:0000003C                 TST             R2, #3
ROM:00000040                 BNE             not_angel
ROM:00000044                 MOV             R0, #0x17
ROM:00000048                 SVC             0x123456
ROM:0000004C
ROM:0000004C not_angel      ; CODE XREF: ROM:00000040j
ROM:0000004C                 MRS             R2, CPSR
ROM:00000050                 ORR             R2, R2, #0xC0
ROM:00000054                 MSR             CPSR_c, R2
ROM:00000058                 ANDEQ           R0, R0, R0
ROM:0000005C                 ANDEQ           R0, R0, R0
; 在goldfish上，r4 存入立即数 0x00008000，为Image的默认加载地址
ROM:00000060                 LDR         R4,=dword_8000 
ROM:00000064                 BL              cache_on

---

cache_on

cache_on函数主要的功能是根据处理器ID，找到处理器对应的体系结构(armXXX)的cache_on函数并调用。kernel支持的所有arm型号的cache_on函数都会包含在zImage里面(这个head.S文件中),如果有新的arm处理器，内核想要支持的话，就需要在kernel.org提交这部分的patch。

//这个8 是proc_types数组中的第三个元素，代表某个处理器型号中cache_on函数的地址。
cache_on:   mov r3, #8          @ cache_on function
        b   call_cache_fn

cache_on->call_cache_fn

//call_cache_fn为一个循环，根据当前cpu的魔数(可能是从cp15中获取，或编译时指定的），找到并调用对应处理器的cache_on函数
call_cache_fn:  adr r12, proc_types

//获取处理器ID,goldfish中是通过cp15获取的处理器ID
#ifdef CONFIG_CPU_CP15
        mrc p15, 0, r9, c0, c0  @ get processor ID
#else
        ldr r9, =CONFIG_PROCESSOR_ID
#endif

//可以先到下面看下proc_types的结构,这里以第一个循环为例
//r1 = proc_types[0] = 0x41560600 代表ARM6/610
1:      ldr r1, [r12, #0]       @ get value
//r2位掩码 r2 = proc_types[1] = 0xffffffe0
        ldr r2, [r12, #4]       @ get mask
//EOR <Rd>,<Rn>, <shifter_operand>, 将shifter_operand与Rn做异或操作，结果存于Rd
        eor r1, r1, r9      @ (real ^ match)
//TST <Rn>, <shifter_operand>， Rn - shifter_operand，用结果更新标志位
        tst r1, r2          @       & mask
//如果r1 = r2，代表处理器匹配，跳转到对应的cache_on函数
        ARM(addeq   pc, r12, r3) @ call cache function
        THUMB(addeq r12, r3)
        THUMB(moveq pc, r12) @ call cache function
//如果不一致，则增加到下一个位置，继续测试
        add r12, r12, #PROC_ENTRY_SIZE
//如果不匹配，则往上跳，循环。
        b   1b

proc_types里面记录各个arm处理器的魔数，掩码，以及相应的cache函数，如下：

/*
 *   - CPU ID match
 *   - CPU ID mask
 *   - 'cache on' method instruction
 *   - 'cache off' method instruction
 *   - 'cache flush' method instruction
*/
        .align  2
        .type   proc_types,#object
proc_types:
        .word   0x41560600      @ ARM6/610
        .word   0xffffffe0
        W(b) __arm6_mmu_cache_off   @ works, but slow
        W(b)    __arm6_mmu_cache_off
        mov pc, lr
        .word   0x41007000      @ ARM7/710
        .word   0xfff8fe00
        W(b)    __arm7_mmu_cache_off
        W(b)    __arm7_mmu_cache_off
        mov pc, lr
        THUMB(      nop             )
        .word   0x41807200  @ ARM720T (writethrough)
        .word   0xffffff00
        W(b)    __armv4_mmu_cache_on
        W(b)    __armv4_mmu_cache_off
        mov pc, lr
        THUMB(      nop             )
        .word   0x41007400      @ ARM74x
        .word   0xff00ff00
        W(b)    __armv3_mpu_cache_on
        W(b)    __armv3_mpu_cache_off
        W(b)    __armv3_mpu_cache_flush

        .word   0x41009400      @ ARM94x
        .word   0xff00ff00
        W(b)    __armv4_mpu_cache_on
        W(b)    __armv4_mpu_cache_off
        W(b)    __armv4_mpu_cache_flush

        .word   0x41069260      @ ARM926EJ-S (v5TEJ)
        .word   0xff0ffff0
        W(b)    __arm926ejs_mmu_cache_on
        W(b)    __armv4_mmu_cache_off
        W(b)    __armv5tej_mmu_cache_flush

        ......

这里以__armv4_mmu_cache_on为例(goldfish 应该是armv7的处理器，看/proc/cpuinfo )：
cache_on->call_cache_fn->__armv4_mmu_cache_on

//cache_on函数做了两件事：初始化页表，开启mmu，因为只有在开启mmu的情况下才能使用cache
__armv4_mmu_cache_on:
//这个函数是通过addeq  pc, r12, r3指令进来的,
//这里保存的lr是start标签的那句bl cache_on之后的位置的
        mov r12, lr
#ifdef CONFIG_MMU
//开启缓存相关,缓存具体怎么开怎么用，这里先不管，
//主要先看__setup_mmu是如何启动分页机制的
        bl  __setup_mmu
//高速缓存相关操作
        mov r0, #0
        mcr p15, 0, r0, c7, c10, 4  
        mcr p15, 0, r0, c8, c7, 0   @ flush I,D TLBs
        mrc p15, 0, r0, c1, c0, 0   @ read control reg
        orr r0, r0, #0x5000     
        orr r0, r0, #0x0030
//这个函数中有一步是将页表基地址写入cp15.c2寄存器，就是开启mmu。
        bl  __common_mmu_cache_on
        mov r0, #0
        mcr p15, 0, r0, c8, c7, 0   
//返回到start标签的bl cache_on后面那一句
        mov pc, r12

__setup_mmu

调用流程是：cache_on->call_cache_fn->__armv4_mmu_cache_on->__setup_mmu

/* 跳转到__setup_mmu之前:
 * r4 = zreladdr，为Image的加载地址(在goldfish里面为0x00008000,
 * 有的系统为0x3/5/7/0008000,这个值在./arch/arm/$(MACH)/
 * Makefile.boot中有定义,$(MACH)指的是具体的芯片)。
 * Image前的16KB内存（glodfish上默认为0x00004000 - 0x00008000）
 * 是内核的整个页表，大小为16K。
 * 
 *  __setup_mmu函数的主要工作是初始化全局页表(Image加载地址向前16KB)
 * 将部分区域加上C/B属性（cache和write buffer),其他区域就直接默认属性了，
 * 这里将当前pc所在的两页和解压后的内核所在的256MB空间加上了C/B属性
 * 估计因为这一片可能为代码区域，加上C/B属性可以提升访问速度？？？
 */ 

//r3 = r4 - 0x4000(16K) 最终r3 = 0x00004000，为页表基地址（pgd) 
__setup_mmu:    sub r3, r4, #16384
//r3 = r3 & 0xffffc000 (清除r3的0x3fff位)
        bic r3, r3, #0xff       @ Align the pointer
        bic r3, r3, #0x3f00
//当前页表项指针 r0 = 0x00004000
        mov r0, r3
//要初始化为C/B属性的起始物理地址，这里r9 = 0x0
        mov r9, r0, lsr #18
        mov r9, r9, lsl #18     @ start of RAM
//要初始化为C/B属性的结束物理地址 r10 = r9 + 256MB
        add r10, r9, #0x10000000    
//r1 = 0xc12, 这是默认的页表属性
        mov r1, #0x12
        orr r1, r1, #3 << 10
//页表项的结束位置 r2 = 0x00008000
        add r2, r3, #16384
//到这里开始初始化页表了，当前的r1是0xc12，同时也能代表虚拟地址0x00000000所在的页
//因为0xc12是个很小的数。每次循环r1都会递增1MB，在每一次循环中都设定r1
//代表的这1MB虚拟地址如何映射。这里做的是一个恒等映射，唯一不同就是各个区段
//的映射属性不同
1:      cmp r1, r9          @ if virt > start of RAM
//如果r1 > r9 则执行 r1 = r1|0x0C = 0x0C1E
        orrhs   r1, r1, #0x0c   
//如果 r1 > r10（过了0x10004000），则清除缓存标记
        cmp r1, r10         @ if virt > end of RAM
        bichs   r1, r1, #0x0c       
//r1是当前页描述符，r0是当前页表项的地址，这里是向当前页表项写入页描述符: *r0 = r1; r0 += 4;
        str r1, [r0], #4        
//r1 += 0x100000 = 2^20 = 1MB,设置下一个页描述符的内容
        add r1, r1, #1048576
//如果r0 != r2(没到页表项结束位置)则向后(向上)跳转到1，实现循环。
//这里是将整个0x00004000- 0x00008000处的内存全部初始化作为页表。
        teq r0, r2
        bne 1b
//16KB页表代表内核4GB空间，其初始化到这里结束，后面修正当前pc所在的虚拟地址
//(等于物理地址)对应的页表的属性了，这是怕pc不在前面那个0xC1E的范围内。
//r1 = 0x0C1E
        mov r1, #0x1e
        orr r1, r1, #3 << 10
//要修正pc所在页的地址
        mov r2, pc
//段对齐
        mov r2, r2, lsr #20
//加上页属性，r1为要写入的页表项内容(恒等映射）
        orr r1, r1, r2, lsl #20
//获取pc所在页的虚拟地址在全局页表pgd中的页表项的地址 -> r0
        add r0, r3, r2, lsl #2
//修改pc所在页和其后面一页的页表属性为0xC1E
        str r1, [r0], #4
        add r1, r1, #1048576
        str r1, [r0]
//返回
        mov pc, lr
ENDPROC(__setup_mmu)

/* 最终一级页表的内容:
其中:
第一列是各个页描述符的物理地址
第二列是各个页描述符的内容，整个第二列就是物理内存中的一级页表
第三列是表示当前页描述符处于一级页表中的第几个页表项。
/物理地址/页描述符内容/当前是第几个页表项/
|0x00004000|0x00000C1E|0000| //最后单独修改的两项页表项
|0x00004004|0x00100C1E|0001| //页表项内容>0x00004000
|0x00004008|0x00200C1E|0002| //<0x10004000的属于C/B区
|0x0000400C|0x00300C1E|0003| 
......
|0x00004400|0x10000C1E|0256| //页表项内容<0x10004000
|0x00004404|0x10100C12|0257| //页表项内容>0x10004000
|0x00004408|0x10200C12|0258|
......
|0x00007FFC|0xFFF00C12|4095|
一个一级页描述符作为段描述符时，可表示的地址范围为2^20 = 1MB(见后面一级页描述符), 32位cpu的寻址空间为4GB，所以一共需要4096个一级页描述符。前面可以看到16KB，刚好能存储4096个页描述符，所以内核初始化的时候，页表的大小为16KB. 16K/4096 = 4B 一个地址。

此恒等映射最终的结果就是，4GB的任意虚拟地址 = 物理地址。
*/

---

Part2:(cache_on,call_kernel]

vmlinux(小)的链接脚本:

//./arch/arm/boot/compressed/vmlinux.lds.in
//这个脚本是用来链接vmlinux(小)的，故zImage代码执行时
//内核各个段的分布也是在这个脚本中定义的（部分代码已省略）。
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
  . = TEXT_START;
  _text = .;
  .text : {
    _start = .;
    *(.start)
    *(.text)
    *(.text.*)
    *(.fixup)
    *(.gnu.warning)
    *(.glue_7t)
    *(.glue_7)
  }
  .rodata : {
    *(.rodata)
    *(.rodata.*)
  }
  //这里是piggy.gz的位置
  .piggydata : {
    *(.piggydata)
  }
  . = ALIGN(4);
  _etext = .;
  .got.plt      : { *(.got.plt) }
  _got_start = .;
  .got          : { *(.got) }
  _got_end = .;

  .pad          : { BYTE(0); . = ALIGN(8); }
  _edata = .;

  . = BSS_START;
  __bss_start = .;
  .bss          : { *(.bss) }
  _end = .;

  . = ALIGN(8);     /* the stack must be 64-bit aligned */
  .stack        : { *(.stack) }

  .stab 0       : { *(.stab) }
  .stabstr 0        : { *(.stabstr) }
  .stab.excl 0      : { *(.stab.excl) }
  .stab.exclstr 0   : { *(.stab.exclstr) }
  .stab.index 0     : { *(.stab.index) }
  .stab.indexstr 0  : { *(.stab.indexstr) }
  .comment 0        : { *(.comment) }
}

piggy.gzip.S

piggy.gzip.S是用来生成piggy.gzip.o的，其实际上相当于将一个piggy.gzip文件当
二进制打包到vmlinux(小)中了。

//./arch/arm/boot/compressed/piggy.gzip.S
    .section .piggydata,#alloc
    //global只是声明，并不分配空间
    .globl  input_data
input_data:
##INCBIN 指令在被汇编的文件内包含一个文件。 该文件按原样包含，没有进行汇编。
    .incbin "arch/arm/boot/compressed/piggy.gzip"
    .globl  input_data_end
input_data_end:

cache_on之后

cache_on之后段代的代码大体可认为做了三件事:
1. 检查内核是否需要移动，如果需要移动则将其移动并重定向.got的内容。
2. 调用decompress_kernel解压内核。
3. 调用call_kernel跳转到Image。

        //cache_on函数的实际作用是开启高速缓存，这样可以加快后续代码的执行速度
        //在arm体系结构中，高速缓存TLB必须依赖于mmu，所以cache_on函数内部通过
        //调用__setup_mmu来初始化页表(代码段的页表属性允许缓存）
        //调用__common_mmu_cache_on来使能mmu
        bl  cache_on
        //跳转到这里，mmu已经开启了，恒等映射!
/*      
        LC0的代码本来是在后面的，这里为了方便解释，先在前面列出了
        各个代码段的分布见后（这些值都是编译地址！）。
LC0:        .word   LC0         @ r1
        //bss段的开始位置
        .word   __bss_start     @ r2
        //bss的结束位置
        .word   _end            @ r3
        //数据段的结束位置
        .word   _edata          @ r6
        //pizzy.gz的结束位置
        .word   input_data_end - 4  @ r10 (inflated size location)
        .word   _got_start      @ r11
        .word   _got_end        @ r12 (ip)
        //栈的结束位置
        .word   .L_user_stack_end   @ sp
        //这个应该是个伪指令，指定LC0大小的
        .size   LC0, . - LC0
*/
        //adr是相对于当前pc的相对寻址，一般用于获取指令的真是地址，而不是加载地址
restart:    adr r0, LC0
        //把上面LC0中的一堆变量载入到各个寄存器中
        ldmia   r0, {r1, r2, r3, r6, r10, r11, r12}
        //设置临时栈, sp = L_user_stack_end，目前sp还指向栈底
        ldr sp, [r0, #28]

        /*
            zImage的加载地址未必是编译地址，所以这里需要
            将各个变量由编译地址修正为真实地址。
        */
        //计算LC0的真实地址(既是物理地址，又是虚拟地址)和编译地址的差值
        sub r0, r0, r1      @ calculate the delta offset
        //将_edata的编译地址转为真实地址
        add r6, r6, r0      @ _edata
        //将input_data_end的编译地址转为真实地址
        add r10, r10, r0        @ inflated kernel size location

        //将sp的编译地址修正为真实地址，并向上增加64K,作为栈顶
        add sp, sp, r0
        add r10, sp, #0x10000

        /*
         * The kernel build system appends the size of the
         * decompressed kernel at the end of the compressed data
         * in little-endian form.
         */
        /*
             r9是piggy.gzip这个gzip文件的最后四个字节，这四个字节记录的
             是解压后的Image的大小存的.在我这里piggy.gzip最后: 30c1 b500 0a
             Image大小为0xb5c130, 最后那个0a估计最后会去掉的。
             这里用ldrb指令是考虑到这个存Image大小的位置可能不是4byte对齐的。
         */
        ldrb    r9, [r10, #0]
        ldrb    lr, [r10, #1]
        orr r9, r9, lr, lsl #8
        ldrb    lr, [r10, #2]
        ldrb    r10, [r10, #3]
        orr r9, r9, lr, lsl #16
        orr r9, r9, r10, lsl #24

/*
 *   这一段代码是来检测是否需要复制自身的
 *   r4是最终内核要解压到的地址，是通过zreladdr来指定的
 *   r9是Image镜像的大小，是从piggy.gz文件末尾获取的
 *   r10是piggy.gz的结束位置
 * 往下执行需要满足两个条件之一:
 *   1) 最终内核要解压到的地址(r4) - 16k页表 >= zImage的基本代码结束位置(r10)
 *   2) 最终内核解压后的结束地址(r4 + r9(image length)) <= 后续执行的代码(wont_overwrite的地址)
0x00000000 -----------------------------------------------------------------------------

                                                ------ Image(zreladdr)
                                                  |
                                                  |
     ----- zImage起始地址                          | 
       |                                          |
       |                                          |
     ----- 当前代码(pc)                          ------ Image end 在此之上都可以
     ----- wont_overwrite的代码                      
       |
     ----- zImage基本代码结束(piggy.gz末尾，r10)
                                                ----- Image(zreladdr)
                                                      ;如果解压到这个位置往下都是可以的
                                                  |
                                                  |
                                                ----- Image end

0xffffffff -----------------------------------------------------------------------------
 */

        //这里r10 += 0x4000是预留给页表的
        add r10, r10, #16384
        cmp r4, r10
        //如果r4 >= r10则满足条件1，Image要解压的地址在zImage后面，
        //跳转到wont_overwrite，不需移动自身代码。
        bhs wont_overwrite
        //r10 = r4 + r9, r10为预计解压后的image的结束地址
        add r10, r4, r9
        //获取wont_overwrite的物理地址
        adr r9, wont_overwrite
        //如果否满足条件2，即image解压后没有覆盖wont_overwrite
        //之后的代码，则也无需移动自身代码。
        cmp r10, r9
        bls wont_overwrite
/*
 * Relocate ourselves past the end of the decompressed kernel.
 *   r6  = _edata
 *   r10 = end of the decompressed kernel
 * Because we always copy ahead, we need to do it from the end and go
 * backward in case the source and destination overlap.
 */
        /*
         * Bump to the next 256-byte boundary with the size of
         * the relocation code added. This avoids overwriting
         * ourself when the offset is small.
         */
        //否则就需要移动代码的位置了，这里的逻辑是把从restart到zImage结束的代码
        //移动到Image预计解压后的结束位置的后面，为什么从restart开始见下面。
        add r10, r10, #((reloc_code_end - restart + 256) & ~255)
        //这里的r10应该就是最终要移动到的地址了
        bic r10, r10, #255

        /* Get start of code we want to copy and align it down. */
        //要复制的代码的起始地址
        adr r5, restart
        //清除末尾位
        bic r5, r5, #31
        //要复制的数据大小
        sub r9, r6, r5      @ size to copy
        add r9, r9, #31     @ rounded up to a multiple
        bic r9, r9, #31     @ ... of 32 bytes
        add r6, r9, r5
        //要复制到的结束位置
        add r9, r9, r10

        //复制数据
1:      ldmdb   r6!, {r0 - r3, r10 - r12, lr}
        cmp r6, r5
        stmdb   r9!, {r0 - r3, r10 - r12, lr}
        bhi 1b

        /* Preserve offset to relocated code. */
        sub r6, r9, r6

        //代码被移动过了，所以清缓存
        bl  cache_clean_flush
        //跳转到restart重新执行，因为当前地址变了，所以LC0的当前地址和编译地址
        //的差值就变了，前面的好多变量都是根据这个差值算出来的，所以这里跳到
        //restart重新来过，所以前面检测的时候是检测wont_overwrite之前
        //的代码是否被覆盖，而移动得要从restart的代码开始移动。
        adr r0, BSYM(restart)
        add r0, r0, r6
        mov pc, r0
        //到这里

wont_overwrite:
/*
 * If delta is zero, we are running at the address we were linked at.
 *   r0  = delta (运行地址与链接地址的偏移量)
 *   r2  = BSS start
 *   r3  = BSS end
 *   r4  = kernel execution address
 *   r5  = appended dtb size (0 if not present)
 *   r7  = architecture ID
 *   r8  = atags pointer
 *   r11 = GOT start
 *   r12 = GOT end
 *   sp  = stack pointer
 */
        //r5在一开始被初始化为0
        orrs    r1, r0, r5
        //这里是如果运行地址与链接地址相等则跳转到not_relocated
        //不执行got段的重定位
        beq not_relocated

        //否则将r11,r12存的GOT表的编译地址修改为当前地址
        add r11, r11, r0
        add r12, r12, r0
        //修正bbs段的起始，结束地址
        add r2, r2, r0
        add r3, r3, r0
        //对GOT表中的所有元素做重定位
1:      ldr r1, [r11, #0]       @ relocate entries in the GOT
        add r1, r1, r0      @ This fixes up C references
        cmp r1, r2          @ if entry >= bss_start &&
        cmphs   r3, r1          @       bss_end > entry
        addhi   r1, r1, r5      @    entry += dtb size
        str r1, [r11], #4       @ next entry
        cmp r11, r12
        blo 1b
        /* bump our bss pointers too */
        add r2, r2, r5
        add r3, r3, r5

not_relocated:  mov r0, #0
        //初始化bss段的所有数据为空
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.
 * Set up some pointers, and start decompressing.
 *   r4  = kernel execution address
 *   r7  = architecture ID
 *   r8  = atags pointer
 */
        mov r0, r4
        mov r1, sp          @ malloc space above stack
        add r2, sp, #0x10000    @ 64k max
        mov r3, r7
        //这个即是将piggy.gz解压为Image的函数，这里是c代码
        bl  decompress_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
        //r4是Image的入口地址，也是Image的解压地址，Image
        //本身是个binary文件，第一个字节即为指令，这里跳转到Image
        //即./arch/arm/kernel/head.s:stext
 ARM(   mov pc, r4  )       @ call kernel

decompress_kernel

decompress_kernel是用c函数完成的，其代码如下

//./kernel/arch/arm/boot/compressed/Misc.c
extern char input_data[];
void decompress_kernel(
    unsigned long output_start,        //zImage的解压地址(r4)
    unsigned long free_mem_ptr_p,      //临时空间，解压用（这里用的是栈）
    unsigned long free_mem_ptr_end_p,  //临时空间结尾 
    int arch_id)                       // arch id
{
    int ret;
    output_data     = (unsigned char *)output_start;
    free_mem_ptr        = free_mem_ptr_p;
    free_mem_end_ptr    = free_mem_ptr_end_p;
    __machine_arch_type = arch_id;
    arch_decomp_setup();
    //putstr是内核启动早期的打印函数，一般都是直接向IO端口写的数据
    putstr("Uncompressing Linux...");
    //内核解压函数，这里用的是gzip解压，这个input_data和input_data_end
    //定义在piggy.gzip.S中，是piggy.gzip的起始和结束位置。
    ret = do_decompress(input_data, input_data_end - input_data, output_data, error);
    if (ret)
        error("decompressor returned an error");
    else
        putstr(" done, booting the kernel.\n");
}

这里要注意一点的是：decompress_kernel函数中就已经开始调用打印函数了,这一句

putstr("Uncompressing Linux...")

在goldfish启动的时候是可以打印出来的，在真实设备上（如MT6582)，通过串口也是可以打出来的，其实现如下:

./kernel/arch/arm/boot/compressed/Misc.c
static void putstr(const char *ptr)
{
    char c;
    while ((c = *ptr++) != '\0') {
        if (c == '\n')
            putc('\r');
        putc(c);
    }
    flush();
}

而这个putc,具体平台实现的方式不同，在goldfish上:

//./arch/arm/mach-goldfish/include/mach/uncompress.h
#define GOLDFISH_TTY_PUT_CHAR (*(volatile unsigned int *)0xff002000)
static void putc(int c)
{
        //向IO端口0xff002000直接写入字符，这就是goldfish的uart端口
        GOLDFISH_TTY_PUT_CHAR = c;
}

在MT6582上，也是通过一个地址写入的，如下：

//./mediatek/platform/mt6582/kernel/core/include/mach/uncompress.h
#define MT_UART_PHY_BASE 0x11002000
#define MT_UART_THR *(volatile unsigned char *)(MT_UART_PHY_BASE+0x0)
static inline void putc(int c)
{
   //向IO端口0x11002000直接写入字符，这就是mt6582的uart端口
   //这一句while循环是测试控制位的，具体位作用需参考板子的手册。
   while (!(MT_UART_LSR & 0x20));
   MT_UART_THR = c;
}

这种写入也就是在内核刚开始，有恒等映射的时候，后续page_init二次映射的时候这些地址都会映射到内核的内核空间的其他地方了（后续分析）。

旧版废弃的内容，但应该是正确的

part1

• arm MMU 一级页表寻址:
  arm协处理器CP15的C2寄存器记录着页基地址(又可以叫做一级页表基地址)，对于一个地址addr, 在arm中第一级寻址算法为：C2[31:14] + addr[31:20] + 00，如图：

注1:
1) C2中记录的页表基地址，又可以叫做一级页表基地址。
2) 一级页表基地址中的每一项元素叫做一级页表项。
3) 一级页表项中的内容叫做一级页表描述符。
4) 一级页表描述符，描述的是否为一个二级页表，这个得看描述符的最后两位是什么。
注2: 一级寻址只与页表基地址的前18位(一级页表基地址)，虚拟地址的前12位(一级页表项的页内偏移)有关 (+最后两位00)，没有任何标记位，mmu通过将二者组合成一个32位物理地址，这个就是一级页表项的物理地址，从这个物理地址中读取到的内容就是一级页表描述符。

• 一级页表描述符：
  arm 开启MMU后，当用户访问一个虚拟地址时，先根据C2和虚拟地址的前12位标记的物理地址中取出一个一级页表描述符，虚拟地址中剩下20位如何解析，是由这个一级页表描述符的低2位决定的。一共四种组合，对应四种不同的解析方式。在__setup_mmu中初始化的一级页表项的最后两位都是10，这里先介绍10。
  一级页表描述符[1:0]为0b10，表示该一级描述符为段描述符。该一级描述符应该如下解析：
  

虚拟地址->物理地址的过程:

这个过程的总体描述如下:
1) 用户访问一个虚拟地址addr。
2) MMU取出addr的前12位，并根据C2定位一级页表描述符X。
3) MMU 发现 X的最后两位为10，则取出x的前12位，拼接addr的后20位，组成物理地址。
4) 访问此物理地址，获取数据返回给用户。

part2

在zImage的反汇编代码中，input_data在_got_start段，值为0x4015，如下：

查看其内容：

查看piggy.gz：

可知整个zImage,实际上就是vmlinux（2.51MB那个）掐头去尾一点，vmlinux是个标准ELF文件，而zImage就是这个vmlinux去了ELF头尾组成的，其二进制差异不过1%20.

也就是说，实际上是vmlinux包含了piggy.gz，而将其裁剪一点，就形成了最终的zImage。
1. vmlinux(小的那个)，是一个标准的elf文件，将其掐头去尾后就形成了zImage，这个就是最终的内核镜像。
2. zImage是最终的内核镜像，其内部包含了一个原封不动的piggy.gz，这是一个压缩后的内核。
3. piggy.gz是image通过gzip命令压缩来的。
4. Image文件是一个纯二进制文件,没有elf头，zImage中的最后一句 MOV PC, R4 ; call_kernel,这个R4就是之前kernel解压的地址，就是直接跳到了Image的相对偏移0位置的指令。
5. Image是从vmlinux(大）中抽取出来的，是objcopy -o binary vmlinux(大)来的。vmlinux(大)入口地址的第一条指令，就是Image这个二进制文件的第一条指令。

所以综上所述，zImage解压内核，跳转到Image偏移0处的指令，实际上相当于执行了vmlinux(大)的入口函数。而vmlinux(大)的入口函数为ENTRY(stext)，定义在./arch/arm/kernel/head.S（注，zImage的入口函数定义在./arch/arm/boot/compressed/head.S),也就是说vmlinux(大)的入口函数，也是体系结构相关的！