[PATCH v2 0/5] bootm: Handle compressed arm64 images with bootm
Simon Glass
sjg at chromium.org
Sun Nov 12 04:49:52 CET 2023
This little series corrects a problem I noticed with arm64 images,
where the kernel is not recognised if compression is used:
U-Boot> tftp image.fit
Using ethernet at 7d580000 device
TFTP from server 192.168.4.7; our IP address is 192.168.4.147
Filename 'image.fit'.
Load address: 0x1000000
Loading: ################################################## 23 MiB
20.5 MiB/s
done
Bytes transferred = 24118272 (1700400 hex)
U-Boot> bootm
## Loading kernel from FIT Image at 01000000 ...
Using 'conf-768' configuration
Trying 'kernel' kernel subimage
Description: Linux
Type: Kernel Image (no loading done)
Compression: gzip compressed
Data Start: 0x01000120
Data Size: 13662338 Bytes = 13 MiB
Verifying Hash Integrity ... OK
Bad Linux ARM64 Image magic!
With this series:
U-Boot> tftp 20000000 image.fit
Using ethernet at 7d580000 device
TFTP from server 192.168.4.7; our IP address is 192.168.4.147
Filename 'image.fit'.
Load address: 0x20000000
Loading: ################################################## 23.5 MiB
20.8 MiB/s
done
Bytes transferred = 24642560 (1780400 hex)
U-Boot> bootm 0x20000000
## Loading kernel from FIT Image at 20000000 ...
Using 'conf-768' configuration
Trying 'kernel' kernel subimage
Description: Linux
Type: Kernel Image (no loading done)
Compression: zstd compressed
Data Start: 0x20000120
Data Size: 14333475 Bytes = 13.7 MiB
Verifying Hash Integrity ... OK
Using kernel load address 80000
## Loading fdt from FIT Image at 20000000 ...
Using 'conf-768' configuration
Trying 'fdt-768' fdt subimage
Description: Raspberry Pi 4 Model B
Type: Flat Device Tree
Compression: zstd compressed
Data Start: 0x215f820c
Data Size: 9137 Bytes = 8.9 KiB
Architecture: AArch64
Verifying Hash Integrity ... OK
Uncompressing Flat Device Tree to 3aff3010
Booting using the fdt blob at 0x3aff3010
Working FDT set to 3aff3010
Uncompressing Kernel Image (no loading done) to 80000
Moving Image from 0x80000 to 0x200000, end=2b00000
Using Device Tree in place at 000000003aff3010, end 000000003afff4c4
Working FDT set to 3aff3010
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
The problem is that the arm64 magic is checked before the image is
decompressed. However this is only part of it. The kernel_noload image
type should not be permitted with compression, so this series adds a
check for that.
Another issue is that the arm64 handling is done too early, before the
image is loaded. This series moves it to after loading, so that
compression can be handled.
This series also adjusts the 'load' address to be optional, since it is
often not possible to select a load address which can work with all
boards. We can use the kernel_addr_r environment variable instead.
A patch is included to show the kernel load-address, so it is easy to
see what is going on.
One annoying feature of arm64 is that the image is often copied to
another address. It might be possible for U-Boot to figure that out
earlier and decompress it to the right place, but perhaps not.
With all of this it should be possible to boot a compressed kernel on
any of the 990 arm64 boards supported by Linux, although I have only
tested two.
Changes in v2:
- Allow omitting the load address rather than messing with kernel_noload
- Rework the patch based on a better understanding of events
- Add a 'success' case to the cover letter
- Redo how the arm64 support is implemented
Simon Glass (5):
image: Correct load_bug typo
image: Show the load address when decompressing
bootm: Allow omitting the load address
bootm: Move arm64-image processing later
boot: Don't allow kernel_noload with compression
boot/bootm.c | 67 ++++++++++++++++++----------
boot/image.c | 13 ++++--
doc/usage/fit/source_file_format.rst | 7 ++-
include/image.h | 2 +-
4 files changed, 60 insertions(+), 29 deletions(-)
--
2.42.0.869.gea05f2083d-goog
More information about the U-Boot
mailing list