common: memsize: fix occasionally failing alias probing
probe_ram_size_by_alias() detects whether a probe address still aliases
a lower address by writing through one address and reading through the
other.
On i.MX95 this occasionally reported a false non-alias when the alias
read happened immediately after the write.
A memory barrier alone, mb(), was tested but did not make the failure go
away. This suggests that ordering the CPU accesses is not sufficient for
this probe, likely because the issue is in the path to the memory
controller rather than in the core itself.
Read the written address back before checking the alias address. This
appears to force the write to become observable at the probe address
before using the alias read to decide whether the tested address range
exists.
If the readback does not match the written pattern, restore the saved
value and continue with the next check. This keeps the probe robust for
addresses that do not reliably retain the test pattern.
Fixes: 0977448b45e2 ("common: memsize: add RAM size probe based on alias detection") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Michal Simek [Wed, 29 Apr 2026 06:29:53 +0000 (08:29 +0200)]
bloblist: fix pointer comparison in bloblist_apply_blobs()
The rec_from_blob() function returns a pointer, but the code was
comparing it using "rec <= 0" which is incorrect for pointer types.
Pointers should be compared using "== NULL" or "!= NULL".
Addresses-Coverity-ID: CID 645841: Incorrect expression (BAD_COMPARE) Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
Michal Simek [Wed, 29 Apr 2026 06:22:08 +0000 (08:22 +0200)]
fdt: check fdt_pack() return value in fdtdec_apply_bloblist_dtos()
The fdt_pack() function can return an error code, but its return value
was not being checked. Add proper error handling to propagate any
failure.
Also fix typo in comment: "Shink" -> "Shrink".
Addresses-Coverity-ID: CID 645839: Error handling issues (CHECKED_RETURN) Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
Franz Schnyder [Tue, 31 Mar 2026 08:10:10 +0000 (10:10 +0200)]
board: toradex: Quote variables in `test` cmd expression
With correct POSIX handling, unquoted empty variables can turn the
expression like
test -n ${fdtfile}
into
test -n
The POSIX handling for single argument `test` evaluates it as true,
so the fallback initialization will be skipped unexpectedly.
Quoting variable expansions in `test` expressions will always result in
correct behavior for empty and non-empty values.
This change was triggered by
commit 8b0619579b22 ("cmd: test: fix handling of single-argument form of test")
The aim is to have a less fragile codebase that is not dependent on a
quirk of the shell implementation.
Use quoted variable expansions in `test` expressions throughout.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 1 May 2026 14:12:31 +0000 (08:12 -0600)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi
Apologies for the delay, but please pull those sunxi changes into
v2026.07. Nothing earth shattering, mostly minor improvements like
better SPL power LED support, and fixes to some H616 DRAM setup. Also
some more forward looking enhancement for the SPI code. I also pulled in
Richard's raw NAND flash improvements for the H6/H616 SoC, though this
lacks proper peer testing due to the lack of mainline support for any
board actually employing those chips.
* .clang-format description
* qemu-arm: describe secure state steps
* mention that CONFIG_BOOTSTD_DEFAULTS provides network features when NET=y
* ti: k3: describe fTPM support
UEFI:
* cmd/bootefi: move efi_init_obj_list() to the start of do_bootefi
* correct return value of efi_bootmgr_run()
* correct efi_binary_run_dp() return value
* centralize messaging for efi_init_obj_list
* correct Kconfig dependencies for EFI_HTTP_BOOT
Others:
* .clang-format: add U-Boot specific for each macros
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmn0hjwACgkQxIHbvCwF
# GsRDVQ/+LADSJv/WxhsEayOe1f0H0wp42bssPZikyUxHGr6azNHjgngw2sExfFt0
# YE9j3HUclZy0LLlsykUk8f6uzHsL4DTLS1pqwoi1tYX/szotvW6fP5eUUxkUD06Y
# GYx8ub+Niq8F5/wT7VYj4cBxs8Pl3Zql4vp0nlBFdgxH0D9APH6ORucjNawa+vCv
# a7yqzSv9vyJXdsOKxpusfrcsz8pdd8UqXRmTwgPxarc8g0gqieLAwP/bECEeq5ZR
# FSKrWF9qYrLUEBVlwUx6jEVgq9JvzL1FP8p9w+WMdP++ani7ytaqL40KGorHm1mU
# JAwaDdWiRgodYGRNoP5aPZNvx1o+e0dRoioF2cL9Eob+6pXG053dN5VVZUgMfGPf
# 9xHfpAI47y+EvSPZEe1T/m7wAIOTBCP58rJGgTXvlCL1+dc3X4Ez68x5zcDMrJF/
# 0QnuAoaZS+XgyWwsCOR9cGHSzNT3rR3Wx/f2lKXklbCMQ+C+sp5UkRFNvYrhCqnk
# tg+sWH54oEKKQ0dTwGG+tsFhn8lsdXzhRKl1jN7w4DVY/R9YZu776biU3yzortfI
# ymbFmfOGmcPSD+lO7S1w+64zjvwnJT+rAzMLuYr3bIuhWpS4rd2phsEyLfcDSXwc
# 51imC2PSnp7Mx51F5qjCXligYC0kHh3BHpxxZok/fHjUVzx2c98=
# =RLJL
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 01 May 2026 04:53:48 AM CST
# gpg: using RSA key 6DC4F9C71F29A6FA06B76D33C481DBBC2C051AC4
# gpg: Good signature from "Heinrich Schuchardt <xypron.glpk@gmx.de>" [unknown]
# gpg: aka "[jpeg image of size 1389]" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4
Richard Genoud [Fri, 27 Mar 2026 14:05:07 +0000 (15:05 +0100)]
mtd: rawnand: sunxi: introduce variable user data length
In Allwinner SoCs, user data can be added in OOB before each ECC data.
For older SoCs like A10, the user data size was the size of a register
(4 bytes) and was mandatory before each ECC step.
So, the A10 OOB Layout is:
[4Bytes USER_DATA_STEP0] [ECC_STEP0 bytes]
[4bytes USER_DATA_STEP1] [ECC_STEP1 bytes]
...
NB: the BBM is stored at the beginning of the USER_DATA_STEP0.
Now, for H6/H616 NAND flash controller, this user data can have a
different size for each step.
So, we are maximizing the user data length to use as many OOB bytes as
possible.
Fixes: 7d1de9801151 ("mtd: rawnand: sunxi_spl: add support for H6/H616 nand controller") Fixes: f163da5e6d26 ("mtd: rawnand: sunxi: add support for H6/H616 nand controller") Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
.clang-format: add U-Boot specific for each macros
Formatting via clang-format is controlled by .clang-format.
For each statements should be formatted with a brace at the line end:
for_each() {
}
This requires clang-format to know that the symbol is not a function
but a for each macro. We use some for each macros which don't exist in
Linux. Add these to file .clang-format.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
doc: bootstd: specify CONFIG_BOOTSTD_DEFAULTS provides network features when NET=y
In the past, we only had one network stack which was called NET. The
network features were enabled for the legacy (and then only) networking
stack since commit 22353fa6b585 ("bootstd: Add some default filesystems
and commands"). Then instead on relying on NET legacy stack for enabling
networking features, the dependencies were (mostly) changed to depend on
CMD_NET in commit a0c739c184ca ("boot: Create a common BOOT_DEFAULTS for
distro and bootstd"). Then a new stack (lwIP) appeared, then CMD_NET was
made available with this new stack in commit 98ad145db61a ("net: lwip:
add DHCP support and dhcp commmand") making the networking features
possible to enable and finally commit f1e978fd54d9 ("boot: Update tests
around network symbols in BOOT_DEFAULTS_CMDS") made it explicit that we
need *a* network stack to enable some networking features.
Align the bootstd documentation with what's actually implemented as
Kconfig dependencies. Note that BOOTSTD_DEFAULTS selects BOOT_DEFAULTS
which selects BOOT_DEFAULTS_CMDS which then selects network features.
The CMDLINE symbol needs to be enabled as well for BOOT_DEFAULTS to
select BOOT_DEFAULTS_CMDS, but I don't think we need to go that far into
explaining what's required to enable some commands.
Reported-by: Simon Glass <sjg@chromium.org> Closes: https://lore.kernel.org/u-boot/CAFLszTgZC1FGy8965pHiG-u=FhrguftRv41ghQ_Qb_RRXx6tyg@mail.gmail.com/ Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
doc: board: ti: k3: Add fTPM support documentation
Add fTPM support documentation including an overview, configuration
steps for RPMB provisioning, OP-TEE TA build instructions, and
verification procedure.
efi_loader: centralize messaging for efi_init_obj_list
If efi_init_obj_list() fails we cannot use the UEFI sub-system.
* Instead of having messages for this everywhere write an error message
in efi_init_obj_list().
* Always use (ret != EFI_SUCCESS) when checking the return value of
efi_init_obj_list().
* Remove the return code from the error message as it does not help
users to understand which initialization went wrong.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add build steps for building U-Boot in secure state with
TF-A and OP-TEE. It includes the full steps for building
OP-TEE and TF-A to use with U-Boot. Also a short description
how to invoke QEMU with enabled EL3 and EL2. EL3 (machine
option secure=on) is required to run TF-A.
Signed-off-by: Johannes Krottmayer <krotti83@proton.me> Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Tom Rini [Tue, 17 Mar 2026 01:24:49 +0000 (19:24 -0600)]
EFI Loader: Correct dependencies for EFI_HTTP_BOOT
As exposed by "make randconfig", we have an issue with the dependencies
for EFI_HTTP_BOOT. As this is implemented by running commands (as seen
by what it selects) it must depend on CMDLINE as well.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Richard Genoud [Fri, 27 Mar 2026 14:05:05 +0000 (15:05 +0100)]
mtd: rawnand: sunxi: make the code mode self-explanatory
In sunxi_nfc_hw_ecc_{read,write}_chunk(), the ECC step was force to 0,
the reason is not trivial to get when reading the code.
The explanation is that, from the NAND flash controller perspective, we
are indeed at step 0 for user data length and ECC errors.
Just add a const value with an explanation to clarify things.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com> Reviewed-By: Michael Trimarchi <michael@amarulasolutions.com> Acked-by: Andre Przywara <andre.przywara@arm.com>
Richard Genoud [Fri, 27 Mar 2026 14:05:04 +0000 (15:05 +0100)]
mtd: rawnand: sunxi: Replace hard coded value by a define
The user data length (4) used all over the code hard coded.
And sometimes, it's not that trivial to know that it's the user data
length and not something else.
Moreover, for the H6/H616 this value is no more fixed by hardware, but
could be modified.
Using a define here makes the code more readable.
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Richard Genoud <richard.genoud@bootlin.com> Acked-by: Andre Przywara <andre.przywara@arm.com>
Yixun Lan [Tue, 21 Apr 2026 04:47:50 +0000 (04:47 +0000)]
spi: sunxi: wait for TX/RX fifo reset done
Once reset SPI TX or RX fifo, the underlying hardware need to take
some time to actually settle down, the two bits will automatically
clear to 0, so use a poll mechanism to check status bits to make sure
it's done correctly.
On Cubie A7A board which using A733 SoC, we encoutered a SPI nor flash
timeout issue, it turns out that the SPI fifo reset take a few time to
settle down, Add a loop to poll the status.
This was the error message shows on A7A board once this issue happened.
=> sf probe
ERROR: sun4i_spi: Timeout transferring data
Failed to initialize SPI flash at 0:0 (error -2)
Signed-off-by: Yixun Lan <dlan@gentoo.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Mon, 27 Apr 2026 13:29:50 +0000 (15:29 +0200)]
sunxi: H616: dram: drop default TPR6 Kconfig value
CONFIG_DRAM_SUNXI_TPR6 is the only DRAM config parameter that has a
non-zero default value. Since we need to provide a value for all the
other parameters anyway, avoiding TPR6 makes no real difference.
To make matters worse, TPR6 is a compound value covering multiple DRAM
types, but also spans over three SoCs, which makes it hard to find one
good default value.
Drop the default from Kconfig, and put some explicit values in the
defconfigs for the few boards that were relying on the default so far.
The value is taken from one BSP, only the lower byte matters anyway for
those boards, all using DDR3 DRAM.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Allwinner's DRAM initialisation code defines a parameter named TPR6,
presumably containing some "Vref" parameter, but containing values for
*all* DRAM types. The runtime code selects one byte based on the DRAM
type used.
This selection code was wrong for LPDDR3, the value is encoded in
bits [23:16], not [15:8]. Fix that in the code, which also aligns it
with the very similar code for the A133 and A523.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reported-by: Philippe Simons <simons.philippe@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Lukas Schmid [Wed, 25 Mar 2026 19:26:09 +0000 (20:26 +0100)]
pinctrl: sunxi: add I2C3 mux for D1/T113-s3 (PG10/PG11)
Boards based on the Allwinner D1/T113-s3, such as the
NetCube Systems Nagami, can expose a third I2C controller
on PG10/PG11. However, the sun20i_d1 pinctrl function table
lacked an entry for this mux.
Add the "i2c3" function with mux value 3 on PG10/PG11, allowing device
trees to enable the I2C3 controller.
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Tue, 7 Apr 2026 22:34:47 +0000 (00:34 +0200)]
sunxi: configs: enable power LEDs on 64-bit boards
We recently gained a simple way to enable a power LED very early in the
SPL boot, through simple Kconfig variables.
Add those symbols to those boards' defconfigs where the DT indicates a
default-on power LED. The number used is <port bank> * 32 + <pin no>,
an active low setup means CONFIG_SPL_SUNXI_LED_STATUS_ACTIVE_HIGH must be
undefined.
This will light up the power LED very early in the (SPL) boot phase on
those 64-bit boards.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Andre Przywara [Tue, 7 Apr 2026 22:34:46 +0000 (00:34 +0200)]
sunxi: configs: enable power LEDs on 32-bit boards
We recently gained a simple way to enable a power LED very early in the
SPL boot, through simple Kconfig variables.
Add those symbols to those boards' defconfigs where the DT indicates a
default-on power LED. The number used is <port bank> * 32 + <pin no>,
an active low setup means CONFIG_SPL_SUNXI_LED_STATUS_ACTIVE_HIGH must be
undefined. Since its default is "high", we can skip the symbol in the
defconfig in this case.
This will light up the power LED very early in the (SPL) boot phase on
those 32-bit boards.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Andre Przywara [Tue, 7 Apr 2026 22:34:45 +0000 (00:34 +0200)]
sunxi: spl: fix SPL_SUNXI_LED active low configuration
The newly introduced Allwinner SPL LED "framework" defined a
SPL_SUNXI_LED_STATUS_STATE Kconfig symbol, that was supposed to denote
the active-low vs. active-high polarity of the LED. However this is
a bool symbol, so it will simply vanish if not defined, and we cannot use
it directly inside a C statement.
Filter the symbol through the IS_ENABLED() macro, which will return 0 if
the symbol is not defined, which is the intended value here.
Since the STATUS_STATE name is a bit confusing, rename it to ACTIVE_HIGH
on the way, because that is its real meaning. Also the LED_STATUS_BIT
name for the GPIO number is similarly a remnant of the old status LED
code, so rename it to LED_STATUS_GPIO as well.
This fixes configuring LEDs with active-low polarity.
Fixes: 256557dd9aae ("sunxi: remove usage of legacy LED API") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Paul Kocialkowski <paulk@sys-base.io> Closes: https://lore.kernel.org/u-boot/adfMQBPdntWy1KIq@shepard/ Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
sunxi: use vendor prefix for $fdtfile on RISC-V too
Once we complete the support for RISC-V Allwinner D1 (sun20i), we will need
to prefix $fdtfile with the vendor prefix to match the Linux device-tree
directory structure.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by: Andre Przywara <andre.przywara@arm.com>
gpio: 74x164: use dev_read_* APIs for live-tree compatibility
With CONFIG_OF_LIVE=y, dev_of_offset(dev) does not return a valid
flat-FDT offset, so fdtdec_get_int(gd->fdt_blob, offset, ...) inside
gen_74x164_probe() fails to locate the "registers-number" property and
always falls back to the default value of 1. This results in a 4-chip
74HC595 daisy chain being exposed as only 8 GPIOs instead of 32, and
any consumer referencing offsets >= 8 fails to bind with -ENOENT
("GPIO ... not found" / Error -22).
The "registers-default" property is ignored for the same reason, so
any configured power-on output pattern is silently discarded.
Replace the flat-FDT helpers with dev_read_u32_default() and
dev_read_u8_array_ptr(), which correctly walk both live and flat
trees. This matches how other DM GPIO drivers (e.g. pca953x_gpio.c)
read their per-device properties.
With gd->fdt_blob no longer referenced, also drop the now-unused
DECLARE_GLOBAL_DATA_PTR and <asm/global_data.h> include.
Tested on stm32mp153d-ssonic (CONFIG_OF_LIVE=y) with a 4-chip 74HC595
chain: all 32 GPIOs are now exposed, and 16 consumer LED nodes at
offsets 0..31 bind successfully.
The build issues found in dtc/yamltree were partially mitigated by a
previous commit (807bcd844a: "scripts/dtc: Fix pkg-config behavior under
sysroot"), but upstream dtc simply disabled yaml, and the same should be
done here in order to permanently avoid those issues.
Backport the change below from Linux v5.18 [1]:
ef8795f3f1c ("dt-bindings: kbuild: Use DTB files for validation")
I tested this patch with a couple Yocto builds: u-boot and u-boot-tools,
using the current master branch (rev. "c53b0708f9"), having removed
libyaml-native from u-boot-tools's dependencies.
Dario Binacchi [Wed, 25 Feb 2026 16:17:00 +0000 (17:17 +0100)]
video: support Rocktech RK050HR345-CT106A panel
Add support for the Rocktech RK050HR345-CT106A RGB panel. This model
uses an Ilitek ILI9806E controller over the SPI bus for initialization
and register configuration only.
The driver is designed to be easily extensible to support other panels
with different sequences and timings by providing a specific descriptor
structure for each model.
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>
projects / thirdparty / u-boot.git / log
