问为什么使用uImage而不是zImage

EN

根据我的理解，uImage是通过在映像上运行my映像获得的。

你的理解只是部分正确。

uImage可以包含任何类型的文件，并且不限于Linux 图像文件。实际上，它不太可能是(未压缩的)图像文件(因为这不是传统的make选项)。

另一方面，zImage是压缩图像，它不包含加载地址和入口点(如果我想错了，请纠正我)

您不正确，zImage确实包含内核的加载地址和入口点。为了将内核映像解压缩到适当的RAM地址，需要加载地址。内核的入口点需要在解压缩后执行。

在为ARM构建映像和zImage时，Makefiles使用

ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)

它应该转换为物理内存+ 0x8000的开始。

zImage本身(即自抽取程序)是独立于位置的代码。zImage可以在RAM中的任何地方加载，并在其第一个地址执行，即它的入口点是它的加载地址。

在这种情况下，为什么使用uImage而不是zImage呢？

对于较早版本的U，没有选择，因为Linux 命令可能无法用于Linux内核。

如今，这可能是一种主观的选择。

请注意，Linux内核社区对内核中的support支持有一些不满。如果有些人有自己的方式，我的印象是，您将无法从主线源构建uImage。

我很想知道zImage和uImage的格式，你能推荐一些参考资料吗？

zImage的布局基本上是由它的链接器规范给出的。

有关ARM，请参见arch/arm/引导/压缩/vmlinux.lds.S。

注意，_magic_start包含一个无意义的加载地址。在文森特·桑德斯的引导ARM Linux第5节中也提到了这一点

The zImage has a magic number and some useful information near its beginning.

Table 2. Useful fields in zImage head code
Offset into zImage  Value       Description
    0x24        0x016F2818      Magic number used to identify this is an ARM Linux zImage
    0x28        start address   The address the zImage starts at
    0x2C        end address     The address the zImage ends at

The start and end offsets can be used to determine the length of the compressed image (size = end - start).  
 ...  
The start address is usually 0 as the zImage code is position independent.

但是请注意，ARM引导需求已经被Russel的文件/arm/引导所取代

uImage的布局只是layout头加上图像文件，不管是什么。

(但愿我写的任何东西都与汤姆·里尼的话相矛盾。)

这并不完全正确。虽然用于制作通常称为uImage的“遗留”u引导头可以是任何东西，包括在arch/arm/boot/Image下找到的映像，但它通常是zImage文件。这是因为历史上不支持在support中直接引导zImage，而且因为zImage不对uImage具有可用内容的crc32的数据提供校验和。

zImage文件是一个独立的可执行文件。遗留的"uImage“格式没有正式记录在format中，但是可以通过阅读代码来理解。在大多数情况下，与其使用"uImage“，不如现在使用FIT映像，它在U源代码中的doc/uImage.FIT目录中有许多文档。