| Age | Commit message (Collapse) | Author |
|---|
|
The prompt is missing the indication this applies for the SPL loading
a FIT image, and not any other stage.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: [email protected]
Reviewed-by: Udit Kumar <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
Reviewed-by: Kory Maincent <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-amlogic into next
- Add u-boot SPL support for GX SoCs
- meson_gx_mmc: reduce maximum frequency
- Add support for EFI capsule updates on all Amlogic boards
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
This pull request brings together a set of fixes and enhancements across
the SoCFPGA platform family, with a focus on MMC/SPL robustness, EFI
boot enablement, and Agilex5 SD/eMMC support.
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/28776
Highlights:
*
SPL / MMC:
o
Fix Kconfig handling for
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
o
Correct raw sector calculations and respect explicit sector values
when loading U-Boot from MMC in SPL
o
Adjust raw MMC loading logic for SoCFPGA platforms
*
EFI boot:
o
Permit EFI booting on SoCFPGA platforms
o
Disable mkeficapsule tool build for Arria 10 where unsupported
*
Agilex5:
o
Upgrade SDHCI controller from SD4HC to SD6HC
o
Enable MMC and Cadence SDHCI support in defconfig
o
Add dedicated eMMC device tree and defconfig for Agilex5 SoCDK
o
Revert incorrect GPIO configuration for SDIO_SEL
o
Refine U-Boot DT handling for SD and eMMC boot variants
*
SPI:
o
Allow disabling the DesignWare SPI driver in SPL via Kconfig
*
Board / configuration fixes:
o
Enable random MAC address generation for Cyclone V
o
Fix DE0-Nano-SoC boot configuration
o
Remove obsolete or conflicting options from multiple legacy
SoCFPGA defconfigs
|
|
constants"
Quentin Schulz <[email protected]> says:
This does a bit of "cleanup" by reusing constants for some FIT
properties instead of having the same string in multiple places.
Additionally, this adds a new constant for the compatible property in
FIT configuration nodes[1] which is useful for FIT images with multiple
FIT configuration nodes to support multiple devices in the same blob.
U-Boot will try to figure out which node to select based on that
compatible[2].
However, if this property is missing (and the first blob in the fdt
property of the configuration node is uncompressed), the compatible from
the root node of the associated kernel FDT will be used for the
autoselection mechanism. For now, I only print the property if it
exists, but maybe it'd make sense to expose the fallback one if it's
missing. I guess we can implement that later on if desired.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
Link: https://lore.kernel.org/r/[email protected]
|
|
Fit conf node may have a compatible property[1] which stores the
compatible of the first blob in the fdt property of the node. This can
be used to automatically select the proper conf node based on the
compatible from the running U-Boot (matching the former's compatible
with the latter)[2].
This brings the ability to mkimage/dumpimage to print the compatibles of
the configuration node(s). U-Boot CLI commands such as iminfo also see
this addition to their output.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Fit conf node may have a compatible property[1] which stores the root
compatible of the first blob in the fdt property of the node. This can
be used to automatically select the proper conf node based on the
compatible from the running U-Boot (matching the former's compatible
with the latter)[2].
This adds (and uses) this constant for FIT node parsing.
Note that this property may also appear in fpga image nodes[3] but that
isn't done in this commit.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
[3] https://fitspec.osfw.foundation/#images-node 2.3.2 Conditionally mandatory property
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Some properties have their string represented in include/image.h via
constants, so let's use those constants instead of using a hardcoded
string.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The BootROM in Rockchip SoCs will enter maskrom mode when boot firmware
cannot be found in nand/spi/mmc storage.
In maskrom mode the USB OTG port can accept one of two custom commands.
Initially a 0x471 command to load TPL into SRAM. After TPL has been
executed and it has returned back-to-BROM, a 0x472 command to load SPL
into start of DRAM.
Add two binman images that can be used to RAM boot from maskrom mode:
- u-boot-rockchip-usb471.bin that contains TPL to init DRAM.
- u-boot-rockchip-usb472.bin that contains SPL and the normal FIT
payload with i.e. U-Boot proper, TF-A and FDT.
A config fragment rockchip-ramboot.config can be used to enable building
of these two binman images, e.g.:
make generic-rk3588_defconfig rockchip-ramboot.config
These binman images can be used with the proprietary rkbin boot_merger
tool to create a special loader image that can be used with tools such
as rkdeveloptool or rockusb tools to RAM boot from maskrom, e.g.:
Create loader image:
$ ../rkbin/tools/boot_merger ./RK3588MINIALL.ini
Boot from maskrom:
$ rkdeveloptool db u-boot-rockchip-rk3588-loader.bin
or
$ rockusb download-boot u-boot-rockchip-rk3588-loader.bin
Another option that does not require use of proprietary tools is using
open source tools such as rkflashtool or rkusbboot that can load the
binman images directly without any need to first create a special loader
image to RAM boot from maskrom, e.g.:
$ rkflashtool l < u-boot-rockchip-usb471.bin
$ rkflashtool L < u-boot-rockchip-usb472.bin
or
$ rkusbboot u-boot-rockchip-usb471.bin u-boot-rockchip-usb472.bin
Signed-off-by: Jonas Karlman <[email protected]>
Tested-by: Arnaud Patard <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu into next
u-boot-dfu-next-20251211:
CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/28724
Android:
* Fix 8-byte alignment for newer versions of libfdt
|
|
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 <[email protected]>
Signed-off-by: Jonas Karlman <[email protected]>
[Ferass: check digest type in _print_header, version in _verify_image]
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Prepare v2026.01-rc4
|
|
If noffset is negative, do not pass it to fit_get_name() and then further to
libfdt, this will crash sandbox with SIGSEGV because libfdt can not handle
negative node offsets without full tree check, which U-Boot inhibits to keep
size lower.
Instead, always check noffset before use, and if the return value indicates
failure, exit right away.
Signed-off-by: Marek Vasut <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
Newer versions of libfdt strictly check whether the FDT blob
passed to them is at 8-byte aligned offset, if it is not, then
the library fails checks with -FDT_ERR_ALIGNMENT . Currently,
android_image_print_dtb_contents() passed FDT directly mapped
from abootimg to libfdt, and this FDT is not always aligned to
8-byte offset. Specifically, the FDTs are somewhat packed in
the abootimg, therefore if the first FDT blob is e.g. 0xfd bytes
long, then the next FDT blob ends up at 0xfd offset, which is
not 8-byte aligned.
Fix this by first extracting the header into 8-byte aligned buffer,
checking only the header for validity, and then by copying the
entire FDT into newly allocated 8-byte aligned buffer. While this
is not efficient, it is the correct way to handle DTs, which must
be at 8-byte aligned offsets. Mitigate the inefficiency for the
common case by checking whether the DT might be 8-byte aligned and
if it is, map it directly.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
With the changes in commit 8fbcc0e0e839 ("boot: Assure FDT is always at
8-byte aligned address") to call memalign(...) we now always call
memalign(...) rather than malloc(...) when allocating a buffer that may
contain a device tree. However, memalign(...) is not portable among all
of the host OSes we support. The C11 standard does require that
aligned_alloc(...) exist and it takes the same parameters as
memalign(...) does. Change this file to call aligned_alloc rather than
memalign, and for the non-USE_HOSTCC case define that function back to
memalign.
Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address")
Suggested-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Heiko Schocher <[email protected]> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Implement sm3 hash, so we can fix this problem.
Link: https://lore.kernel.org/r/[email protected]
|
|
add the U-Boot specific parts for the SM3 hash
implementation:
Signed-off-by: Heiko Schocher <[email protected]>
|
|
The Linux kernel can discover SMBIOS tables through two primary methods:
1. Via EFI tables, when using EFI boot;
2. Via the 'smbios3-entrypoint' property in the /chosen node of the
device tree.
When U-Boot boots a Linux kernel using a non-EFI command ("bootm",
"bootz", or "booti"), the kernel relies on the device tree to detect
the hardware. If SMBIOS tables are available in U-Boot, they should
be passed to the kernel via this device tree property.
This patch modifies boot_fdt_prepare(), to inject the SMBIOSv3 table
address into the device tree if there is a table generated by U-boot.
The "board_fdt_chosen_smbios" is weak in order to leave the possibilty
for specific boards to select custom SMBIOS addresses.
The changes in this patch are added in the context of supporting this
device tree property in linux kernel:
https://lkml.org/lkml/2025/10/24/1393
Device tree schema was updated to include the "smbios3-entrypoint" node
in pull request: https://github.com/devicetree-org/dt-schema/pull/177
Signed-off-by: Adriana Nicolae <[email protected]>
|
|
The fitImage may contain FDT at 4-byte aligned address, because alignment
of DT tags is 4 bytes. However, libfdt and also Linux expects DT to be at
8-byte aligned address. Make sure that the DTs embedded in fitImages are
always used from 8-byte aligned addresses. In case the DT is decompressed,
make sure the target buffer is 8-byte aligned. In case the DT is only
loaded, make sure the target buffer is 8-byte aligned too.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Partitions can be become unusable due to power cuts or failed updates.
Use the bootmeth RAUC if partitions for at least one slot exist. The
bootmeth can then select the working slot.
Signed-off-by: Leonard Anderweit <[email protected]>
Tested-by: Martin Schwan <[email protected]>
|
|
Only check if the root partition exists when scanning for the slots
partitions and not if the filesystem can be accessed. It is not needed
to access the filesystem of the root partition as it might not be
supported by u-boot or be encrypted.
Signed-off-by: Leonard Anderweit <[email protected]>
Tested-by: Martin Schwan <[email protected]>
|
|
Prepare v2026.01-rc3
|
|
Fix two memory allocation bugs in label_boot_extension():
1. When label->fdtdir is not set, overlay_dir was used without any
memory allocation.
2. When label->fdtdir is set, the allocation size was incorrect,
using 'len' (just the fdtdir length) instead of 'dir_len' (which
includes the trailing slash and null terminator).
Resolve both issues by moving the memory allocation and string
formatting outside the conditional block, resulting in clearer code
flow and correct sizing in all cases.
Closes: https://lists.denx.de/pipermail/u-boot/2025-November/602892.html
Addresses-Coverity-ID: 638558 Memory - illegal accesses (UNINIT)
Fixes: 935109cd9e97 ("boot: pxe_utils: Add extension board devicetree overlay support")
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
Tested-by: Surkov Kirill <[email protected]>
|
|
Size of array buf was incorrect due to sizeof returning the
size of an integer (typically 32 bits) instead of a u64 type
(64 bits). Hence, buf array was shorter than expected.
Signed-off-by: Francois Berder <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Quentin Schulz <[email protected]> says:
While historically signature verification is mostly done for FIT such
FIT_SIGNATURE dependency for signature algorithm makes sense, it isn't
the only kind of file we can verify signatures of. It can also be done
manually with rsa_verify_hash() with an embedded public key.
Considering the impacted code is guarded by RSA_VERIFY, let's make the
symbol depend on that otherwise selecting it without RSA_VERIFY won't do
anything. The FIT_SIGNATURE dependency wasn't also enough before as it
only implied RSA_VERIFY.
Then, simply relocate the RSA SSA PSS padding with the other RSA symbols
in lib/rsa instead of in boot/ and rename it to remove the mention to
FIT.
Finally, add the PSS padding wherever PKCS1.5 padding is specified as
one or the other can be used.
Link: https://lore.kernel.org/r/[email protected]
|
|
This renames FIT_RSASSA_PSS symbols to drop the FIT_ prefix to avoid
potential confusion since there's nothing FIT specific to those symbols.
It also isn't really related to booting, so boot/Kconfig is an odd place
for them to live. Since they make sense only in relation with RSA,
simply move them to lib/rsa where it makes more sense for them to
reside.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Let's not mix with symbols from other phases.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
It's defined a bit later in the same file, so let's remove the
duplicated entry.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This padding has nothing to do with FIT except that we can make use of
it when verifying the FIT signatures.
This padding can also be used to verify the signature "manually" e.g. by
calling rsa_verify_hash() directly with an embedded public key.
Additionally, this padding is only useful if RSA (and specifically
RSA_VERIFY) is enabled otherwise it's not used.
The only other place it's used is in rsa-sign.c which is only built for
the host tools and handled by TOOLS_FIT_RSASSA_PSS symbol instead, so no
need to care for that one.
Finally, the FIT_SIGNATURE dependency also wasn't enough because it only
implies RSA_VERIFY, meaning it can be disabled and still have
FIT_RSASSA_PSS enabled.
So add a dependency on RSA_VERIFY and reword the input prompt.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu
u-boot-dfu-20251107:
CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/28223
Android:
* Add bootargs environment to kernel commandline
DFU:
* Support DFU over PCIe in SPL
|
|
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
SPL_FIT_FULL_CHECK currently shares its description and help text with
FIT_FULL_CHECK which is quite confusing, so let's specify this applies
to SPL.
Fixes: 6f3c2d8aa5e6 ("image: Add an option to do a full check of the FIT")
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
When previously using script based bootflows, the U-Boot
environment variable bootargs was used to customize the kernel
commandline at boot time.
In order to get the same behaviour, concatenate the bootflow
commandline with the contents the bootargs environment variable.
Signed-off-by: Nicolas Belin (TI.com) <[email protected]>
Signed-off-by: Guillaume La Roque (TI.com) <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Anshul Dalal <[email protected]> says:
Hi all,
We currently make use of CMD_BOOTI and CMD_BOOTZ in the SPL boot flow in
falcon mode, this isn't correct since all CMD_* configs are only meant
for U-Boot proper and not the SPL.
Therefore this patch set adds new LIB_BOOT[IMZ] configs that allow for
more granular selection of their respective compilation targets.
Additionally, this also allows us to more easily disable support for
raw images from secure falcon mode (SPL_OS_BOOT_SECURE) by doing the
following:
config LIB_SPL_BOOTI
...
depends on SPL_OS_BOOT && !SPL_OS_BOOT_SECURE
...
Link: https://lore.kernel.org/r/[email protected]
|
|
Using CMD_* configs from spl doesn't make logical sense. Therefore
this patch replaces the checks for CMD_BOOTx with newly added library
symbols LIB_BOOT[IMZ] and SPL_LIB_BOOT[IMZ] which are enabled by their
respective CMD_* or SPL_* counterparts.
On platforms with non-secure falcon mode, SPL_BOOTZ is enabled by
default for 32-bit ARM systems and SPL_BOOTI is enabled by default for
64-bit ARM and RISCV.
The respective C files (image.c/zimage.c) are compiled based on library
symbols $(PHASE_)LIB_BOOTx instead which are in turn selected by both
CMD_BOOTx and SPL_BOOTx as required.
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
to boot flows"
Kory Maincent (TI.com) <[email protected]> says:
This series converts the extension board framework to use UCLASS as
requested by Simon Glass, then adds extension support to pxe_utils
and bootmeth_efi (not tested) to enable extension boards devicetree load
in the standard boot process.
I can't test the imx8 extension scan enabled by the
imx8mm-cl-iot-gate_defconfig as I don't have this board.
I also can't test the efi bootmeth change as I don't have such board.
Link: https://lore.kernel.org/r/20251030-feature_sysboot_extension_board-v5-0-cfb77672fc68@bootlin.com
|
|
Add support for scanning and applying extension board devicetree
overlays during EFI boot. After loading the main board devicetree,
the system now scans for available extension boards and applies their
overlays automatically.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Simplify the return path in distro_efi_try_bootflow_files() to prepare
for adding extension board support in a subsequent commit.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add support for scanning and applying extension board devicetree
overlays during PXE boot. After loading the main board devicetree,
the system now scans for available extension boards and applies their
overlays automatically.
This enables dynamic hardware configuration for systems with extension
boards during boot scenarios which are using pxe_utils.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The extension_overlay_cmd environment variable approach is specific to
the U-Boot extension_board command, while other boot flows (pxe_utils,
bootstd) handle overlay loading differently.
Move the extension_overlay_cmd execution out of the core extension
framework to the command level. This decouples the framework from
command-specific behavior and prepares for future extension support
in other boot flows.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Remove the legacy extension board implementation now that all boards
have been converted to use the new UCLASS-based framework. This
eliminates lines of legacy code while preserving functionality
through the modern driver model approach.
Update the bootstd tests, due to the removal of extension hunter.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
|
|
Introduce UCLASS-based extension board support to enable more
standardized and automatic loading of extension board device tree
overlays in preparation for integration with bootstd and pxe_utils.
Several #if CONFIG_IS_ENABLED are used in cmd/extension_board.c to ease the
development but don't worry they are removed later in the series.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Relocate extension board support from cmd/ to boot/ directory in
preparation for converting the extension framework to use UCLASS.
Also improve code style by applying reverse xmas tree ordering.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
|
|
Fix a typo in image-fit.c.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Wolfgang Wallner <[email protected]>
|
|
Fix typos in boot/Kconfig.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Wolfgang Wallner <[email protected]>
|
|
Add the option to load the bootscript with the tftp command (static IP)
instead of the dhcp command (dynamic IP). For this a new function
tftpb_run similar to dhcp_run, is needed. The selection of which command
to use can be done with the ip_dyn environment variable, which can be
set to yes or no. The ip_dyn variable was chosen as it is already in use
on the imx platforms.
Also edit the bootstd doc.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Benjamin Hahn <[email protected]>
|
|
At present the EFI bootmgr scans all devices in the system before
deciding which one to boot. Ideally it would use the bootstd iterator
for this, but in the meantime, give it a lower priority, so it runs
just before the network devices.
Note that if there are no hunted network devices hunted, then it will
run at the end, after all bootdevs are exhausted. In other words, it
will always run.
Signed-off-by: Simon Glass <[email protected]>
|
|
When there are no more bootdevs we should still go through the global
bootmeths, since some may not have yet been used, if their priority has
not yet come up.
Add a final check for this at the end of the iterator.
Update the documentation to match the new behaviour of global bootmeths.
Signed-off-by: Simon Glass <[email protected]>
|
|
At present before scanning global bootmeths, the iterator sets the
method count to the index of the first global bootmeth. Now that we
support scanning the global bootmeths multiple times, we must leave this
count alone.
Check against have_global and first_glob_method instead.
Signed-off-by: Simon Glass <[email protected]>
|
|
Allow bootmeths to select when they want to run, using the bootdev
priority. Provide a new bootmeth_glob_allowed() function which checks if
a bootmeth is ready to use.
Fix a comment in bootflow_system() which is a test for global bootmeths.
Signed-off-by: Simon Glass <[email protected]>
|
|
Use the methods_done flags to make sure that each global bootmeth is
only used once. For now this has no effect, since they are all processed
at the start.
Signed-off-by: Simon Glass <[email protected]>
|
