[PATCH v2 0/4] bootm: Handle compressed arm64 images with bootm

Simon Glass sjg at chromium.org
Sun Nov 12 01:45:31 CET 2023


This little series corrects a problem I noticed with arm64 images,
where the kernel is not recognised:

   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.

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.

Changes in v2:
- Add a 'success' case to the cover letter

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



More information about the U-Boot mailing list