bootstd: android: add the bootargs env to the commandline

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) <nbelin@baylibre.com>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20251024-botargsappend-v1-1-0b78f05f9132@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

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

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>

Merge tag 'u-boot-imx-master-20251104' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/28144

- Extend USB support for the i.MX9 family.
- Update memory controller for imx6ulz_smm_m2.
- Add remoteproc support for several i.MX boards.
- Add support for iMX95 15x15 EVK.

Gitlab: Drop vexpress_fvp from tests

Now that we have a test for QEMU using transfer list from the previous
stage, there are two platforms testing this particular infrastructure. A
problem with the vexpress_fvp platform emulation in Gitlab is that we
often run it on hosts that are fast enough that we run in to a race
condition when trying to acquire the console and the test fails. Remove
both vexpress_fvp tests from Gitlab (they can remain in Azure) to remove
these spurious failures.

Signed-off-by: Tom Rini <trini@konsulko.com>

CI: Move to Ubuntu 'Jammy' 20251001 tag

This also incorporates the following commits to the Dockerfile:
da7942de29f7 Dockerfile: remove Python 2.7
183299d9a400 docker: add OP-TEE and TF-A build for testing Firmware Handoff

Signed-off-by: Tom Rini <trini@konsulko.com>

Dockerfile: remove Python 2.7

We don't use Python 2 anywhere. Remove the package from our Docker image.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge patch series "Enable Firmware Handoff CI test on qemu_arm64"

Raymond Mao <raymond.mao@linaro.org> says:

This patch series enable Firmware Handoff [1] CI tests on qemu_arm64 by:
1. fetch MbedTLS (v3.6), OP-TEE (v4.7.0) and TF-A (v2.13.0);
2. build bl1 and fip with both Firmware Handoff and Measured Boot
   enabled;
3. pytest to validate the Firmware Handoff feature via bloblist by
   checking the existence of expected FDT nodes and TPM events generated
   and handed over from TF-A/OP-TEE.

[1] https://github.com/FirmwareHandoff/firmware_handoff

Link: https://lore.kernel.org/r/20251021181703.598342-1-raymond.mao@linaro.org

ci: add test entries for qemu_arm64_tfa_fw_handoff

Add qemu_arm64_tfa_fw_handoff test entries to azure and gitlab
pipelines.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

ci: check existence of bl1 and fip in the test script

Check the existence of bl1 and fip from:
1. /opt/tf-a/${board_type}_${board_ident}, if not exist, then;
2. /opt/tf-a/${board_type}

This change allows to test with TF-A with specified board ID only.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>

configs: select CMD_BLOBLIST for Firmware Handoff testing

Firmware Handoff tests will leverage the same board type 'qemu_arm64'
with a new board ID 'fw_handoff_tfa_optee', thus select CMD_BLOBLIST
in qemu_arm64_defconfig for running the test.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

pytest: add test script to validate Firmware Handoff

Add test cases to validate FDT and TPM eventlog handoff from TF-A
and OP-TEE via bloblist.

For FDT, the nodes 'reserved-memory' and 'firmware' appended by
OP-TEE indicates a successful handoff.

For TPM eventlog, the events 'SECURE_RT_EL3', 'SECURE_RT_EL1_OPTEE'
and 'SECURE_RT_EL1_OPTEE_EXTRA1' created by TF-A indicates a
successful handoff.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

docker: add OP-TEE and TF-A build for testing Firmware Handoff

Fetch OP-TEE (4.7.0), TF-A (v2.13.0), MbedTLS (v3.6) and build
bl1 and fip with both Firmware Handoff and Measured Boot enabled.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

arm: armv8: mmu: fix mem_map_from_dram_banks

mem_map_from_dram_banks calls fdtdec_setup_memory_banksize to setup the
dram banks though that is expected to be done by dram_init_banksize as
part of board_r sequence.

This has the side effect of modifying gd->bd->bi_dram as well, therefore
this patch removes the call and updates spl_enable_cache for K3 to call
dram_init_banksize.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reported-by: Francesco Dolcini <francesco@dolcini.it>
Closes: https://lore.kernel.org/u-boot/20251027165225.GA71553@francesco-nb/
Fixes: fe2647f2a0d4 ("arm: armv8: mmu: add mem_map_from_dram_banks")
Tested-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>

imx95_evk: Add basic support for iMX95 15x15 EVK

Add boot support and peripherals like eMMC/SD, UART, I2C, GPIO, ENETC0/1
and PCIE0/1 for iMX95 15x15 LPDDR4X EVK.
Updated doc for build instructions.

Signed-off-by: Ye Li <ye.li@nxp.com>

arm: dts: imx95-15x15-evk: Add -u-boot.dtsi for SPL and binman

Add -u-boot.dtsi for iMX95 15x15 EVK used by SPL and binman.
iMX95 15x15 EVK uses LPDDR4X which needs dedicated DDR FW.

Signed-off-by: Ye Li <ye.li@nxp.com>

imx95_evk: Share the env file for both 19x19 EVK and 15x15 EVK

Rename the env file to imx95_evk.env to share it with iMX95 15x15 EVK

Signed-off-by: Ye Li <ye.li@nxp.com>

imx: kontron-sl-mx8mm: Add support for reading HW UIDs

The factory provides a CPU UID in the OTPs and the SoM module
and the carrier board might provide additional UIDs in the GP
registers of the OTPs. Load these values in the following order
and create a serial number string:

* Board UID (GP2)
* SoM UID (GP1)
* CPU UID (UNIQUE_ID)

The string is stored in the "serial#" env variable and
exported to Linux. Further this prints the used UID to the
console which looks like this

  ID:    0042152331 (Board)

or:

  ID:    0030124840 (SoM)

or:

  ID:    4696668CD9516886 (CPU)

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>

imx: kontron-sl-mx6ul: Add support for reading HW UIDs

The factory provides a CPU UID in the OTPs and the SoM module
and the carrier board might provide additional UIDs in the GP
registers of the OTPs. Load these values in the following order
and create a serial number string:

* Board UID (GP2)
* SoM UID (GP1)
* CPU UID (UNIQUE_ID)

The string is stored in the "serial#" env variable and
exported to Linux. Further this prints the used UID to the
console which looks like this

  ID:    0042152331 (Board)

or:

  ID:    0030124840 (SoM)

or:

  ID:    4696668CD9516886 (CPU)

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>

imx: kontron: Add common function to get HW UIDs from OTPs

The factory provides a CPU UID in the OTPs and the SoM module
and the carrier board might provide additional UIDs in the GP
registers of the OTPs.

Provide a common function to load UIDs from arbitrary OTP
registers and generate a serial number string that is saved
in the "serial#" env variable.

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>

imx: kontron-sl-mx6ul: Enable CONFIG_BOARD_LATE_INIT to fix auto fastboot

Recently code was added in board_late_init() to autostart fastboot
in case of booting from USB OTG. This change was ineffective as
enabling CONFIG_BOARD_LATE_INIT got lost during upstreaming.

Fixes: 410d9ccc0388 ("imx: kontron-sl-mx6ul: Autostart fastboot if booted from USB")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>

imx: kontron-sl-mx8mm: Implement spl_board_loader_name()

This allows to print user-friendly names for the boot device
probed by SPL to the console.

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>

imx: kontron-sl-mx8mm: Adjust offset for U-Boot proper in case of eMMC fastboot

The image offset on SD/MMC devices is 33 KiB, except for eMMC boot if
fastboot is enabled. In this case it is 1 KiB. In order to make the
the bootloader universal, check the fastboot OTP boot fuse and adjust
the offset.

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>

doc: cmd: Document remoteproc usage

Add documentation for rproc cmd usage.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

doc: board: nxp: Add remoteproc guide

Add guide on how to use the Remote Processors on i.MX8M and i.MX93.

Update MAINTAINERS to include doc/board/nxp.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

imx93: Enable remoteproc for i.MX93-EVK/QSB/FRDM

Select configs to enable remoteproc for i.MX93-EVK/QSB/FRDM

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

imx8mq: Enable remoteproc for i.MX8MQ EVK

Select configs to enable remoteproc for i.MX8MQ EVK

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

imx8mn: Enable remoteproc for i.MX8MN EVK

Select configs to enable remoteproc for NXP i.MX8MN EVK boards

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

imx8mm: Enable remoteproc for i.MX8MM EVK

Select configs for remoteproc on i.MX8MM EVK boards

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

imx8mp: Enable remoteproc for i.MX8MP EVK

Select configs to enable remoteproc for NXP i.MX8MP EVK

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

arm: dts: imx8m: Add remoteproc node

Add CM7/4 nodes for i.MX8MQ/M/N/P.

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

remoteproc: imx_rproc: Add support for i.MX93 CM33

Introduce remote processor configuration for the i.MX93 Cortex-M33 core.

This patch adds:
- Address translation table (ATT) for i.MX93, including TCM
  (secure and non-secure) and DDR regions.
- A new device configuration structure `imx_rproc_cfg_imx93` using SMC
  method and ARM SMC ops.
- Device tree match entry for "fsl,imx93-cm33"

This enables remoteproc framework to properly initialize and manage the
Cortex-M33 core on i.MX93 platforms.

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

remoteproc: imx_rproc: Support i.MX8MQ/M

i.MX8MQ/M use MMIO based method to directly configure SRC registers
to start/stop M4.

Add mmio ops to start/stop/is_running.
Add i.MX8MQ cfg data, i.MX8MN reuses i.MX8MQ data.

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

remoteproc: Add imx_rproc driver to support NXP i.MX8MP/N

Support i.MX8MP/N with start/stop/device_to_virt/is_running/load
implemented. The device static configuration is mostly reused from
Linux Kernel with adapation to U-Boot dm_rproc_ops.
The booting method:
 - load mmc 2:2 0x90000000 /lib/firmware/imx8mp_m7_DDR_rpmsg_lite_str_echo_
   rtos.elf
 - rproc load 0 0x90000000 ${filesize}
 - rproc start 0

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

remoteproc: Extend device_to_virt with a is_iomem parameter

Some areas needs to be initialized by using memcpy_toio and memset_io.
Following Linux Kernel commit: 40df0a91b2a5 ("remoteproc: add is_iomem to
da_to_va"), add this to U-Boot.

Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

arm64: dts: imx8mp: Add missing LED enumerators for DH electronics i.MX8M Plus DHCOM on PDK2

The LED enumerators are missing, which prevents the LEDs from being
accurately told apart by label. Fill in the enumerators the same way
they are already present on PDK3. Put this into local DT extras until
matching kernel patch lands in Linux.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

arm64: imx8ulp: Split SRAM0 mapping to isolate the SCMI shared memory as non-cacheable

This patch splits the 2MB SRAM0 mapping into three regions:
- 0x22000000~0x2201f000: cacheable normal memory
- 0x2201f000~0x22020000: non-cacheable device memory
- 0x22020000~0x22200000: cacheable normal memory

The change ensures the SCMI shared memory is non-cacheable, which
avoids cache-related issues after removing
mmu_set_region_dcache_behaviour() from scmi_dt_get_smt_buffer().

Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>

ARM: imx: Enable DFU SF on all i.MX6 DHSOM and include dfu_alt_info in env

Enable DFU SF on all i.MX6 DHSOM so the SPI NOR can be exposed via
DFU, and include dfu_alt_info which exposes the full SPI NOR via DFU.
To install new bootloader into the SPI NOR using DFU, it is necessary
to pad the u-boot-with-spl.imx to 0x400 Bytes offset first and then
send it to the board as follows:

"
u-boot=> dfu 0 sf
"

"
host$ dd if=/dev/zero of=pad.bin bs=1024 count=1
host$ cat pad.bin u-boot-with-spl.imx > flash.bin
host$ dfu-util -w -a 0 -D flash.bin
"

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>

imx9: scmi: Drop parenthesis around enable

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

configs: toradex-smarc-imx95: enable USB Gadget OS Descriptors for fastboot

USB OS Descriptors are used to install and configure the device without
requiring any user interaction on OS which support them (e.g. Windows).
Enable them in order to improve the user experience when fastboot is used.

Fixes: ff0540fcfe49 ("board: toradex: add Toradex SMARC iMX95")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>

bsh: imx6ulz_smm_m2: Update imx6ulz BSH SMM M2B board

Improve support for the BSH SystemMaster (SMM) M2B board.
In particular, this patch adds the timing for the 512 MB version, and
the spi.c reflects it by removing the safe guards.

Signed-off-by: Andrea Calabrese <andrea.calabrese@amarulasolutions.com>

bsh: update readme with instructions to build M2B

readme was missing instructions to build M2B. Now added.

Signed-off-by: Andrea Calabrese <andrea.calabrese@amarulasolutions.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

imx943_evk: Enable ENETC1 and ENETC2

With this patch, both ENETC1 and ENETC2 are functional on the i.MX943
EVK board and can be used for networking.

Signed-off-by: Alice Guo <alice.guo@nxp.com>

net: fsl_enetc_mdio: Add support for phy-supply property

Add support for the optional 'phy-supply' property in the ENETC MDIO
driver. This allows the driver to enable and manage the PHY's power
supply via the regulator framework when specified in device tree.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>

net: fsl_enetc: Add i.MX94 support to NETC block control driver

Extend the NETC block control driver to support the i.MX94 SoC.

Acked-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>

imx943_evk: Add support for booting from USB SDP on USB3.0

This patch is used to enable USB Gadget in SPL to make i.MX943 evk board
can use SDP on USB3.0 interface.

Signed-off-by: Alice Guo <alice.guo@nxp.com>

phy: imx8mq-usb: Add SPL support for i.MX8MQ, i.MX8MP, i.MX95, and i.MX94 USB3.0 PHY

This patch adds SPL Kconfig option (SPL_PHY_IMX8MQ_USB) for the i.MX8MQ,
i.MX8MP, i.MX95, and i.MX94 USB3.0 PHY driver, allowing the driver to be
compiled and probed in SPL stage.

Signed-off-by: Alice Guo <alice.guo@nxp.com>

usb: f_sdp: Update SDP driver to support PQC container

Since PQC container has changed version to 0x2 in container header,
update the header's check.

Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

Add serial# for SPL SDP download

After update this, uuu(>1.6) can use below command to filter out devices
when multi boards connected.

uuu -ms <serial#> ...
[sudo] uuu -lsusb can list known devices with serial# informaiton.

Serial number is retrieved via get_board_serial() and passed to
g_dnl_set_serialnumber(). This part is conditionally compiled for i.MX94
only now.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>

imx943_evk: Enable USB 2.0 controller host mode

This patch enables the USB 2.0 controller to operate in host mode on the
i.MX943 EVK board. It updates the device tree files to configure the USB
2.0 controller appropriately and modifies the defconfig to include
necessary support.

Signed-off-by: Alice Guo <alice.guo@nxp.com>

arm: arch-imx9: Add USB2.0 and USB3.0 base address definitions

Add USB1_BASE_ADDR and USB2_BASE_ADDR for i.MX9 platform, and define
USB_BASE_ADDR as an alias to USB2_BASE_ADDR.

Signed-off-by: Alice Guo <alice.guo@nxp.com>

usb: ehci-mx6: Extend support to i.MX91, i.MX93, i.MX94, and i.MX95

Since the EHCI USB driver is shared across i.MX91, i.MX93, i.MX94, and
i.MX95, the condition check is updated to use IMX9.

Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>

Merge branch 'master' of git://source.denx.de/u-boot-usb

Merge branch 'staging' of https://source.denx.de/u-boot/custodians/u-boot-tegra

usb: musb-new: fix typos

Typos found via codespell utility.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>

usb: musb-new: fix ti-musb dependencies

If OF_CONTROL is on, ti-musb.c registers a "ti-musb-wrapper" driver
that requires UCLASS_MISC. Hence, select MISC if both OF_CONTROL
and USB_MUSB_TI are selected.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>

Merge patch series "Allow falcon boot from A-core SPL on K3 devices"

Anshul Dalal <anshuld@ti.com> says:

With the addition of secure falcon mode since commit 7674ac9c820f ("Merge patch
series "Add support for secure falcon mode: disable args file""), this series now
adds support for the same to TI's K3 devices and documents the feature taking
AM62x EVM as an example.

With secure falcon mode from A-Core SPL, the boot flow changes as follows:

Existing:
  R5 SPL -> TFA -> OP-TEE -> A-Core SPL -> *U-Boot* -> Linux Kernel

Modified:
  R5 SPL -> TFA -> OP-TEE -> A-Core SPL -> Linux Kernel

Link: https://lore.kernel.org/r/20251024081408.1610102-1-anshuld@ti.com

Merge patch series "Remove usage of CMD_BOOTx from SPL code"

Anshul Dalal <anshuld@ti.com> 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/20251027-fix_cmd_bootx-v10-0-10487e907710@ti.com

doc: develop: add docs for secure falcon mode

This patch documents the newly added SPL_OS_BOOT_SECURE option that
enables authenticated boot in falcon mode.

The document provides steps for using secure falcon mode on ARM64 taking
TI's AM62x EVM as an example.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

arm: mach-k3: enable support for falcon mode

With CONFIG_SPL_OS_BOOT enabled, U-Boot checks for the return value of
spl_start_uboot to select between falcon or the regular boot flow. Where
a return value of 0 means 'boot to linux'.

This patch overrides the weak definition form common/spl/spl.c to allow
K3 devices to use falcon mode with SPL_OS_BOOT_SECURE enabled for the
A-Core SPL.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

board: ti: common: Kconfig: add CMD_SPL

Add CMD_SPL to list of configs implied by TI_COMMON_CMD_OPTIONS. This
allows the use of 'spl export'[1] command for preparing a device-tree
for falcon boot.

[1]:
https://docs.u-boot.org/en/v2025.10/develop/falcon.html#using-spl-command

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: Kconfig: allow falcon mode for TI secure devices

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 <anshuld@ti.com>

Merge patch series "Remove usage of CMD_BOOTx from SPL code"

Anshul Dalal <anshuld@ti.com> 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/20251027-fix_cmd_bootx-v10-0-10487e907710@ti.com

configs: disable SPL_BOOTZ to preserve spl size

In the existing behaviour, CMD_BOOTZ is not enabled by default which
means zimage.o is not compiled in the SPL in falcon mode unless
explicitly enabled. This changes now as SPL_BOOTZ is default y for
falcon users which leads to larger SPL size with zimage.o being present.

This patch modifies the defconfigs that used falcon mode but don't
require zimage support.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: remove usage of CMD_BOOTx from image parsing

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>

Merge patch series "Convert extension support to UCLASS and adds its support to boot flows"

Kory Maincent (TI.com) <kory.maincent@bootlin.com> 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

boot: bootmeth_efi: Add extension board devicetree overlay support

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) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boot: bootmeth_efi: Refactor distro_efi_try_bootflow_files return logic

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) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boot: pxe_utils: Add extension board devicetree overlay support

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) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boot: extension: Move overlay apply custom logic to command level

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) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boot: Remove legacy extension board support

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) <kory.maincent@bootlin.com>

board: compulab: Convert imx8mm-cl-iot-gate to UCLASS extension framework

Migrate CompuLab imx8mm-cl-iot-gate board extension detection from legacy
implementation to the new UCLASS-based extension board framework.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

board: sandbox: Convert extension support to UCLASS framework

Migrate sandbox extension board detection from legacy implementation to
the new UCLASS-based extension board framework.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: sandbox: Improve extension board scan implementation

Enhance the extension board scanning code in sandbox with better error
handling and code organization.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: sunxi: Convert extension support to UCLASS framework

Migrate sunxi board extension detection from legacy implementation to
the new UCLASS-based extension board framework.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

board: sunxi: Refactor CHIP board extension code

Clean up and improve code structure in the sunxi CHIP board extension
detection implementation.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

board: ti: Convert cape detection to use UCLASS framework

Migrate TI board cape detection from legacy extension support to the
new UCLASS-based extension board framework.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

board: ti: Refactor cape detection code for readability

Clean up and reorganize cape detection code structure for improved
maintainability and readability.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

boot: Add UCLASS support for extension boards

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) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boot: Move extension board support from cmd/ to boot/

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) <kory.maincent@bootlin.com>

include: extension_board: Document the extension structure

Add documentation to describe the extension structure.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

board: compulab: Exclude compulab extension board detection from XPL builds

Disable compulab extension board detection functionality in XPL (eXtended
Program Loader) images to reduce size and complexity in the early boot
stage.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

board: sunxi: Exclude DIP detection from XPL builds

Disable DIP detection functionality in XPL (eXtended Program Loader)
images to reduce size and complexity in the early boot stage.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

board: ti: Fix CAPE_EEPROM_BUS_NUM Kconfig dependency

The CAPE_EEPROM_BUS_NUM configuration option was incorrectly depending
on CMD_EXTENSION, which represents the extension board command. However,
the cape scan functionality can be built and used independently of the
command interface through the SUPPORT_EXTENSION_SCAN option.

Change the dependency from CMD_EXTENSION to SUPPORT_EXTENSION_SCAN to
properly reflect that the I2C bus configuration is needed for the cape
scan function itself, not specifically for the command.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

board: ti: Exclude cape detection from xPL builds

Disable cape detection functionality in xPL images to reduce size and
complexity in the early boot stage.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

MAINTAINERS: Add maintainer for extension board support

Add myself as maintainer for the extension board support that was
originally added to track ongoing development and maintenance.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

Merge tag 'u-boot-rockchip-20251101' of https://source.denx.de/u-boot/custodians/u-boot-rockchip

CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/28119
- New Boards support:
    rk3588: MNT Reform2
    rk3528: Radxa ROCK 2A/2F
    rk3576: ArmSoM Sige1, Luckfox Omni3576, FriendlyElec NanoPi M5,
            Radxa ROCK 4D
    rk3568: Lunzn FastRhino R66S
- Other board level updates.

mmc: rockchip_sdhci: Set xx_TAP_VALUE for RK3528

eMMC erase and write support on RK3528 is somewhat unreliable, sometime
e.g. mmc erase and write commands will fail with an error.

Use the delay line lock value for half card clock cycle, DLL_LOCK_VALUE,
to set a manual xx_TAP_VALUE to fix the unreliable eMMC support.

This is only enabled for RK3528, remaining SoCs still use the automatic
tap value, (DLL_LOCK_VALUE * 2) % 256, same value we configure manually
for RK3528.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: Ensure env in SPI Flash can work correctly

Ensure that the spi/sfc node for SPI flash is aviliable during pre-reloc
phase so that env can successfully be loaded from SPI Flash.

No boards with these SoCs seem to be affected as there is no default use
of ENV_IS_IN_SPI_FLASH=y.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: spl-boot-order: Defer probe of boot device

Boot devices are being probed when SPL boot order is determined. This
may delay boot slightly and can prevent booting from SPI Flash on boards
that use same pins for SPI Flash and eMMC due to pinctrl being applied
prior to booting.

Instead defer probe of the boot device until SPL try to load image from
the boot device by using uclass_find_device_by_of_offset() instead of
the get variant.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>

board: rockchip: Add support for rk3588 MNT Reform2

Add support for MNT Reform2, it works as a carrier board
with a Firefly iCore-3588Q SoM.

Specification:
- Rockchip RK3588
- LPDDR5X 16/32 GB
- eMMC 128/256 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for Wireless connection
- PCIE M.2 M Key for NVME connection
- DSI to eDP panel
- 1Gb Ethernet w/ Microchip KSZ9310 PHY

Tested using Fedora boot on USB stick and eMMC.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: add Lunzn FastRhino R66S

Lunzn Fastrhino R66S is a high-performance mini router.

Specification:
- Rockchip RK3568
- 1/2GB LPDDR4 RAM
- SD card slot
- 2x USB 3.0 Port
- 2x 2500 Base-T (PCIe, r8125b)
- 12v DC Jack

Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: Fix RG353M model renaming

Anbernic RG353M is hardware compatible with RG353P. Only the form-factor
differs. So only one DTS is created for both machines with
"Anbernic RG353P" as default model. If a RG353M is detected, the model
should be overwritten with the correct name.
Actually, it's overwritten with "Anbernic" only making the process of
machine detection a little harder.
However, to determine the size of the string "Anbernic RG353M", it is
sizeof() which is used resulting in obtaining the size of the pointer
(which is 8 bytes on ARM64) not the size of the pointed string.
strlen() should be used instead.

Signed-off-by: David Barbion <davidb@230ruedubac.fr>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: imply most symbols for ARCH_ROCKCHIP

Forcing all those symbols on means we cannot make the binary smaller or
with unnecessary features or drivers disabled. This is especially useful
for security, auditing and certification where less code built means
less to look at (and less surface attack) and less to patch, but also
for making binary images smaller which typically means faster boot.

It is possible to have boards without MMC, NAND or SPI flashes, without
anything on SPI or I2C buses, nothing to control over PWM or GPIO or for
which we have no interest in regulator control or serial output so make
it possible to remove all that if desired.

No intended change in default selected symbols.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

binman: btool: mkimage: fix Bintoolmkimage.run() method docstring

Commit 65e2c14d5a5a ("binman: btool: mkimage: use Bintool.version")
removed the version argument from the run method but forgot to remove it
from the method docstring, so let's fix this oversight.

Fixes: 65e2c14d5a5a ("binman: btool: mkimage: use Bintool.version")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: spl_common: fix TIMER_FMODE constant

The free running mode is 0 at bit offset 1. User mode is 1 at bit offset
1. Currently, free running mode is 1 at offset 0, which is already the
case thanks to TIME_EN.

So, this essentially does not change the actual value written to the
register as it is TIME_EN | TIMER_FMODE which currently is 0x1 | BIT(0)
= 0b1, and will become 0x1 | (0 << 1) = 0b1.

I checked PX30, RK3128, RK3188, RK3228, RK3288, RK3308, RK3328, RK3368
RK3506, RK3562 and RK3568 TRMs.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3399: fix TIMER_FMODE constant

The free running mode is 0 at bit offset 1. User mode is 1 at bit offset
1. Currently, free running mode is 1 at offset 0, which is already the
case thanks to TIME_EN.

So, this essentially does not change the actual value written to the
register as it is TIME_EN | TIMER_FMODE which currently is 0x1 | BIT(0)
= 0b1, and will become 0x1 | (0 << 1) = 0b1.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3036: use rockchip_stimer_init from spl_common.o

The only difference with the implementation in spl_common.c is that we
check whether the timer has already been enabled. Considering this is
running in SPL, the first stage on RK3036, I feel like it's guaranteed
to not be enabled by default. No public TRM though and I don't have
access to an RK3036 device so take this as a guess.

Size of SPL binary increases by 8B for evb-rk3036.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: px30: use rockchip_stimer_init from spl_common.o for TPL

Instead of redefining what is essentially the same code in
secure_timer_init, let's simply use rockchip_stimer_init from
spl_common.o instead.

This increases the size of the TPL by 16B, due to the added check of
STIMER already being enabled. Experimentally, STIMER is not already
enabled when in TPL.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: Add ArmSoM Sige1

The Sige1 is a single board computer developed by ArmSoM, based on the
Rockchip RK3528A SoC.

Add support for the ArmSoM Sige1 board.

Features tested on a ArmSoM Sige1 v1.1:
- SD-card boot
- eMMC boot
- Ethernet
- USB host (with pending DT changes)

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add ArmSoM Sige1

The Sige1 is a single board computer developed by ArmSoM, based on the
Rockchip RK3528A SoC.

Add initial device tree for the ArmSoM Sige1 board.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250717103720.2853031-5-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 1c6b12ef9575bc18dad2393e50ca1ebf96f0a0c8 ]

(cherry picked from commit 3ba04aa78ba71faab4a339f5ab15bc81a3e0a51b)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>