Linux 2.6.34 内核启动详细分析(一)

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) $(obj)/compressed/vmlinux: $(obj)/Image FORCE $(Q)$(MAKE) $(build)=$(obj)/compressed $@  #make obj=$(obj)/compressed $@

由此可见,zImage的是elf格式的arch/arm/boot/compressed/vmlinux二进制化得到的
在arch/arm/boot/compressed/Makefile中:

    $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).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 .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 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 查看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中的位置了吧。
来源url
栏目
文章分类