Make environment support in SPI NOR available in sandbox,
so the environment storage in SPI NOR can be tested in CI.
Enable redundant environment support as well to cover this
in CI tests too.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add new PID4 to ConfigBlock handling:
- 0217 Lino iMX93 Dual 2GB IT
- 0218 Lino iMX91 Solo 2GB IT
- 0219 OSM iMX93 Dual 2GB IT
- 0220 OSM iMX91 Solo 2GB IT
- 0221 Verdin AM62 Dual 1GB ET
Lino and OSM are two new SoM families.
The Verdin variant differs from the existing 0073 Verdin AM62 Dual 1GB ET
by the presence of the GPU (AM625 instead of AM623), the absence of
DSI interface (bridge not mounted) and eMMC size increased to 16GB instead
of 4GB.
Link: https://www.toradex.com/computer-on-modules/lino-arm-family
Link: https://www.toradex.com/computer-on-modules/osm-arm-family
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Our last sync with the kernel was 5.1.
We are so out of sync now, that tracking the patches and backporting
them one by one makes little sense and it's going to take ages.
This is an attempt to sync up Makefiles to 6.1.
Unfortunately due to sheer amount of patches this is not easy to review,
but that's what we decided during a community call for the bump to 5.1,
so we are following the same guidelines here.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>a #rebased on -next
Change mt8365_evk_defconfig to use CONFIG_OF_UPSTREAM=y and delete the
U-Boot copy of the devicetree source files for mt8365.
The upstream devicetree is identical to the U-Boot one being removed
(other than having more nodes for devices not used by U-Boot and
upstream fixed a compatible string in &scpsys, also not affecting
U-Boot).
There was one minor glitch with upstream missing a few topckgen macro
definitions, so those are added to the clock driver directly as a
workaround.
Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Add board-specific environment variables to imx8ulp_evk.env for better
maintainability. Define bsp_bootcmd in the environment to resolve the
runtime error: "bsp_bootcmd" not defined.
Signed-off-by: Alice Guo <alice.guo@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
We are trying to get rid of the legacy LED API and this is one of the
last users.
As far as I understood from the code, only one LED is controllable and
it is a GPIO led. When initializing the LED, it is always enabled
regardless of the passed argument, same for the mask.
In addition, the LED is used as a BOOT LED.
To keep the same behavior, a GPIO driver should be written, then add a
gpio-leds node which makes use of a GPIO from said driver, add the
/options/u-boot/boot-led property pointing at this new GPIO LED node and
then enable CONFIG_LED as well as CONFIG_LED_BOOT. This should result in
the same behavior using the modern framework.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Include the FDT for Radxa ROCK 5T in the FIT, in addition to those for
5B and 5B+, and add board selection code to load the 5T FDT when the
DRAM type is LPDDR5 and ADC channel 5 value is close to 1016.
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Include FDTs for both ROCK 5B and 5B+ in the FIT and add board selection
code to load the 5B+ FDT when the DRAM type is LPDDR5 and ADC channel 5
value is close to 4095.
U-Boot 2025.07 (Jul 14 2025 - 21:28:20 +0000)
Model: Radxa ROCK 5B+
SoC: RK3588
DRAM: 8 GiB
Features tested on a ROCK 5B+ v1.2:
- SD-card boot
- eMMC boot
- SPI flash boot
- PCIe/NVMe
- Ethernet
- USB/TCPM
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The BootROM in Rockchip SoCs will enter maskrom mode when boot firmware
cannot be found in nand/spi/mmc storage.
In maskrom mode the USB OTG port can accept one of two custom commands.
Initially a 0x471 command to load TPL into SRAM. After TPL has been
executed and it has returned back-to-BROM, a 0x472 command to load SPL
into start of DRAM.
Add two binman images that can be used to RAM boot from maskrom mode:
- u-boot-rockchip-usb471.bin that contains TPL to init DRAM.
- u-boot-rockchip-usb472.bin that contains SPL and the normal FIT
payload with i.e. U-Boot proper, TF-A and FDT.
A config fragment rockchip-ramboot.config can be used to enable building
of these two binman images, e.g.:
make generic-rk3588_defconfig rockchip-ramboot.config
These binman images can be used with the proprietary rkbin boot_merger
tool to create a special loader image that can be used with tools such
as rkdeveloptool or rockusb tools to RAM boot from maskrom, e.g.:
Create loader image:
$ ../rkbin/tools/boot_merger ./RK3588MINIALL.ini
Boot from maskrom:
$ rkdeveloptool db u-boot-rockchip-rk3588-loader.bin
or
$ rockusb download-boot u-boot-rockchip-rk3588-loader.bin
Another option that does not require use of proprietary tools is using
open source tools such as rkflashtool or rkusbboot that can load the
binman images directly without any need to first create a special loader
image to RAM boot from maskrom, e.g.:
$ rkflashtool l < u-boot-rockchip-usb471.bin
$ rkflashtool L < u-boot-rockchip-usb472.bin
or
$ rkusbboot u-boot-rockchip-usb471.bin u-boot-rockchip-usb472.bin
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Arnaud Patard <arnaud.patard@collabora.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Commit c37a668481 ("stm32mp: fix compilation issue with DEBUG_UART")
split the debug UART initialization code into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
until debug UART is enabled, which is not the default. Update the
Makefile accordingly to allow debug UART to work.
Fixes: c37a668481 ("stm32mp: fix compilation issue with DEBUG_UART")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add DRAM settings for 1 GiB variant of DH STM32MP13xx DHCOR SoM
and support for SoM DRAM coding HW straps decoding and automatic
DRAM configuration selection. Enable CONFIG_BOARD_EARLY_INIT_F on
all STM32MP1 DHSOM, as it is required for the HW straps decoding.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
There are multiple boards that use the PolarFire SoC, so extract
the Kconfig sections that are determined at a CPU level from the board
Kconfigs now that we have a CPU Kconfig.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
PolarFire SoC needs a custom implementation of top_of_ram(), so stop
using the generic CPU & create a custom CPU instead.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
phyFLEX are SoMs based on the FPSC standard.
Add additional "SOM types" for the phyFLEX modules base on the
FPSC Gamma specification. These modules come in four different
variants; prototypes (PT), standard product (SP), KSP (KP) and
KSM (KM).
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Reviewed-by: Teresa Remmet <t.remmet@phytec.de>
Tested-by: Dominik Haller <d.haller@phytec.de>
Assign the return value of snprintf (total length) to a variable to
properly check if the string has the correct length.
Currently, this variable is always zero and the length check after
snprintf will always fail.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Set boot_targets environment variable dynamically, so that when booting
from SD-card, boot binaries are also preferably fetched from the SD-card
by default. If the user decides to set their own boot_targets, we should
not overwrite them.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Enable standard boot for the phyCORE-i.MX93 board and use it as a new
default. Add required standard boot variables to the environment, while
removing old boot scripts and now unnecessary environment variables.
Adjust variables according to the requirements of PHYTEC ampliphy-boot
distro-boot. Last but not least, order environment vars by alphabet and
run 'make savedefconfig' to resync defconfig.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
I am moving over to using my email address at kernel.org.
Change this in all the affected MAINTAINERS files.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Otherwise the custom-cape eeprom (at address 57) reports NACK which
results into "i2c_write: error waiting for data ACK (status=0x116)" and
terminates further scanning.
Signed-off-by: Marian Cingel <cingel.marian@gmail.com>
red_led_on is either called from the legacy LED shell command (which is
disabled for corvus) or from arm-specific assembly code right before
jumping into board_init_r() in U-Boot proper.
Let's migrate to use the more modern LED subsystem by migrating to DM.
The default-state is set to on to mimic red_led_on() from the
arm-specific assembly code as a missing default-state FDT property
currently means the LED is not probed except if explicitly done via the
led shell command. Note though that this is running much later in the
boot process, once DM is started.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
green_led_on and green_led_off are only called by the legacy LED command
(CONFIG_LED_STATUS_CMD) when CONFIG_LED_STATUS_GREEN is enabled, both of
which aren't enabled for corvus, so let's simply remove it as it's dead
code.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Remove get_led() and setup_led() which became obsolete since
led_boot_on() introduction. led_boot_on() is automatically called
from board_r.c
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Remove get_led() and setup_led() which became obsolete since
led_boot_on() introduction. led_boot_on() is automatically called
from board_r.c
Regarding "u-boot,error-led" property can't be used anymore since commit
Since commit 516a13e8db32 ("led: update LED boot/activity to new property implementation")
Instead get the LED labeled "red:status".
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Commit c37a668481 ("stm32mp: fix compilation issue with DEBUG_UART")
split the debug UART initialization code into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
until debug UART is enabled, which is not the default. Update the
Makefile accordingly to allow debug UART to work.
Fixes: c37a668481 ("stm32mp: fix compilation issue with DEBUG_UART")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add DRAM settings for 1 GiB variant of DH STM32MP13xx DHCOR SoM
and support for SoM DRAM coding HW straps decoding and automatic
DRAM configuration selection. Enable CONFIG_BOARD_EARLY_INIT_F on
all STM32MP1 DHSOM, as it is required for the HW straps decoding.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Signed-off-by: Tom Rini <trini@konsulko.com>
The MAINTAINERS files for B&R boards are not in sync
with the current file names. Update the files so
that they are correct again.
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
B&R Industrial Automation has been acquired by ABB in 2017, and this
will be reflected in our email addresses beginning from December 2025.
The email addresses change as follows:
@br-automation.com -> @<country-code>.abb.com
The existing email addresses will be valid until December 2026.
Add entries for Bernhard Messerklinger and myself to .mailmap, and
update the MAINTAINERS files.
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@at.abb.com>
Quentin Schulz <foss+uboot@0leil.net> says:
u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).
For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.
For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.
The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/94ed1988-13e8-4fe3-bdff-ba2c9973c556@foss.st.com/
and
https://lore.kernel.org/u-boot/2a3aa43a-ce19-41e1-ab56-556629ce5cf9@foss.st.com/
After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?
The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.
In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.
The help text for the blink subcommand of the led command was misleading
so this is now fixed.
This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.
This also gets rid of dt-binding that we already have in dts/upstream.
Finally, this adds documentation for the led shell command.
[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116
Link: https://lore.kernel.org/r/20251112-led-old-dt-v1-0-2892d49517db@cherry.de
This board is one of the last users of /config/u-boot,boot-led property
which is a U-Boot property out of the DT spec.
Let's migrate it to use the in-spec /options/u-boot/boot-led property.
When enabling LED_BOOT, U-Boot proper will lit the LED right before
entering the main loop, so nothing needs to be done in board files.
As explained in the commit adding support for this u-boot,boot-led
property, let's keep backward compatibility in case LED_BOOT isn't
selected.
Note that this is not tested as I do not own this device.
Cc: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Alexander Dahl <ada@thorsis.com>
Add initial support for Renesas R-Car X5H R8A78000 Ironhide board.
This consists mainly of DTs, Makefile and Kconfig entries and board
specific configuration files.
The DTs will be gradually switched over to Linux DTs via OF_UPSTREAM
once Linux DTs become available upstream, as upstreaming progresses.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
