linux – 为什么使用uImage而不是zImage

我试图了解zImage和uImage之间的区别.

在我的理解中,通过在Image上运行mkimage来获得uImage,结果它添加了一个U-Boot包装器(我不知道它包含的内容)包含一个header加上加载地址和入口点,也许是“额外的信息” “我不知道.

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

>在这种情况下为什么使用uImage而不是zImage？
>我很想知道zImage的格式是什么,uImage可以请一些参考资料吗？

解决方法:

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

你的理解只是部分正确.
uImage可以包含任何类型的文件,并且不限于Linux映像文件.实际上它不太可能是(未压缩的)Image文件(因为那不是传统的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确实包含了内核的加载地址和入口点.需要加载地址才能将内核映像解压缩到正确的RAM地址.在解压缩后,需要内核的入口点来执行它.
在为ARM构建Image和zImage时,Makefile使用

ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)

这应该转换为物理内存0x8000的开头.

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

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

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

请注意,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的布局基本上由其链接器规范给出.
对于ARM,请参阅arch/arm/boot/compressed/vmlinux.lds.S.
请注意,_magic_start包含无意义的加载地址.这也在Vincent Sanders’Booting 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标头加上图像文件,无论可能是什么.

(希望我写的任何内容都与Tom Rini写的内容相矛盾.)

标签：linux,kernel,boot,u-boot
来源： https://codeday.me/bug/20190622/1264511.html