为什么要使用uImage而不是zImage

据我了解，uImage是通过在Image上运行mkimage获得的

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

另一方面，zImage是压缩的Image，它不包含加载地址和入口点（我认为，如果我错了，请纠正我）

您不正确，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）的引导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标头加上图像文件，无论可能是什么。

（希望我写的东西与汤姆·里尼写的东西不矛盾。）