From: Tom Rini Date: Fri, 15 Dec 2023 14:41:44 +0000 (-0500) Subject: Merge patch series "bootm: Handle compressed arm64 images with bootm" X-Git-Url: http://git.dujemihanovic.xyz/html/%7B%7B%20.Permalink%20%7D%7D?a=commitdiff_plain;h=d7a2c7ff7528653612dfeed175a127b1e691e855;p=u-boot.git Merge patch series "bootm: Handle compressed arm64 images with bootm" To quote the author: 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 doesn't work with compression, since the kernel is not loaded. So this series deals with that by using an lmb-allocated buffer for the uncompressed kernel. 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. 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. --- d7a2c7ff7528653612dfeed175a127b1e691e855