Dario Binacchi [Wed, 25 Feb 2026 16:16:58 +0000 (17:16 +0100)]
spi: stm32: add support for bits-per-word setting
Implement the set_wordlen operation to allow dynamic bus width
configuration. This is required for peripherals with non-standard
requirements, such as display panels that need 9-bit word transfers
during the initialization and setup phase.
Dario Binacchi [Wed, 25 Feb 2026 16:16:57 +0000 (17:16 +0100)]
spi: stm32: add stm32_spi_is_enabled() helper
Add a helper to check the SPE (SPI Enable) bit and replace the
open-coded bitwise check in stm32_spi_stopxfer() with this helper to
improve readability and consistency.
This is also a preparatory step for future driver updates that require
checking the SPI enable state across different code paths.
Dario Binacchi [Wed, 25 Feb 2026 16:16:55 +0000 (17:16 +0100)]
test: dm: spi: add testcase for spi_set_wordlen()
Add a unit test to verify that the SPI word length configuration is
correctly handled by the SPI uclass and successfully passed down to
the sandbox driver.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Simon Glass <simon.glass@canonical.com>
Dario Binacchi [Wed, 25 Feb 2026 16:16:52 +0000 (17:16 +0100)]
spi: add support for bits-per-word setting
Allow dynamic configuration of the SPI word length. This is required
for controllers and slaves that need to operate with non-standard
word lengths, such as 9-bit wide transfers.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Simon Glass <simon.glass@canonical.com>
Tom Rini [Wed, 25 Mar 2026 19:00:27 +0000 (13:00 -0600)]
arm: stm32mp: Drop unnecessary BOARD_EARLY_INIT_F usage
All of these platforms enable CONFIG_BOARD_EARLY_INIT_F and then have a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Fix the following errors yielded by Coverity Scan:
CID 644836: Error handling issues (CHECKED_RETURN)
Calling device_chld_unbind without checking return value (as is done elsewhere 6 out of 7 times)
CID 644834: Error handling issues (CHECKED_RETURN)
Calling device_chld_remove without checking return value (as is done elsewhere 4 out of 5 times).
Link: https://lore.kernel.org/r/20260309212331.GF1388590@bill-the-cat/ Fixes: a6d047c0a86b ("video: stm32: remove all child of DSI bridge when its probe failed") Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Depending of plugged power source (computer, wall charger, ...) it can
happen that we got the following message:
"****************************************************"
"* USB TYPE-C charger not compliant with *"
"* specification *"
"****************************************************"
" "
"### ERROR ### Please RESET the board ### "
This issue has been detected on STM32MP135f-DK board.
It's due to max_uV and min_uV value are initialized at beginning of
board_check_usb_power() and can then be used for the 2 iteration of
adc_measurement().
max_uV/min_uV values issued of the first adc_measurement() iteration
are used as input of the second adc_measurement() iteration, which
can lead to incoherent pair of min_uV/max_uV values.
To ensure that adc_measurement() returns coherent value for max_uV and
min_uV, initialize max_uV and min_uV at each loop start.
Tom Rini [Wed, 29 Apr 2026 20:49:24 +0000 (14:49 -0600)]
Merge tag 'mediatek-for-master-2026-04-29' of https://source.denx.de/u-boot/custodians/u-boot-mediatek
* MMC fixes for Genio 520/720 (mt8189)
* SPI NOR Flash controller fixes
* SPI NOR Flash support for Genio 520/720
* PMIC controller fixes
* PMIC support for Genio 1200 (mt8195)
* Drop CONFIG_IDENT_STRING to be consistent across the platform
* Remove empty header on mt7622
David Lechner [Thu, 9 Apr 2026 20:30:38 +0000 (15:30 -0500)]
power: pmic: mtk-pwrap: use pmic compatible to select child info
Change the logic for selecting pmic_children_info to use the compatible
string from the devicetree instead of expecting the pwrap (part of the
MCU) to correspond to the separate PMIC chip.
In addition to being more correct, it also saves a few lines of code for
each MCU type that is added by dropping the enum and type field.
David Lechner [Thu, 9 Apr 2026 20:30:35 +0000 (15:30 -0500)]
power: pmic: mtk-pwrap: add init capability flag
Add a PWRAP_CAP_INIT capability flag to specify if it is safe to call
pwrap_init() or not. Not all targets define the registers accessed
by pwrap_init(). In that case, it is expected that an earlier bootloader
has already initialized the PMIC. If not, we now return an error instead
of trying to access undefined registers.
David Lechner [Thu, 9 Apr 2026 20:30:33 +0000 (15:30 -0500)]
power: pmic: mtk-pwrap: fix file description
Fix the comment at the start of the file to accurately describe what
this file does. The old description was likely copied from the related
regulator driver.
Marek Vasut [Fri, 24 Apr 2026 03:33:38 +0000 (05:33 +0200)]
cmd: ums: Switch HW partition before block access
An UMS session with eMMC device specifier "ums C mmc dev.part1,dev.part2"
exposes the same eMMC HW partition 'part2' twice instead of exposing both
HW partitions 'part1' and 'part2'. Fix this by switching the eMMC HW
partition before block device read/write access.
An eMMC is represented by a single struct blk_desc, with the currently
selected HW partition being stored in this struct blk_desc. Each call to
part_get_info_by_dev_and_name_or_num() with partition string dev[.partN]
does trigger HW partition switch by calling blk_get_device_part_str() ->
blk_get_device_part_str() -> get_dev_hwpart() -> get_dev_hwpart() ->
blk_dselect_hwpart(). The ums_init() iterates over the device specifier
string and calls part_get_info_by_dev_and_name_or_num() in a loop for
each dev[.partN] entry used as the partition string. If the device
specifier string contains more than one dev[.partN] partition strings
for the same dev device, then it is the HW partition described in the
last dev[.partN] partition string entry that is accessed for all dev
device partition strings in the device specifier string, because that
last dev[.partN] partition string entry was the last one that triggered
blk_dselect_hwpart() call for that device.
To access the expected HW partition for every dev[.partN] partition string
entry, it is necessary to call blk_dselect_hwpart() before each block read
or write. Store HW partition described for each dev[.partN] partition string
in struct ums and use the stored value to make it so.
The blk_dselect_hwpart() does test whether the currently selected HW
partition is already configured in hardware and does not reconfigure
the hardware if that is the case, therefore for the majority of block
reads and writes, blk_dselect_hwpart() is a no-op with negligible
performance impact.
Example reproducer is listed below. The last sector of both eMMC HW BOOT
partitions is populated with distinct test pattern and UMS is launched:
"
=> mmc dev 1 1 ; mmc read $loadaddr 0x1fff 1 ; md $loadaddr 4
switch to partitions #1, OK
mmc1(part 1) is current device
MMC read: dev # 1, block # 8191, count 1 ... 1 blocks read: OK 84000000: 1234abcd1234abcd1234abcd1234abcd ..4...4...4...4.
=> mmc dev 1 2 ; mmc read $loadaddr 0x1fff 1 ; md $loadaddr 4
switch to partitions #2, OK
mmc1(part 2) is current device
MMC read: dev # 1, block # 8191, count 1 ... 1 blocks read: OK 84000000: 567890ef567890ef567890ef567890ef ..xV..xV..xV..xV
Read of the two block devices on host without this fix produces
identical data present in HW BOOT partition 2:
"
$ dd if=/dev/sdX of=mmc-a.bin ; dd if=/dev/sdY of=mmc-b.bin
$ hexdump -C mmc-a.bin | tail -n 3 | head -n 1 ; \
hexdump -C mmc-b.bin | tail -n 3 | head -n 1 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV| 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV|
"
Read of the two block devices on host with this fix produces the
expected distinct data from either HW BOOT partition 1 or 2:
"
$ dd if=/dev/sdX of=mmc-a.bin ; dd if=/dev/sdY of=mmc-b.bin
$ hexdump -C mmc-a.bin | tail -n 3 | head -n 1 ; \
hexdump -C mmc-b.bin | tail -n 3 | head -n 1 003ffe00 cd ab 34 12 cd ab 34 12 cd ab 34 12 cd ab 34 12 |..4...4...4...4.| 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV|
"
Reported-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Marek Vasut <marex@nabladev.com> Reviewed-by: Simon Glass <sjg@chromium.org>
David Lechner [Mon, 6 Apr 2026 20:37:09 +0000 (15:37 -0500)]
arm: dts: mediatek: add Genio 520/720 SNOR support
Add devicetree nodes needed to enable SNOR support on Genio 520 and 720
EVKs. This is copied from the most recent upstream submission [1] of the
devicetree for these boards, so there should be minimal differences when
we eventually switch to OF_UPSTREAM.
Macpaul Lin [Mon, 6 Apr 2026 20:13:33 +0000 (15:13 -0500)]
spi: mtk_snor: fix zeroed data in DMA read bounce path
Implement proper bounce buffer handling for the read path to fix zeroed
data when using DMA. In the bounce path, map the bounce buffer with
dma_map_single(), perform DMA using bounce_dma, then copy data from the
bounce buffer to the user buffer, and finally unmap with
dma_unmap_single().
Add support for some newer SOCs. New compatible strings are added to the
lookup table. Some SOCs also need a extra bit clocked out as a hardware
quirk, so a new capability structure and code is added to support that.
spi: mtk_snor: avoid alloc in mtk_snor_cmd_program()
Rework mtk_snor_cmd_program() to avoid allocating a temporary buffer
for tx data. This improves performance a bit by avoiding the need to
allocate memory and copy data an extra time.
Remove CONFIG_IDENT_STRING from the mt8395_genio_1200_evk_ufs defconfig.
This makes it consistent with other mediatek defconfigs and frees the
option for use by downstream users. This only affects the version string
printed by U-Boot, so it doesn't have any functional impact.
Remove CONFIG_IDENT_STRING from the mt8395_genio_1200_evk defconfig.
This makes it consistent with other mediatek defconfigs and frees the
option for use by downstream users. This only affects the version string
printed by U-Boot, so it doesn't have any functional impact.
Remove CONFIG_IDENT_STRING from the mt8390_genio_700_evk defconfig. This
makes it consistent with other mediatek defconfigs and frees the option
for use by downstream users. This only affects the version string
printed by U-Boot, so it doesn't have any functional impact.
Remove CONFIG_IDENT_STRING from the mt8370_genio_510_evk defconfig. This
makes it consistent with other mediatek defconfigs and frees the option
for use by downstream users. This only affects the version string
printed by U-Boot, so it doesn't have any functional impact.
Remove CONFIG_IDENT_STRING from the mt8365_evk defconfig. This makes it
consistent with other mediatek defconfigs and frees the option for use
by downstream users. This only affects the version string printed by
U-Boot, so it doesn't have any functional impact.
Correct the check condition in msdc_cmd_is_ready() for MSDC_PS_DAT0
polling. Without this change, it may not be able to detect if the SD
controller is busy correctly for issuing the command.
Fixes: d24b69395949 ("mmc: mtk-sd: add SD/MMC host controller driver for MT7623 SoC") Signed-off-by: ht.lin <ht.lin@mediatek.com> Reviewed-by: Julien Stephan <jstephan@baylibre.com> Tested-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20260421-mmc-mtk-sd-fixes-v1-3-5b840c546af2@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
David Lechner [Tue, 21 Apr 2026 14:24:04 +0000 (09:24 -0500)]
mmc: mtk-sd: enable DMA on mediatek,mt8189-mmc
Enable DMA on mediatek,mt8189-mmc compatible. The issue that was
preventing DMA from working correctly was fixed by the
get_effective_memsize() implementation in commit a7c682565b4b ("arm:
mediatek: add support of MT8189 SoC family").
This series replaces the SYNC_CACHE approach with FUA (Force Unit
Access) to prevent data loss during board resets while avoiding
system hangs during large sparse image flashing operations.
The previous SYNC_CACHE implementation caused timeouts and hangs
when flashing large sparse images because it issued cache sync
commands after every write operation. The FUA approach achieves
the same data integrity goal by setting the FUA bit in
WRITE10 commands.
Enable the Force Unit Access (FUA) bit in SCSI WRITE10 commands to
ensure writes bypass the device's volatile cache and go directly to
non-volatile storage. This provides write-through behavior that prevents
data loss during board resets.
While the SYNC_CACHE approach prevents data loss during board resets,
it causes system hangs during large sparse image flashing operations.
This will be replaced with a FUA (Force Unit Access) approach in future
commit, which achieves the same data integrity goal more efficiently.
Tom Rini [Mon, 27 Apr 2026 17:28:25 +0000 (11:28 -0600)]
Merge patch series "net: migrate NO_NET out of the networking stack choice"
Quentin Schulz <foss+uboot@0leil.net> says:
This migrates the net options away from the main Kconfig to net/Kconfig,
rename the current NET option to NET_LEGACY to really highlight what it
is and hopefully encourage more people to use lwIP, add a new NET
menuconfig (but keep NO_NET as an alias to NET=n for now) which then
allows us to replace all the "if legacy_stack || lwip_stack" checks with
"if net_support" which is easier to read and maintain.
The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed
for now even when no network is configured? Likely due to
include/net-common.h with PKTBUFSRX?
No change in behavior is intended. Only change in defconfig including
other defconfigs where NO_NET=y or NET is not set, in which case NO_NET
is not set or NET=y should be set in the top defconfig. Similar change
required for config fragments. See commit log in patch adding NET
menuconfig for details.
This was tested based on 70fd0c3bb7c2 ("x86: there is no
CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container
trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up
similarly as in "build all platforms in a single job" GitLab CI job.
O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt
I can't really decipher the log.txt, but there's no line starting with
+ which would be an error according to tools/buildman/builder.py help
text. Additionally, because I started the script with set -e set and
because buildman has an exit code != 0 when it fails to build a board,
and I have the summary printed (which is the second buildman call), I
believe it means all builds passed.
The summary is the following:
aarch64: (for 537/537 boards) all +0.0 rodata +0.0
uniphier_v8 : all +1 rodata +1
u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1)
function old new delta
data_gz 10640 10641 +1
arm: (for 733/733 boards) all -0.0 rodata -0.0
uniphier_v7 : all -1 rodata -1
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1)
function old new delta
data_gz 11919 11918 -1
opos6uldev : all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 18778 18775 -3
uniphier_ld4_sld8: all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 11276 11273 -3
stemmy : all -20 rodata -20
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20)
function old new delta
data_gz 15783 15763 -20
As far as I could tell this data_gz is an automatically generated array
when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored
in binary form. Because I'm changing the name of symbols, replacing a
menu with a menuconfig, additional text makes it to .config and the
"# Networking" section in .config disappears.
Here is the diff for the 5 defconfigs listed above, generated with:
for f in build/*-m; do
diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config
done
(-m is the build directory for master, and without the suffix, it's the
top commit of this series)
This is fine:
- Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't
be in .config anymore.
- opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have
(old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but
CONFIG_NET_LEGACY also needs to be defined now to reflect the stack
choice (even if default),
- stemmy has CONFIG_NO_NET set, which means CONFIG_NET and
CONFIG_NET_LWIP are not reachable anymore hence why they don't need to
be part of .config,
GitLab CI was run on this series (well, not exactly, but it's only
changes to the git logs that were made):
https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849
NO_NET is now a transitional symbol which may eventually be removed. Its
meaning is the opposite of the new meaning of NET (that is, any
networking stack).
Update the symbol dependency by using NET instead of !NO_NET.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
simplify NET_LEGACY || NET_LWIP condition with NET condition
Since the move to make NET a menuconfig and NO_NET a synonym of NET=n,
when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so
let's simplify the various checks across the codebase.
SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so
the proper symbol is still defined in SPL whenever needed.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
net: make NET a menuconfig (and downgrade NO_NET to a simple config)
This will allow a bunch of simplifications across the code base.
Disabling NET is the equivalent of today's NO_NET choice. This means
that if NET is enabled, either the legacy or lwIP stack is necessarily
selected, which allows us to simplify if NET_LEGACY || NET_LWIP into
if NET in a later commit.
Config fragments - or defconfigs including other defconfigs - setting
the network stack (NET_LEGACY or NET_LWIP) must also set NET (or unset
NO_NET) if the config they apply to - or the included defconfigs -
unsets NET (or selects NO_NET) as otherwise the NET_LEGACY and NET_LWIP
symbols are unreachable. This is the case for the two defconfig modified
in this commit.
NO_NET is now a convenience symbol which hides NET entirely to avoid
modifying many defconfigs. If one selected NO_NET to disable the
networking stack in the past, this will still work for now. Technically,
we should be using the "transitional" Kconfig attribute but that is only
available since Kconfig from Linux kernel v6.18 and we're on 6.1 right
now.
Note that this moves CONFIG_SYS_RX_ETH_BUFFER from under the Network
menu back into the main menu as it seems like it needs to be defined
even when there's no need for NET support at all and menuconfig option
doesn't work the same way as a menu.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
In the main Kconfig, there are only two more menus, General Setup and
Expert, in addition to the net menu. Since the part in the main Kconfig
is mostly about selecting the network stack (legacy or lwIP), and that
we already have a net/Kconfig, let's move those to net/Kconfig to have
everything in the same place.
No intended change in behavior.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
The hardware configuration pins are used both to select the DDR
configuration and to determine the installed memory size.
On Aquila AM69, the DDR timing patch is applied in the R5 SPL, while the
memory size fixup for the next-stage U-Boot DT is done later in the A72
SPL path.
The previous immplementation was not taking in account that the hw_cfg
value is lost both during SPL execution (board_init_f and board_init_r)
and between SPL and U-Boot proper.
Fix this by reading the hardware configuration pins when the memory size
is actually needed:
- in the R5 SPL, to select the correct DDR configuration
- in the A72 SPL, to fix up the U-Boot DT memory size and bank layout
The 16GB dual-rank DDR configuration uses an incorrect DDRSS_PLL_FHS_CNT
value. This makes DDR initialization hang during the DDR frequency
handshake sequence.
Update DDRSS_PLL_FHS_CNT to the correct value for the 16GB dual-rank
configuration.
Fixes: 39e014f43a15 ("board: toradex: aquila-am69: Add support for 16GB dual rank memory configuration") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Tom Rini [Mon, 27 Apr 2026 17:19:46 +0000 (11:19 -0600)]
Merge patch series "k3-am69-aquila: Migrate to OF_UPSTREAM and add remoteproc FW pre-loading"
Ernest Van Hoecke <ernestvanhoecke@gmail.com> says:
This patch series migrates the Aquila AM69 to OF_UPSTREAM to receive
automatic device tree updates. It also adds remoteproc firmware
pre-loading to the environment.
Some use cases require remoteproc firmware to be loaded before Linux
boots. Introduce rprocsemmcboot and rproc_fw_binaries to load the
remoteproc cores from U-Boot, relying on the TI k3_rproc framework
which already handles the secure firmware variants, firmware loading,
and proper initialization.
The firmware binaries are expected to be present in the eMMC rootfs
under /lib/firmware/.
To activate, run rprocsemmcboot or add it to bootcmd:
bootcmd=run rprocsemmcboot; bootflow scan -b
The upstream U-Boot does not yet have the remoteproc DT nodes enabled
for the Aquila AM69, making firmware loading fail. Marking as pending
waiting for remoteproc enabling, which could happen along with the
OF_UPSTREAM migration.
Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
virtio: add support for SIZE_MAX & SEG_MAX features
Some virtio implementations may forward the virtio requests directly to
the underlying hw. The hw may have some restrictions in how many and how
big the requests can be. Therefore, the corresponding virtio device will
announce this limitations with the SIZE_MAX & SEG_MAX feature.
Add support for those features. Split an io request into multiple virtio
requests if more than seg_max segments would be used. Also split a
single buffer request into multiple segments if the buffer is bigger
then size_max.
Signed-off-by: Christian Pötzsch <christian.poetzsch@kernkonzept.com> Signed-off-by: Adam Lackorzynski <adam@l4re.org>
Maximilian Brune [Wed, 22 Apr 2026 12:57:53 +0000 (14:57 +0200)]
pci: correct PCI device enumeration to include all functions on device 0
Currently the implementation does not just skip all devices beside
device 0, it also skips all functions (besides 0) on device 0. This
broke basically all AMD platforms, since they have a lot of internal SOC
devices behind these functions.
This was detected, because the XHCI controller and therefore the USB
devices were not found by u-boot on AMD/crater platform.
PCI_MASK_BUS() returns both device and function bits, so it skips any
bdf where either device > 0 or function > 0. Using PCI_DEV() extracts
only the device number, matching the intent in only_one_child().
It therefore now checks all functions on device 0 (Linux does the same).
I build tested u-boot as coreboot payload and run it on a recent x86 AMD
platform. Devices like the XHCI controller are now found again.
Fixes: fbde868ba4aa ("pci: skip unnecessary PCIe scanning") Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> CC: Tom Rini <trini@konsulko.com> CC: Andrew Goodbody <andrew.goodbody@linaro.org> CC: George McCollister <george.mccollister@konsulko.com> CC: Simon Glass <sjg@chromium.org>
Tom Rini [Mon, 27 Apr 2026 15:44:40 +0000 (09:44 -0600)]
Merge patch series "Add support for DT overlays handoff"
Raymond Mao <raymond.mao@linaro.org> says:
The series include refactoring on bloblist and fdtdec to support handoff
of multiple DT overlays and applying them into the DT base during setup.
All changes are aligned to the spec update for supporting DT overlay
handoff[1].
Notes for testing:
Currently DT overlay is not yet enabled in TF-A, but with the test
patches I provided for TF-A and OP-TEE build, importing a DT overlay
blob file from QEMU to TF-A reserved memory is supported.
Follow below instructions to build and run for test:
$ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
Replace your local qemu_v8.xml with [2], which contains all necessary
changes in both TF-A and OP-TEE build.
$ repo sync
$ cd build
$ make toolchains
$ make ARM_FIRMWARE_HANDOFF=y all
Copy and rename your DT overlay blob as 'qemu_v8.dtb' into out/bin
$ make ARM_FIRMWARE_HANDOFF=y run-only
[1] Add Transfer Entry for Devicetree Overlay
https://github.com/FirmwareHandoff/firmware_handoff/pull/74
Raymond Mao [Fri, 18 Jul 2025 14:16:18 +0000 (07:16 -0700)]
fdtdec: apply DT overlays from bloblist
During FDT setup, apply all existing DT overlays from the bloblist
to the base FDT if bloblist is being used for handoff from previous
boot stage.
According to the Firmware Handoff spec update to support DT overlay [1],
an overlay must have the same top-level compatible string as its target
base DT has.
Before applying the overlays, check whether sufficient space is
reserved in the base DT blob, if not, resize the blob to the allowed
padded size, which is limited by CONFIG_SYS_FDT_PAD and the bloblist
spare space size.
After all overlays are applied, resize the merged DT to its actual size.
[1] Add Transfer Entry for Devicetree Overlay
https://github.com/FirmwareHandoff/firmware_handoff/pull/74
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Michal Simek <michal.simek@amd.com>
Raymond Mao [Fri, 18 Jul 2025 14:16:17 +0000 (07:16 -0700)]
bloblist: add API for applying blobs with specified tag
Add an API to search for the blobs with specified tag and use the
hook function to apply the blob data.
Add a helper function to return the inline header size as according
to recent spec[1] updates, the actual data can be following an inline
header instead of following the TE header immediately.
Raymond Mao [Fri, 18 Jul 2025 14:16:16 +0000 (07:16 -0700)]
bloblist: fix a potential negative size for memmove
It causes a panic when blob is shrunk and 'new_alloced' is less than
'next_ofs'. The data area that needs to be moved should end up at
'hdr->used_size'.
Fixes: 1fe59375498f ("bloblist: Support resizing a blob") Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Michal Simek <michal.simek@amd.com>
Raymond Mao [Fri, 18 Jul 2025 14:16:14 +0000 (07:16 -0700)]
bloblist: add blob type for DT overlay
Add blob type for DT overlay according to the update of Firmware
Handoff spec[1].
Add an inline header to represent the 'subtype' in a DT overlay
blob payload.
[1] Add Transfer Entry for Devicetree Overlay
https://github.com/FirmwareHandoff/firmware_handoff/pull/74
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Michal Simek <michal.simek@amd.com>
Tom Rini [Mon, 27 Apr 2026 14:05:40 +0000 (08:05 -0600)]
Merge branch 'casey/qcom-main-13Apr2026' of https://source.denx.de/u-boot/custodians/u-boot-snapdragon
Various Qualcomm additions this cycle:
* USB superspeed support for 1 platform
* Initial support for the Milos platform and the Fairphone Gen 6
(chainloaded from ABL)
* Improved support for booting with OP-TEE on supported platforms
* Initial basic power domain support
Notably there is a generic change to the device core, missing power
domains will no longer cause a device to fail probe and instead will
just print a warning. This shouldn't affect any existing platforms.
Aswin Murugan [Tue, 24 Mar 2026 17:59:13 +0000 (23:29 +0530)]
qcom_defconfig: Disable EFI_HAVE_RUNTIME_RESET in qcom_defconfig
Qualcomm platforms rely on the kernel to manage specialized reboot modes
such as EDL, bootloader entry, and other vendor-specific reset flows.
Allowing U-Boot to override these via EFI runtime reset services leads to
incorrect behavior when the kernel issues advanced reboot requests.
Now that EFI_HAVE_RUNTIME_RESET is exposed as a user-configurable Kconfig
option, disable it for qcom_defconfig so that the kernel retains full
control over reboot handling on Qualcomm SoCs.
This ensures that EFI runtime reboot callbacks are not registered on
these platforms, preventing conflicts with kernel-managed PSCI reset
paths.
Aswin Murugan [Tue, 24 Mar 2026 17:59:12 +0000 (23:29 +0530)]
efi_loader: make EFI_HAVE_RUNTIME_RESET a user-selectable option
Expose EFI_HAVE_RUNTIME_RESET as a proper Kconfig boolean with a prompt
so platforms can explicitly enable or disable advertising the EFI reset
runtime service.
The current PSCI-based EFI runtime reset implementation is always
enabled whenever CONFIG_PSCI_RESET is selected, but it does not support
passing the additional arguments required for specialized reset modes.
As a result, reboot requests such as bootloader mode or EDL mode cannot
be propagated correctly and instead fall back to a normal reboot.
By making EFI_HAVE_RUNTIME_RESET user-configurable, platforms that
depend on extended PSCI reset can now explicitly disable EFI runtime
reset handling even when CONFIG_PSCI_RESET is enabled, ensuring
that the kernel retains full control of advanced reboot paths.
Default behavior for existing platforms remains unchanged.
dts: qcs6490-rb3gen2: Remove USB controller dr_mode override
Remove the USB controller dr_mode override from the u-boot device
tree. The upstream Linux device tree already configures the USB
controller with dr_mode = "otg", which supports both host and
peripheral modes including fastboot.
The previous override to "host" mode prevented fastboot from working
as it requires peripheral mode support. By removing this override,
the upstream OTG configuration is inherited, enabling fastboot while
maintaining host mode capability through the usb-role-switch
property.
Luca Weiss [Wed, 18 Mar 2026 12:46:30 +0000 (13:46 +0100)]
regulator: qcom-rpmh-regulator: add support for PM7550 regulators
Add the PM7550 regulator data found on Qualcomm Milos devices.
The tables are imported from the Linux driver (tag v7.0-rc4). The SMPS
regulators were not added now.
Sumit Garg [Tue, 27 Jan 2026 06:23:41 +0000 (11:53 +0530)]
board/qualcomm: Introduce TF-A and OP-TEE config fragment
Recently upstream TF-A/OP-TEE has started gaining support for Qcom
platforms. RB3Gen2 being the first one and more to come. U-Boot in
corresponding boot flow is packaged as a position independent executable.
So, lets add a generic U-Boot config fragment for Qcom platforms to
support TF-A/OP-TEE based TrustZone stack. Build command:
$ ./scripts/kconfig/merge_config.sh \
configs/qcom_defconfig \
board/qualcomm/tfa-optee.config
$ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
For more information refer here:
https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
Sumit Garg [Tue, 27 Jan 2026 06:23:40 +0000 (11:53 +0530)]
mach-snapdragon: of_fixup: Add OP-TEE DT fixup support
Add support for OP-TEE live tree DT fixup support which enables U-Boot
OP-TEE driver to be probed. As well as the EFI DT fixup protocol allows
the live tree fixup to be carried over to the OS for the OP-TEE driver
in the OS to probe as well.
Note that this fixup only gets applied if OP-TEE support is detected via
checking for OP-TEE message UID.
Sumit Garg [Tue, 27 Jan 2026 06:23:39 +0000 (11:53 +0530)]
tee: optee: Export OP-TEE message UID check API
OP-TEE message UID check API can be useful to know whether OP-TEE
is enabled on not assuming the corresponding SMC call is properly
handled if OP-TEE is not supported.
This API can be used by platform code to know OP-TEE presence and
on that basis OP-TEE DT node can be added as part of DT fixups for
the OP-TEE driver probe to happen for both U-Boot and Linux.
drivers: sysreset: Add sysreset op that can take arguments
Add a 'request_arg' op to struct sysreset_ops to enable sysreset drivers
to receive arguments given to the 'reset' command. Process the
request_arg() op before the usual request() op.
arm: psci: Add API to check for support of specific PSCI function
Add an API to check if a specific PSCI function is supported or not.
This is based on the psci_features() function present in Linux kernel
(drivers/firmware/psci/psci.c).
arch: arm: mach-snapdragon: Auto-detect USB SSPHY driver support
Automatically detect super-speed USB PHY driver availability and
skip the USB speed fixup if driver is available, eliminating the need
for manual configuration.
Previously, U-Boot unconditionally limited USB to high-speed mode
on all Qualcomm platforms because most lacked super-speed PHY
drivers.
This change implements runtime detection that checks if a PHY
driver exists for the super-speed PHY node referenced by the DWC3
controller. The fixup is automatically skipped when a compatible
driver is found, allowing the hardware to operate at full
capability. Platforms without super-speed PHY drivers continue to
receive the fixup automatically.
Add support for the Qualcomm QMP USB3-DP Combo PHY found on
SC7280 and QCM6490 platforms. This driver currently implements
USB3 super-speed functionality of the combo PHY.
The QMP Combo PHY is a dual-mode PHY
that can operate in either USB3 mode or DisplayPort mode. This
initial implementation focuses on USB3 mode to enable Super-Speed
USB support.
Taken from Linux commit 3d25d46a255a ("pmdomain: qcom: rpmhpd: Add rpmhpd support for SM8750")
This patch is dependent on this patch: https://lore.kernel.org/u-boot/20251112164204.1557934-1-aswin.murugan@oss.qualcomm.com/
Enabled and tested the driver on Qualcomm RB3 Gen2 (QCS6490) board.
drivers: usb: dwc3: Add delay after core soft reset
Add a 100 ms delay after clearing the core soft reset bit to ensure
the DWC3 controller has sufficient time to complete its reset
sequence before subsequent register accesses.
Without this delay, USB initialization can fail on some Qualcomm
platforms, particularly when using super-speed capable PHYs like
the QMP USB3-DP Combo PHY on SC7280/QCM6490.
Taken from Linux commit f88359e1588b ("usb: dwc3: core: Do core softreset when switch mode")
Allocate a 1 MiB LMB region for fdtoverlay_addr_r when
CONFIG_OF_LIBFDT_OVERLAY is enabled, allowing runtime application of
DT overlays on Snapdragon platforms.
This is useful for Android-based boot flows where the final DT passed
to the kernel must contain modified /firmware/android/fstab entries.
One use case is redirecting system and vendor partitions to microSD
storage instead of internal eMMC without rebuilding the base DTB.
The allocation is conditional on CONFIG_OF_LIBFDT_OVERLAY and has no
effect on boards that do not enable overlay support.
projects / thirdparty / u-boot.git / log
