u-boot.git/include/image.h, branch v2025.01

Merge patch series "Make LMB memory map global and persistent"

2024-09-03T20:09:30+00:00

Sughosh Ganu  says:

This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.

This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.

The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.

The tests have been tweaked where needed because of these changes.

The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.

[1] - https://lore.kernel.org/u-boot/20240704073544.670249-1-sughosh.ganu@linaro.org/T/#t

Notes:

1) These patches are on next, as the alist patches have been
   applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
   get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
   (ideally an 85xx, as I do not have one).

lmb: make LMB memory map persistent and global

2024-09-03T20:08:50+00:00

The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.

Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.

[sjg: Use a stack to store pointer of lmb struct when running lmb tests]

Signed-off-by: Sughosh Ganu 
Signed-off-by: Simon Glass 
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]

boot: android: fix booting without a ramdisk

2024-08-22T07:23:33+00:00

android_image_get_ramdisk() will return an error if there is no ramdisk.
Using the android image without a ramdisk worked until commit
1ce8e10f3b4b ("image: Fix up ANDROID_BOOT_IMAGE ramdisk code") because
the return code wasn't checked until then. Return -ENOENT in case
there is no ramdisk and translate that into -ENOPKG in the calling
code, which will then indicate "no ramdisk" to its caller
(boot_get_ramdisk()).

This way, we can get rid of the "*rd_data = *rd_len = 0;" in the error
path, too.

With this, I'm able to boot a linux kernel using fastboot again:

  fastboot --base 0x41000000 --header-version 2 --dtb /path/to/dtb \
  --cmdline "root=/dev/mmcblk0p1 rootwait" boot path/to/Image

Signed-off-by: Michael Walle 
Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Simon Glass 
Link: https://lore.kernel.org/r/20240729213657.2550935-1-mwalle@kernel.org
Signed-off-by: Mattijs Korpershoek

android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr()

2024-07-18T19:51:30+00:00

The only way to configure the load addresses for both bootimg and
vendor_bootimg is by using the "abootimg" command.
If we want to use the C API, there is no equivalent.

Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
specify the load address from C.

This can be useful for implementing an Android bootmethod.

Reviewed-by: Igor Opaniuk 
Reviewed-by: Julien Masson 
Reviewed-by: Simon Glass 
Reviewed-by: Guillaume La Roque 
Tested-by: Guillaume La Roque 
Signed-off-by: Mattijs Korpershoek

cmd: bootm: add ELF file support

2024-07-05T19:57:02+00:00

Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.

Signed-off-by: Maxim Moskalets

abootimg: Add init_boot image support

2024-06-07T22:20:33+00:00

Quote from [1]:

"For devices launching with Android 13, the generic ramdisk is removed
from the boot image and placed in a separate init_boot image.
This change leaves the boot image with only the GKI kernel."

While at it, update wrong error handling message when vendor_boot
cannot be loaded.

[1]: https://source.android.com/docs/core/architecture/partitions/generic-boot

Signed-off-by: Roman Stratiienko 
Reviewed-by: Mattijs Korpershoek

boot: fdt: Change type of env_get_bootm_low() to phys_addr_t

2024-04-11T15:38:57+00:00

Change type of ulong env_get_bootm_low() to phys_addr_t env_get_bootm_low().
The PPC/LS systems already treat env_get_bootm_low() result as phys_addr_t,
while the function itself still returns ulong. This is potentially dangerous
on 64bit systems, where ulong might not be large enough to hold the content
of "bootm_low" environment variable. Fix it by using phys_addr_t, similar to
what env_get_bootm_size() does, which returns phys_size_t .

Reviewed-by: Laurent Pinchart 
Reported-by: Laurent Pinchart 
Signed-off-by: Marek Vasut

tools: fix build without LIBCRYPTO support

2024-01-12T03:09:11+00:00

Commit cb9faa6f98ae ("tools: Use a single target-independent config to
enable OpenSSL") introduced a target-independent configuration to build
crypto features in host tools.

But since commit 2c21256b27d7 ("hash: Use Kconfig to enable hashing in
host tools and SPL") the build without OpenSSL is broken, due to FIT
signature/encryption features. Add missing conditional compilation
tokens to fix this.

Signed-off-by: Paul-Erwan Rio 
Tested-by: Alexander Dahl 
Cc: Simon Glass 
Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass

Merge patch series "bootm: Handle compressed arm64 images with bootm"

2023-12-15T14:41:44+00:00

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.

image: Correct load_bug typo

2023-12-15T14:41:38+00:00

Correct a typo in the function comment for image_decomp().

Signed-off-by: Simon Glass 
Reviewed-by: Tom Rini