Chinaunix首页 | 论坛 | 博客
  • 博客访问: 353354
  • 博文数量: 90
  • 博客积分: 2017
  • 博客等级: 大尉
  • 技术积分: 615
  • 用 户 组: 普通用户
  • 注册时间: 2009-10-19 08:10
文章分类

全部博文(90)

文章存档

2012年(4)

2011年(74)

2010年(11)

2009年(1)

分类: LINUX

2009-10-19 08:25:01

核心代码 Arm-linux内核启动——基于S3C2410 zImage 自解压 位置在内核源码linux-2.6.22的arch/arm/boot/compressed/head.S的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生命终止。之后代码会读取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地址处将分段信息导入r0-r6、ip、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相关的. 这些操作发生在代码开始的地方,下面只粘贴一部分                 add     r5, r5, r0                 add     r6, r6, r0                 add     ip, ip, r0 后面在进行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  然后打开cache,并为后面解压缩设置64KB的临时malloc空间                 bl      cache_on                   mov     r1, sp              @ malloc space above stack                 add     r2, sp, #0x10000    @ 64k max  接下来进行检查,确定内核解压缩后的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}                 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 随着头部代码移动到新的位置,不会再和内核的目标地址冲突,可以开始内核自身的搬移了。此时r0寄存器存放的是内核长度(严格的说是长度外加128Byte的栈),r4存放的是内核的目的地址0x30008000,r5是目前内核存放地址,r6是CPU ID,r7是machine ID,r8是atags地址。代码从501行开始 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 接下来在516行清除并关闭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 从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 processor 2:      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 space 1:      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 machine 2:      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, #0x4000 1:      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 needed 1:      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(); 到这里,系统进入了start_kernel.
阅读(1787) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~