zImage内核镜像解压过程详解

Linux vmlinuz与xImage 编译Linux内核生成的镜像主要有Image、arch/arm/boot/zImage、bzImage和uImage四种,它们有何区别呢? 阅读详情

本文以linux-2.6.14内核在S3C2410平台上运行为例,讲解内核的解压过程。

内核编译完成后会生成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中的位置了吧。

时间关系,可能叙述的不够详细,大家可以集合内核代码和网上的其它相关文章,理解启动解压过程。


嵌入式Linux的内核镜像生成过程 嵌入式Linux的内核镜像生成过程最近读了《embedded linux primer》,里面讲到了Linux内核镜像的生成过程。 感觉在这方面算是讲的比较好的。在这里翻译一下。顶层目录的vmlinux配置好交叉编译环境后,就可以以开始准备编译内核了。首先需要编译生成内核头文件,然后开始编译内核。内核编译完成后,会在 顶层目录生成vmlinux ELF文件。这个vmlinux文件包含整个内核代码 阅读详情

相关推荐

嵌入式系统/ARM技术中的zImage内核镜像解压过程详解

作者:刘洪涛,华清远见嵌入式培训中心讲师。     本文以linux-2.6.14内核在S3C2410平台上运行为例,讲解内核的解压过程。   内核编译完成后会生成zImage内核镜像文件。关于bootloader加载zImage到内核,并且跳转到zImage开始地址运行zImage的过程,相信大家都很容易理解。但对于zImage是如何解压的过程,就不是那么好理解了。本文将结合部分关键代码,讲解zImage的解压过程。   先看看zImage的组成吧。在内核编译完成后会在arch/arm/boot/下生成zImage。   在arch/armboot/Makefile中:  

zImag 解压相关问题 收集

zImage内核镜像解压过程详解 http://www.embedu.org/Column/Column13.htm作者:刘洪涛,华清远见嵌入式培训中心讲师。在华清远见教学过程中,发现很多学员对内核镜像解压过程比较感兴趣,但网上相关的文章往往不能把关键问题讲清楚,所以写了这篇文章。本文以linux-2.6.14内核在S3C2410平台上运行为例,讲解内核的解压过程。 内核编译完

bromi的专栏 888

计量经济学(因果关系探究-空间双重差分模型: 破解空间溢出效应的因果分析工具)

本文介绍了传统双重差分(DID)模型及其局限性,重点阐述了空间DID模型的必要性。传统DID通过组间差分分离干预效应,但无法处理空间溢出效应。空间DID模型引入空间计量方法,包括三种类型:空间自回归模型(SDID-SAR)捕捉因变量溢出,空间误差模型(SDID-SEM)处理残差相关性,空间杜宾模型(SDID-SDM)同时考虑因变量和自变量的空间滞后。模型选择需结合空间相关性检验,适用于环境政策、房地产限购等存在空间交互效应的研究场景。

YBAdvanceFu的博客 2030

vmlinux, zImage, Image的区别 (

下面的内核编译过程,可以看出vmlinux, arch/arm/boot/compressed/vmlinux, arch/arm/boot/Image, arch/arm/boot/zImage 之间的区别     LD      vmlinux   SYSMAP  System.map   SYSMAP  .tmp_System.map   OBJCOPY arch/arm/boo

sadamoo的专栏 1152

当R语言遇见MaxENT:参数优化的艺术与自动化调参实践

本文探讨了R语言与MaxENT在生态位建模中的结合应用,重点介绍了参数优化与自动化调参的实践方法。通过caret与ENMeval工具链,研究人员可以高效处理多物种、多环境变量的大规模分析任务,提升模型性能与工作效率。文章还涵盖了从数据准备到结果可视化的全流程,为生态学家提供了实用的技术指导。

corn8的博客 455

嵌入式通信协议框架的四层架构设计与实现

本文详细介绍一种模块化的嵌入式通信协议框架设计,采用四层架构:硬件抽象层统一管理数据收发与缓冲,隔离硬件差异;协议管理层通过特征识别自动路由多协议数据,支持动态扩展;协议处理层独立实现各协议解析/构建,确保校验安全与零拷贝效率;应用层采用表驱动模式处理业务逻辑,与协议细节解耦。 该架构已应用于工业控制等领域,具备强类型安全、高扩展性和平台无关性特点,显著提升复通信场景下的开发效率与系统可靠性。提供完整代码实现与设计要点分析,助力开发者构建高效通信栈。

Bit_Dong的博客 2464

Linux内核源码分析--内核启动之zImage自解压过程

  参考: http://blog.chinaunix.net/uid-20543672-id-3018233.html Linux内核编译流程分析 linux2.6内核启动分析--李枝果(不看是你的损失^_^) 文档下载地址: http://files.cnblogs.com/pengdonglin137/Linux%E5%86%85%E6%A0%B8%E6%BA%90%E7%A0%...

weixin_34128839的博客 931

Python对象的基本组成和内存示意图及引用的本质

在Python中,变量也称为:对象的引用(reference)。变量存储的就是对象的地址。变量不需要显式声明类型。根据变量引用的对象,Python解释器自动确定数据类型。一个内存块,拥有特定的值,支持特定类型的相关操作。变量位于:栈内存(压栈出栈等细节,后续再介绍)。⚠️Python是动态类型语言。变量通过地址引用了“对象”。

Calor13的博客 557

Linux学习之zImage内核镜像解压过程详解

  zImage内核镜像解压过程详解 收藏<br /><br />zImage内核镜像解压过程详解 <br />作者: 刘洪涛,华清远见嵌入式培训中心 讲师。<br />本文以linux-2.6.14内核在S3C2410平台上运行为例,讲解内核的解压过程。 <br />内核编译完成后会生成zImage内核镜像文件。关于bootloader加载zImage到内核,并且 跳转到zImage开始地址运行zImage的过

guopeixin的专栏 2707

DCMM评估报告模板样例

这篇DCMM评估报告对某数据管理公司2020年的数据管理能力进行了全面分析。报告显示,该公司在数据战略方面取得初步进展,但在数据治理和数据架构方面仍存在明显不足,包括缺乏有效治理流程、数据质量监控不足,以及数据标准化和转换灵活性不足等问题。评估报告提出了针对性改进建议,包括完善数据战略、建立治理流程、加强质量监控和提升数据转换灵活性等,为提升数据管理成熟度提供了重要指导。

cdfunlove的博客 166

[yolov5/yolov8修改]替换yolov5/yolov8中的主干网络为EfficientNetv2

针对yolov5和yolov8的主干网络进行替换。

PLH19990227的博客 4146
上一篇: head.s 分析
下一篇: Linux-Android启动之Init进程前传
hellolwl
博客等级 码龄24年 16粉丝 0原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值