summaryrefslogtreecommitdiff
path: root/boot
AgeCommit message (Collapse)Author
2 daysboot: image-fit.c: check target, not source, for 8-byte alignment when ↵Rasmus Villemoes
loading FDT A number of our boards no longer boot with v2026.04, ironically as a result of the effort to ensure 8-byte alignment of the dtb passed to the kernel and getting rid of the fdt_high=0xffffffff. The problem exists when the FIT image does specify a (properly aligned) load address to use for the fdt. For example, we have fdt-am335x-boneblack.dtb { description = "Flattened Device Tree blob"; data = /incbin/(...); ... load = <0x88000000>; } Now, with v2026.04 and depending on just exactly where that data ends up, in a good case we see Loading fdt from 0x8a8c6e10 to 0x88000000 Booting using the fdt blob at 0x88000000 Working FDT set to 88000000 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Using Device Tree in place at 88000000, end 8801af2f Working FDT set to 88000000 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 and the board boots (though with that ominous warning). However, modifying the .its file a little, e.g. just removing the word "blob" from the description, we end up with Loading fdt from 0x8a8c6e14 to 0x88000000 Booting using the fdt blob at 0x9df94718 Working FDT set to 9df94718 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Failed to reserve memory for fdt at 0x9df94718 FDT creation failed! resetting ... Notice how the "Loading fdt from" line still claims to load the fdt to that 0x88000000 address, but since this "else if" clause looks at the source address (buf) and comes before the "else if (load != data)" clause, we end up doing the "allocate another buffer to use as target" instead of actually copying to 0x88000000, but then the "fdt_high=~0" logic in boot_relocate_fdt() obviously fails to do an lmb-reservation of that area, and the boot fails. When there's no load= property in the fdt node, this should not change anything. But when there is, it is the alignment of that target which is relevant, not the alignment of the fdt blob within the FIT image. With this patch applied, we instead get the expected Loading fdt from 0x8a8c6e14 to 0x88000000 Booting using the fdt blob at 0x88000000 Working FDT set to 88000000 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Using Device Tree in place at 88000000, end 8801af2f Working FDT set to 88000000 Starting kernel ... Signed-off-by: Rasmus Villemoes <ravi@prevas.dk> Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address") Reviewed-by: Simon Glass <sjg@chromium.org>
10 daysefi_loader: centralize messaging for efi_init_obj_listHeinrich Schuchardt
If efi_init_obj_list() fails we cannot use the UEFI sub-system. * Instead of having messages for this everywhere write an error message in efi_init_obj_list(). * Always use (ret != EFI_SUCCESS) when checking the return value of efi_init_obj_list(). * Remove the return code from the error message as it does not help users to understand which initialization went wrong. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
14 daysMerge patch series "net: migrate NO_NET out of the networking stack choice"Tom Rini
Quentin Schulz <foss+uboot@0leil.net> says: This migrates the net options away from the main Kconfig to net/Kconfig, rename the current NET option to NET_LEGACY to really highlight what it is and hopefully encourage more people to use lwIP, add a new NET menuconfig (but keep NO_NET as an alias to NET=n for now) which then allows us to replace all the "if legacy_stack || lwip_stack" checks with "if net_support" which is easier to read and maintain. The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed for now even when no network is configured? Likely due to include/net-common.h with PKTBUFSRX? No change in behavior is intended. Only change in defconfig including other defconfigs where NO_NET=y or NET is not set, in which case NO_NET is not set or NET=y should be set in the top defconfig. Similar change required for config fragments. See commit log in patch adding NET menuconfig for details. This was tested based on 70fd0c3bb7c2 ("x86: there is no CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up similarly as in "build all platforms in a single job" GitLab CI job. #!/usr/bin/env bash set -o pipefail set -eux ARGS="-BvelPEWM --reproducible-builds --step 0" ./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $* ./tools/buildman/buildman -o ${O} $ARGS -Ssd $* O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt I can't really decipher the log.txt, but there's no line starting with + which would be an error according to tools/buildman/builder.py help text. Additionally, because I started the script with set -e set and because buildman has an exit code != 0 when it fails to build a board, and I have the summary printed (which is the second buildman call), I believe it means all builds passed. The summary is the following: aarch64: (for 537/537 boards) all +0.0 rodata +0.0 uniphier_v8 : all +1 rodata +1 u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1) function old new delta data_gz 10640 10641 +1 arm: (for 733/733 boards) all -0.0 rodata -0.0 uniphier_v7 : all -1 rodata -1 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1) function old new delta data_gz 11919 11918 -1 opos6uldev : all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 18778 18775 -3 uniphier_ld4_sld8: all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 11276 11273 -3 stemmy : all -20 rodata -20 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20) function old new delta data_gz 15783 15763 -20 As far as I could tell this data_gz is an automatically generated array when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored in binary form. Because I'm changing the name of symbols, replacing a menu with a menuconfig, additional text makes it to .config and the "# Networking" section in .config disappears. Here is the diff for the 5 defconfigs listed above, generated with: for f in build/*-m; do diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config done (-m is the build directory for master, and without the suffix, it's the top commit of this series) """ --- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200 +++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200 @@ -970,4 +969,0 @@ - -# -# Networking -# @@ -975,0 +972 @@ +CONFIG_NET_LEGACY=y --- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200 +++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200 @@ -733,4 +732,0 @@ - -# -# Networking -# @@ -738,2 +733,0 @@ -# CONFIG_NET is not set -# CONFIG_NET_LWIP is not set --- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200 +++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200 @@ -997,4 +996,0 @@ - -# -# Networking -# @@ -1002,0 +999 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200 +++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200 @@ -1004,4 +1003,0 @@ - -# -# Networking -# @@ -1009,0 +1006 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200 +++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200 @@ -875,4 +874,0 @@ - -# -# Networking -# @@ -880,0 +877 @@ +CONFIG_NET_LEGACY=y """ This is fine: - Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't be in .config anymore. - opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have (old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but CONFIG_NET_LEGACY also needs to be defined now to reflect the stack choice (even if default), - stemmy has CONFIG_NO_NET set, which means CONFIG_NET and CONFIG_NET_LWIP are not reachable anymore hence why they don't need to be part of .config, GitLab CI was run on this series (well, not exactly, but it's only changes to the git logs that were made): https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849 It passes. Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de
14 daysboot: remove NO_NET useQuentin Schulz
NO_NET is now a transitional symbol which may eventually be removed. Its meaning is the opposite of the new meaning of NET (that is, any networking stack). Update the symbol dependency by using NET instead of !NO_NET. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-04-21boot/fit: fix misleading commentJulien Stephan
When load address is specified but set to 0, we ignore it and load in place instead. The current comment is misleading, so update it. Signed-off-by: Julien Stephan <jstephan@baylibre.com>
2026-04-17bootstd: efi: Handle prior-stage FDT in network pathSimon Glass
When CONFIG_OF_HAS_PRIOR_STAGE is enabled and fdtfile is not set, efi_get_distro_fdt_name() returns -EALREADY to indicate the prior-stage FDT should be used. The block-device EFI path handles this by setting BOOTFLOWF_USE_PRIOR_FDT, but the network path treats it as an error, causing the bootflow to stay in 'base' state with a -EALREADY error. This also means fdt_addr_r is required even when no FDT download is needed, giving a spurious -EINVAL error. Fix this by calling efi_get_distro_fdt_name() before checking fdt_addr_r, and handling -EALREADY by setting BOOTFLOWF_USE_PRIOR_FDT to skip the FDT download, matching the block-device behaviour. THere is no test for this at present, since sandbox does not enable CONFIG_OF_HAS_PRIOR_STAGE and lacks infra for network-based EFI boot. Signed-off-by: Simon Glass <sjg@chromium.org>
2026-04-07lmb: boot: Update dependencies within BOOT_DEFAULTS_CMDSTom Rini
The CMD_BOOT[IZ] symbols have a dependency on LMB, correctly, currently. Make sure that in BOOT_DEFAULTS_CMDS we only select these commands if LMB is enabled. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-04-06Merge branch 'next'Tom Rini
2026-04-03boot: Add DM_RTC as a dependency to CEDITTom Rini
The CEDIT functionality, due to the cmos functions, depends directly on DM_RTC being enabled in order to provide that API. Express this in Kconfig as well. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-04-03lmb: Correct dependency around CMD_BOOT[IMZ]Tom Rini
The calls around lmb functions for these commands are not specific to SYS_BOOT_RAMDISK_HIGH but rather part of the general loading portion of the command itself currently. Move this dependency to the right spot. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-04-03global: Audit Kconfig usage of PARTITION_TYPE_GUIDTom Rini
It is not functionally possible to use the code enabled by PARTITION_TYPE_GUID without having EFI_PARTITION be enabled as well. Not all users of the former had ensured that the latter was enabled however, so audit all current users and then as appropriate select or imply EFI_PARTITION as needed. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-03-30boot: Update dependencies for some UPL optionsTom Rini
As exposed by "make randconfig", we have an issue around SPL_UPL. This depends on SPL_LIBGENERIC_SUPPORT indirectly. In turn, SPL_UPL_OUT needs to next depend on SPL_UPL. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-03-30boot: Update tests around network symbols in BOOT_DEFAULTS_CMDSTom Rini
As exposed by "make randconfig", we have an issues around a number of symbols in BOOT_DEFAULTS_CMDS. Due to the nature of how we currently handle other networking related command options, we need to be testing for "!NO_NET" (which is the symbol for no networking stack) or "NET || NET_LWIP" rather than CMD_NET alone. For consistency and clarity here use "CMD_NET && !NO_NET" here. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-03-30xPL FIT: Rework SPL_FIT dependenciesTom Rini
As exposed by "make randconfig", we have xPL_FIT select'ing xPL_OF_CONTROL, and that in turn requires xPL_LIBGENERIC_SUPPORT. The most reasonable solution here is to have xPL_FIT select xPL_LIBGENERIC_SUPPORT. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-03-30FIT: Image pre-load signature support must select not depends on FIT_SIGNATURETom Rini
The options to enable pre-load signature support (full U-Boot or in SPL) must depend on FIT_SIGNATURE being enabled, and not select it. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-03-27Remove confusing NULL from error messageLudwig Nussel
If no signature could be verified and the loop terminates, the iterator 'noffset' has no meaningful value so name yields NULL. Signed-off-by: Ludwig Nussel <ludwig.nussel@siemens.com>
2026-03-27Add back debug output of hashed nodesLudwig Nussel
Commit 2092322b31cc ("boot: Add fit_config_get_hash_list() to build signed node list") removed printing the list of hashed nodes during verification. Add it back to have a chance to compare the list when debugging. Signed-off-by: Ludwig Nussel <ludwig.nussel@siemens.com>
2026-03-27treewide: fix uImage.FIT document pathsDaniel Golle
Commit 488445cefa1 ("doc: Move FIT into its own directory") moved the documentation in doc/uImage.FIT to doc/usage/fit, subsequently all documents and example sources have been converted to reStructuredText. Fix (almost) all of the remaining occurrences of the old path and filenames across the tree. The exception is doc/uImage.FIT/command_syntax_extensions.txt which apparently has been removed entirely, or at least I was unable to locate where that document is now. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2026-03-18Merge patch series "bootm: Clean up arch-specific, pre-OS clean-up"Tom Rini
Simon Glass <sjg@chromium.org> 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
2026-03-18bootm: Stash bootstage data in bootm_final()Simon Glass
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 <simon.glass@canonical.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-03-18riscv: Call bootm_final()Simon Glass
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 <simon.glass@canonical.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-03-18bootm: Create bootm_final() for pre-boot cleanupSimon Glass
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 <simon.glass@canonical.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-03-18Merge patch series "led: remove legacy API"Tom Rini
Quentin Schulz <quentin.schulz@cherry.de> 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
2026-03-18led: remove legacy APIQuentin Schulz
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 <quentin.schulz@cherry.de>
2026-03-18image-fit: Fix mismatched parameter type in commentKunihiko Hayashi
The functions use 'ulong', however, the comments said 'uint32_t'. Update the comments to match the prototype. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
2026-03-13Merge tag 'net-20260312' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-net into next Pull request net-20260312. net: - Move network PHY under NETDEVICES - s/DM_CLK/CLK/ in HIFEMAC_{ETH,MDIO} - Add support for Airoha AN8811HB PHY - airoha: PCS and MDIO support for Airoha AN7581 SoC net-lwip: - Fix issue when TFTP blocksize is >8192 - Adjust PBUF_POOL_SIZE/IP_REASS_MAX_PBUFS for better performance and resource usage. - Enable mii command for NET_LWIP
2026-03-12boot: availability of command mii for NET_LWIPHeinrich Schuchardt
If we are using the legacy or the LWIP network stack, should not influence our decision to provide command `mii`. Let BOOT_DEFAULTS_CMDS imply MII if either of the network stacks is available. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2026-03-10boot: don't select non-existent CONFIG_VPL_CRYPTOHeinrich Schuchardt
Symbol CONFIG_VPL_CRYPTO does not exist. Don't select it. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Fixes: 4218456b3fac ("vbe: Add Kconfig options for VPL") Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
2026-03-09Merge tag 'v2026.04-rc4' into nextTom Rini
Prepare v2026.04-rc4
2026-03-09boot: Add fit_config_get_hash_list() to build signed node listSimon Glass
The hashed-nodes property in a FIT signature node lists which FDT paths are included in the signature hash. It is intended as a hint so should not be used for verification. Add a function to build the node list from scratch by iterating the configuration's image references. Skip properties known not to be image references. For each image, collect the path plus all hash and cipher subnodes. Use the new function in fit_config_check_sig() instead of reading 'hashed-nodes'. Update the test_vboot kernel@ test case: fit_check_sign now catches the attack at signature-verification time (the @-suffixed node is hashed instead of the real one, causing a mismatch) rather than at fit_check_format() time. Update the docs to cover this. The FIT spec can be updated separately. Signed-off-by: Simon Glass <simon.glass@canonical.com> Closes: https://lore.kernel.org/u-boot/20260302220937.3682128-1-trini@konsulko.com/ Reported-by: Apple Security Engineering and Architecture (SEAR) Tested-by: Tom Rini <trini@konsulko.com>
2026-03-06bootm: fix booting kernel_noload imageLudwig Nussel
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 <ludwig.nussel@siemens.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-02-24boot: fit: validate FDT/DTO payload before fdt_open_into()James Hilliard
boot_get_fdt_fit_into_buffer() calls fdt_open_into() for both the base FDT and overlay DTO blobs loaded from a FIT image. Those blobs come from FIT payload data. In the overlay path, fit_image_load() is called with FIT_LOAD_IGNORED, so the IH_TYPE_FLATDT header check in fit_image_load() is skipped. This leaves fdt_open_into() to consume header-derived offsets/sizes from unvalidated input. Validate the full blob against the payload length first with fdt_check_full(fdtsrcbuf, srclen), then proceed with fdt_totalsize() and fdt_open_into(). This fixes Coverity CID 644638 (TAINTED_SCALAR). Fixes: 5ebf0c55a23 ("image: fit: Apply overlays using aligned writable FDT copies") Link: https://lore.kernel.org/all/20260223195109.GG3233182@bill-the-cat/ Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-02-23Merge tag 'v2026.04-rc3' into nextTom Rini
Prepare v2026.04-rc3
2026-02-17treewide: Clean up DECLARE_GLOBAL_DATA_PTR usagePeng Fan
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 <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards Acked-by: Yao Zi <me@ziyao.cc> #TH1520 Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-16bootstd: rauc: Fix null pointer access while checking root partMartin Schwan
Fix a segmentation fault caused by a null pointer access during root partition checking. The function part_get_info() was falsely given null for the disk_partition struct, which later resulted in accessing a null pointer and thus undefined behavior. Fixes: 5d7c080ae5dc ("bootstd: rauc: Don't check root part filesystem") Signed-off-by: Martin Schwan <m.schwan@phytec.de>
2026-02-16cmd: pxe_utils: fix syntax error in commentsHugo Villeneuve
Add missing "to" so that the sentence makes sense. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
2026-02-16image: fit: Apply overlays using aligned writable FDT copiesJames Hilliard
libfdt expects FDT/DTO blobs to be 8-byte aligned. When loading the base FDT or overlays from a FIT, the mapped buffer may be unaligned, which can break fdt_open_into() on strict-alignment architectures. boot_get_fdt_fit() relocates the base FDT with boot_relocate_fdt() before applying overlays. That uses the bootm memory map and can overlap with the FIT buffer when the FIT is loaded into RAM, corrupting data needed to load the kernel and ramdisk. Allocate writable, 8-byte aligned copies of the base FDT and overlays with memalign() and fdt_open_into(). Grow the base buffer as needed, apply overlays to it and pack the final tree. Free each temporary overlay copy after application and check fdt_pack() errors. Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always 8-byte aligned") Fixes: 881f0b77dc8c ("image: apply FDTOs on FDT image node") Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Cc: Jamie Gibbons <Jamie.Gibbons@microchip.com> Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
2026-01-30boot/fit: print error name in boot_get_fdt_fit()David Lechner
Print the actual error code in a couple of places in boot_get_fdt_fit(). These are FDT error codes, not errno, so printing the string is more helpful than printing the numeric value. The only caller of boot_get_fdt_fit() unconditionally replaces the returned error code (fdt_noffset) with ENOENT so the actual error would otherwise be lost. Signed-off-by: David Lechner <dlechner@baylibre.com>
2026-01-27boot/fit: print name of config node not foundFrank Wunderlich
Show name of configuration node which was not found. current state gives no hint if fit image is wrong or the requested name. Could not find configuration node load of <NULL> failed After this patch we see name like this: Could not find configuration node '#ov-test' load of <NULL> failed Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
2026-01-27fit: Rework SPL_LOAD_FIT_ADDRESS slightlyTom Rini
Options which deal with memory locations and have a default value of 0x0 are dangerous, as that is often not a valid memory location. Rework SPL_LOAD_FIT_ADDRESS as follows: - Add SPL_HAS_LOAD_FIT_ADDRESS to guard prompting the question as the case of loading a FIT image does not strictly require setting an address and allows for a malloc()'d area to be used. - For SPL_RAM_SUPPORT, select the new guard symbol if SPL_LOAD_FIT is enabled because in that case an address must be provided. - Update defconfigs for these new changes. Largely this means some defconfigs need to enable SPL_HAS_LOAD_FIT_ADDRESS to maintain their current status. In the case of sandbox, we also need to set SPL_LOAD_FIT_ADDRESS to 0x0. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-01-19bootm: fix boot failure from compressed image for IH_OS_EFIMasahisa Kojima
The bootm command can handle the compressed image, but current code fails to boot from it. ## Loading kernel (any) from FIT Image at a8000000 ... <snip> Compression: gzip compressed Data Start: 0xa80000d4 Data Size: 10114520 Bytes = 9.6 MiB Architecture: AArch64 OS: EFI Firmware Load Address: 0x90000000 <snip> Uncompressing Kernel Image to 90000000 ## Transferring control to EFI (at address a80000d4) ... Booting <NULL> Not a PE-COFF file Loading image failed To take care of the compressed image, the load address needs to be passed instead of the original compressed image address. Signed-off-by: Masahisa Kojima <kojima.masahisa@socionext.com> Tested-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
2026-01-16Merge tag 'u-boot-dfu-20260116' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-dfu u-boot-dfu-20260116 CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/29018 Android: * Fix missing dependency for BOOTMETH_ANDROID * Add bootconfig support * Add 'get ramdisk' command to abootimg DFU: * Improve error handling in dfu_fill_entity() USB Gadget: * ci_udc: Ensure ci_ep->desc is valid before using it * ci_udc: Add additional debug prints
2026-01-16bootstd: rauc: Free memory during error handlingFrancois Berder
While reading bootflow, memory was not released if an error occurred. Signed-off-by: Francois Berder <fberder@outlook.fr> Acked-by: Martin Schwan <m.schwan@phytec.de> Tested-by: Martin Schwan <m.schwan@phytec.de>
2026-01-15boot: android: Add bootconfig supportGuillaume La Roque (TI.com)
For android vendor boot image version 4 bootconfig is mandatory.[1] In the android_image_get_ramdisk function, after copying both vendor and boot ramdisks, we extract all androidboot.* entries from the kernel command line. These entries are added to the bootconfig section. We then update the sizes of the ramdisk and bootconfig. Finally, all androidboot.* entries are removed from the kernel command line. [1] https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions#bootloader-support Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com> Link: https://lore.kernel.org/r/20260112-bootconfig-v5-3-79b242159ac7@baylibre.com [mkorpershoek: dropped irrelevant code comments] Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
2026-01-15boot: android: Add sandbox memory mapping supportGuillaume La Roque (TI.com)
Use map_to_sysmem() to convert header pointers to physical addresses in parse_hdr functions, and add proper map_sysmem()/unmap_sysmem() calls in android_image_get_data() for sandbox compatibility. Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com> Link: https://lore.kernel.org/r/20260112-bootconfig-v5-2-79b242159ac7@baylibre.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
2026-01-15boot: android: import addBootConfigParameters() from AOSPMattijs Korpershoek (TI.com)
To properly implement Android boot image v4, U-Boot must be able to add additional entries to the bootconfig. Add `add_bootconfig_parameters()` to do so. This has been imported from Google's U-Boot source[1] The variables/function names have been reworked to be compliant with U-Boot's coding style. [1] https://android.googlesource.com/platform/external/u-boot/+/7af0a0506d4de6f5ea147d10fb0664a8af07d326 Signed-off-by: Mattijs Korpershoek (TI.com) <mkorpershoek@kernel.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com> Link: https://lore.kernel.org/r/20260112-bootconfig-v5-1-79b242159ac7@baylibre.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
2026-01-15bootstd: android: Add missing free in android_read_bootflowFrancois Berder
If strdup call fails, one needs to free priv variable. Signed-off-by: Francois Berder <fberder@outlook.fr> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Tom Rini <trini@konsulko.com> Link: https://lore.kernel.org/r/BESP194MB28052734FD0361EA602F6360DA8FA@BESP194MB2805.EURP194.PROD.OUTLOOK.COM Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
2026-01-09boot: fix missing dependency for BOOTMETH_ANDROIDQuentin Schulz
The code depends on set_avendor_bootimg_addr and set_abootimg_addr functions which are only defined in cmd/abootimg.c, only built when CMD_ABOOTIMG=y so let's add a dependency. It should be "depends on" to be properly implemented, but we get a circular dependency otherwise: boot/Kconfig:566:error: recursive dependency detected! boot/Kconfig:566: symbol BOOTMETH_ANDROID depends on CMD_ABOOTIMG cmd/Kconfig:504: symbol CMD_ABOOTIMG depends on ANDROID_BOOT_IMAGE boot/Kconfig:7: symbol ANDROID_BOOT_IMAGE is selected by BOOTMETH_ANDROID so instead we do a select. It is safe because CMD_ABOOTIMG depends on ANDROID_BOOT_IMAGE which we select here as well. Fixes: 125d9f3306ea ("bootstd: Add a bootmeth for Android") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Link: https://lore.kernel.org/r/20251218-bootmeth_android-deps-v1-1-0113c804f951@cherry.de Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
2025-12-31Merge patch series "configs: Remove default malloc length for K3 R5 SPL"Tom Rini
This series from Andrew Davis <afd@ti.com> makes a number of the TI K3 CONFIG symbols have consistent values in SPL, as they are things determined by the SoC and not the board design. Link: https://lore.kernel.org/r/20251208190635.2044082-1-afd@ti.com
2025-12-31spl: Kconfig: k3: Set common default for SPL_LOAD_FIT(_ADDRESS)Andrew Davis
These are common for all K3 based boards. Add the common values as defaults and remove from each board defconfig Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com>
generated by cgit v1.2.3 (git 2.0.4) at 2026-05-11 06:15:44 +0000