kernel 启动过程之一， uimge, zimage，arch/arm/boot/compressed/head.S

最新推荐文章于 2023-02-04 12:19:59 发布

pottichu

最新推荐文章于 2023-02-04 12:19:59 发布

阅读量8.1k

点赞数

分类专栏： kernel 文章标签： input makefile linux output byte 工作

kernel 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

这几天因为工作原因，升级 2.6.22.7 的kernel 到 Mavell 的arm 板子上去，遇到一些头疼的问题，
不得不分析启动代码，郁闷阿。

zImage是ARM Linux常用的一种压缩映像文件，uImage是U-boot专用的映像文件，它是在zImage之前加上一个长度为0x40的“头”，说明这个映像文件的类型、加载位置、生成时间、大小等信息。换句话说，如果直接从uImage的0x40位置开始执行，zImage和uImage没有任何区别。另外， Linux2.4内核不支持uImage，Linux2.6内核加入了很多对嵌入式系统的支持，但是uImage的生成也需要设置。

内核编译完成后会生成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