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@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@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(-)