为什么使用uImage而不是zImage

I'am trying to learn the difference between a zImage and a uImage.

我想知道zImage和uImage的区别。

In my understanding uImage is got by running mkimage on the Image and as a result it adds a U-Boot wrapper (i don't know what it contains exactly) that contains a header plus the load address and entry point and maybe "extra informations" that i don't know.

在我的理解中，uImage是通过在映像上运行mkimage获得的，因此它添加了一个U-Boot包装器(我不知道它具体包含什么)，其中包含一个header，加上加载地址和入口点，可能还有“额外的信息”，我不知道。

In the other hand the zImage is the compressed Image, it doesn't contain the load address and entry point(what i think, correct me if i'am wrong) but also U-Boot can load it using bootz.

另一方面，zImage是压缩后的映像，它不包含加载地址和入口点(我想，如果我错了，请纠正我)，但是U-Boot也可以使用bootz加载。

In this case why using a uImage instead of a zImage?

在这种情况下，为什么要使用uImage而不是zImage呢?
I'am curious to learn what are the formats of a zImage and a uImage could you please suggest some references ?

我想知道zImage和uImage的格式是什么，你能推荐一些参考吗?

2 个解决方案

#1

In my understanding uImage is got by running mkimage on the Image

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

Your understanding is only partly correct.
A uImage can contain any type of file, and is not restricted to the Linux Image file. In fact it not likely to be the (uncompressed) Image file (since that is not a conventional make option).

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

In the other hand the zImage is the compressed Image, it doesn't contain the load address and entry point(what i think, correct me if i'am [sic] wrong)

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

You're incorrect, the zImage does contain the kernel's load address and entry point. The load address is needed in order to decompress the kernel Image to the proper RAM address. The kernel's entry point is needed to execute it after it has been decompressed.
When building the Image and zImage for ARM, the Makefiles use

不正确，zImage确实包含内核的加载地址和入口点。为了将内核映像解压缩到适当的RAM地址，需要加载地址。在解压缩后，需要内核的入口点来执行它。在为ARM构建映像和zImage时，makefile会使用

ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)

which should translate to the start of physical memory + 0x8000.

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

The zImage itself (i.e. the self-extraction program) is PIC, position independent code. The zImage can be loaded anywhere in RAM, and executed at its first address, i.e. its entry point is its load address.

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

In this case why using a uImage instead of a zImage?

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

For older versions of U-Boot, there was no choice since the bootz command may not have been available for Linux kernels.
Nowadays it may be a subjective choice.

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

Note that there has been some resentment in the Linux kernel community towards the support of U-Boot in the kernel. IOW if some people had their way, I get the impression that you would not be able to build a uImage from the mainline source.

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

I'am [sic] curious to learn what are the formats of a zImage and a uImage could you please suggest some references ?

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

The layout of the zImage is essentially given by its linker specification.
For ARM see arch/arm/boot/compressed/vmlinux.lds.S.
Note that _magic_start contains a meaningless load address. This is also mentioned in Section 5 of Vincent Sanders' Booting ARM Linux

zImage的布局实质上是由它的链接器规范给出的。手臂看到弓/胳膊/ boot /压缩/ 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.

Note however that the ARM booting requirements have been superseded by Russel King's Documentation/arm/Booting

但是，请注意，Russel King的文档/ ARM / booting已经取代了ARM的引导需求。

The layout of a uImage is simply the U-Boot header plus the image file, whatever that may be.

uImage的布局只是U-Boot头加上图像文件，不管它是什么。

(Hopefully nothing I wrote contradicts what Tom Rini wrote.)

(但愿我写的东西与汤姆·里尼写的不一样。)

#2

This is not quite right. While the "legacy" u-boot header that is used to make what is typically called a uImage can be anything, including the Image found under arch/arm/boot/Image, it is most often the zImage file. This is because historically there was no support for directly booting a zImage in U-Boot and because a zImage provides no checksum on the data a uImage has a crc32 of the contents available.

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

The zImage file is a stand-alone executable. The legacy "uImage" format is not formally documented in U-Boot but could be understood by reading the code. In most cases, rather than using a "uImage" you would want to use a FIT image today, which has a number of docs in the doc/uImage.FIT directory in the U-Boot sources.

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

#1