Currently (since 2026.01-rc) on all SDM630/660 based devices this is
printed, after observing long boot delay (several seconds) before
executing preboot commands:
QCOM-FMP: Failed to find boot partition
find_target_partition() function incorrectly assumes that eMMC is always
at number 0. In general you can't rely on device numbering to determine if
particular block device is eMMC or SD-card, because it depends on how
aliases are defined in device tree "chosen" node. Some SoCs have MMC
numbers starting at 1, not 0; so mmc1 is eMMC, mmc2 is SD-card.
Make eMMC detection reliable by using IS_SD() macro from mmc.h header.
Using this method target boot partition can be found successfully.
With debug prints enabled, this is printed:
QCOM-FMP: skipped SD-Card (devnum 2)
QCOM-FMP: Capsule update target: boot (disk 1:60)
QCOM-FMP: DFU string: 'mmc 0=u-boot.bin part 1 60'
Without debug prints nothing is printed, no error about failure to find
boot partition.
Fixes: fe80a5f800 ("mach-snapdragon: CapsuleUpdate: support all boot methods")
Signed-off-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://patch.msgid.link/20251107232935.283843-1-alexeymin@minlexx.ru
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Peripheral registers on MPC83xx-series chips are declared in
immap_83xx.h as a set of structs that ultimately fill the entire MMIO
space of 1 MiB. This patch introduces a compile-time check of the size
of each peripheral struct. The purpose of these checks is two-fold:
1. To quickly tell readers of the code the total size of each struct
2. To verify that the size does not change when a struct is edited
If the size of a peripheral struct were to change by a few bytes due
to an editing error, the result would be mayhem for all following
peripherals, because all offsets would shift by the amount of the error.
All new checks have been compile-tested.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Tom Rini <trini@konsulko.com> says:
As seen by a number of patches fixing memory leaks, U-Boot has a problem
with developer expectations around devm_kmalloc and friends. Namely,
whereas in Linux these memory allocations will be freed automatically in
most cases, in U-Boot this is only true if DEVRES is enabled. Now,
intentionally, in xPL phases, we do not (and do not offer as an option)
enabling DEVRES. However in full U-Boot this is left either to the user,
or some drivers have select'd DEVRES on their own. This inconsistency is
a problem. This series goes and deals with two small issues that were
shown by having all drivers that use devm_.alloc to allocate memory also
select DEVRES and then we make DEVRES no longer be a prompted option and
instead select'd as needed. We do not make this unconditional as it
would result in growing the resulting binary on the many platforms which
have no users of the devm_.alloc family of functions.
Link: https://lore.kernel.org/r/20251227223833.3019311-1-trini@konsulko.com
The devm alloc functions that we have may follow the Linux kernel model
where allocations are (almost always) automatically free()'d. However,
quite often we don't enable, in full U-Boot, the tracking and free()'ing
functionality. This in turn leads to memory leaks because the driver
author expects that since the functions have the same name as in the
Linux Kernel they have the same behavior. In turn we then get
functionally correct commits such as commit 00e1fed93c ("firmware:
ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually
add these calls. Rather than manually tracking allocations and
implementing free()s, rework things so that we follow expectations by
enabling the DEVRES functionality (outside of xPL phases).
This turns DEVRES from a prompted symbol to a symbol that must be
select'd, and we now remove our non-managed alloc/free functions from
outside of xPL builds.
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
A few x86 platforms use a SYS_MALLOC_F_LEN value of 0x1000 or higher.
With the impending move to having DEVRES enabled by default, we will
need a little more room here. Raise the default value.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This adds basic support for MediaTek MT8188 SoC.
Add watchdog support by adding upstream compatible string.
Add tphy support by adding "mediatek,generic-tphy-v2" compatible string
in arch/arm/dts/mt8188-u-boot.dtsi
Signed-off-by: Julien Masson <jmasson@baylibre.com>
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Make sure the end of U-Boot is at 8-byte aligned offset, not 4-byte
aligned offset. This allows safely appending DT at the end of U-Boot
with the guarantee that the DT will be at 8-byte aligned offset. This
8-byte alignment is now checked by newer libfdt 1.7.2 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
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>
These are common for all K3 based boards. Add the common values as
defaults and remove from each board defconfig
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
The current implementation of flash.bin generation with
CONFIG_SPL_LOAD_IMX_CONTAINER=y requires build of u-boot.cnt
which is i.MX8 specific. Reinstate the i.MX8 check to avoid
this dependency for i.MX9 .
Fill in flash.bin target for i.MX9 into imx specific Makefile.
Fixes: c3587197c0 ("Makefile: Make flash.bin target available for all platforms")
Signed-off-by: Marek Vasut <marex@nabladev.com>
Get rid of most globals that are spread around between TU's and place
them in their own structs managed by dm. Device state is now owned by
each driver instance. This design mirrors the Linux IPUv3 driver
architecture.
This work is done in preparation to migrate the driver to the clock
framework. While not the primary intent, this change also enables
multiple IPU instances to exist contemporarily.
Signed-off-by: Brian Ruley <brian.ruley@gehealthcare.com>
Enable OF_UPSTREAM for i.MX8ULP EVK so that devicetree imported from
Linux kernel release can be used.
If mailbox@29220000 is enabled, gd->arch.ele_dev will be set to this
device for communication with ELE firmware. This is incorrect because
mu@27020000 is the MU used for communication with the ELE firmware. To
prevent misconfiguration, disable mailbox@29220000.
The driver model for watchdog timer is not enabled yet, so disable wdog3
temporarily.
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
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>
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>
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>
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.
This reverts commit b0dbc9fcb7.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
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.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
AM62d previously reused the AM62a DM. Since a dedicated DM is now
available, migrate to device specific DM.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
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>
Add a helper function based on rockchip_sdram_size() that return what
DRAM type is used on current running board.
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>
Drop SoC specific TEXT_BASE and use a common TEXT_BASE for all SoCs.
Move the common TEXT_BASE to 8 MiB offset from start of DRAM to help
support RAM boot from maskrom introduced in next patch.
RAM boot from maskrom mode will expect the FIT payload to be located at
2 MiB offset from start or DRAM.
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>
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.
This reverts commit fe780310cf.
Reported-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
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:
=> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=796180D4-AAB2-50F1-B16A-53DFF9CA89B2
ESRT: fw_type=unknown
ESRT: fw_version=0
ESRT: lowest_supported_fw_version=0
ESRT: capsule_flags=0
ESRT: last_attempt_version=0
ESRT: last_attempt_status=success
========================================
Reviewed-by: Evgeny Bachinin <EABachinin@salutedevices.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org>
Link: https://patch.msgid.link/20251211-meson-capsule-v4-1-59f126ba4115@postmarketos.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
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>
