Why using a uImage instead of a zImage

Question

I'am trying to learn the difference between a zImage and a 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.

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.

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

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

Phase

Answer 1

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

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).

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)

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

ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)

which should translate to the start of physical memory + 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.

In this case why using a uImage instead of a 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.

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.

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

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

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/arch/arm/booting

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

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

Tectrix

Thank you, 1- "A uImage can contain any type of file, and is not restricted to the Linux Image file", could you please give example of file that a uImage can contain? 2- "You're incorrect, the zImage does contain the kernel's load address and entry point", i was talking about boot device load address not the kernel load address, anyway i think i have understand; the zImage is PIC so no matter where it is loaded – Phase

(1) The header has a byte that encodes the type of image. See elixir.free-electrons.com/u-boot/latest/source/include/… for the more-than-thirty possible values. (2) The zImage does contain its load address at offset 0x28 (but nobody seems to use it). – Tectrix

I would please like to ask, does it mean: The load address of zImage=zImage entry point=(start_of_phy_address+0x8000) – Precipitant

@Precipitant -- No, you're confusing zImage with Image. The zImage is position independent, which means that it can be loaded anywhere it fits, and then executed at its first address. – Tectrix

Answer 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.

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.

Subaquatic