Hi, On Sun, 5 Nov 2023 at 20:05, Simon Glass <s...@chromium.org> wrote: > > This little series corrects a problem I noticed with arm64 images, > where the kernel is not recognised: > > ## Loading kernel from FIT Image at 10000000 ... > Using 'conf-930' configuration > Verifying Hash Integrity ... OK > Trying 'kernel' kernel subimage > Description: Linux-6.6.0-rc7-next-20231024-00003-g259c196f194c > Type: Kernel Image (no loading done) > Compression: gzip compressed > Data Start: 0x10000138 > Data Size: 13667956 Bytes = 13 MiB > Verifying Hash Integrity ... OK > Bad Linux ARM64 Image magic! > > The problem is that the arm64 magic is checked before the image is > decompressed. > > Another issue is that the load address is read from the 'load' property > even with a kernel_noload image. This means that the kernel is loaded > to address 0, which may not be valid on the board. 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. > > > Simon Glass (4): > bootm: Allow ignoring the load address with kernel_noload > bootm: Move arm64-image processing later > image: Show the load address when decompressing > image: Correct load_bug typo > > boot/bootm.c | 61 ++++++++++++++++++++++++++++++------------------- > boot/image.c | 13 +++++++---- > include/image.h | 2 +- > 3 files changed, 48 insertions(+), 28 deletions(-) > > -- > 2.42.0.869.gea05f2083d-goog >
This series has a few problems still, but I am sending it now since I believe it fixes a real problem on arm64. I will tidy it up soon. Regards, Simon