我正在尝试了解 zImage 和 uImage 之间的区别。
根据我的理解,
uImage
是通过在mkimage
上运行Image
获得的,因此它添加了一个U-Boot包装器(我不知道它到底包含什么),其中包含一个header加上负载地址和入口点,也许还有我不知道的“额外信息”。
另一方面,
zImage
是压缩的Image
,它不包含加载地址和入口点(我的想法,如果我错了请纠正我),但U-Boot也可以使用加载它bootz
。
在这种情况下为什么使用
uImage
而不是zImage
?我很想知道 zImage 和 uImage 的格式是什么,您能建议一些参考吗?
根据我的理解,uImage 是通过在 Image 上运行 mkimage 得到的
您的理解仅部分正确。
uImage 可以包含任何类型的文件,并且不限于 Linux Image 文件。事实上,它不太可能是(未压缩的)Image 文件(因为这不是传统的 make 选项)。
另一方面,zImage是压缩图像,它不包含加载地址和入口点(我的想法,如果我错了,请纠正我)
你错了,zImage确实包含内核的加载地址和入口点。需要加载地址才能将内核映像解压到正确的 RAM 地址。解压后需要内核的入口点来执行它。
为 ARM 构建 Image 和 zImage 时,Makefile 使用
ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)
这应该转换为物理内存的开头 + 0x8000。
zImage本身(即自解压程序)是PIC,位置无关代码。 zImage 可以加载到 RAM 中的任何位置,并在其首地址执行,即其入口点为其加载地址。
在这种情况下为什么使用 uImage 而不是 zImage?
对于旧版本的 U-Boot,别无选择,因为 bootz 命令可能不适用于 Linux 内核。
如今这可能是一个主观选择。
请注意,Linux 内核社区对内核中对 U-Boot 的支持存在一些不满。 IOW,如果有些人按自己的方式行事,我的印象是您将无法从主线源构建uImage。
我[原文如此]想了解 zImage 和 uImage 的格式是什么,您能否建议一些参考资料?
zImage 的布局本质上是由其链接器规范给出的。
对于 ARM,请参阅 arch/arm/boot/compressed/vmlinux.lds.S。
请注意,_magic_start包含无意义的加载地址。 Vincent Sanders 的 Booting ARM Linux
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 标头加上图像文件,无论是什么。
(希望我所写的内容与 Tom Rini 所写的内容没有任何矛盾。)
这不太正确。虽然用于制作通常称为 uImage 的“传统”u-boot 标头可以是任何东西,包括在 arch/arm/boot/Image 下找到的 Image,但它最常见的是 zImage 文件。这是因为历史上不支持在 U-Boot 中直接启动 zImage,并且 zImage 不提供数据校验和,uImage 具有可用内容的 crc32。
zImage 文件是一个独立的可执行文件。传统的“uImage”格式并未正式记录在 U-Boot 中,但可以通过阅读代码来理解。在大多数情况下,您今天不想使用“uImage”,而是希望使用 FIT 映像,该映像在 U-Boot 源代码的 doc/uImage.FIT 目录中包含许多文档。