u-boot.git/common/spl/Kconfig, branch v2026.01

spl: Remove ARCH_SOCFPGA from MMC raw mode enablement

2025-12-01T06:30:46Z

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 Reviewed-by: Tien Fong Chee

spl: Add support for Device Firmware Upgrade (DFU) over PCIe

2025-11-06T09:17:05Z

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 Reviewed-by: Mattijs Korpershoek Link: https://lore.kernel.org/r/20251023080922.3527052-1-h-salunke@ti.com Signed-off-by: Mattijs Korpershoek

spl: Kconfig: allow falcon mode for TI secure devices

2025-11-03T17:52:29Z

Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc ("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

spl: remove usage of CMD_BOOTx from image parsing

2025-11-03T17:52:05Z

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 Reviewed-by: Tom Rini

spl: Restore args file being default in falcon mode

2025-10-20T19:55:37Z

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: b1a3ed068869 ("spl: make args file optional in falcon mode") Signed-off-by: Tom Rini

spl: prevent loading args file in secure falcon mode

2025-10-20T17:54:33Z

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 Signed-off-by: Anshul Dalal

spl: make args file optional in falcon mode

2025-10-20T17:54:29Z

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

spl: Kconfig: add SPL_OS_BOOT_SECURE config symbol

2025-10-20T16:14:00Z

This patch adds the new SPL_OS_BOOT_SECURE symbol that enables secure boot flow in falcon mode. This symbol can be used to disable certain inherently insecure options during falcon boot. Reviewed-by: Tom Rini Signed-off-by: Anshul Dalal

global: Disable xPL phases when we have enabled COMPILE_TEST

2025-10-13T20:54:32Z

Due to how we implement the logic for selecting what should/shouldn't be built in a given phase it becomes extremely cumbersome to make these phases link when configured by "allyesconfig". As a starting point for being able to enable "allyesconfig" and expand our static coverage, disable all other phases in this case. Future work can be done to enable other phases as time and interest permit. Signed-off-by: Tom Rini

spl: FIT: Make SPL_LOAD_FIT_FULL depend on SPL_LOAD_FIT

2025-10-13T20:54:32Z

Today, only a few platforms enable SPL_LOAD_FIT_FULL, and all enable SPL_LOAD_FIT. As can be seen in usage, the FULL symbol is a superset of the first symbol, not an alternative. Update Kconfig entries based on this and simplify the only code which checks for either being set. Signed-off-by: Tom Rini