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>
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>
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>
Currently the logic to handle falcon mode as well as the regular boot is
inside spl_mmc_do_fs_boot, this prevents us from cleanly extending
falcon mode functionality like toggleable fallback to U-Boot proper.
Therefore this patch splits the logic into spl_mmc_fs_load and
spl_mmc_fs_load_os to handle the regular boot and falcon mode use case.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
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 <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
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 <trini@konsulko.com>
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 <trini@konsulko.com>
We can only enable Falcon Mode (aka SPL_OS) on architectures which
implement certain hooks. Express these dependencies in Kconfig.
Signed-off-by: Tom Rini <trini@konsulko.com>
It is possible that we will not have enabled the options to call
spl_sata_load_image_raw so use the __maybe_unused decorator to silence
the compiler warning.
Signed-off-by: Tom Rini <trini@konsulko.com>
In Kconfig syntax, "!=" is a string and not numerical comparison. This
means that to check for a non-zero SPL_SIZE_LIMIT_PROVIDE_STACK value we
need to test that it is "> 0" rather than "!=" 0. This is because "0x0 >
0" is false while "0x0 != 0" is true.
Signed-off-by: Tom Rini <trini@konsulko.com>
Anshul Dalal <anshuld@ti.com> says:
During the implementation of falcon mode for TI's K3 devices [1], I encountered
several limitations in regards to the current falcon mode support in U-Boot
especially in ensuring a secure boot flow.
Although the current implementation allows for loading of a signed fitImage as
the SPL payload, there are still a few edge cases that might allow bypassing the
verified boot path.
The following issues with current falcon mode need to be resolved:
1) No fallback:
We currently fallback to regular boot flow if falcon mode fails,
this might not be secure.
2) No arguments file:
We currently load a kernel file (which could be a raw image or FIT)
alongside an args file (usually the DT). The args file here doesn't have
any verification mechanism, so should be skipped altogether as the FIT can
contain the DT.
3) No access to env:
In ext and fat fs boot, currently we also reads the environment to get the
names of the kernel and the arg file. This should be disabled in secure
falcon flow as the env might not be secure.
4) No raw image boot:
Boot should fail when the kernel file is a raw kernel image, only FIT should
be allowed.
As per the recommendation of maintainers[2], I have decided to split the above
set of tasks into multiple patch series. This is the first one which fixes the
load order of kernel image and the args file in falcon mode. Along with some
minor cleanup.
[1]: https://lore.kernel.org/u-boot/20250603142452.2707171-1-anshuld@ti.com/
[2]: https://lore.kernel.org/u-boot/20250911172313.GT124814@bill-the-cat/
Link: https://lore.kernel.org/r/20250923124639.667718-1-anshuld@ti.com
Minor cleanup of spl_ext and spl_fat files, removing the outdated
CONFIG_SPL_LIBCOMMON_SUPPORT symbols similar to the commit 1847129025
("spl: mmc: Drop checks for CONFIG_SPL_LIBCOMMON_SUPPORT") and adding a
few extra failure reports.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Load the kernel image before args in falcon mode to be consistent with
the load order for other boot media.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Load the kernel image before args in falcon mode to be consistent with
the load order for other boot media.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Currently in falcon mode, the FS and raw mmc boot loads the args file
first followed by the kernel image whereas others load in the opposite
order. This inconsistency means falcon boot doesn't behave the same
across various boot media.
For example, in the case where the kernel file is a FIT with the kernel
image present alongside the dtb and the args file is another DT, which
DT should be picked? The one form the FIT or the one set by the args
file? Currently this depends entirely on how the boot media handles
falcon mode.
Therefore, this patch enforces the load order of the kernel image first
followed by the args file in FAT FS boot. So in the above example, the
args file would take precedence.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
spl_start_uboot is a board overridable function that switches to falcon
boot mode on return value of 0.
Though for SPI, the falcon boot mode was being enabled on return value
of 1 which is not the correct behaviour. Therefore this patch fixes it
to the expected boot flow.
Fixes: 14509a28aa ("spl: spi: Consolidate spi_load_image_os into spl_spi_load_image")
Signed-off-by: Anshul Dalal <anshuld@ti.com>
I had trouble booting some am335x boards (both
beagleboneblack and a custom board). SPL would start just fine, and
apparently load U-Boot proper, but it would hang when jumping to
U-Boot.
While debugging, I stumbled on this memcpy() which from code
inspection very much looked to have overlapping src and dst, and
indeed a simple printf revealed
calling memcpy(0x8087bf68, 0x8087bf80, 0xf7f8)
Now, it will always be with src > dst, our memcpy()
implementations "most likely" do forward-copying, and in the end it
turned out that this wasn't the culprit after all [*].
But to avoid me or others barking up the wrong tree in the future, and
because this use of memcpy() is technically undefined, use memmove()
instead.
[*] That was 358d1cc232 ("spl: Align FDT load address"), which has
since been fixed in master but not the v2025.07 I worked of by
52caad0d14 ("ARM: Align image end to 8 bytes to fit DT alignment").
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@gmx.de>
Explicitly specify the type by replacing macro with variable
to fix the possible compilation warning.
Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Explicitly specify the type by replacing macro with variable
to fix the possible compilation warning.
Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
In boot_from_devices the variable loader is not NULL checked after
assignment and before first use but later code does check it for NULL.
Add a NULL check before first use.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Add the basic Kconfig options, addresses and other values for the
existing Kconfig settings for the new Allwinner A523/T527/H728 SoC.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The 'overhead' variable is uninitialized and actually shall not be used.
Delete it to fix coverity CID 37041718 - Uninitialized scalar variable.
Fixes: 73c40fcb73 ("spl: Refactor spl_load_info->read to use units of bytes")
Reported-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Andrew Goodbody <andrew.goodbody@linaro.org>
To support PQC container format which is used for post quantum
authentication on new i.MX parts like i.MX94
The major changes compared to legacy container format is in
signature block, new container tag and version, and new alignment
of container header.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
We have a few options that we cannot enable in a "allyesconfig" type
build because we cannot use zero as a default value.
- The logic around HAS_BOARD_SIZE_LIMIT assumes that if we have set this
then we compare with it. Similarly, we need to set SPL_NO_BSS_LIMIT as
the default there.
- Both SYS_CUSTOM_LDSCRIPT and ENV_USE_DEFAULT_ENV_TEXT_FILE then prompt
for a file name to use.
- The SYS_I2C_SOFT driver is a legacy driver which requires a lot of
configuration within the board config. file instead, so disable it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add Renesas R-Car Gen4 SCIF/HSCIF loader compatible SREC generation.
This is a regular U-Boot SPL SREC augmented with a short header which
describes where to store the received data and how much data to store.
This header is interpreted by the R-Car Gen4 BootROM SCIF/HSCIF loader.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Alif Zakuan Yuslaimi