u-boot FIT image介绍

作者：wowo

1. 前言

Linux kernel在ARM架构中引入device tree（全称是flattened device tree，后续将会以FDT代称）的时候[1]，其实怀揣了一个Unify Kernel的梦想----同一个Image，可以支持多个不同的平台。随着新的ARM64架构将FDT列为必选项，并将和体系结构有关的代码剥离之后，这个梦想已经接近实现：

在编译linux kernel的时候，不必特意的指定具体的架构和SOC，只需要告诉kernel本次编译需要支持哪些板级的platform即可，最终将会生成一个Kernel image，以及多个和具体的板子（哪个架构、哪个SOC、哪个版型）有关的FDT image（dtb文件）。

bootloader在启动的时候，根据硬件环境，加载不同的dtb文件，即可使linux kernel运行在不同的硬件平台上，从而达到unify kernel的目标。

本文将基于嵌入式产品中普遍使用的u-boot，以其新的uImage格式（FIT image，Flattened uImage Tree）为例，介绍达到此目标的步骤，以及背后的思考和意义。

2. Legacy uImage

从u-boot的角度看，它要boot一个二进制文件（例如kernel Image），需要了解该文件的一些信息，例如：

该文件的类型，如kernel image、dtb文件、ramdisk image等等？

该文件需要放在memory的哪个位置（加载地址）？

该文件需要从memory哪个位置开始执行（执行地址）？

该文件是否有压缩？

该文件是否有一些完整性校验的信息（如CRC）？

等等

结合“X-010-UBOOT-使用booti命令启动kernel(Bubblegum-96平台)”中有关booti的例子，上面信息被隐含在我们的命令行中了，例如：

通过DFU工具，将指定的image文件下载到指定的memory地址，间接的指定了二进制文件加载地址；

booti命令本身，说明加载的文件类型是ARM64平台的Image文件；

通过booti的参数，可以指定Kernel Image、ramdisk、DTB文件的执行位置；

等等。

不过，这种做法缺点很明显（总结来说，就是太啰嗦了）：

需要往memory中搬不同的二进制文件（Kernel、DTB、ramdisk等）；

boot指令（booti等）有比较复杂的参数；

无法灵活地处理二进制文件的校验、解压缩等操作；

等等。

为了解决上述缺点，u-boot自定义了一种Image格式----uImage。最初的时候，uImage的格式比较简单，就是为二进制文件加上一个header（具体可参考“include/image.h”中的定义），标示该文件的特性。然后在boot该类型的Image时，从header中读取所需的信息，按照指示，进行相应的动作即可。这种原始的Image格式，称作Legacy uImage，其特征可总结为：

1）使用mkimage工具（位于u-boot source code的tools/mkimage中）生成。

2）支持OS Kernel Images、RAMDisk Images等多种类型的Image。

3）支持gzip、bzip2等压缩算法。

4）支持CRC32 checksums。

5）等等。

最后，之所以称作Legacy&#