一. 内核镜像格式
这里有一篇很好的博客 Linux Kernel image_Hacker_Albert的博客-CSDN博客
以下信息摘自上面的博客
vmlinux :
vmlinux是最原始,未压缩的内核镜像。vm代表Virtual Memory。Linux支持虚拟内存,因此得名vm。它是通过源码经过编译汇编, 链接而成的 ELF 文件。因此这个 vmlinux 文件包含了 ELF 的属性,以及各种调试信息等,因此这个阶段的内核镜像 vmlinux 特别大,而且不能直接在 arm 上直接运行。
Image:
Image 由于 vmlinux 镜像体积巨大而且不能在 arm 上运行,因此需要使用 objcopy工具将不需要 的 section 从 vmlinux 里面剥离出来,最终在就是 arch/arm/boot/Image 文件, 此时 Image 是可以在 arm 平台上运行的,该镜像文件也是未压缩。
piggy_data:
piggy.gz/piggy_data The file Image compressed with gzip. 一开始只支持 gzip 压缩方法,所以将压缩之后的 Image 称为 piggy.gz,但随着内核的不断 发展,内核支持更多的压缩算法,因此把压缩之后的 Image 称为 piggy_data。位置 arch/arm/boot/compressed/piggy_data
piggy.o 之前说过 Image 可以在 arm 上运行,当不能直接运行,因为 Image 运行前需要一些已知初始化环境,这就需要特定功能的代码实现这些功能,这里称这些代码为 bootstrap。 于是内核在 arch/arm/boot/compressed/ 目录下增加了 bootstrap 功能的代码。和制作 vmlinux 一样,需要将这个目录下的源文件编译汇编成目标文件,然后再链接成一个文件。 为了构造这个,内核将 piggy_data 直接塞到了一个汇编文件 piggy.S 中,然后这个文件 经过汇编之后,就生成了 piggy.o。位置arch/arm/boot/compressed/piggy.o
zImage:
zImage 是通过带 bootstrap loader 的内核 ELF 文件经过 objcopy 命令之后制作生成 的二进制文件,用于在 arm 上直接运行。同原始 vmlinux 转换为 Image 过程一致。制作完 zImage 之后, 可以将 zImage 在 arm 上运行。最终在内存SDRAM中的内核镜像是经过压缩的,只是在运行时再将其解压。所以编译时会先使用gzip将镜像文件image进行压缩,再将压缩后的镜像文件和源码中的两个文件(如下所示)一起链接生成压缩后的镜像文件compress/vmlinux,注意,这两个源码文件是解压程序,用于将内存SDRAM中的压缩镜像zImage进行解压,然后再执行kernel 的第一阶段启动代码arch/arm/kernel/head.S。简而言之,在内存中运行内核时,kernel先自身解压,再执行第一阶段启动代码。
System.map:
System.map是由“nm vmlinux”产生并且不相关的符号被滤出。
二. 镜像piggy_data的生成过程
Makefile位置:arch/arm/boot/compressed/Makefile
$(obj)/piggy_data: $(obj)/../Image FORCE
$(call if_changed,$(compress-y))
if_changed是自定义函数,位置在scripts/Kbuild.include
# Execute command if command has changed or prerequisite(s) are updated.
if_changed = $(if $(strip $(any-prereq) $(arg-check)), \
@set -e; \
$(echo-cmd) $(cmd_$(1)); \
printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
- any-prereq:检查是否有依赖比目标新,或者依赖还没有创建
- arg-check: 检查编译目标的命令相对上次是否发生变化
- set –e : 表示make出错时直接退出,@符号表示不显示该set命令
- cmd_$(1):中的1表示传给if_changed的第一个参数
对于对于compress-y
compress-$(CONFIG_KERNEL_GZIP) = gzip
compress-$(CONFIG_KERNEL_LZO) = lzo
compress-$(CONFIG_KERNEL_LZMA) = lzma
compress-$(CONFIG_KERNEL_XZ) = xzkern
compress-$(CONFIG_KERNEL_LZ4) = lz4
对于上面的压缩方式,这里百度得到了以下内容
在压缩大小方面,GZIP生成最小的压缩内核大小,其次是LZO(比它大16%)和LZ4(比它大25%)。
在解压时间上,LZ4比GZIP快7倍以上,LZO比GZIP在x86上快1.25倍左右。
即使使用慢速旋转媒体和慢速CPU, LZ4内核的较长的加载时间也会被更快的解压时间所克服。
随着媒体速度的加快,GZIP、LZ4和LZO之间的加载时间差减小,解压时间成为主要的速度因素,而LZ4显然是赢家。
比如我现在手里的板子是RV1126,内核配置的是CONFIG_KERNEL_LZ4=y,也就是说piggy_data是Image通过LZ4压缩后得到的。
lz4的命令如下
quiet_cmd_lz4c = LZ4C $@
cmd_lz4c = (cat $(filter-out FORCE,$^) | \
lz4c -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
(rm -f $@ ; false)
可以看到有个size_append的函数,这个函数用于计算Image镜像的大小
其实最终命令是这样的
cat arch/arm/boot/compressed/../Image | lz4c -tdin stdout && printf \\134\\265\\324\\000) > arch/arm/boot/compressed/piggy_data
实际测试一下
# ls arch/arm/boot/Image -l
-rwxr-xr-x 1 root root 13940060 Apr 9 01:02 arch/arm/boot/Image
# ls arch/arm/boot/compressed/piggy_data -l
-rw-r--r-- 1 root root 6043027 Apr 9 01:02 arch/arm/boot/compressed/piggy_data
# hexdump arch/arm/boot/compressed/piggy_data -s 6043023
05c358f b55c 00d4
05c3593
13940060 = 0xd4b55c
可以看到piggy_data最后4个字节存储的是Image的大小
因为后面的内核解压会用到这里的部分知识,所以才会有这样一个开篇。
后面开始分析内核解压过程。