1. 内核镜像组成及编译

一. 内核镜像格式

这里有一篇很好的博客 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的大小

因为后面的内核解压会用到这里的部分知识，所以才会有这样一个开篇。

后面开始分析内核解压过程。