When SPL_NET is included, scripts/Makefile.xpl includes net/. However,
in this directory, the Makefile only compiles things if CONFIG_NET or
CONFIG_NET_LWIP is defined (it doesn't use $(PHASE_)). Therefore, at
least one networking stack needs to be enabled for SPL_NET=y to do
anything meaningful.
In certain cases (e.g. am62px_evm_r5_ethboot_defconfig + NO_NET=y via
menuconfig), it is possible to fail the build with undefined references
(since include/net-common.h does check with CONFIG_IS_ENABLED(NET) which
would be true for SPL_NET, but the implementation wouldn't be compiled).
Fix this oversight by making sure a network stack (and the legacy one)
is available when selecting SPL_NET.
Fixes: 8cb330355b ("net: introduce alternative implementation as net/lwip/")
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
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>
Seems the "generous 2MB space" is no longer enough for SPL on some K3 R5
platforms so let's increase this to 4MB. That matches what we give to
ARM64 SPL, so combine these.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
The variable bmp_load_addr is used to hold the address in memory of
where to put the splash image (as a bmp). For 32/64bit correctness, this
needs to be a ulong and not u32 today.
Signed-off-by: Tom Rini <trini@konsulko.com>
SPL_BOOTROM_SUPPORT currently doesn't specify it enables returning to
BootROM *from SPL*, which TPL_BOOTROM_SUPPORT does say. So let's align
the prompts so that both say from which stage you can return to the
BootROM.
Fixes: 225d30b708 ("spl: add a 'return to bootrom' boot method")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
AMD/Xilinx/FPGA changes for v2026.04-rc1
xilinx:
- Sync ESRT with detected GUID
- DT cleanups
- Add logic for FRU information multiple times
- Enable more drivers pca9541, usb5744
- Enable more commands
- Cleanup firmware DT bindings
firmware:
- Add enhancement SMC format support
clk/versal:
- Various cleanups
- Add support for Versal Gen 2
i2c:
- cdns: Add timeout for RXDV status bit polling
spi:
- cadence: Remove cdns,is-dma DT property
- cadence: Remove duplicated return
- cadence_versal: Update flash reset delay
memtop:
- Update max memory reserved spaces to 64
Versal Gen 2:
- Aligned addresses with default memory map
- Add support for reading multiboot value
MB-V:
- Make SPL smaller
- Add support for SPI
- Move SPL to run out of BRAM
ZynqMP:
- Change default load address for BL32
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
This function and the sector parameter evolved over the time. By now,
sector is influenced by spl_mmc_get_uboot_raw_sector which allows to
adjust the read sector with an offset that U-Boot proper may have inside
the partition. That used to work by chance if both
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION were enabled. Since
2a00d73d08 they are a choice, and we need to drop the condition to
maintain this feature.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Add SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE as condition where so
far SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION was enough - though often
by chance as both options were enabled.
Reorder the #ifdef blocks at this chance to follow the order in the
Kconfig menu.
Fixes: 2a00d73d08 ("spl: mmc: Try to clean up raw-mode options")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
We need to explicitly select SPL_LOAD_BLOCK when USE_PARTITION_TYPE is
enabled, just like the other choices do.
Fixes: 2a00d73d08 ("spl: mmc: Try to clean up raw-mode options")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
To support booting Linux from MMC, the file name should be
set up correctly. To support booting Linux from Parallel Flash,
the SPL_LOAD_FIT_ADDRESS should point to the Parallel Flash.
Signed-off-by: Randolph <randolph@andestech.com>
Commit 5f70be08b0 ("Fix autoboot countdown printing wrong") introduces
inconsistency in how the countdown is displayed. For example, in case
when BOOTDELAY=5, the next output is observed during the boot:
Hit any key to stop autoboot: 5
Hit any key to stop autoboot: 4
Hit any key to stop autoboot: 3
That happens due to different printf format (%2d vs %1d). Moreover, the
mentioned commit fails to handle the case when the user is holding some
key before the countdown is shown. E.g. if BOOTDELAY=101, the next
malformed output is being produced:
Hit any key to stop autoboot: 1 0
That's because the fast path code wasn't modified accordingly, and still
tries to erase the number using '\b\b\b' format.
Fix both issues by introducing a dedicated routine for printing the
whole countdown line.
Fixes: 5f70be08b0 ("Fix autoboot countdown printing wrong")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: David Zang <davidzangcs@gmail.com>
To the exception of red_led_on in the arm-specific assembly code, all
code interacting with the red status LED was guarded by the
CONFIG_LED_STATUS_RED symbol, which is enabled in none of the upstream
defconfigs.
Since the last board which overrode the weak red_led_on function got
migrated to the new LED mechanism, there's also no user of the
arm-specific assembly code anymore, therefore it can be removed along
the other unreachable code sections.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
The last user of it was removed in a previous commit so let's remove its
support entirely.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
The code is guarded by a condition none of the defconfigs meet (that is
CONFIG_SYS_FAULT_ECHO_LINK_DOWN and CONFIG_LED_STATUS_RED both enabled),
so we can remove the unreachable code sections.
When doing that, there's no caller for miiphy_link anymore, so it can be
removed.
This in turns makes CONFIG_SYS_FAULT_ECHO_LINK_DOWN and
CONFIG_SYS_FAULT_MII_ADDR unused so they are removed as well.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
The last user of coloured_LED_init has been recently removed, so we can
remove all places it's called and defined as it does nothing now.
Nobody makes use of the yellow and blue status LEDs from the legacy API,
so let's remove all references to it.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Heiko Schocher <hs@nabladev.com> 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/20251118043042.27726-1-hs@nabladev.com
We no longer use raw mode to boot from MMC for our devices in favor
of FAT filesystem.
Maintaining this config for legacy gen5 devices as to not risk breaking
any configurations still utilizing raw mode.
Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
For some tests the current default of 0x400 for
CONFIG_CONSOLE_RECORD_OUT_SIZE is too small.
Raise the value to 0x6000 which is already the most common value.
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
There are cases where qfw_read_entry() does not set the output parameter
passed by address. This occurs with qfw_sandbox_read_entry_dma, which
leaves the size variables uninitialized and causes a segfault when running
bootflow scan in U-Boot sandbox.
$ ./u-boot
...
U-Boot 2026.01-rc1-00199-gc2637036b8f0 (Nov 04 2025 - 10:32:21 +0100)
...
Hit any key to stop autoboot: 0
=> bootflow scan
efi_var_to_file() Cannot persist EFI variables without system partition
efi_tcg2_register() Missing TPMv2 device for EFI_TCG_PROTOCOL
efi_rng_register() Missing RNG device for EFI_RNG_PROTOCOL
scanning bus for devices...
[3] 1015761 segmentation fault (core dumped) ./u-boot
Initalize all these variables to 0 to fix this issue.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Support for using "u-boot,dm-..." rather than "bootph-..." has been
deprecated since February 2023. Any platforms using this have had a
console message saying to migrate by 2023.07. Go and remove all support
here now, for the v2026.01 release.
The results of this change that aren't clear from the above are that we
still have a checkpatch.pl error message, and document in
doc/develop/spl.rst that they have been migrated since 2023. We also
change the key2dtsi.py tool to use the correct bootph phase rather than
the legacy phase.
Signed-off-by: Tom Rini <trini@konsulko.com>
The null check for loader in boot_from_devices was moved earlier in the
code path by the commit ae409a84e7 ("spl: NULL check variable before
dereference"), therefore the subsequent null checks for loader are not
necessary.
This patch removes those checks and refactors the prints to be more
useful in case of errors.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a to SPL.
This is already supported on ARMv8a, this patch adds the ARMv7a support.
Extend the SPL fitImage loader to record OPTEE-OS load address and in case
the load address is non-zero, use the same bootm-optee.S code used by the
U-Boot fitImage jump code to start OPTEE-OS first and jump to Linux next.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
When spl boot device list has multiple FAT devices, any previousely
registered FAT device should be deregistered before registering
next FAT boot device, otherwise the function may not attempt boot
from next FAT device.One of the situations where this issue can be
observed is when the boot device list has two FAT partitions of a
memory device and if booting fails on first partition (because of
file or partition related errors), boot from next partition actually
gets attempted on previous boot device only, as the previous device
has remained marked as registered. Call the function that invalidates
cached boot device in case of failure in booting from current FAT
boot device.
Signed-off-by: Prasad Kale <prasad.kale@live.com>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Sean Anderson <seanga2@gmail.com>
Technically, commit 24bf44cf88 ("spl: fit: Do not fail immediately if
an overlay is not available") introduced that regression as the code
will never advance if spl_fit_get_image_name() will return an error. But
at that time, spl_fit_get_image_node() was used in spl_fit_append_fdt()
which calls fdt_subnode_offset() to get the image node. And I presume
the commit was about the latter failing gracefully and trying the next
one.
But with commit b13eaf3bb4 ("spl: fit: Add board level function to
decide application of DTO") that behavior changed and the loop in
spl_fit_append_fdt() no longer uses spl_fit_get_image_node() but
spl_fit_get_image_name() directly. Thus it doesn't make any sense to not
break the loop if that fails.
Also, the original use case of commit 24bf44cf88 ("spl: fit: Do not
fail immediately if an overlay is not available") is preserved because
spl_subnode_offset() is now called within the loop and errors are
handled gracefully (and advancing the index).
Fixes: b13eaf3bb4 ("spl: fit: Add board level function to decide application of DTO")
Signed-off-by: Michael Walle <mwalle@kernel.org>
Introduces support for Device Firmware Upgrade (DFU) over PCIe in
U-Boot. Traditionally, the DFU protocol is used over USB, where a
device enters DFU mode and allows a host to upload firmware or binary
images directly via the USB interface. This is a widely adopted and
convenient method for updating firmware.
In the context of Texas Instruments (TI) SoCs, PCIe can be used as a
boot interface in a manner that differs from the conventional
"PCIe Boot" process, which typically refers to booting an OS or
firmware image from an NVMe SSD or other PCIe-attached storage devices.
Instead, TI SoCs can be configured as a PCIe Endpoint, allowing a
connected PCIe Root Complex (host) to transfer images directly into the
device’s memory over the PCIe bus for boot purposes. This mechanism is
analogous to DFU over USB, but leverages the high-speed PCIe link and
does not depend on traditional storage devices.
By extending the DFU framework in U-Boot to support PCIe, it will be
possible to flash images over PCIe. While this implementation is
motivated by TI SoC use cases, the framework is generic and can be
adopted by everyone for platforms that support PCIe Endpoint mode.
Platforms with hardware support for PCIe-based memory loading can use
this to implement PCIe as a boot mode, as well as to enable flashing
and recovery scenarios similar to DFU over USB.
In summary, enable support for:
- DFU-style flashing of firmware/images over PCIe, analogous to existing
USB DFU workflows
- PCIe as a boot mode where a host can load images directly into device
memory using DFU over PCIe
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20251023080922.3527052-1-h-salunke@ti.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437
("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
HS devices and but can now be enabled with the addition of
OS_BOOT_SECURE.
For secure boot, the kernel with x509 headers can be packaged in a fit
container (fitImage) signed with TIFS keys for authentication.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
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 <anshuld@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The current spl_board_fixups API allows for modification of spl_image
before the SPL jumps to it. This can be used to modify the DT for the
next boot stage, however the current API only allows either the machine
arch or the board to use it.
This limits the utility of the API as there might be certain fixups that
should be applied to all boards sharing the same machine architecture
with others being board specific.
For TI's K3 specifically, this prevents us from performing architecture
level fixups since a lot of TI boards are already making use of the
spl_board_fixups API.
Therefore this patch splits the API into two to allow both board and the
architecture specific fixups. The order is kept as arch then board to
give board specific fixups the precedence.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
When falcon mode is enabled and SPL_OS_BOOT_SECURE is not enabled,
restore the previous default behavior of having an args file be
expected. Platforms which are using a FIT image here and do not need
this can update at their convenience to disable this option now.
Fixes: b1a3ed0688 ("spl: make args file optional in falcon mode")
Signed-off-by: Tom Rini <trini@konsulko.com>
The arg field of `struct spl_image_info` is used by jump_to_image_linux
as the argument for the kernel in falcon mode.
Since commit 601cebc29d ("cmd: spl: Remove ATAG support from this
command"), fdt is the only valid argument for kernel in falcon mode.
However fdt was only being set as the argument in nor and xip boot
modes, this patch fixes it for all boot modes and removes the now
redundant code from spl_nor and spl_xip.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
The expected payload for the SPL in secure falcon mode is a fitImage
that contains the kernel image and the DT. This removes the need to load
an additional args file, which exposes an additional attack vector since
it can not be verified.
Therefore this patch disables loading of the arg file when
SPL_OS_BOOT_SECURE is set.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Falcon mode loads a kernel file and an args file which is the
device-tree. However in the case of kernel file being a FIT that
contains the device-tree within it, loading the args file is not
required.
Therefore, this patch introduces a new SPL_OS_BOOT_ARGS config options
that allows us to enable or disable loading of the args file in falcon
mode.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Instead of falling back to the standard U-Boot boot flow, we should just
halt boot if the expected boot flow in falcon mode fails.
This prevents a malicious actor from accessing U-Boot proper if they can
cause a boot failure on falcon mode.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch moves the falcon mode handling logic out of
spl_ubi_load_image to spl_ubi_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch moves the falcon mode handling logic out of
spl_nor_load_image to spl_nor_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch moves the falcon mode handling logic out of
spl_spi_load_image to spl_spi_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
