Linux 2.6.34 内核启动详细分析

内核编译完成后会生成zImage内核镜像文件。关于bootloader加载zImage到内核，
并且跳转到zImage开始地址运行zImage的过程，相信大家都很容易理解。但对于zImage
是如何解压的过程，就不是那么好理解了。
本文将结合部分关键代码，讲解zImage的解压过程;

先看看zImage的组成吧。在内核编译完成后会在arch/arm/boot/下生成zImage。
在arch/arm/boot/Makefile中：
$(obj)/zImage: $(obj)/compressed/vmlinux FORCE
$(call if_changed,objcopy)
由此可见，zImage的是elf格式的arch/arm/boot/compressed/vmlinux二进制化得到的
在arch/arm/boot/compressed/Makefile中：

$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
$(addprefix $(obj)/, $(OBJS)) $(lib1funcs) FORCE
$(call if_changed,ld)

$(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
$(call if_changed,$(suffix_y))

$(obj)/piggy.$(suffix_y).o:  $(obj)/piggy.$(suffix_y) FORCE
其中Image是由内核顶层目录下的vmlinux二进制化后得到的。
注意：arch/arm/boot/compressed/vmlinux是位置无关的，这个有助于理解后面的代码。
链接选项中有个 –fpic参数：
EXTRA_CFLAGS := -fpic

PIC就是position independent code 
PIC使.so文件的代码段变为真正意义上的共享 
如果不加-fPIC,则加载.so文件的代码段时,代码段引用的数据对象需要重定位, 重定位会修改代码段的内容,这就造成每个使用这个.so文件代码段的进程在内核里都会生成这个.so文件代码段的copy.每个copy都不一样,取决于 这个.so文件代码段和数据段内存映射的位置. 

总结一下zImage的组成，它是由一个压缩后的内核piggy.gzip.o，连接上一段初始化及解压功能的代码（head.o misc.o）,组成的。

下面就要看内核的启动了，那么内核是从什么地方开始运行的呢？这个当然要看lds文件啦。
zImage的生成经历了两次大的链接过程：
一次是顶层vmlinux的生成，由arch/arm/boot/vmlinux.lds（这个lds文件是由arch/arm/kernel/vmlinux.lds.S生成的）决定；
另一次是arch/arm/boot/compressed/vmlinux的生成，是由arch/arm/boot/compressed/vmlinux.lds（这个lds文件是由arch/arm/boot/compressed/vmlinux.lds.in生成的）决定。

因此，zImage的入口点应该由arch/arm/boot/compressed/vmlinux.lds决定。

首先，我们来看内核解压部分,这部分的代码主要存放在
1. arch/arm/boot/compressed/Makefile   
2. arch/arm/boot/compressed/vmlinux.lds
3. arch/arm/kernel/vmlinux.lds



Linux内核解压流程
arch/arm/boot/compressed/head.S

• 对于各种Arm CPU的DEBUG输出设定，通过定义宏来统一操作；
#include <mach/debug-macro.S>
.macro    writeb,    ch, rb
senduart \ch, \rb
.endm
#defined(CONFIG_ARCH_S3C2410)
.macro loadsp, rb, tmp
mov    \rb, #0x50000000
add    \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
.endm
#endif

.macro    kputc,val 
mov    r0, \val
bl    putc
.endm

.macro    kphex,val,len 
mov    r0, \val
mov    r1, #\len
bl    phex
.endm

.macro    debug_reloc_start 
kputc    #'\n'
kphex    r6, 8        /* processor id */
kputc    #':'
kphex    r7, 8        /* architecture id */
kputc    #':'
mrc    p15, 0, r0, c1, c0
kphex    r0, 8        /* control reg */
kputc    #'\n'
kphex    r5, 8        /* decompressed kernel start */
kputc    #'-'
kphex    r9, 8        /* decompressed kernel end  */
kputc    #'>'
kphex    r4, 8        /* kernel execution address */
kputc    #'\n'

.macro    debug_reloc_end 
kphex    r5, 8        /* end of kernel */
kputc    #'\n'
mov    r0, r4
bl    memdump        /* dump 256 bytes at start of kernel */
.endm

•设置kernel开始和结束地址，保存architecture ID；

Start: 
.type   start,#function                    @.type 符号,类型描述(函数类型或者对象类型)
.rept   8                                             @.rept 数据定义 .endr  重复协议操作
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

• 如果在ARM2以上的CPU中，如用的是普通用户模式，则升到超级用户模式，然后关中断
这也标志着u-boot将系统完全的交给了OS，bootloader生命终止，系统已经处于SVC32模式；而利用
angel进入则处于user模式，还需要额外两条指令。之后是再次确认中断关闭，并完成cpsr写入

mrs       r2, cpsr                @ get current mode
tst         r2, #3                   @ not user mode?
bne      not_angel
mov     r0, #0x17             @ angel_SWIreason_EnterSVC 
swi       0x123456             @ angel_SWI_ARM 软中断指令 进入SVC模式

not_angel: 
mrs     r2, cpsr                   @ turn off interrupts to
orr     r2, r2, #0xc0           @ prevent angel from running
msr     cpsr_c, r2


• 分析LC0结构delta offset，判断是否需要重载内核地址(r0存入偏移量，判断r0是否为零)。在LC0
地址处将分段信息导入r0-r6、r11、ip、sp等寄存器，并检查代码是否运行在与链接时相同的目标地址，
以决定是否进行处理。

adr       r0, LC0 
ldmia   r0, {r1, r2, r3, r4, r5, r6, r11, 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.


                         .align  2
                         .type   LC0, #object
LC0:            
.word   LC0                                 @ r1
.word   __bss_start                     @ r2
.word   _end                                @ r3
.word   zreladdr                         @ r4
.word   _start                              @ r5
.word   _image_size                  @ r6
.word   _got_start                      @ r11
.word   _got_end                        @ ip
.word   user_stack+4096         @ 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相关的

这些操作发生在代码172行开始的地方，下面只粘贴一部分
/*We're running at a different address.  We need to fix
* up various pointers:
*   r5 - zImage base address ( _start )
*   r6 - size of decompressed image
*   r11 - GOT start
*   ip - GOT end*/

add     r5, r5, r0
add     r11, r11, r0
add     ip, ip, r0

•需要重载内核地址，将r0的偏移量加到BSS region和GOT table中的每一项。对于位置无关
的代码，程序是通过GOT表访问全局数据目标的，也就是说GOT表中中记录的是全局数据目标
的绝对地址，所以其中的每一项也需要重载。 

/* If we're running fully PIC === CONFIG_ZBOOT_ROM = n,
* we need to fix up pointers into the BSS region.
*   r2 - BSS start
*   r3 - BSS end
*   sp - stack pointer*/

add     r2, r2, r0
add     r3, r3, r0
add     sp, sp, r0

/*Relocate all entries in the GOT table.*/
1:              
ldr        r1, [r11, #0]           @ relocate entries in the GOT
add      r1, r1, r0                 @ table.  This fixes up the
str        r1, [r11], #4           @ C references.
cmp     r11, ip
blo       1b

• 清空bss堆栈空间r2－r3

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

•打开cache,建立C程序运行需要的64KB的临时malloc空间

bl      cache_on 
mov     r1, sp                            @ malloc space above stack
add     r2, sp, #0x10000        @ 64k max 接下来238行进行检查，确定内核解压缩后的
                                                  @Image目标地址是否会覆盖到zImage头，如果是则准备
@将zImage头转移到解压出来的内核后面

•这时r2是缓存的结束地址，r4是kernel的最后执行地址，r5是kernel境象文件的开始地址
/*
* Check to see if we will overwrite ourselves.
*   r4 = final kernel address
*   r5 = start of this image
*   r6 = size of decompressed 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

•用文件misc.c的函数decompress_kernel()，解压内核于缓存结束的地方(r2地址之后)。

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指针指向新的栈（原来的栈也会被内核覆盖掉）
* r0     = decompressed kernel length
* r1-r3  = unused
* r4     = kernel execution address
* r5     = decompressed kernel start
* r7     = architecture ID
* r8     = atags pointer
* r9-r12,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

搬移完成后刷新cache，因为代码地址变化了不能让cache再命中被内核覆盖的老地址。
然后跳转到新的地址继续执行

bl      cache_clean_flush 
add     pc, r5, r0              @ call relocation code(reloc_start:)

注意:zImage在解压后的搬移和跳转会给gdb调试内核带来麻烦。因为用来调试的符号表是在编译
生成的，并不知道以后会被搬移到何处去，只有在内核解压缩完成之后，根据计算出来的参数“告诉”
调试器这个变化。以撰写本文时使用的zImage为例，内核自解压头重定向后，reloc_start地址由0x30008360变为0x30533e60。故我们要把vmlinux的符号表也相应的从0x30008000后移到0x30533b00开始，这样gdb就可以正确的对应源代码和机器指令。随着头部代码移动到新的位置，
不会再和内核的目标地址冲突，可以开始内核自身的搬移了。此时r0寄存器存放的是内核长度（严格
的说是长度外加128Byte的栈），r4存放的是内核的目的地址0x30008000，r5是目前内核存放地
址，r6是CPU ID，r7是machine ID，r8是atags地址。

* 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
* r7     = architecture ID
* r8     = atags pointer
* r9-r12,r14 = corrupted 

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

接下来在566行清除并关闭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

至此，开始正式跳到内核代码执行！

遗留问题解决：
问题1：zImage是如何知道自己最后的运行地址是0x30008000的？
这个地址的确定和Makefile和链接脚本有关
在arch/arm/mach-s3c2410/Makefile.boot中
zreladdr-y := 0x30008000 这个就是zImage的运行地址了
在arch/arm/boot/Makefile文件中
ZRELADDR := $(zreladdr-y)
在arch/arm/boot/compressed/Makefile文件中
zreladdr=$(ZRELADDR)
在arch/arm/boot/compressed/head.S中有
.word zreladdr @ r4
内核就是用这种方式让代码知道最终运行的位置的

问题2：调用decompress_kernel函数时，其4个参数是什么值及物理含义？

decompress_kernel(ulg output_start, 
ulg free_mem_ptr_p, 
ulg free_mem_ptr_end_p,
int arch_id)

output_start：指解压后内核输出的起始位置，紧接在解压缓冲区后；
free_mem_ptr_p：解压函数需要的内存缓冲开始地址；
free_mem_ptr_end_p：解压函数需要的内存缓冲结束地址，共64K；
arch_id ：architecture ID，对于SMDK2410这个值为193；


问题3：解压函数是如何确定代码中压缩内核位置的？

首先看看piggy.o是如何生成的，在arch/arm/boot/compressed/Makefie中
$(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
Piggy.gzip.o是由piggy.gzip.S生成的，咱们看看piggy.gzip.S的内容：
.section .piggydata,#alloc
.globl input_data
input_data:
.incbin "arch/arm/boot/compressed/piggy.gzip"
.globl input_data_end
input_data_end:
再看看misc.c中decompress_kernel函数吧，它将调用gunzip()解压内核。
gunzip()在lib/inflate.c中定义，它将调用NEXTBYTE()，进而调用get_byte()来获取压缩内核代码。

在misc.c中
#define get_byte() (inptr < insize ? inbuf[inptr++] : fill_inbuf())

查看fill_inbuf函数
int fill_inbuf(void)
{
if (insize != 0)
error("ran out of input data");
inbuf = input_data;
insize = &input_data_end[0] - &input_data[0];
inptr = 1;
return inbuf[0];
}
发现什么没？这里的input_data不正是piggy.gzip.S里的input_data吗？这个时候应该
明白内核是怎样确定piggy.gz在zImage中的位置了吧。