Linux内核启动流程分析(一)【转】

简介:

转自:http://blog.chinaunix.net/uid-25909619-id-3380535.html

很久以前分析的,一直在电脑的一个角落,今天发现贴出来和大家分享下。由于是word直接粘过来的有点乱,敬请谅解!

S3C2410 Linux 2.6.35.7启动分析(第一阶段)

arm linux 内核生成过程 

1. 依据arch/arm/kernel/vmlinux.lds 生成linux内核源码根目录下的vmlinux,这个vmlinux属于未压缩,带调试信息、符号表的最初的内核,大小约23MB; 
命令:arm-linux-gnu-ld -o vmlinux -T arch/arm/kernel/vmlinux.lds  
arch/arm/kernel/head.o  
init/built-in.o  
--start-group   
arch/arm/mach-s3c2410/built-in.o   
kernel/built-in.o          
mm/built-in.o   
fs/built-in.o   
ipc/built-in.o   
drivers/built-in.o   
net/built-in.o  
--end-group .tmp_kallsyms2.o 


2. 将上面的vmlinux去除调试信息、注释、符号表等内容,生成arch/arm/boot/Image,这是不带多余信息的linux内核,Image的大小约3.2MB 
  命令:arm-linux-gnu-objcopy -O binary -S  vmlinux arch/arm/boot/Image 

3.将 arch/arm/boot/Image gzip -9 压缩生成arch/arm/boot/compressed/piggy.gz大小约1.5MB;          命令:gzip -f -9 < arch/arm/boot/compressed/../Image > arch/arm/boot/compressed/piggy.gz 

4. 编译arch/arm/boot/compressed/piggy.S 生成arch/arm/boot/compressed/piggy.o大小约1.5MB,这里实际上是将piggy.gz通过piggy.S编译进piggy.o文件中。而piggy.S文件仅有6行,只是包含了文件piggy.gz; 
 命令:arm-linux-gnu-gcc -o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/piggy.S 


5. 依据arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/目录下的文件head.o piggy.o misc.o链接生成 arch/arm/boot/compressed/vmlinux,这个vmlinux是经过压缩且含有自解压代码的内核,大小约1.5MB; 
命令:arm-linux-gnu-ld zreladdr=0x30008000 params_phys=0x30000100 -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux 


6. 将arch/arm/boot/compressed/vmlinux去除调试信息、注释、符号表等内容,生成arch/arm/boot/zImage大小约1.5MB;这已经是一个可以使用的linux内核映像文件了; 
命令:arm-linux-gnu-objcopy -O binary -S  arch/arm/boot/compressed/vmlinux  arch/arm/boot/zImage 


7. 将arch/arm/boot/zImage添加64Bytes的相关信息打包为arch/arm/boot/uImage大小约1.5MB; 
命令./mkimage -A arm -O linux -T kernel -C none -a 0x30008000 -e 0x30008000 -n 'Linux-2.6.35.7' -d arch/arm/boot/zImage arch/arm/boot/uImage

 

 

内核启动分析:

本文着重分析S3C2410 linux-2.6.35.7 内核启动的详细过程,主要包括: zImage 解压缩阶段、 vmlinux 启动汇编阶段、 startkernel 到创建第一个进程阶段三个部分,一般将其称为 linux 内核启动一、二、三阶段,本文也将采用这种表达方式。对于 zImage 之前的启动过程,本文不做表述,可参考前面正亮讲得 “ u-boot的启动过程分析”。

 

本文中涉及到的术语约定如下:

基本内核映像:即内核编译过程中最终在内核源代码根目录下生成的 vmlinux 映像文件,并不包含任何内核解压缩和重定位代码;

zImage 内核映像:包含了内核piggy.o及解压缩和重定位代码,通常是目标板 bootloader 加载的对象;

zImage 下载地址:即 bootloader 将 zImage 下载到目标板内存的某个地址或者 nand read 将 zImage 读到内存的某个地址;

zImage 加载地址:由 Linux 的 bootloader 完成的将 zImage 搬移到目标板内存的某个位置所对应的地址值,默认值 0x30008000 。

1、 Linux 内核启动第一阶段:内核解压缩和重定位

该阶段是从 u-boot 引导进入内核执行的第一阶段,我们知道 u-boot 引导内核启动的最后一步是:通过一个函数指针 thekernel()带三个参数跳转到内核( zImage )入口点开始执行,此时, u-boot 的任务已经完成,控制权完全交给内核( zImage )。 

稍作解释,在 u-boot 的文件arch\arm\lib\bootm.c(uboot-2010.9)中定义了 thekernel, 并在 do_bootm_linux 的最后执行 thekernel.

定义如下:void (*theKernel)(int zero, int arch, uint params); 

theKernel = (void (*)(int, int, uint))ntohl(hdr->ih_ep); 

//hdr->ih_ep----Entry Point Address uImage 中指定的内核入口点,这里是 0x30008000 。 

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

其中第二个参数为机器 ID, 第三参数为 u-boot 传递给内核参数存放在内存中的首地址,此处是 0x30000100 。 

由上述 zImage 的生成过程我们可以知道,第一阶段运行的内核映像实际就是arch/arm/boot/compressed/vmlinux,而这一阶段所涉及的文件也只有三个:   

(1)arch/arm/boot/compressed/vmlinux.lds

(2)arch/arm/boot/compressed/head.S      

(3)arch/arm/boot/compressed/misc.c 

下面的图是使用64MRAM时,通常的内存分布图:

下面我们的分析集中在 arch/arm/boot/compressed/head.S, 适当参考 vmlinux.lds 。

从linux/arch/arm/boot/compressed/vmlinux.lds文件可以看出head.S的入口地址为ENTRY(_start),也就是head.S汇编文件的_start标号开始的第一条指令。

下面从head.S中得_start 标号开始分析。(有些指令不影响初始化,暂时略去不分析)

代码位置在/arch/arm/boot/compressed/head.S中: 

start:

.type start,#function   /*uboot跳转到内核后执行的第一条代码*/

.rept 8            /*重复定义8次下面的指令,也就是空出中断向量表的位置*/

 mov r0, r0            /*就是nop指令*/

.endr

 

b 1f                   @ 跳转到后面的标号1处

.word 0x016f2818 @ 辅助引导程序的幻数,用来判断镜像是否是zImage

.word start @ 加载运行zImage的绝对地址,start表示赋的初值

.word _edata @ zImage结尾地址,_edata是在vmlinux.lds.S中定义的,表示init,text,data三个段的结束位置

1: mov r7, r1 @ save architecture ID 保存体系结构ID 用r1保存

mov r8, r2 @ save atags pointer 保存r2寄存器 参数列表,r0始终为0

mrs r2, cpsr @ get current mode  得到当前模式

tst r2, #3 @ not user?,tst实际上是相与,判断是否处于用户模式

bne not_angel            @ 如果不是处于用户模式,就跳转到not_angel标号处

/*如果是普通用户模式,则通过软中断进入超级用户权限模式*/

mov r0, #0x17 @ angel_SWIreason_EnterSVC,向SWI中传递参数

swi 0x123456 @ angel_SWI_ARM这个是让用户空间进入SVC空间

not_angel:                                /*表示非用户模式,可以直接关闭中断*/

mrs r2, cpsr @ turn off interrupts to 读出cpsr寄存器的值放到r2中

orr r2, r2, #0xc0 @ prevent angel from running关闭中断

msr cpsr_c, r2           @ 把r2的值从新写回到cpsr中

 

/*读入地址表。因为我们的代码可以在任何地址执行,也就是位置无关代码(PIC),所以我们需要加上一个偏移量。下面有每一个列表项的具体意义。

LC0是表的首项,它本身就是在此head.s中定义的

.type LC0, #object

LC0: .word LC0 @ r1 LC0表的起始位置

.word __bss_start @ r2 bss段的起始地址在vmlinux.lds.S中定义

.word _end @ r3 zImage(bss)连接的结束地址在vmlinux.lds.S中定义

.word zreladdr @ r4 zImage的连接地址,我们在arch/arm/mach-s3c2410/makefile.boot中定义的

.word _start @ r5 zImage的基地址,bootp/init.S中的_start函数,主要起传递参数作用

.word _got_start @ r6 GOT(全局偏移表)起始地址,_got_start是在compressed/vmlinux.lds.in中定义的

.word _got_end @ ip GOT结束地址

.word user_stack+4096 @ sp 用户栈底 user_stack是紧跟在bss段的后面的,在compressed/vmlinux.lds.in中定义的

@ 在本head.S的末尾定义了zImag的临时栈空间,在这里分配了4K的空间用来做堆栈。

.section ".stack", "w"

user_stack: .space 4096

GOT表的初值是连接器指定的,当时程序并不知道代码在哪个地址执行。如果当前运行的地址已经和表上的地址不一样,还要修正GOT表。*/

.text

adr r0, LC0                              /*把地址表的起始地址放入r0中*/

ldmia r0, {r1, r2, r3, r4, r5, r6, ip, sp} /*加载地址表中的所有地址到相应的寄存器*/

@r0是运行时地址,而r1则是链接时地址,而它们两都是表示LC0表的起始位置,这样他们两的差则是运行和链接的偏移量,纠正了这个偏移量才可以运行与”地址相关的代码“

subs r0, r0, r1 @ calculate the delta offset 计算偏移量,并放入r0中

beq not_relocated @ if delta is zero, we are running at the address we  were linked at.

@ 如果为0,则不用重定位了,直接跳转到标号not_relocated处执行

/*

  *   偏移量不为零,说明运行在不同的地址,那么需要修正几个指针 

         *   r5 – zImage基地址 

         *   r6 – GOT(全局偏移表)起始地址 

         *   ip – GOT结束地址 

*/

add r5, r5, r0 /*加上偏移量修正zImage基地址*/

add r6, r6, r0 /*加上偏移量修正GOT(全局偏移表)起始地址*/

add ip, ip, r0 /*加上偏移量修正GOT(全局偏移表)结束地址*/

              /*

  * 这时需要修正BSS区域的指针,我们平台适用。 

          *   r2 – BSS 起始地址 

            *   r3 – BSS 结束地址 

            *   sp – 堆栈指针 

*/

add r2, r2, r0 /*加上偏移量修正BSS 起始地址*/

add r3, r3, r0 /*加上偏移量修正BSS 结束地址*/

add sp, sp, r0 /*加上偏移量修正堆栈指针*/

/*

* 重新定位GOT表中所有的项.

*/

1: ldr r1, [r6, #0] @ relocate entries in the GOT

add r1, r1, r0 @ table.  This fixes up the

str r1, [r6], #4 @ C references.

cmp r6, ip

blo 1b

not_relocated: mov r0, #0 

1: str r0, [r2], #4 @ clear bss 清除bss段

str r0, [r2], #4

str r0, [r2], #4

str r0, [r2], #4

cmp r2, r3

blo 1b

bl cache_on        /* 开启指令和数据Cache ,为了加快解压速度*/

@ 这里的 r1,r2 之间的空间为解压缩内核程序所使用,也是传递给 decompress_kernel 的第二和第三的参数

mov r1, sp @ malloc space above stack

add r2, sp, #0x10000 @ 64k max解压缩的缓冲区

@下面程序的意义就是保证解压地址和当前程序的地址不重叠。上面分配了64KB的空间来做解压时的数据缓存。

/*

 *   检查是否会覆盖内核映像本身 

 *   r4 = 最终解压后的内核首地址 

 *   r5 = zImage 的运行时首地址,一般为 0x30008000

 *   r2 = end of malloc space分配空间的结束地址(并且处于本映像的前面) 

 * 基本要求:r4 >= r2 或者 r4 + 映像长度 <= r5 

(1)vmlinux 的起始地址大于 zImage 运行时所需的最大地址( r2 ) , 那么直接将 zImage 解压到 vmlinux 的目标地址

cmp r4, r2

bhs wont_overwrite /*如果r4大于或等于r2的话*/

(2)zImage 的起始地址大于 vmlinux 的目标起始地址加上 vmlinux 大小( 4M )的地址,所以将 zImage 直接解压到 vmlinux 的目标地址

add r0, r4, #4096*1024 @ 4MB largest kernel size

cmp r0, r5

bls wont_overwrite /*如果r4 + 映像长度 <= r5 的话*/

@ 前两种方案通常都不成立,不会跳转到wont_overwrite标号处,会继续走如下分支,其解压后的内存分配示意图如下:

mov r5, r2 @ decompress after malloc space

mov r0, r5          /*解压程序从分配空间后面存放 */

mov r3, r7

bl decompress_kernel

/******************************进入decompress_kernel***************************************************/

@ decompress_kernel共有4个参数,解压的内核地址、缓存区首地址、缓存区尾地址、和芯片ID,返回解压缩代码的长度。

decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,

  int arch_id)

{

output_data = (uch *)output_start;/* Points to kernel start */

free_mem_ptr = free_mem_ptr_p;     /*保存缓存区首地址*/

free_mem_ptr_end = free_mem_ptr_end_p;/*保存缓冲区结束地址*/

__machine_arch_type = arch_id;           

arch_decomp_setup();  

makecrc();                             /*镜像校验*/

putstr("Uncompressing Linux...");

gunzip();                            /*通过free_mem_ptr来解压缩*/

putstr(" done, booting the kernel.\n");

return output_ptr;                     /*返回镜像的大小*/

}

/******************************从decompress_kernel函数返回*************************************************/

add r0, r0, #127 + 128

bic r0, r0, #127 @ align the kernel length对齐内核长度

/*

 * r0     = 解压后内核长度

 * r1-r3  = 未使用 

 * r4     = 真正内核执行地址  0x30008000

 * r5     = 临时解压内核Image的起始地址 

 * r6     = 处理器ID         

 * r7     = 体系结构ID         

 * r8     = 参数列表               0x30000100

 * r9-r14 = 未使用

 */

@ 完成了解压缩之后,由于内核没有解压到正确的地址,最后必须通过代码搬移来搬到指定的地址0x30008000。搬运过程中有

@ 可能会覆盖掉现在运行的重定位代码,所以必须将这段代码搬运到安全的地方,

@ 这里搬运到的地址是解压缩了的代码的后面r5+r0的位置。

add r1, r5, r0 @ end of decompressed kernel 解压内核的结束地址

adr r2, reloc_start

ldr r3, LC1             @ LC1: .word reloc_end - reloc_start 表示reloc_start段代码的大小

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

bl cache_clean_flush  @清 cache

ARM(add pc, r5, r0)                     @ call relocation code 跳转到重定位代码开始执行

@ 在此处会调用重定位代码reloc_start来将Image 的代码从缓冲区r5帮运到最终的目的地r4:0x30008000处

reloc_start: add r9, r5, r0         @r9中存放的是临时解压内核的末尾地址

sub r9, r9, #128      @ 不拷贝堆栈

mov r1, r4      @r1中存放的是目的地址0x30008000

1:

.rept 4

ldmia r5!, {r0, r2, r3, r10 - r14} @ relocate kernel

stmia r1!, {r0, r2, r3, r10 - r14} /*搬运内核Image的过程*/

.endr

cmp r5, r9

blo 1b

mov sp, r1                            /*留出堆栈的位置*/

add sp, sp, #128              @ relocate the stack

call_kernel: bl cache_clean_flush    @清除cache             

bl cache_off            @关闭cache

mov r0, #0 @ must be zero

mov r1, r7 @ restore architecture number

mov r2, r8 @ restore atags pointer

@ 这里就是最终我们从zImage跳转到Image的伟大一跳了,跳之前准备好r0,r1,r2

mov pc, r4 @ call kernel

到此kernel的第一阶段zImage 解压缩阶段已经执行完。

第二阶段的在另外一篇中分析。











本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/sky-heaven/p/4846720.html,如需转载请自行联系原作者


相关文章
|
7天前
|
安全 Linux 编译器
探索Linux内核的奥秘:从零构建操作系统####
本文旨在通过深入浅出的方式,带领读者踏上一段从零开始构建简化版Linux操作系统的旅程。我们将避开复杂的技术细节,以通俗易懂的语言,逐步揭开Linux内核的神秘面纱,探讨其工作原理、核心组件及如何通过实践加深理解。这既是一次对操作系统原理的深刻洞察,也是一场激发创新思维与实践能力的冒险。 ####
|
9天前
|
网络协议 Linux 调度
深入探索Linux操作系统的心脏:内核与系统调用####
本文旨在揭开Linux操作系统中最为核心的部分——内核与系统调用的神秘面纱,通过生动形象的语言和比喻,让读者仿佛踏上了一段奇妙的旅程,从宏观到微观,逐步深入了解这两个关键组件如何协同工作,支撑起整个操作系统的运行。不同于传统的技术解析,本文将以故事化的方式,带领读者领略Linux内核的精妙设计与系统调用的魅力所在,即便是对技术细节不甚了解的读者也能轻松享受这次知识之旅。 ####
|
6天前
|
缓存 算法 安全
深入理解Linux操作系统的心脏:内核与系统调用####
【10月更文挑战第20天】 本文将带你探索Linux操作系统的核心——其强大的内核和高效的系统调用机制。通过深入浅出的解释,我们将揭示这些技术是如何协同工作以支撑起整个系统的运行,同时也会触及一些常见的误解和背后的哲学思想。无论你是开发者、系统管理员还是普通用户,了解这些基础知识都将有助于你更好地利用Linux的强大功能。 ####
14 1
|
7天前
|
缓存 编解码 监控
深入探索Linux内核调度机制的奥秘###
【10月更文挑战第19天】 本文旨在以通俗易懂的语言,深入浅出地剖析Linux操作系统内核中的进程调度机制,揭示其背后的设计哲学与实现策略。我们将从基础概念入手,逐步揭开Linux调度策略的神秘面纱,探讨其如何高效、公平地管理系统资源,以及这些机制对系统性能和用户体验的影响。通过本文,您将获得关于Linux调度机制的全新视角,理解其在日常计算中扮演的关键角色。 ###
27 1
|
14天前
|
网络协议 Linux 芯片
Linux 内核 6.11 RC6 发布!
【10月更文挑战第12天】
77 0
Linux 内核 6.11 RC6 发布!
|
17天前
|
监控 安全 Java
linux服务器上启动framework应用程序流程
【10月更文挑战第17天】在Linux服务器上启动Framework应用程序需经过准备工作、部署、启动、监控及访问五个步骤。首先确保服务器满足系统要求并安装依赖项;接着上传应用文件,编译构建,配置参数;然后通过脚本、命令行或系统服务启动应用;启动后检查日志,监控性能;最后确认访问地址,验证应用运行状态。具体操作应参照应用文档。
|
16天前
|
监控 Java Linux
linux服务器上启动framework应用程序流程
【10月更文挑战第18天】在 Linux 服务器上启动框架应用程序的流程包括:准备工作(确保访问权限、上传部署文件、了解启动要求)、检查依赖项、配置环境变量、切换到应用程序目录、启动应用程序、监控启动过程以及验证应用程序是否正常运行。具体步骤可能因应用程序类型和框架而异。
|
2月前
|
存储 安全 Linux
探索Linux操作系统的心脏:内核
在这篇文章中,我们将深入探讨Linux操作系统的核心—内核。通过简单易懂的语言和比喻,我们会发现内核是如何像心脏一样为系统提供动力,处理数据,并保持一切顺畅运行。从文件系统的管理到进程调度,再到设备驱动,我们将一探究竟,看看内核是怎样支撑起整个操作系统的大厦。无论你是计算机新手还是资深用户,这篇文章都将带你领略Linux内核的魅力,让你对这台复杂机器的内部运作有一个清晰的认识。
71 3
|
2月前
|
存储 传感器 Linux
STM32微控制器为何不适合运行Linux系统的分析
总的来说,虽然技术上可能存在某些特殊情况下将Linux移植到高端STM32微控制器上的可能性,但从资源、性能、成本和应用场景等多个方面考虑,STM32微控制器不适合运行Linux系统。对于需要运行Linux的应用,更适合选择ARM Cortex-A系列处理器的开发平台。
191 0
|
网络协议 NoSQL Linux
阿里云 Linux 内核优化实战(sysctl.conf 和 ulimits )
一、sysctl.conf优化Linux系统内核参数的配置文件为 /etc/sysctl.conf 和 /etc/sysctl.d/ 目录。其读取顺序为: /etc/sysctl.d/ 下面的文件按照字母排序;然后读取 /etc/sysctl.conf 。
8543 1