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

Merge patch series "led: remove legacy API"

2026-03-18T19:13:57+00:00

Quentin Schulz  says:

This migrates the last user of the legacy LED API, IMX233-OLinuXino and
net/bootp.c, to the modern LED framework.

I do have concern about being able to use BOOTP in SPL? In which case, I
should probably add an additional check on CONFIG_IS_ENABLED(LED) in
addition to IS_ENABLED(CONFIG_LED_BOOT)?

I haven't tested this as I do not own an IMX233-OLinuXino, so please
give this a try if you own this device.

Then, since there's no user left of this legacy API, it is entirely
removed.

Link: https://lore.kernel.org/r/20251120-legacy-led-removal-v1-0-369d44338358@cherry.de

led: remove legacy API

2026-03-18T19:07:36+00:00

No user of the legacy LED API anymore (except Sunxi with the PinePhone
but that is now a Sunxi-specific implementation), so let's remove
anything related.

Signed-off-by: Quentin Schulz

treewide: Clean up DECLARE_GLOBAL_DATA_PTR usage

2026-02-17T19:50:22+00:00

Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.

Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.

Reviewed-by: Patrice Chotard  #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal  #TI boards
Acked-by: Yao Zi  #TH1520
Signed-off-by: Peng Fan

tools: mkimage: Add Amlogic Boot Image type

2025-12-11T10:44:41+00:00

Add support for creating an Amlogic Boot Image that pass CHK in BL1 on
Amlogic AArch64 SoCs.

Images can optionally be signed for secure boot scenario, however
creation of signed images has not been implemented.

Example of how to use it:
  # Create an amlogic boot image
  tools/mkimage -T amlimage -n gxbb -d u-boot-spl.bin u-boot-amlogic.bin

  # List boot image header information
  tools/mkimage -l u-boot-amlogic.bin

  # Extract amlogic boot image payload
  tools/dumpimage -T amlimage -o bl2-payload.bin u-boot-amlogic.bin

Or with binman using something like:
  binman {
	u-boot-amlogic {
		filename = "u-boot-amlogic.bin";
		pad-byte = <0xff>;

		mkimage {
			filename = "bl2.bin";
			args = "-n", "gxbb", "-T", "amlimage";

			u-boot-spl {
			};
		};
	};
  };

Reviewed-by: Neil Armstrong 
Signed-off-by: Jonas Karlman 
[Ferass: check digest type in _print_header, version in _verify_image]
Signed-off-by: Ferass El Hafidi 
Link: https://patch.msgid.link/20251126-spl-gx-v5-1-6cbffb2451ca@postmarketos.org
Signed-off-by: Neil Armstrong

tools: stm32image: Add support for STM32 Image V2.0

2025-06-11T07:42:56+00:00

Add support for generating STM32 Image V2.0, which is used by STM32MP13xx.
The image header layout is similar to STM32MP15xx STM32 Image V1.0, but is
different enough to justify duplicate functions to generate the v2 image.
This code at least attempts to align the V1 and V2 image handling where
possible.

Signed-off-by: Marek Vasut

Revert "riscv: image: Add new image type for RV64"

2025-06-02T08:18:33+00:00

This reverts commit 14a4792a71db3561bea065415ac1f2ac69ef32b5 as
discussed in [1].

[1] https://lists.denx.de/pipermail/u-boot/2025-May/590841.html

Signed-off-by: Mayuresh Chitale 
Reviewed-by: Leo Yu-Chi Liang

riscv: image: Add new image type for RV64

2025-05-21T08:45:55+00:00

Similar to ARM and X86, introduce a new image type which allows u-boot
to distinguish between images built for 32-bit vs 64-bit Risc-V CPUs.

Signed-off-by: Mayuresh Chitale 
Reviewed-by: Maxim Moskalets

image: Add support for starting TFA BL31 as fitImage loadables

2025-02-15T13:44:43+00:00

Add support for starting TFA from U-Boot running in EL3 as part of
fitImage boot, so the user can start U-Boot in the highest privilege
level on the platform, bundle TFA, Linux, DT into a single fitImage
and boot such a bundle as a whole.

There are two main benefits of this approach. First is the ability
to run U-Boot in EL3, where it has unrestricted access to the entire
system and can act as a useful debug tool, as it was always intended
to be used. Second is the ability to easily and safely update of any
component in the fitImage, be it TFA, Linux or DT.

The boot process is similar to regular Linux with DT fitImage boot
process, except the TFA has to be bundled into the fitImage. For the
bundling instructions, see below. The TFA is started as a 'loadables'
with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling implemented in board code, and performing the handoff and
boot in case the TFA was loaded.

The loadables handler is optional and meant to set up any sort of
handoff structures used by the TFA BL31 or perform any other setup
that is needed by the blob. The custom armv8_switch_to_el2_prep()
has to implement the jump to TFA BL31 with return to U-Boot just
before booting the Linux kernel.

Example fitImage image and configuration section:

/dts-v1/;

/ {
    description = "Linux kernel with FDT blob and TFA BL31";

    images {
        kernel-1 { ... };
        fdt-1 { ... };
        atf-1 {                  /* This is the TFA BL31 image */
            description = "TFA BL31";
            data = /incbin/("../build/plat/release/bl31.bin");
            type = "tfa-bl31";
            arch = "arm64";
            os = "arm-trusted-firmware";
            compression = "none";
            load = <0x46400000>;
            entry = <0x46400000>;
        };
    };

    configurations {
        default = "conf-1";
        conf-1 {
            description = "Boot Linux";
            kernel = "kernel-1";
            fdt = "fdt-1";
            loadables = "atf-1"; /* This is the TFA BL31 loadable */
        };
    };
};

Reviewed-by: Tom Rini 
Signed-off-by: Marek Vasut

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

image: Set load_end on partial loads

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

When decompressing, it's possible that the algorithm only performs
a partial decompression.
This usually happens when CONFIG_SYS_BOOTM_LEN is too small for
the uncompressed image.

When that happens, image_decomp() returns an error and *load_end == load.
The error is then handled by handle_decomp_error().

handle_decomp_error() expects the number of uncompressed bytes in
uncomp_size but receives *load_end - load == load - load == 0.

Because of this, handle_decomp_error does not report the expected
"Image too large: increase CONFIG_SYS_BOOTM_LEN" error message.

Modify the image_decomp() logic to always report the decompressed size,
even when a partial decompression happened.

Signed-off-by: Mattijs Korpershoek