转载:kernel 启动过程

    技术2022-05-20  38

    zImage是ARM Linux常用的一种压缩映像文件,uImage是U-boot专用的映像文件,它是在zImage之前加上一个长度为0x40的“头”,说明这个映像文件的类型、加载位置、生成时间、大小等信息。换句话说,如果直接从uImage的0x40位置开始执行,zImage和uImage没有任何区别。另外, Linux2.4内核不支持uImage,Linux2.6内核加入了很多对嵌入式系统的支持,但是uImage的生成也需要设置。

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

    先看看zImage的组成吧。在内核编译完成后会在arch/arm/boot/下生成zImage。

    在arch/armboot/Makefile中:

    $(obj)/zImage: $(obj)/compressed/vmlinux FORCE

                        $(call if_changed,objcopy)

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

    在arch/armboot/compressed/Makefile中:

    $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o /

                                                                $(addprefix $(obj)/, $(OBJS)) FORCE

                        $(call if_changed,ld)

    $(obj)/piggy.gz: $(obj)/../Image FORCE

                        $(call if_changed,gzip)

    $(obj)/piggy.o: $(obj)/piggy.gz FORCE

    其中Image是由内核顶层目录下的vmlinux二进制化后得到的。注意:arch/arm/boot/compressed/vmlinux是位置无关的,这个有助于理解后面的代码。,链接选项中有个 –fpic参数:

    EXTRA_CFLAGS := -fpic

    总结一下zImage的组成,它是由一个压缩后的内核piggy.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决定。从中可以看出入口点为‘_start’

    OUTPUT_ARCH(arm)

    ENTRY(_start)

    SECTIONS

    {

            . = 0;

           _text = .;

           .text : {

           _start = .;

           *(.start)

           *(.text)

                                ……

    }

    在arch/arm/boot/compressed/head.S中找到入口点。

    看看head.S会做些什么样的工作:

    • 对于各种Arm CPU的DEBUG输出设定,通过定义宏来统一操作;

    •设置kernel开始和结束地址,保存architecture ID;

    • 如果在ARM2以上的CPU中,用的是普通用户模式,则升到超级用户模式,然后关中断

    • 分析LC0结构delta offset,判断是否需要重载内核地址(r0存入偏移量,判断r0是否为零)。

    •需要重载内核地址,将r0的偏移量加到BSS region和GOT table中的每一项。

    对于位置无关的代码,程序是通过GOT表访问全局数据目标的,也就是说GOT表中中记录的是全局数据目标的绝对地址,所以其中的每一项也需要重载。

    • 清空bss堆栈空间r2-r3

    •建立C程序运行需要的缓存

    •这时r2是缓存的结束地址,r4是kernel的最后执行地址,r5是kernel境象文件的开始地址

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

    可能大家看了上面的文字描述还是不清楚解压的动态过程。还是先用图表的方式描述下代码的搬运解压过程。然后再针对中间的一些关键过程阐述。

    假定zImage在内存中的初始地址为0x30008000(这个地址由bootloader决定,位置不固定)

    1、初始状态

    .text  0x30008000 开始,包含piggydata 段(即压缩的内核段) . got  ?  . data  ?  .bss  ?  .stack  4K 大小 

    2、head.S调用misc.c中的decompress_kernel刚解压完内核后

    .text  0x30008000 开始,包含piggydata 段(即压缩的内核段) . got  ?  . data  ?  .bss  ?  .stack  4K 大小 解压函数所需缓冲区 64K 大小 解压后的内核代码 小于4M  

    3、此时会将head.S中的部分代码重定位

    .text  0x30008000 开始,包含piggydata 段(即压缩的内核段) . got  ?  . data  ?  .bss  ?  .stack  4K 大小 解压函数所需缓冲区 64K 大小 解压后的内核代码 小于4M  head.S 中的部分重定位代码代码 reloc_start 至reloc_end  

    4、跳转到重定位后的reloc_start处,由reloc_start至reloc_end的代码复制解压后的内核代码到0x30008000处,并调用call_kernel跳转到0x30008000处执行。

    解压后的内核 0x30008000 开始 

    在通过head.S了解了动态过程后,大家可能会有几个问题:

    问题1:zImage是如何知道自己最后的运行地址是0x30008000的?

    问题2:调用decompress_kernel函数时,其4个参数是什么值及物理含义?

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

    先回答第1个问题

    这个地址的确定和Makefile和链接脚本有关,在arch/arm/Makefile文件中的

    textaddr-y := 0xC0008000 这个是内核启动的虚拟地址

    TEXTADDR := $(textaddr-y)

    在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/Makefile中有

                               .word zreladdr @ r4

    内核就是用这种方式让代码知道最终运行的位置的

    接下来再回答第2个问题

    decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,

    int arch_id)

    l output_start:指解压后内核输出的起始位置,此时它的值参考上面的图表,紧接在解压缓冲区后;

    l free_mem_ptr_p:解压函数需要的内存缓冲开始地址;

    l ulg free_mem_ptr_end_p:解压函数需要的内存缓冲结束地址,共64K;

    l arch_id :architecture ID,对于SMDK2410这个值为193;

    最后回答第3个问题

    首先看看piggy.o是如何生成的,在arch/arm/boot/compressed/Makefie中

    $(obj)/piggy.o: $(obj)/piggy.gz FORCE

    Piggy.o是由piggy.S生成的,咱们看看piggy.S的内容:

                 .section .piggydata,#alloc

                 .globl input_data

    input_data:

                 .incbin "arch/arm/boot/compressed/piggy.gz"

                 .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.S里的input_data吗?这个时候应该明白内核是怎样确定piggy.gz在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 processor2: 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 space1: 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 machine2: 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, #0x40001: 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_ICACHE_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 needed1: 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内核 早期的汇编初始化到这里就结束了


    最新回复(0)