Chinaunix首页 | 论坛 | 博客

  • 博客访问: 480959
  • 博文数量: 86
  • 博客积分: 2010
  • 博客等级: 大尉
  • 技术积分: 878
  • 用 户 组: 普通用户
  • 注册时间: 2008-11-06 14:11
文章分类

全部博文(86)

文章存档

2010年(12)

2009年(60)

2008年(14)

我的朋友

分类: LINUX

2009-06-10 15:54:31

linux内核启动过程——基于S3C2410

1zImage自解压

本文以流行的Samsung公司的S3C2410mini2440平台和linux-2.6.29为例,介绍如何在ZIX嵌入式开发环境下探索linux内核启动过程。

Linux内核启动一般由外部的bootloader引导,也可以在内核头部嵌入一个loader,实际的应用中这两种方式都会经常遇到。所以要了解内核启动最开始的过程,必须对bootloader如何引导内核有所熟悉。下面我们从u-boot加载linux内核的代码开始分析(关于u-boot 自身的启动流程,请参考)。

1.处理器内核加载代码

u-boot里,实现了处理器架构相关的linux内核加载代码,特别是tags传递。

该函数中,在(u-boot-1.6)lib_arm/armlinux.c调用了getenvbootargs环境变量保存在commandline

    char *commandline = ("bootargs");

然后解析uImage文件头,并且按照头中的定义分解和加载uImage。所以这部分代码的运行取决于uImage文件是如何生成的,本文不做过多叙述,可参考另文了解u-boot使用。接下来进行tags设置工作,分别调用了

  • setup_start_tag()
  • setup_memory_tag()
  • setup_commandline_tag()
  • setup_initrd_tag()
  • setup_end_tag()

然后对TLBcache等进行invalid操作,这是通过在lib_arm/armlinux.c调用(cpu/arm920t/108)实现,然后即可跳入从uImage中分解出来的内核ImagezImage入口

    cleanup_before_linux ();

    theKernel (0, machid, bd->bi_boot_params);

    /* does not return */

    return;

s3c2410平台上,该入口theKernel一般是物理地址0x30008000。如果我们使用zImage自解压内核映像,对应的代码正是自解压头,位置在内核源码linux-2.6.29arch/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将系统完全的交给了OSbootloader生命终止。之后代码在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-r6ipsp等寄存器,并检查代码是否运行在与链接时相同的目标地址(162),以决定是否进行处理。由于现在很少有人不使用loadertags,将zImage烧写到rom直接从0x0位置执行,所以这个处理是必须的(但是zImage的头现在也保留了不用loader也可启动的能力)。arm架构下自解压头一般是链接在0x0地址而被加载到0x30008000运行,所以要修正这个变化。涉及到

  • r5寄存器存放的zImage基地址
  • r6r12(即ip寄存器)存放的gotglobal offset table
  • r2r3存放的bss段起止地址
  • sp栈指针地址

很简单,这些寄存器统统被加上一个你也能猜到的偏移地址 0x30008000。该地址是s3c2410相关的,其他的ARM处理器可以参考下表

  • PXA2xx0xa0008000
  • IXP2x00IXP4xx0x00008000
  • Freescale i.MX31/370x80008000
  • TI davinci DM64xx0x80008000
  • TI omap系列是0x80008000
  • AT91RM/SAM92xx系列是0x20008000
  • Cirrus EP93xx0x00008000

这些操作发生在代码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}

管理员在2009年8月13日编辑了该文章文章。

-->
阅读(1920) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~