[PATCH] boot: Support decompressing non-kernel OS images

Sometimes the kernel is built as an EFI application rather than a binary. We still want to support compression for this case.
For arm64 the entry point is set later in the bootm_load_os() function, since these images are typically relocated due to the 2MB-alignment requirement of arm64 images. But since the EFI image is not in the same format, we need to update the entry point earlier.
Set the entry point always, for kernel_noload to resolve this problem. It should be harmless to do this always.
Signed-off-by: Simon Glass sjg@chromium.org ---
boot/bootm.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/boot/bootm.c b/boot/bootm.c index 301cfded05c..75a94d97643 100644 --- a/boot/bootm.c +++ b/boot/bootm.c @@ -643,6 +643,7 @@ static int bootm_load_os(struct bootm_headers *images, int boot_progress) if (!load) return 1; os.load = load; + images->ep = load; debug("Allocated %lx bytes at %lx for kernel (size %lx) decompression\n", req_size, load, image_len); }

On Fri, Dec 15, 2023 at 04:54:16PM -0700, Simon Glass wrote:
Sometimes the kernel is built as an EFI application rather than a binary. We still want to support compression for this case.
For arm64 the entry point is set later in the bootm_load_os() function, since these images are typically relocated due to the 2MB-alignment requirement of arm64 images. But since the EFI image is not in the same format, we need to update the entry point earlier.
Set the entry point always, for kernel_noload to resolve this problem. It should be harmless to do this always.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
participants (2)
-
Simon Glass
-
Tom Rini