u-boot.git/boot/bootm.c, branch master

Merge patch series "bootm: Clean up arch-specific, pre-OS clean-up"

2026-03-19T00:36:50+00:00

Simon Glass  says:

Each arch does something slightly different before booting the OS. Some
archs even do different things depending on the CPU type.

It is quite hard to know what actually happens in the final milliseconds
before the OS boot.

This series attempts to start cleaning up U-Boot in this area.

The basic intent is to create a new bootm_final() function which can be
called by all archs. It provides some flags for a couple of necessary
variations but otherwise it is generic.

All architectures are converted over to use this new function.

board_quiesce_devices() is moved into bootm_final() so that all archs
benefit from it.

This series fixes a bug in device_remove() is fixed where removing a
parent with specialised flags (e.g. DM_REMOVE_ACTIVE_ALL) could leave
children activated, since they do not match the flags. This fixes is
needed to avoid bootm_final() causing test failures on sandbox.

Future work could take this a little further:
- Convert EFI loader to use the same function
- Improve comments for cleanup_before_linux() across architectures
- Support fake-run tracing on all archs

Link: https://lore.kernel.org/r/20260306023638.2678886-1-sjg@chromium.org

bootm: Stash bootstage data in bootm_final()

2026-03-18T19:17:34+00:00

ARM stashes bootstage data to a known memory location before booting,
so the kernel can pick it up. Add this to bootm_final() so all
architectures benefit from it.

The bootstage_stash_default() function is a no-op when bootstage or
stashing is disabled.

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

riscv: Call bootm_final()

2026-03-18T19:17:34+00:00

The RISC-V announce_and_cleanup() duplicates the common pre-boot
steps. Replace it with a call to bootm_final().

Move board_quiesce_devices() into bootm_final() so it is available to
all architectures. Drop the RISC-V weak definition and header
declaration since the generic one in bootm.h is used instead.

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

bootm: Create bootm_final() for pre-boot cleanup

2026-03-18T19:17:34+00:00

There are various functions which announce that booting is imminent and
do related preparation. Most of these are arch-specific.

In practice, most archs do a similar thing. It would be better to
have a common function, with perhaps some events for things that are
really arch- and board-specific.

Create a new bootm_final() function with the common pre-boot steps:
printing the "Starting kernel" message, recording bootstage data,
optionally writing bootstage to the FDT and printing a report, and
removing active devices.

Be careful to avoid using BIT() macros which are not available with host
tools.

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

bootm: fix booting kernel_noload image

2026-03-06T16:33:35+00:00

FIT images don't work without having to explicitly specify physical
load addresses. Digging into that it looks like a flaw in
bootm_load_os().
It duplicates images->os for convenience. However, the code handling
"kernel_noload" images then updates the load address in the copy with
the value lmb_alloc_mem() returned. Later there's another call to
lmb_alloc_mem() that uses the old value. This leads to havoc due
to subsequent calls of lmb_alloc_mem() picking too low addresses.

The "fix" is to mark the local variable const to avoid accidental
assignments. This works but IMO the logic is still flawed somehow as
this leads to overlapping lmb reservations. I guess the fixed
reservation should only be done when the noload path wasn't hit.

Without the change:
+ bootm 0x40200000#qemu-arm 0x40200000#qemu-arm 0x40000000
   Using 'qemu-arm' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel' kernel subimage
     Description:  Linux kernel
     Created:      2026-02-24  14:10:09 UTC
     Type:         Kernel Image (no loading done)
     Compression:  gzip compressed
     Data Start:   0x402000b8
     Data Size:    12227440 Bytes = 11.7 MiB
     Hash algo:    sha256
     Hash value:   7ea661fdecdd1127edd419cfbf8bff52e2d5ac55c...
   Verifying Hash Integrity ... sha256+ OK
   Using 'qemu-arm' configuration
   Verifying Hash Integrity ... OK
   Trying 'ramdisk' ramdisk subimage
     Description:  Initial ramdisk
     Created:      2026-02-24  14:10:09 UTC
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x40da9528
     Data Size:    1067114 Bytes = 1 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   2a711dcb5f58615187645ccec615c67eddcfbb3138...
   Verifying Hash Integrity ... sha256+ OK
   Booting using the fdt blob at 0x40000000
Working FDT set to 40000000
   Uncompressing Kernel Image (no loading done) to 13a400000
   Loading Ramdisk to 400fb000, end 401ff86a ... OK
device tree - allocation error
FDT creation failed!
resetting ...
Bloblist at 0 not found (err=-2)
alloc space exhausted ptr 400 limit 0
Bloblist at 0 not found (err=-2)
[reset]

After:
+ bootm 0x40200000#qemu-arm 0x40200000#qemu-arm 0x40000000
   Using 'qemu-arm' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel' kernel subimage
     Description:  Linux kernel
     Created:      2026-02-24  14:10:09 UTC
     Type:         Kernel Image (no loading done)
     Compression:  gzip compressed
     Data Start:   0x402000b8
     Data Size:    12227440 Bytes = 11.7 MiB
     Hash algo:    sha256
     Hash value:   7ea661fdecdd1127edd419cfbf8bff52e2d5ac55ce...
   Verifying Hash Integrity ... sha256+ OK
   Using 'qemu-arm' configuration
   Verifying Hash Integrity ... OK
   Trying 'ramdisk' ramdisk subimage
     Description:  Initial ramdisk
     Created:      2026-02-24  14:10:09 UTC
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x40da9528
     Data Size:    1067114 Bytes = 1 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   2a711dcb5f58615187645ccec615c67eddcfbb3138...
   Verifying Hash Integrity ... sha256+ OK
   Booting using the fdt blob at 0x40000000
Working FDT set to 40000000
   Uncompressing Kernel Image (no loading done) to 13a400000
   Loading Ramdisk to 13a2fb000, end 13a3ff86a ... OK
   Loading Device Tree to 000000013a1f8000, end 000000013a2fafff ... OK
Working FDT set to 13a1f8000

Starting kernel ...

Signed-off-by: Ludwig Nussel 
Reviewed-by: Tom Rini

lmb: replace the lmb_alloc() and lmb_alloc_base() API's

2025-06-25T15:50:37+00:00

There currently are two API's for requesting memory from the LMB
module, lmb_alloc() and lmb_alloc_base(). The function which does the
actual allocation is the same. Use the earlier introduced API
lmb_alloc_mem() for both types of allocation requests.

Signed-off-by: Sughosh Ganu 
Acked-by: Ilias Apalodimas

lmb: replace lmb_reserve() and lmb_alloc_addr() API's

2025-06-25T15:50:37+00:00

There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.

Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.

There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.

Signed-off-by: Sughosh Ganu 
Acked-by: Ilias Apalodimas

bootm: Fix bmi->images pointer not initialized in some cases

2025-05-30T19:43:37+00:00

When building with only bootz command, without bootm, images pointer
inside bootm_info structure is not initialized. And since this structure
is stored in stack, the generated error is kind of random, but most of
the time this will generate: "ramdisk - allocation error".

Also, after analysis, this problem could occur with the command booti,
if the command bootm is disabled.

Currently bootm_init() is called by: do_bootz(), do_bootm(), do_booti()
and by do_stm32prog(). And all of these commands execute bootm_run_states()
which access the images pointer stored into bootm_info structure.

So, to fix this issue, just do the assignment unconditionally.

Fixes: c2211ff65136 ("bootm: Add more fields to bootm_info")
Signed-off-by: Benjamin ROBIN 
Reviewed-by: Tom Rini

bootm: improve error message when gzip decompression buffer is too small

2025-05-05T20:16:57+00:00

Currently, when decompressing a gzip-compressed image during bootm, a
generic error such as "inflate() returned -5" is shown when the buffer is
too small. However, it is not immediately clear that this is caused by
CONFIG_SYS_BOOTM_LEN being too small.

This patch improves error handling by:
- Detecting Z_BUF_ERROR (-5) returned from the inflate() call
- Suggesting the user to increase CONFIG_SYS_BOOTM_LEN when applicable
- Preserving the original return code from zunzip() instead of overwriting
  it with -1

By providing clearer hints when decompression fails due to insufficient
buffer size, this change helps users diagnose and fix boot failures more
easily.

Signed-off-by: Aristo Chen 
Reviewed-by: Tom Rini 
Reviewed-by: Mattijs Korpershoek

bootm: Support load images when os is elf

2025-04-11T02:55:53+00:00

This extends the bootm command to allow find images when os type is elf.

Signed-off-by: Niu Zhihong