mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 18:21:39 +01:00
Michal Orzel
6d317b10f8
At the moment, Xen does not support booting gzip compressed uImages.
This is because we are trying to decompress the kernel before probing
the u-boot header. This leads to a failure as the header always appears
at the top of the image (and therefore obscuring the gzip header).
Move the call to kernel_uimage_probe before kernel_decompress and make
the function self-containing by taking the following actions:
- take a pointer to struct bootmodule as a parameter,
- check the comp field of a u-boot header to determine compression type,
- in case of compressed image, call kernel_decompress passing uImage
header size as an offset to gzip header,
- set up zimage.{kernel_addr,len} accordingly,
- return -ENOENT in case of a u-boot header not found to distinguish it
amongst other return values and make it the only case for falling
through to try to probe other image types.
Modify kernel_decompress to take an additional parameter being an offset
to a gzip header from start address. This is needed so that a function
can first operate on a region containing actually compressed kernel (in case
of compressed uImage, size of u-boot header is an offset to a gzip header)
and then at the end pass the entire region (as it was before taking an offset
into account) to fw_unreserved_regions for freeing.
This approach avoids splitting the uImage probing into 2 stages (executed
before and after decompression) which otherwise would be necessary to
properly parse header, update boot module start and size before
decompression and update zimage.{kernel_addr,len} afterwards.
Remove the limitation from the booting.txt documentation.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewwed-by: Julien Grall <jgrall@amazon.com>