linux内核启动过程——zImage自解压

linux内核启动过程——基于S3C2410(1)zImage自解压

linux内核启动过程——基于S3C2410 （1）zImage自解压 本文以流行的Samsung公司的S3C2410，mini2440平台和linux-2.6.29为例，介绍如何在ZIX嵌入式开发环境下探索linux内核启动过程。 Linux内核启动一般由外部的bootloader引导，也可以在内核头部嵌入一个loader，实际的应用中这两种方式都会经常遇到。所以要了解内核启动最开始的过程，必须对bootloader如何引导内核有所熟悉。下面我们从u-boot加载linux内核的代码开始分析（关于u-boot 自身的启动流程，请参考u-boot 启动过程 —— 基于S3C2410）。 1.处理器内核加载代码 在u-boot的do_bootm_linux函数里，实现了处理器架构相关的linux内核加载代码，特别是tags传递。   该函数中，在(u-boot-1.6)lib_arm/armlinux.c的90行调用了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等进行invalid操作，这是通过在lib_arm/armlinux.c的268行调用cleanup_before_linux()(cpu/arm920t/108)实现，然后即可跳入从uImage中分解出来的内核Image或zImage入口     cleanup_before_linux ();     theKernel (0, machid, bd->bi_boot_params);     /* does not return */     return; 在s3c2410平台上，该入口theKernel一般是物理地址0x30008000。如果我们使用zImage自解压内核映像，对应的代码正是自解压头，位置在内核源码linux-2.6.29的arch/arm/boot/compressed/head.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地址(157行)处将分段信息导入r0-r6、ip、sp等寄存器，并检查代码是否运行在与链接时相同的目标地址(162行)，以决定是否进行处理。由于现在很少有人不使用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｝   注意：对于uncompressed kernel是以arch/arm/boot/head.S开始的.对于内核解压缩部分的code,在 arch/arm/boot/compressed/head.S中经过上面的zImage自解压然后内核再从arch/arm/boot/head.S中启动,本文不做讨论.