分类: LINUX
2009-06-10 15:54:31
linux内核启动过程——基于S
(1)zImage自解压
本文以流行的Samsung公司的S
Linux内核启动一般由外部的bootloader引导,也可以在内核头部嵌入一个loader,实际的应用中这两种方式都会经常遇到。所以要了解内核启动最开始的过程,必须对bootloader如何引导内核有所熟悉。下面我们从u-boot加载linux内核的代码开始分析(关于u-boot 自身的启动流程,请参考)。
在u-boot的里,实现了处理器架构相关的linux内核加载代码,特别是tags传递。
该函数中,在(u-boot-1.6)lib_arm/armlinux.c的调用了getenv将bootargs环境变量保存在commandline
char *commandline = ("bootargs");
然后解析uImage文件头,并且按照头中的定义分解和加载uImage。所以这部分代码的运行取决于uImage文件是如何生成的,本文不做过多叙述,可参考另文了解u-boot使用。接下来进行tags设置工作,分别调用了
然后对TLB、cache等进行invalid操作,这是通过在lib_arm/armlinux.c的调用(cpu/arm920t/108)实现,然后即可跳入从uImage中分解出来的内核Image或zImage入口
cleanup_before_linux ();
theKernel (0, machid, bd->bi_boot_params);
/* does not return */
return;
在s
start:
.type start,#function
.rept 8
mov r0, r0
.endr
b
.word 0x
.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生命终止。之后代码在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-r6、ip、sp等寄存器,并检查代码是否运行在与链接时相同的目标地址(162行),以决定是否进行处理。由于现在很少有人不使用loader和tags,将zImage烧写到rom直接从0x0位置执行,所以这个处理是必须的(但是zImage的头现在也保留了不用loader也可启动的能力)。arm架构下自解压头一般是链接在0x0地址而被加载到0x30008000运行,所以要修正这个变化。涉及到
很简单,这些寄存器统统被加上一个你也能猜到的偏移地址 0x30008000。该地址是s
这些操作发生在代码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链接到同样的地址,s
在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日编辑了该文章文章。