| Age | Commit message (Collapse) | Author |
|---|
|
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 <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
Tested-by: Wadim Egorov <[email protected]>
|
|
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 <[email protected]>
|
|
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 601cebc29d2a ("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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
When I migrated this to Kconfig in commit 68e54040ccc3 ("sandbox: Move
CONFIG_IO_TRACE to Kconfig") I didn't look hard enough for other
details. As explained in the README, this is valid for ARM too. So start
by making this be a prompted question and CMD_IOTRACE depend on IO_TRACE
being enabled. Next, migrate the information out of README and in to
the appropriate help text for existing options in Kconfig. Finally, make
this option be default y on SANDBOX but not selected as it's valid to
build without it.
Signed-off-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
|
|
While MMU_PGPROT is currently only functional for arm64 it can be
extended for other real platforms as well. It does not however make
sense for sandbox to enable and create dummy functions for. Make this
depend on !SANDBOX.
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
|
|
We have a large number of library symbols that should not be prompted
for by the user really but rather selected by the platform (or SoC) as
needed. To start with however, make these depend on !COMPILE_TEST.
Signed-off-by: Tom Rini <[email protected]>
|
|
before args"
Anshul Dalal <[email protected]> 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/[email protected]/
[2]: https://lore.kernel.org/u-boot/20250911172313.GT124814@bill-the-cat/
Link: https://lore.kernel.org/r/[email protected]
|
|
Minor cleanup of spl_ext and spl_fat files, removing the outdated
CONFIG_SPL_LIBCOMMON_SUPPORT symbols similar to the commit 1847129025e0
("spl: mmc: Drop checks for CONFIG_SPL_LIBCOMMON_SUPPORT") and adding a
few extra failure reports.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
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 <[email protected]>
|
|
Load the kernel image before args in falcon mode to be consistent with
the load order for other boot media.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
DT binding doesn't mandate i2c-bus as required property because hub itself
doesn't need to have i2c connected.
It can be in standalone mode that only power regulator and reset should be
handled.
Or hub should be configured via spi interface.
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
SoCFPGA updates for v2025.10:
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/27762
This pull request brings a set of updates across SoCFPGA platforms
covering Agilex5, Agilex7, N5X, and Stratix10. The changes include:
* Agilex5 enhancements:
- USB3.1 enablement and DWC3 host driver support
- System Manager register configuration for USB3
- Watchdog timeout increase and SDMMC clock API integration
- dcache handling improvements in SMC mailbox path
- Enable SPL_SYS_DCACHE_OFF in defconfig
* Clock driver improvements:
- Introduce dt-bindings header for Agilex clocks
- Add enable/disable API and EMAC clock selection fixes
- Replace manual shifts with FIELD_GET usage
* DDR updates:
- IOSSM mailbox compatibility check
- Correct DDR calibration status handling
* Device tree changes:
- Agilex5: disable cache allocation for reads
- Stratix10: add NAND IP node
- Enable driver model watchdog
- Enable USB3.1 node for Agilex5
* Config cleanups:
- Simplify Agilex7 VAB defconfig
- Remove obsolete SYS_BOOTM_LEN from N5X VAB config
- Enable CRC32 support for SoCFPGA
- Increase USB hub debounce timeout
Overall this set improves reliability of DDR and cache flows,
adds missing USB and MMC features for Agilex5, and refines clock
and configuration handling across platforms.
This patch set has been tested on Agilex 5 devkit, and Agilex devkit.
|
|
When the data cache (dcache) is disabled, calling related
status functions can lead to compilation errors due to
undefined references.
Adding a !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) check before
invoking dcache_status() (used in common/memsize.c:get_ram_size())
and mmu_status() (from arch/arm/include/asm/io.h).
Without this check, builds with dcache disabled will fail to compile.
Signed-off-by: Boon Khai Ng <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
This all started from me wondering "why does this standalone app end
up being so huge"? Oh, it essentially links in its own standard C
library to get strlen() and snprintf(). Which then led to asking "why
don't we export all those standard C functions when we have them
anyway?".
CI has chewed on these and seem happy - it was CI which told me about
the necessity of [1/9]: https://github.com/u-boot/u-boot/pull/813
Link: https://lore.kernel.org/r/[email protected]
|
|
The !CONFIG_PHY_AQUANTIA defines were already superfluous since
_exports.h does have a CONFIG_PHY_AQUANTIA, so the entries never
existed. In fact, it couldn't have worked, because the defines would
affect both occurences of the mdio_get_current_dev identifier in the
EXPORT_FUNC(mdio_get_current_dev, struct mii_dev *,
mdio_get_current_dev, void)
so the C code would end up containing four copies of
gd->jt->dummy = dummy
but struct jt_funcs would not and does not have any 'dummy' member.
Now that nothing in _exports.h refers to dummy(), remove the empty
function.
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Prepare v2025.10-rc5
|
|
If neither CONFIG_BLOBLIST_FIXED NOR CONFIG_BLOBLIST_ALLOC is set,
currently CONFIG_BLOBLIST_SIZE_RELOC defaults to 0 except if
* CONFIG_ARM=y && CONFIG_EFI_LOADER=y && GENERATE_ACPI_TABLE=y.
A size of zero never makes sense for a bloblist.
When using QFW we need more than 64 KiB to host the ACPI table.
In this case CONFIG_BLOBLIST_ALLOC is used.
Set a reasonable default.
Remove the CONFIG_BLOBLIST_SIZE_RELOC in ARM QEMU defconfigs which are
not compatible with ACPI tables passed from QEMU.
Reported-by: Emil Renner Berthing <[email protected]>
Fixes: 6f9b015c138b ("common: Enable BLOBLIST_TABLES on arm")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
It is expected that bloblists are stored in high memory beyond 2 GiB.
We must not use int as data type for these addresses but phys_addr_t.
Fixes: f9ef9fb033d5 ("bloblist: Handle alignment with a void entry")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
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: 14509a28aa20 ("spl: spi: Consolidate spi_load_image_os into spl_spi_load_image")
Signed-off-by: Anshul Dalal <[email protected]>
|
|
The SPI flash driver does not build without SPI support enabled.
Fixes: 4151f4f822bb ("spl: Rework and tighten some dependencies")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Peng Fan <[email protected]>
Acked-by: Anshul Dalal <[email protected]>
|
|
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 358d1cc232c ("spl: Align FDT load address"), which has
since been fixed in master but not the v2025.07 I worked of by
52caad0d14a ("ARM: Align image end to 8 bytes to fit DT alignment").
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The CONFIG_SYS_EARLY_PCI_INIT symbol is currently not supported
by Kconfig.
Make it a Kconfig symbol so that users could select it via defconfig.
Signed-off-by: Fabio Estevam <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Explicitly specify the type by replacing macro with variable
to fix the possible compilation warning.
Signed-off-by: Leo Yu-Chi Liang <[email protected]>
|
|
Explicitly specify the type by replacing macro with variable
to fix the possible compilation warning.
Signed-off-by: Leo Yu-Chi Liang <[email protected]>
|
|
family"
Lukasz Czechowski <[email protected]> says:
This patch series extends the usb_onboard_hub driver to allow for
support of more types of onboard hub devices, and adds the Cypress HX3
hub family.
First patch in the series updates the bind function, so that it no
longer uses hardcoded compatible strings.
Next patch simplifies the code, by removing unnecessary dm_gpio function
call.
Third patch updates the remove function, which allows the prevent issues
with usb devices reenumeration, in case of calling "usb reset". Although
the issue could still occur in case of invalid initial state of reset
gpio, it is minimized with no impact on main usb_hub driver.
Fourth patch extends the driver with support for multiple power
supplies, the same way it is done in kernel driver. Finally, last patch
provides hub data and of_match table entries for Cypress HX3
Link: https://lore.kernel.org/r/20250722-usb_onboard_hub_cypress_hx3-v4-0-91c3ee958c0e@thaumatec.com
|
|
The HX3 is a family of USB3.0 hub controllers that comes in
different variants: CYUSB330x/CYUSB331x/CYUSB332x/CYUSB230x.
To support this hub, controlling of reset pin and two
power supplies is required.
The reset time is set to 10ms, based on the datasheet [1].
Power-on delay time is not required, so it is set to 0.
The compatible strings added to of_match table are
compliant with usb/cypress,hx3.yaml bindings.
[1] https://www.infineon.com/dgdl/Infineon-HX3_USB_3_0_Hub_Consumer_Industrial-DataSheet-v22_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ecb53f644b8
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: Lukasz Czechowski <[email protected]>
|
|
Some of the onboard hubs require multiple power supplies, so extend
the driver to support them.
The implementation is inspired by the kernel driver, as introduced
by commit [1] in the v6.10 kernel.
[1] https://github.com/torvalds/linux/commit/ec1848cd5df426f57a7f6a8a6b95b69259c52cfc
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: Lukasz Czechowski <[email protected]>
|
|
In the usb_onboard_hub_remove, the reset gpio, if available, is
freed. The pin state however, remains unchanged, as set in the
usb_onboard_hub_reset. The hub is then left enabled.
During second onboard hub probing, the hub is initially enabled
(reset pin in state "0"), and then it is being reset by the reset
function (transition to "1" and then to "0"). Because of this,
the hub first disconnects from root hub, and then it connects again.
When the devices are being discovered in the usb_scan_port in the
usb_hub driver, initially there is the USB_PORT_STAT_CONNECTION bit
not set in portstatus, but USB_PORT_STAT_C_CONNECTION set in
portchange data (which is because disconnect event occurred first).
In this condition, the driver does not wait for devices to appear.
This can cause the hub (and all child devices) to be not enumerated
when rescanning on "usb reset" command.
To fix this, set the reset gpio to active in usb_onboard_hub_remove,
to put the hub into reset state.
However, in case the hub reset pin is by default held in high
state by HW before U-Boot takes over, in which case the USB hub is
active, then during the first probe it gets reset and we might get
into the same issue of the hub being not enumerated.
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: Lukasz Czechowski <[email protected]>
|
|
The reset GPIO is obtained during driver probing by the function
devm_gpiod_get_optional, which means the GPIO will be automatically
freed when the device is removed. Because of this, explicit call
to free the reset GPIO in hub remove function is not needed.
To support the Managed device resources, the DEVRES config must
be enabled, otherwise the devres functions fall back to non-managed
variants. Set the necessary dependency to DEVRES in Kconfig.
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: Lukasz Czechowski <[email protected]>
|
|
Currently the check in usb_onboard_hub_bind is relying on specific
compatible string for the Michrochip USB5744. Replace this with
more generic approach that will allow to add new types of devices
to the of_match table. Because the driver only needs to bind one
"half" of the hub, the peer-hub node is used to find out if it
was already done. In case peer-hub was bound, -ENODEV is returned.
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: Lukasz Czechowski <[email protected]>
|
|
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 <[email protected]>
|
|
I updated the mailmap a while back but it's nice to have authorship
comments adjusted too.
Signed-off-by: Casey Connolly <[email protected]>
|
|
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 <[email protected]>
|
|
The 'overhead' variable is uninitialized and actually shall not be used.
Delete it to fix coverity CID 37041718 - Uninitialized scalar variable.
Fixes: 73c40fcb7367 ("spl: Refactor spl_load_info->read to use units of bytes")
Reported-by: Andrew Goodbody <[email protected]>
Signed-off-by: Ye Li <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Fabio Estevam <[email protected]>
Reviewed-by: Andrew Goodbody <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jacky Bai <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
Acked-by: Peng Fan <[email protected]>
|
