common: memtop: Update the MEM_RGN_COUNT macro to 64
Crashes are occurring due to the number of reserved memory regions
exceeding the current maximum limit of 16. It is recommended to
increase the supported number of memory regions to 64, as newer
platforms may utilize more reserved regions.
Padmarao Begari [Wed, 19 Nov 2025 08:50:23 +0000 (09:50 +0100)]
board: xilinx: Retry FRU EEPROM read on timeout
Wrap the dm_i2c_read() call is used for FRU EEPROM reads in a
retry loop, attempting up to EEPROM_FRU_READ_RETRY times if a
-ETIMEDOUT error is returned. The loop exits immediately on
success or any error other than -ETIMEDOUT. This improves
robustness against transient I2C timeouts during FRU detection
and decoding.
GEMs are using mdio node that's why don't need cells description in the
node.
SPIs should be using partitions subnode that's why don't need to have
cells description in the node
Also no need to specify cells in DT overlay root node when there is no
child which needs it.
Michal Simek [Mon, 10 Nov 2025 15:19:56 +0000 (16:19 +0100)]
spi: cadence: Remove cdns,is-dma DT property
cdns,is-dma is not documented property that's why setup CQSPI_DMA_MODE
quirk to enable DMA mode based on compatible string. And also change
compatible string for mini configurations also with recording compatible
string in the driver (Compatible string is already the part of existing DT
binding).
Michal Simek [Mon, 10 Nov 2025 15:24:13 +0000 (16:24 +0100)]
clk: versal: Enable clock driver for Versal Gen 2
Versal Gen 2 is using enhancement SMC format but in near future SCMI client
should be used. This patch is just bridging this gap till SCMI server is
fully tested.
Michal Simek [Mon, 10 Nov 2025 12:33:32 +0000 (13:33 +0100)]
clk: versal: Add support for CLK_AUTO_ID
When CLK_AUTO_ID is enabled 8 higher bits of clk->id is unique clock
identifier in clk uclass that's why it is necessary to mask lower bits
which are clock ID.
Also check that ID not bigger then maximum supported clock.
Michal Simek [Fri, 7 Nov 2025 10:28:49 +0000 (11:28 +0100)]
clk: versal: Use __data macro for moving variable to data section
The commit 1b267fe1824e ("firmware: xilinx: Prepare code for new SMC
firmware format") introduce new __data macro that's why use it in clock
driver too.
Padmarao Begari [Tue, 4 Nov 2025 12:57:25 +0000 (18:27 +0530)]
board: xilinx: Update ESRT after copying GUID
The EFI System Resource Table (ESRT) is updated after the firmware
image GUID is copied to the fw_images structure. This ensures that
the ESRT accurately reflects the current firmware resources.
Marek Vasut [Wed, 17 Dec 2025 19:57:38 +0000 (20:57 +0100)]
cmd: nvedit: Validate argument count before use
Avoid NULL pointer dereference in case 'env select' is invoked
without parameters, check the arg count and make sure it is at
least 2, otherwise print usage.
The crash is easy to trigger e.g. in sandbox:
$ ./u-boot -Tc "env select"
Fixes: a97d22ebba23 ("cmd: env: add env select command") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Andrew Goodbody [Fri, 5 Dec 2025 17:28:36 +0000 (17:28 +0000)]
net: lwip: tftp: Fix filename handling
The code to choose the filename to use does not cope with no name set at
all. Firstly the test for a name in net_boot_file_name tests the pointer
rather than the string it points to. Secondly the cleanup on exit in
this case attempts to free a global variable. Fix both issues.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Tom Rini [Thu, 18 Dec 2025 14:06:10 +0000 (08:06 -0600)]
Merge tag 'u-boot-socfpga-next-20251217' of https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
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.
*
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
Jan Kiszka [Thu, 11 Dec 2025 16:36:28 +0000 (17:36 +0100)]
configs: socfpga: Permit EFI booting
Commit f369e1564cf4 turned those off because the SPL size grew too
large. It also argued that those boards would never support EFI booting.
The former is correct, therefore keep CONFIG_SPL_EFI_PARTITION off.
CONFIG_SPL_ISO_PARTITION is default off. What is not correct is that
those boards are limited to legacy boot - you just need a hybrid
partition table to make both the bootrom and UEFI happy.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Jan Kiszka [Thu, 11 Dec 2025 16:34:59 +0000 (17:34 +0100)]
configs: socfpga: Fix de0_nano_soc boot
By default, the de0_nano_soc used raw sectors, but the address became
invalid due the raw-mode refactorings. With loading via partition type
fixed, we can switch to that mode which is in line with what the ROM
loader does.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Jan Kiszka [Thu, 11 Dec 2025 16:34:58 +0000 (17:34 +0100)]
arch: arm: mach-socfpga: Adjust a raw sectors for MMC loading of U-Boot from SPL
If U-Boot is located on MMC, SPL and U-Boot proper are glued together.
More precisely, SPL is stored 4 times. Take this and its padding into
account and adjust sector number via board_spl_mmc_get_uboot_raw_sector.
This allows loading from a partition, without the need to hard-code the
offset via SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Jan Kiszka [Thu, 11 Dec 2025 16:34:57 +0000 (17:34 +0100)]
spl: mmc: Respect sector value passed to mmc_load_image_raw_partition
This function and the sector parameter evolved over the time. By now,
sector is influenced by spl_mmc_get_uboot_raw_sector which allows to
adjust the read sector with an offset that U-Boot proper may have inside
the partition. That used to work by chance if both
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION were enabled. Since 2a00d73d081a they are a choice, and we need to drop the condition to
maintain this feature.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Jan Kiszka [Thu, 11 Dec 2025 16:34:56 +0000 (17:34 +0100)]
spl: mmc: Account for SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE being a choice
Add SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE as condition where so
far SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION was enough - though often
by chance as both options were enabled.
Reorder the #ifdef blocks at this chance to follow the order in the
Kconfig menu.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Jan Kiszka [Thu, 11 Dec 2025 16:34:55 +0000 (17:34 +0100)]
spl: Kconfig: Add missing SPL_LOAD_BLOCK for SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
We need to explicitly select SPL_LOAD_BLOCK when USE_PARTITION_TYPE is
enabled, just like the other choices do.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
mkeficapsule tool will be built by default if EFI_LOADER is set due to
commit b7a625b1ce49 ("tools: Build mkeficapsule tool by default if
EFI_LOADER is set").
This will cause compilation error on all our SoCFPGA devices, hence we will
be disabling this config as we do not utilize this tool.
Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Tanmay Kathpalia [Mon, 15 Dec 2025 11:01:17 +0000 (03:01 -0800)]
arm: dts: socfpga: agilex5: Add dedicated eMMC device tree support
Add dedicated device tree support for eMMC configuration on the Agilex5
SoCDK board, providing an alternative to the default SD card setup.
Changes to socfpga_agilex5.dtsi:
-
- Configure always-on regulator for stable eMMC operation
New device tree files:
- socfpga_agilex5_socdk_emmc.dts: Main eMMC device tree configuration
* Configure for eMMC operation (no-sd, no-sdio, non-removable)
* Set 8-bit bus width and high speed capability
* Add timing parameters for legacy and SDR modes
* Configure voltage supplies for eMMC power and I/O
* Add fixed 1.8V regulator for eMMC I/O voltage supply
- socfpga_agilex5_socdk_emmc-u-boot.dtsi: U-Boot specific additions
* Include common Agilex5 U-Boot configurations
* Set SPL boot order with eMMC support
* Enable necessary peripherals for boot-time operation
Configuration files:
- configs/socfpga_agilex5_emmc_defconfig: eMMC-specific configuration
* Inherit from base Agilex5 configuration
* Disable GPIO regulator support (not needed for fixed eMMC setup)
* Set eMMC-specific device tree
Build system integration:
- Add socfpga_agilex5_socdk_emmc.dtb target to Makefile
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Tanmay Kathpalia [Mon, 15 Dec 2025 11:01:16 +0000 (03:01 -0800)]
configs: socfpga_agilex5: Enable MMC and Cadence SDHCI support
Enable MMC support with Cadence SDHCI controller for both SPL and
U-Boot proper on Agilex5 platform to support SD card operations in
legacy and high speed timing modes.
MMC controller configuration:
- Enable MMC subsystem (CONFIG_MMC=y, CONFIG_DM_MMC=y)
- Add Cadence SDHCI controller support (CONFIG_MMC_SDHCI_CADENCE=y)
- Enable SDHCI with ADMA support for better performance
- Add MMC command support for user interaction
SPL configuration:
- Enable MMC support in SPL (CONFIG_SPL_DM_MMC=y)
- Add SDHCI ADMA support in SPL (CONFIG_SPL_MMC_SDHCI_ADMA=y)
- Enable GPIO support in SPL (CONFIG_SPL_DWAPB_GPIO=y)
Voltage regulator support:
- Add device model regulator framework (CONFIG_DM_REGULATOR=y)
- Enable fixed voltage regulator support for card power
- Add GPIO-controlled regulator for I/O voltage switching
- Include regulator support in SPL for early initialization
These changes enable SD card functionality with legacy and high speed
timing modes, providing proper voltage regulation and GPIO control
for the Agilex5 SoCDK platform.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Tanmay Kathpalia [Mon, 15 Dec 2025 11:01:15 +0000 (03:01 -0800)]
arm: dts: socfpga: agilex5: Upgrade SDHCI controller from SD4HC to SD6HC
Upgrade the SDHCI Cadence controller from SD4HC to SD6HC for Agilex5
platform to support the newer controller version with enhanced features.
Key changes:
- Remove combophy0 node and associated references as SD6HC doesn't require
separate PHY configuration node
- Upgrade MMC controller compatible from "cdns,sd4hc" to "cdns,sd6hc"
- Add Agilex5-specific compatible string "altr,agilex5-sd6hc" for
platform-specific optimizations
Hardware configuration updates:
- Add voltage regulator support:
* sd_emmc_power: Fixed 3.3V regulator for card power supply
* sd_io_1v8_reg: GPIO-controlled regulator for 1.8V/3.3V I/O switching
- Configure proper reset control with named resets including combophy
reset
- Add GPIO control via portb pin 3 for voltage switching
SD card operation:
- Configure for SD card specific operation (no-mmc, cap-sd-highspeed)
- Set maximum frequency to 200MHz
- Configure timing parameters for SD modes:
* Default Speed (DS) and UHS-I SDR12 mode timing:
* High Speed and UHS-I SDR25 mode timing:
- Add PHY timing delays for optimal signal integrity
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Tanmay Kathpalia [Mon, 15 Dec 2025 11:01:14 +0000 (03:01 -0800)]
Revert "arch: arm: dts: agilex5: Set SDIO_SEL GPIO pin as output"
Remove GPIO hog configuration for SDIO_SEL pin as it is now handled
through the voltage regulator framework for SD ultra high speed mode
support. The GPIO pin 3 on portb controller is used to control the
level shifter for SD card I/O voltage switching.
The regulator-based approach provides proper voltage switching control
for UHS-I modes (SDR50, SDR104) while maintaining compatibility with
the MMC subsystem's voltage switching protocols.
Enable CONFIG_NET_RANDOM_ETHADDR to allow U-Boot to assign a random MAC
address during Ethernet initialization when a valid MAC is not programmed
in hardware.
This avoids network initialization failures and MAC address conflicts,
especially on boards used for development or shipped without a
factory-programmed MAC.
Signed-off-by: Tien Fong Chee <tien.fong.chee@altera.com> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Tom Rini [Tue, 16 Dec 2025 17:40:54 +0000 (11:40 -0600)]
Merge patch series "fit: print conf node compatibles + use property string constants"
Quentin Schulz <foss+uboot@0leil.net> says:
This does a bit of "cleanup" by reusing constants for some FIT
properties instead of having the same string in multiple places.
Additionally, this adds a new constant for the compatible property in
FIT configuration nodes[1] which is useful for FIT images with multiple
FIT configuration nodes to support multiple devices in the same blob.
U-Boot will try to figure out which node to select based on that
compatible[2].
However, if this property is missing (and the first blob in the fdt
property of the configuration node is uncompressed), the compatible from
the root node of the associated kernel FDT will be used for the
autoselection mechanism. For now, I only print the property if it
exists, but maybe it'd make sense to expose the fallback one if it's
missing. I guess we can implement that later on if desired.
Quentin Schulz [Wed, 3 Dec 2025 16:19:35 +0000 (17:19 +0100)]
boot/fit: print all configuration node compatibles
Fit conf node may have a compatible property[1] which stores the
compatible of the first blob in the fdt property of the node. This can
be used to automatically select the proper conf node based on the
compatible from the running U-Boot (matching the former's compatible
with the latter)[2].
This brings the ability to mkimage/dumpimage to print the compatibles of
the configuration node(s). U-Boot CLI commands such as iminfo also see
this addition to their output.
Quentin Schulz [Wed, 3 Dec 2025 16:19:34 +0000 (17:19 +0100)]
boot/fit: declare (and use) new constant for conf's compatible prop
Fit conf node may have a compatible property[1] which stores the root
compatible of the first blob in the fdt property of the node. This can
be used to automatically select the proper conf node based on the
compatible from the running U-Boot (matching the former's compatible
with the latter)[2].
This adds (and uses) this constant for FIT node parsing.
Note that this property may also appear in fpga image nodes[3] but that
isn't done in this commit.
Quentin Schulz [Wed, 3 Dec 2025 16:19:33 +0000 (17:19 +0100)]
lib: rsa: use FIT_ALGO_PROP constant instead of "algo" in FIT
Some FIT image properties have their string represented in
include/image.h via constants. FIT_ALGO_PROP does exist and would fit the
bill so let's use it instead of using a hardcoded string.
Quentin Schulz [Wed, 19 Nov 2025 17:27:27 +0000 (18:27 +0100)]
board: BuS: remove support for BOOT LED
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.
Add initial support for the Toradex Aquila AM69 module.
The Aquila AM69 SoM is based on the TI AM69 SoC from the Jacinto 7
family and is designed for high-end embedded computing, featuring up to
32GB of LPDDR4 and 256GB eMMC storage, extensive multimedia support (3x
Quad CSI, 2x Quad DSI, DisplayPort, 5x Audio I2S/TDM), six Ethernet
interfaces (1x 1G, 4x 2.5G SGMII, 1x 10G), USB 3.2 Host/DRD support, and
a Wi-Fi 7/BT 5.3 module, alongside an RX8130 RTC, I2C EEPROM and
Temperature Sensor, and optional TPM 2.0 module.
Anshul Dalal [Thu, 4 Dec 2025 11:11:55 +0000 (16:41 +0530)]
ti: k3: abstract common fdt api for reserved mem fixups
The usage of fdt_fixup_reserved is repeated for ATF and OP-TEE for
multiple platforms, this patch creates a single fdt API for fixing up
the reserved-memory node with added error handling.
All k3 platforms already share a common tispl template which ensures
binaries are loaded as per the respective CONFIG_*_LOAD_ADDR. And the
provided new_size for the fixup is overridden by the size from fdt node
anyways. This allows for safe abstraction of the reserved memory fixups
for all current platforms.
fdt_fixup_reserved now abstracts the ATF and OP-TEE fixups by calling
the renamed static fdt_fixup_reserved_memory function with the required
parameters.
Jonathan GUILLOT [Thu, 11 Dec 2025 21:20:39 +0000 (22:20 +0100)]
cmd: part: Fix part argument description for `part number`
Signed-off-by: Jonathan GUILLOT <jonathan@joggee.fr> Fixes: ff6ef4b9093f ("doc: man-page for the part command") Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Max Merchel [Tue, 26 Aug 2025 06:30:29 +0000 (08:30 +0200)]
tools/libfdt/fdt_rw: fix SPDX-License-Identifier
Currently, the terms of both licenses (GPL 2.0 and BSD-2-Clause) must be
met.
However, before switching to the SPDX license identifier, the license
information in the file begins with:
"libfdt is dual licensed: you can use it either under the terms of
the GPL, or the BSD license, at your option."
Therefore, the missing "OR" between the licenses is added.
Fixes: 3508476 ("libfdt: SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause") Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>
Quentin Schulz [Wed, 12 Nov 2025 14:58:00 +0000 (15:58 +0100)]
rockchip: mkimage: enhance comments for v1 header
Improve the image header documentation for v1 header:
- specify this applies to all MMC, not only SD cards,
- specify the offset for SPI flashes,
- specify the key used for RC4 encoding,
- specify what "init" refers to, especially since some configs enable
TPL,
- specify what "init_boot_size" refers to, especially since some configs
enable TPL,
- specify the size of a block,
- add documentation for init_size and init_boot_size,
Note that the offset on the storage medium isn't necessarily 32KiB (64
blocks) for MMC or 0 for SPI flashes, it's just the first offset the
BootROM checks. Barebox[1] lists a few options, though those are
applicable to RK35xx which use the v2 header, so not guaranteed they can
be shared. On RK3399, the binary can at least be stored at offset 0 and
32KiB on SPI flashes.
In the last message sent in rockchip_i2c_xfer, the controller is
disabled (see rk_i2c_disable() in rk_i2c_read()/rk_i2c_write()), then
the STOP condition is sent (see rk_i2c_send_stop_bit() in
rockchip_i2c_xfer()) and the controller is disabled once again (see
rk_i2c_disable() right after).
The issue is that re-enabling the controller just to send the STOP
condition doesn't work. When, the controller is disabled, the SCL and
SDA lanes are not driven anymore and thus enter the idle mode where they
are kept high by the external HW pull-up. To send a STOP condition, one
needs to drive the SDA line so that a rising edge happens while SCL is
high. Experimentally (on PX30 and RK3399), when enabling the controller
to send a STOP condition after it's been disabled, the controller only
drives the SDA line to trigger the rising edge for the STOP condition,
leaving SCL undriven (and thus, high). This means, that because SDA is
high before this happens and that we need a rising edge, the controller
drives the SDA line low and then releases it, meaning we trigger a START
condition followed by a STOP condition:
5. A START condition immediately followed by a STOP condition (void
message) is an illegal format. Many devices however are designed to
operate properly under this condition.
My guess is that the I2C controller IP knows that it makes only sense to
send a STOP condition after a START condition, meaning the controller is
already driving the SCL line low and neither the device nor controller
drive the SDA line after the last ACK/NACK as there's no need to, then
it needs to drive SDA, release SCL to make it high and then release the
SDA line. However, after it's been disabled, the SCL is already released
so the controller only essentially drives SDA and then releases it.
It happens that this seems to be breaking the SE050 Secure Element after
a few transfers in the middle of a transfer where it starts clock
stretching the bus forever. It may be related to Errata 3.2[2] but the
description of the setup isn't an exact match to the current situation.
It seems to be required to disable the I2C controller between messages
as the Linux kernel states that "The HW is actually not capable of
REPEATED START. But we can get the intended effect by resetting its
internal state and issuing an ordinary START.". Between messages, this
logic seems fine as I get an Sr (repeated START condition) before
starting the next message in the transfer without a STOP condition.
However, we should NOT disable the controller after the last message in
the transfer otherwise we do this illegal START condition followed by
the STOP condition, hence the added check.
[1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf 3.1.10 The target address and R/W bit point 5
[2] https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf
Fixes: c9fca5ec8849 ("rockchip: i2c: don't sent stop bit after each message") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Heiko Schocher <hs@nabladev.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Quentin Schulz [Fri, 7 Nov 2025 11:39:18 +0000 (12:39 +0100)]
rockchip: i2c: move ACK comment where it applies
The I2C_CON_LASTACK is kind of a misnomer as setting it means sending a
NACK as last byte acknowledge when the controller is in receive mode. It
should therefore be used only when there's no more data to transfer
after this.
Move the comment in the proper if block.
Sync the comment with the Linux kernel's while at it so it's more
explicit.
Quentin Schulz [Fri, 7 Nov 2025 11:39:17 +0000 (12:39 +0100)]
rockchip: i2c: fix incorrect STOP flag for the interrupt enable register
I2C_CON_STOP is a flag to be used for the con register, where it is bit
4 to send the STOP condition.
To enable the interrupt the controller sends to tell it's finished
sending the STOP condition, it's the ien register at bit 5.
Let's use the proper offset.
My hunch is that enabling the interrupt is useless as the interrupt
status register is always up-to-date and enabling the interrupt is just
so that the interrupt is available via the GIC. However, U-Boot has no
interrupt support and the logic was working well before this patch. This
is just so people aren't side-tracked when debugging I2C issues on
Rockchip by checking all writes are proper.
FUKAUMI Naoki [Fri, 7 Nov 2025 06:47:16 +0000 (06:47 +0000)]
rockchip: rock5b-rk3588: Add support for Radxa ROCK 5T
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>
Jonas Karlman [Fri, 1 Aug 2025 17:09:28 +0000 (17:09 +0000)]
rockchip: rock5b-rk3588: Add support for ROCK 5B+
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>
Jonas Karlman [Sat, 2 Aug 2025 22:07:23 +0000 (22:07 +0000)]
rockchip: Add support for RAM boot from maskrom mode
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.:
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>
When one attempts to build Tiger and Jaguar from the same directory,
because Tiger will set the IOMUX to 2 but Jaguar doesn't reset it,
Jaguar will have IOMUX set to 2 if built after Tiger.
This isn't an issue if in separate directories or building Tiger after
Jaguar because the default if missing from the configuration file is 0.
Let's make it explicit that the iomux is 0 for Jaguar.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
board: theobroma-systems: add instructions for how to use upstream TF-A
Upstream TF-A has support for RK3588 since v2.12 so let's document how
to use upstream TF-A instead of the prebuilt binary blob from Rockchip
if one wants to do that.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
board: theobroma-systems: update instructions for newer Rockchip rkbin
The instructions are regularly out of date because the generated or
prebuilt binaries are updated and the filename doesn't match our
instructions anymore.
Additionally, since commit 55a95caaef15 ("tools: ddrbin_tool: add
ddrbin_tool.py and update to v1.21 20241211") end of October 2024,
ddrbin_tool doesn't exist anymore and has been replaced by
ddrbin_tool.py python script (which currently isn't an executable) so
let's update these instructions as well.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tom Rini [Fri, 12 Dec 2025 21:19:41 +0000 (15:19 -0600)]
Merge patch series "clk: ti: Cleanup common functions and omap-cm"
Markus Schneider-Pargmann (TI.com) <msp@baylibre.com> says:
This series cleans up the direct dependency of ARCH_OMAP2PLUS to compile
ti/clk.c which holds common functions for other clock drivers. It creates its
own config symbols for these common functions and for the omap-cm driver as
well.
The omap-cm driver config symbol is added as default enabled.
clk: ti: Split common omap2plus functions into new symbol
Create a new symbol for the common clock functions used by some of the
omap2plus clock drivers. These drivers now select this new symbol when
they need the functions. Note these common functions are not
ARCH_OMAP2PLUS specific.
Note that the common functions are using regmap, so select it here.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
Upstream DT uses simple-pm-bus instead of simple-bus. simple-pm-bus
requires power domain support. On am33xx, PRM manages power domains but
all domains are enabled at boot. Add stub driver with custom of_xlate
that expects no argumetns to allow simple-pm-bus and dependent devices
to probe.
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
Tom Rini [Tue, 9 Dec 2025 21:23:01 +0000 (15:23 -0600)]
fs: fat: Perform sanity checks on getsize in get_fatent()
We do not perform a check on the value of getsize in get_fatent to
ensure that it will fit within the allocated buffer. For safety sake,
add a check now and if the value exceeds FATBUFBLOCKS use that value
instead. While not currently actively exploitable, it was in the past so
adding this check is worthwhile.
This addresses CVE-2025-24857 and was originally reported by Harvey
Phillips of Amazon Element55.
Tom Rini [Fri, 12 Dec 2025 01:19:06 +0000 (19:19 -0600)]
Revert "clk: Return value calculated by ERR_PTR"
While this change was intended to fix a mistake in the code, of calling
the ERR_PTR macro but not making use of the result, it seems that
functionally platforms depend on the loop not existing here. The TI K3
families of platforms for example were broken by this commit.
Ferass El Hafidi [Thu, 11 Dec 2025 15:37:00 +0000 (15:37 +0000)]
arm: meson: add support for EFI capsule updates
Previously, few Amlogic devices supported EFI capsule updates.
Generally only the Libre Computer ones with SPI flash supported it,
thanks to board-specific code.
This commit commonises capsule update support across supported
Amlogic boards. Similar to Qualcomm's support for it, the dfu string
and firmware name is automatically generated at runtime depending on
which device we are booted from. Right now this supports flashing to
the eMMC/SD and SPI flash.
As usual, the capsule UUID is automatically generated. You can get it
by enabling CONFIG_CMD_EFIDEBUG and running:
mmc: sdhci-cadence6: Add DLL master control and improve tuning reliability
- Add support for configuring the PHY DLL master control register for all
SD/eMMC timing modes (DS, HS, SDR, DDR, HS200, HS400) by extending the
PHY configuration arrays and writing the value during PHY adjustment.
- Fix tuning reliability by toggling the DLL reset before and after
updating the PHY_DLL_SLAVE_CTRL_REG_ADDR register.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
1. Replace underscores with hyphens in device tree property names to
follow the standard DT naming convention. This affects all
"lpbk_ctrl" properties which are now correctly named "lpbk-ctrl".
mmc: sdhci-cadence: Enable software tuning for both SD and eMMC interfaces
Remove interface type restrictions in sdhci_cdns_execute_tuning() to
enable software tuning for both SD and eMMC devices. The previous
assumption that SD timing should be handled by SDHCI core is incorrect
based on the actual function assignment logic.
The execute_tuning function is assigned based on MMC_SUPPORTS_TUNING
config, which is enabled by both MMC_UHS_SUPPORT and MMC_HS200_SUPPORT.
Changes:
Remove IS_MMC() check that restricted tuning to eMMC only
Remove opcode validation limited to MMC_CMD_SEND_TUNING_BLOCK_HS200
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
mmc: sdhci-cadence: Use hardware version field for Cadence SDHCI controller
Replace device tree compatible string checks with hardware version field
detection to determine SDHCI controller capabilities. This approach is
more robust and aligns with standard SDHCI specification practices.
Controllers with SDHCI version 4.2 and above will automatically use the
enhanced PHY adjustment, and tuning v6-specific procedures.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
mmc: sdhci: Add SDHCI_SPEC_400, _410, and _420 version defines
Add SDHCI_SPEC_400, SDHCI_SPEC_410, and SDHCI_SPEC_420 macros to sdhci.h
to support newer SDHCI specification versions. These defines are required
for compatibility with controllers implementing SDHCI 4.0 and above.
mmc: sdhci-cadence: Set controller and PHY speed modes for SD and eMMC cards
Replace the legacy clock frequency-based timing mode selection with
proper MMC timing mode constants.
Changes to sdhci-cadence.c:
- Add sdhci_cdns_get_hrs06_mode() helper function for mode selection
- Replace clock frequency logic with mmc->selected_mode switch statement
- Use proper MMC timing constants (MMC_HS, UHS_SDR104, etc.)
- Add SD card specific handling with standard SDHCI control register setup
Changes to sdhci-cadence6.c:
- Add SD high speed PHY and control configuration arrays
- Update sdhci_cdns6_phy_adj() to use timing modes instead of HRS06 modes
- Support both SD and eMMC timing modes with appropriate PHY settings
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
mmc: sdhci-cadence: Use max-frequency property from device tree
When f_max parameter is 0 in sdhci_setup_cfg(), the function defaults
to using the maximum frequency from host controller capabilities register
instead of the max-frequency property parsed from device tree.
The max-frequency property from device tree is parsed by mmc_of_parse()
and stored in plat->cfg.f_max, but sdhci_setup_cfg() was being called
with f_max=0, causing it to ignore the device tree value and use the
host capabilities register value instead.
Fix this by passing plat->cfg.f_max to sdhci_setup_cfg() to ensure
the device tree specified maximum frequency is respected over the
hardware default.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
mmc: mmc-uclass: Use max-frequency from device tree with default handling
When the max-frequency property is not specified in the device tree,
the function now explicitly defaults to 0 instead of leaving cfg->f_max
uninitialized. This allows sdhci_setup_cfg() to properly detect the
absence of a device tree specified frequency and fall back to using
the host controller's maximum base clock frequency from the capabilities
register.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add reset control functionality to the SDHCI Cadence driver to properly
handle hardware reset sequences during probe. This ensures the controller
is in a known state before initialization.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
armv8/fsl-layerscape: fdt: Remove offline cores from cooling device maps
Some processor families use a generic device tree, and rely on u-boot
fixups to massage that for lower core count personalities (i.e. NXP
LX2* family). For example, the LX2160A device tree will be used and
then modified to offline non-existent cores when running on an 8-core
LX2080A.
However, the cooling maps still contain references to the non-existent
core phandles, resulting in:
OF: /thermal-zones/cluster6-7-thermal/cooling-maps/map0:
could not find phandle 15
Rebuild the cooling maps as non-existent cores are deleted.
Signed-off-by: Anthony Pighin <anthony.pighin@nokia.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
[Ferass: check digest type in _print_header, version in _verify_image] Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org> Link: https://patch.msgid.link/20251126-spl-gx-v5-1-6cbffb2451ca@postmarketos.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Tom Rini [Wed, 19 Nov 2025 14:55:30 +0000 (08:55 -0600)]
ls1043a: Stop disabling device tree relocation
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> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Wed, 19 Nov 2025 14:55:28 +0000 (08:55 -0600)]
ls1012afrdm: Stop disabling device tree relocation
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> Signed-off-by: Peng Fan <peng.fan@nxp.com>
binman: blob_dtb: improve error message when SPL is not found
When using binman with the '-a spl-dtb=y' flag, if the SPL blob is not
found, binman throws a cryptic error message:
binman: 'NoneType' object has no attribute 'startswith'
Let's improve the error message to explicitly state which SPL blob is
missing.
This is particularly useful when binman is used as a standalone tool
outside the U-Boot source tree.
Signed-off-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
[trini: Add '# pragma: no cover' because coverage doesn't seem to like
the documentation about this error] Signed-off-by: Tom Rini <trini@konsulko.com>
projects / thirdparty / u-boot.git / log
