为什么使用uImage而不是zImage

我试图学习zImage和uImage之间的区别。

在我的理解uImage是通过在Image上运行mkimage得到的,因此它添加了一个U-Boot包装器(我不知道它包含的是什么),它包含一个头文件加载地址和入口点,也许“额外的信息“我不知道。

另一方面, zImage是压缩Image ,它不包含加载地址和入口点(我认为,纠正我,如果我错了),而且U-Boot可以使用bootz加载它。

在我的理解uImage是通过在图像上运行mkimage得到的

你的理解只是部分正确的。
uImage可以包含任何类型的文件,并且不限于Linux 映像文件。 实际上它不可能是(未压缩的) 图像文件(因为这不是常规的make选项)。

另一方面,zImage是压缩的图像,它不包含加载地址和入口点(我认为,纠正我,如果我[原文]错误)

你是不正确的, zImage包含内核的加载地址和入口点。 需要加载地址才能将内核映像解压到适当的RAM地址。 内核的入口点在解压后需要执行。
在构建ARM的Image和zImage时,使用Makefiles

 ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET) 

这应该转化为物理内存+ 0x8000的开始。

zImage本身(即自解压程序)是PIC,位置无关的代码。 zImage可以加载到RAM中的任何地方,并在第一个地址执行,即它的入口点是它的加载地址。

在这种情况下,为什么使用uImage而不是zImage?

对于旧版本的U-Boot,没有选择,因为bootz命令可能不适用于Linux内核。
如今它可能是一个主观的选择。

请注意,Linux内核社区在内核中对U-Boot的支持方面存在一些不满。 如果有人有他们的路,我觉得你不能从主线来源建立一个uImage

我想知道什么是zImage和uImage的格式,请问您能推荐一些参考吗?

zImage的布局基本上由其链接器规范给出。
对于ARM,请参阅arch / arm / boot / compressed / vmlinux.lds.S 。
请注意, _magic_start包含一个无意义的加载地址。 Vincent Sanders的引导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 King的Documentation / arm / Booting所取代

uImage的布局只不过是U-Boot头文件和图像文件,无论如何。

(希望我写的内容与汤姆·里尼写的相矛盾。)

这是不正确的。 虽然用于制作通常称为uImage的“传统”u-boot标头可以是任何东西,包括在arch / arm / boot / Image下找到的图像,但它通常是zImage文件。 这是因为历史上不支持在U-Boot中直接引导zImage,并且由于zImage不提供对数据的校验和,因此uImage具有可用内容的crc32。

zImage文件是一个独立的可执行文件。 传统的“uImage”格式在U-Boot中没有正式记录,但可以通过阅读代码来理解。 在大多数情况下,不是使用“uImage”,而是使用今天的FIT图像,在U-Boot源文件的doc / uImage.FIT目录中有许多文档。