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>
Tom Rini [Wed, 12 Nov 2025 21:19:42 +0000 (15:19 -0600)]
fs/jffs2: Make depend on !64BIT
Building this code on 64bit platforms leads to warnings (and so errors
in CI). Rather than rework the code, as this is a deprecated filesystem,
don't try and disallow building on 64bit hosts.
Adriana Nicolae [Tue, 9 Dec 2025 15:55:38 +0000 (07:55 -0800)]
test: dm: fdtdec: Validate FDT size in unit test
The current FDT decoding tests calculate the memory required
for FDT manipulation by directly adding a fixed margin to
fdt_totalsize(gd->fdt_blob). The static analyzer flagged
"gd->fdt_blob->totalsize" as a tainted value being passed
to fdt_open_into().
Ensure the size is validated by checking that the total size
is within a reasonable maximum FDT limit for unit tests.
Signed-off-by: Adriana Nicolae <adriana@arista.com>
Beleswar Padhi [Tue, 9 Dec 2025 05:50:43 +0000 (11:20 +0530)]
configs: am43xx: Migrate to CONFIG_SYS_MEM_TOP_HIDE from CFG_PRAM
The TI AM43xx HS boards have been using CFG_PRAM to hide the top 64MB
firewalled DRAM memory from U-Boot. However, CFG_PRAM only prevents
U-Boot from relocating into that memory, but it is still open for access
for any other usage.
Therefore, migrate into using CONFIG_SYS_MEM_TOP_HIDE which reduces the
ram size itself ensuring that memory is not visible to U-Boot at all
(either for reloc, or general usage).
_ Add 1 GiB DRAM support for STM32MP13x DHCOR SoM
_ Fix 512 MiB DRAM support for STM32MP13x DHCOR SoM
_ Fix handling OPTEE in middle of the DRAM
_ Add missing debug UART build for STM32MP1 DHSOM
Marek Vasut [Tue, 18 Nov 2025 23:17:23 +0000 (00:17 +0100)]
ARM: stm32: Add missing build of debug UART init code on DH STM32MP1 DHSOM
Commit c37a6684818d ("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: c37a6684818d ("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>
Marek Vasut [Tue, 18 Nov 2025 23:19:36 +0000 (00:19 +0100)]
ARM: dts: stm32: Add 1 GiB DRAM settings for DH STM32MP13xx DHCOR SoM
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>
Marek Vasut [Tue, 18 Nov 2025 23:17:14 +0000 (00:17 +0100)]
stm32mp: Fix handling of OPTEE in the middle of DRAM
STM32MP13xx may have OPTEE-OS at 0xdd000000 even on systems with 1 GiB
of DRAM at 0xc0000000, which is not the end of DRAM anymore. This puts
the OPTEE-OS in the middle of DRAM. Currently, the code sets RAM top to
0xdd000000 and prevents the DRAM range past OPTEE at 0xe0000000..0xffffffff
from being set as cacheable and from being usable. The code also sets the
area over OPTEE as invalid region in MMU tables, which is not correct.
Adjust the code such, that it only ever sets RAM top just before OPTEE
in case the OPTEE is really at the end of DRAM, mainly to be backward
compatible. Furthermore, adjust the MMU table configuration such, that
the regions over the OPTEE are simply skipped and not reconfigured, and
the regions between end of OPTEE and RAM top are set as cacheable, if
any actually exist.
Pranav Tilak [Mon, 8 Dec 2025 13:54:24 +0000 (14:54 +0100)]
arm64: versal: Fix LTO for mini_ospi/mini_qspi
With LTO enabled, mini U-Boot was hanging during reloc_fdt().
The initial stack pointer was placed too low, and the FDT memcpy
destination was carved only 4KB above it. This left insufficient
margin, causing the FDT copy to overwrite the live early stack
and corrupt execution before relocation.
To fix this, increase the malloc heap from 8KB to 12KB and raise the
initial stack pointer by 4KB. Together these adjustments increase
the separation between the early stack and the FDT region during
the pre-relocation phase, eliminating the overlap and fixing the
hang on mini builds (QSPI/OSPI).
Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com> Signed-off-by: Michal Simek <michal.simek@amd.com>
Tom Rini [Wed, 19 Nov 2025 14:55:36 +0000 (08:55 -0600)]
sifive-unleashed: 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.
Tom Rini [Wed, 19 Nov 2025 14:55:19 +0000 (08:55 -0600)]
ae350: 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> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Conor Dooley [Wed, 19 Nov 2025 12:38:43 +0000 (12:38 +0000)]
riscv: mpfs: move SoC level options to the CPU Kconfig
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.
projects / thirdparty / u-boot.git / log
