When compiling for R5 with CONFIG_TI_PRUSS enabled, the
pruss_probe() function passed a u64* to ofnode_get_addr_size_index(),
which expects an fdt_size_t*. This caused a compiler error
about incompatible pointer types.
Cast the size pointer to fdt_size_t* to match the function
signature.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
passing 'size' (ulong) to ti_secure_image_post_process() caused
a type mismatch compiler error.
On platforms where ulong and size_t differ in size, directly
casting could lead to out-of-bounds memory access. Fix by
introducing a size_t temporary variable, passing it to the
function, and writing back the potentially modified value for
use in subsequent calls.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch> Acked-by: Andrew Davis <afd@ti.com>
The device tree contained a duplicate DT node 'main_mmc1_pins_default',
which was already defined a few lines below. This patch removes the
redundant entry.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch> Reviewed-by: Anshul Dalal <anshuld@ti.com>
Partially reverted commit "soc: qcom: cmd-db: drop unused
functions" by restoring only the cmd_db_read_slave_id() and
cmd_db_read_aux_data() functions, which were removed in that
commit. These functions are required for the RPMH Power Domain
Driver.
dhelectronics:
- Move dh_add_item_number_and_serial_to_env() to common code
- Read values from M24256 write-lockable page on STM32MP13xx DHCOR
- Add MAC address readout from fuses on DH STM32MP1 DHSOM
- Keep the reg11 and reg18 regulators always enabled on STM32MP13xx DHCOR.
- Fix boot for stm32mp15xx-dhsom.
- Fix build of ST DFU virt code on DH STM32MP1 DHSOM
- Introduce DH STM32MP13x target.
STM32MP2:
- Add support for stm32mp257-dk board.
- Fix arm, smc-id value for stm32mp23/25.
- Fix stm32mp235f-dk boot (add syscon compatible, add txbyteclk).
- Add display support:
- Introduce LVDS driver.
- Add LTDC support.
- Add Ethernet support for stm32mp255.
STM32MP13:
- Add ADC support.
- Add power check for stm32mp135f-dk board.
Marek Vasut [Thu, 23 Oct 2025 21:48:26 +0000 (23:48 +0200)]
ARM: stm32: Add MAC address readout from fuses on DH STM32MP1 DHSOM
Add support for reading out the MAC address from SoC fuses on DH STM32MP1 DHSOM.
The DH STM32MP1 DHSOM may contain external ethernet MACs, which benefit from the
MAC address stored in SoC fuses as well, handle those consistently. This however
means the architecture setup_mac_address() cannot be used and instead a simpler
local fuse read out is implemented in the board file.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Thu, 23 Oct 2025 21:48:25 +0000 (23:48 +0200)]
ARM: stm32: Read values from M24256 write-lockable page on STM32MP13xx DHCOR
The STM32MP13xx DHCOR SoM is populated with M24256 EEPROM that contains
an additional write-lockable page called ID page, which is populated with
a structure containing ethernet MAC addresses, DH item number and DH serial
number.
Read out the MAC address from the WL page between higher priority SoC fuses
and lower priority plain EEPROM storage area. Read out the DH item and serial
numbers and set environment variables accordingly.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Fri, 31 Oct 2025 04:16:09 +0000 (05:16 +0100)]
ARM: stm32: Add missing build of ST DFU virt code on DH STM32MP1 DHSOM
Commit 6d91f0a3a14d ("board: st: common: cleanup dfu support") split
the vendor-specific DFU implementation into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
with plain simple dfu-util, but it makes the ST proprietary programmer
CLI tool end in an infinite loop. Update the Makefile accordingly to
allow even that kind of tooling to work.
Marek Vasut [Thu, 23 Oct 2025 21:46:05 +0000 (23:46 +0200)]
ARM: dts: stm32: Fix STM32MP15xx DHSOM boot breakage due to ETZPC
Switch etzpc bus to simple-bus to prevent breakage on non-TFA systems.
This fixes boot of every STM32MP15xx DHSOM device.
Fixes: ad3cdc677dda ("ARM: stm32mp: add ETZPC system bus driver for STM32MP1") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Asadeds [Tue, 28 Oct 2025 05:39:26 +0000 (11:09 +0530)]
arm: stm32mp25: add ethernet support for stm32mp255 series
Add missing CPU_STM32MP255* cases in get_eth_nb() so that U-Boot
correctly reports 2 Ethernet interfaces on stm32mp255 devices.
This fixes the "ethernet not found" error during boot.
video: stm32: ltdc: properly search the first available panel
Initially there was only one DSI bridge with one panel attached to this
device. This explained the call to uclass_first_device_err(UCLASS_PANEL,
...) which worked fine at the time.
Now that multiple bridges and panels, with different technologies, can
be plugged onto the board this way to get the panel device is outdated.
The lookup is done is two steps. First we circle through the
UCLASS_VIDEO_BRIDGE, and once we get one, we search through its
endpoints until we get a UCLASS_PANEL device available.
video: stm32: ltdc: support new hardware version for STM32MP25 SoC
STM32MP2 SoCs feature a new version of the LTDC IP. This new version
features a bus clock, as well as a 150MHz pad frequency. Add its
compatible to the list of device to probe and handle quirks. The new
hardware version features a bus clock.
The LVDS Display Interface Transmitter handles the LVDS protocol:
it maps the pixels received from the upstream Pixel-DMA (LTDC)
onto the LVDS PHY.
The LVDS controller driver supports the following high-level features:
• FDP-Link-I and OpenLDI (v0.95) protocols
• Single-Link or Dual-Link operation
• Single-Display or Double-Display (with the same content
duplicated on both)
• Flexible Bit-Mapping, including JEIDA and VESA
• RGB888 or RGB666 output
• Synchronous design, with one input pixel per clock cycle
• No resolution limitation.
video: simple_panel: add support for "panel-lvds" display
Add the compatible "panel-lvds" for simple-panel driver in U-Boot. In
Linux this compatible is managed by the driver
drivers/gpu/drm/panel/panel-lvds.c but in U-Boot the specific LVDS
features (bus_format/bus_flags) are not supported.
ofnode: support panel-timings in ofnode_decode_display_timing
The "Display Timings" in panel-common.yaml can be provided by 2 properties
- panel-timing: when display panels are restricted to a single resolution
the "panel-timing" node expresses the required timings.
- display-timings: several resolutions with different timings are supported
with several timing subnode of "display-timings" node
This patch update the parsing function to handle this 2 possibility
when index = 0.
Olivier Moysan [Fri, 14 Nov 2025 16:08:52 +0000 (17:08 +0100)]
adc: stm32mp13: add support of adc to stm32mp13
Add support of STM32 ADCs to STM32MP13x. This patch introduces
stm32_adc_regspec structure, as this is already done in kernel
driver, to manage smartly the differences in register set
between STMP32MP15 and STM32MP13 ADCs.
Tom Rini [Wed, 12 Nov 2025 21:18:41 +0000 (15:18 -0600)]
ufs: rcar-gen5: Use a unique U_BOOT_DRIVER name
All instances of U_BOOT_DRIVER must be unique or we will have link time
failures. It is possible to enable both ufs-renesas-rcar.c and
ufs-renesas-rcar-gen5.c at the same time, so give
ufs-renesas-rcar-gen5.c a new unique U_BOOT_DRIVER name.
Fixes: 3351fe7ecc1a ("ufs: Add UFS driver for Renesas R-Car X5H") Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://patch.msgid.link/20251112211841.1428696-1-trini@konsulko.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
* Correct the linux/arm64 platform string for Docker builds
* Complete pytest dependencies list with missing packages
UEFI:
* Use Sphinx style comments in efi_selftest_console.c
* Don't include asm/global_data.h in lib/efi_client/efi_app.c twice
* efi_client: correct memset() return value
* Assure fitImage from capsule is used from 8-byte aligned address
* Fix warning when building efi_selftest_snp with clang
Marek Vasut [Thu, 13 Nov 2025 11:55:49 +0000 (12:55 +0100)]
efi_loader: Assure fitImage from capsule is used from 8-byte aligned address
The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Thu, 6 Nov 2025 23:28:39 +0000 (17:28 -0600)]
efi_selftest: efi_selftest_snp: Fix warning when building with clang
When building with clang, we see a warning:
lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within
'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due
to 'struct dhcp' being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by
packing struct dhcp_hdr as well, as the only place it is used also is
packed.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Rev.0.81 of the R-Car V4M Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Huy Bui [Fri, 7 Nov 2025 16:16:56 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779h0: Remove CC5_OSCOUT
Rev.0.71 of the R-Car V4M Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Huy Bui [Fri, 7 Nov 2025 16:16:55 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove STPWT_EXTFXR
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Huy Bui [Fri, 7 Nov 2025 16:16:54 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove CC5_OSCOUT
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Thanh Quan [Fri, 7 Nov 2025 16:16:53 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove AVB[01]_MII
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"AVB[01]_MII_*" signals from the pin control register tables. As these
are further unused in the pin control driver, they can be removed
safely.
Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tom Rini [Fri, 26 Sep 2025 15:30:34 +0000 (09:30 -0600)]
usb: gadget: Tighten CI_UDC dependencies
This driver cannot build when DM_USB_GADGET is enabled as both options
control building of files that use the same global namespace and
functionality. In this case make CI_UDC depend on DM_USB_GADGET being
disabled as non-DM support is the legacy choice.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tom Rini [Fri, 26 Sep 2025 15:30:33 +0000 (09:30 -0600)]
usb: host: xhci: Make U_BOOT_DRIVER entries unique
All instances of the U_BOOT_DRIVER must use a unique name or they will
lead to link time failures due to name space conflicts when both are
present. Most of the XHCI drivers follow pattern of xhci_xxx in their
name, but a few used "usb_xhci". Change these to follow the pattern of
the rest of the XHCI glue drivers.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Peter Robinson [Fri, 26 Sep 2025 15:30:31 +0000 (09:30 -0600)]
usb: musb: drop musb legacy drivers
The last of the users of the legacy musb drivers have been
migrated so now remove the old musb stack, all users should
now be using the new musb stack if they need this functionality.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[trini: Remove a Makefile reference that was missed in v1] Signed-off-by: Tom Rini <trini@konsulko.com>
Peter Robinson [Fri, 26 Sep 2025 15:30:30 +0000 (09:30 -0600)]
omap3: evm: Drop old musb omap3 driver
The USB_OMAP3 driver was (re)added in commit e74e9f620a6 as part
of migrating to DM_USB but the config already had MUSB_OMAP2PLUS
which is the newer musb driver and what other omap3 devices use.
So drop it so we can drop the old driver.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Tom Rini [Fri, 3 Oct 2025 20:39:22 +0000 (14:39 -0600)]
usb: gadget: spl: Add missing dependency for SPL_USB_GADGET
It makes no sense to ask about nor enable SPL_USB_GADGET without
SPL_FRAMEWORK being enabled. Attempting to do so leads to Kconfig noting
dependency issues. Add the missing dependency.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tom Rini [Wed, 12 Nov 2025 15:42:50 +0000 (09:42 -0600)]
Merge patch series "ti: add speed grades support for AM62a"
Anshul Dalal <anshuld@ti.com> says:
TI offers SoCs in various speed grades, each speed grade specifies a
certain maximum operating frequency of the clocks for each core.
In K3's boot flow, the R5 SPL starts the A53 or A72 core and configures
the correct clocks and power using the K3 ARM64 rproc driver
(compatible: ti,am654-rproc). However, the driver expects the dt node
for the ARM64 core to be set with a correct "assigned-clock-rates"
value.
Currently the dt has a value of 1.2GHz for the A53 core on AM62a, this
is incorrect for lower speed grades. Therefore this patch set adds
support for fixing this value at runtime based on the detected speed
grade from the efuse MMR.
For the speed grade table, refer to Table 6-1 of the AM62a datasheet.
Anshul Dalal [Thu, 30 Oct 2025 13:03:22 +0000 (18:33 +0530)]
mach-k3: am62a: add support for speed grades
Speed grades indicate the maximum operating frequency of any core on the
SoC. This patch adds support for the same to AM62a, this allows the A53
core to be started with the correct frequency by the R5 SPL.
The K3 ARM64 rproc driver uses the "assigned-clock-rates" value in the
respective "/a53@0" node to properly configure the clocks for the A53
core.
Although the clock value in the DT node might need to be fixed based on
SoC's speed grade at runtime. Certain SoCs such as AM62p and AM62x
already had this implemented, this patch moves the common code to
common.c to avoid duplication and simplify speed grade handling.
The logic to detect the correct entry in the "assigned-clock-rates"
property has also changed. Where we earlier relied on per SoC specific
device and clock IDs for the A53 core, we now use the "clock-names"
property which is device agnostic.
fdt_fixup_cpu_freq_nodes_am62p is used to delete unsupported opp table
entries at runtime based on the SoC's speed grade.
However, the ti-cpufreq driver in kernel already has support for
rejecting unsupported entries. Therefore this fdt fixup is not necessary
and can be dropped.
Fixes: 8d05cbef73ae ("arm: mach-k3: am62p: Fixup a53 max cpu frequency by speed-grade") Signed-off-by: Anshul Dalal <anshuld@ti.com>
Add the compatible string of Exynos7's PMU as defined in upstream
dt-schema. This also supports derivative PMUs as defined in schema.
There's no additional setup required here, so pmu_init is skipped.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add the compatible for Exynos8895 UART as described in upstream
devicetree bindings. This enables support for Exynos8895 and other
similar UART devices, such as Exynos7870. Other than that, the driver
works as-is.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Henrik Grimler <henrik@grimler.se> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
pinctrl: exynos78x0: add proper support for exynos7870 pinctrl
The pinctrl blocks for Exynos7870 and Exynos7880 are similar, however in
Exynos7870, the CCORE block is actually referred to as MIF. Since
ordering happens lexically, it isn't directly compatible with
samsung,exynos78x0-pinctrl.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
pinctrl: exynos: bind GPIO driver along with pinctrl
The devicetree of Samsung devices typically have the pin controller and
GPIO bank descriptors under the same pinctrl node. In U-Boot, these are
handled by two separate drivers. It is not possible to invoke both
drivers from a single node compatible.
Bind the GPIO driver on pinctrl driver bind, with the same OF node as
the pinctrl driver. This solution is already being used in other pinctrl
drivers. The hierarchy, as represented in `dm tree`, is as follows:
There may be cases where the flags set for a clock is not available.
This is usually the case with clocks which have been retrieved using
clk_request(). However, clock flags are found in their respective
private clock struct, so use that instead.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Introduce a simple clock driver for Exynos7870's CMU blocks, more
specifically, CMU_MIF, CMU_FSYS, and CMU_PERI banks. This should be
enough to serve U-Boot's minimal requirements.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
clk: exynos: add function for Samsung CMU ops->request
The request function performs a simple check if the clock with the
provided ID is present or not. This is done with a simple call to
clk_get_by_id(). A non-zero return value indicates that the requested
clock is not available.
In some cases, clk->dev points to the clock bank device instead of
the clock device. This pointer is therefore overwritten in order to
reference to the correct device instance.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
PLL1417X seem to be compatible with PLL0822X, as also seen in the
respective Linux kernel driver. Add an enum entry for the type, while
merely being an alias for PLL0822X.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
clk: exynos: add support for fixed rate and fixed factor clocks
Add register functions for fixed rate and fixed factor clock drivers.
The vendor-specific structs defined are borrowed from the CCF driver
found in the Linux kernel.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
clk: exynos: provide device pointer to clk_register_* functions
The device pointer set as NULL causes problems when clock banks depend
on clocks from another clock bank. In such case, the appropriate clock
needs to be resolved from OF phandle arguments, which is not possible if
the associated device is not provided. Make necessary changes to make
the correct device pointer available.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Tom Rini [Tue, 11 Nov 2025 20:53:47 +0000 (14:53 -0600)]
Merge patch series "reenable dm_gpio tests, add support for gpio-line-names lookup"
Rasmus Villemoes <ravi@prevas.dk> says:
Hopefully third time's the charm.
I merely wanted to add support (mostly for use by the 'gpio' shell
command) for looking up a gpio via the gpio-line-names DT property. We
already have a "gpio_request_by_line_name()", but cmd/gpio.c does a
separate "lookup + request", so it felt more natural to teach the
lookup machinery this as well. That ran into
OF_CONTROL-but-not-OF_LIBFDT being a thing for SPL, so here's yet
another attempt.
Now, when trying to do my civic duty and add tests for this, I found
that test/dm/gpio.c has been defunct for a couple of years, and
reinstating it is not entirely trivial.
After a couple of rounds CI is now happy with this:
https://github.com/u-boot/u-boot/pull/828
gpio: search gpio-line-names property in dm_gpio_lookup_name
In scripts as well as interactively, it's much nicer to be able to
refer to GPIOs via their names defined in the device tree property
"gpio-line-names", instead of the rather opaque names derived from the
bank name with a _xx suffix. E.g.
gpio read factory_reset FACTORY_RESET
if test $factory_reset = 1 ; then ...
versus
gpio read factory_reset gpio@481ac000_16
if test $factory_reset = 1 ; then ...
This is also consistent with the move on the linux/userspace side towards
using line names instead of legacy chip+offset or the even more legacy
global gpio numbering in sysfs.
As dev_read_stringlist_search() depends on both OF_CONTROL and
OF_LIBFDT (which matters for the SPL case), we need some .config
conditional. However, it only adds about ~50 bytes of code to U-Boot
proper, and dm_gpio_lookup_name() most often ends up being GC'ed for
SPL, thus adds no overhead there, so for now make it a hidden symbol
which is merely a convenient shorthand for
CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(OF_LIBFDT).
Commit ebaa3d053e5 ("test: fix CONFIG_ACPIGEN dependencies"), which
got into v2022.10-rc1, accidentally left out a $
before (CONFIG_DM_GPIO), with the effect that test/dm/gpio.c has not
been built for three years.
Unsurprisingly, the code in there has bit-rotted.
- There's a missing ; causing plain build fail.
That code was added in 9bf87e256c2 ("test: dm: update test for
open-drain/open-source emulation in gpio-uclass"), which was part of
v2020.07-rc3, i.e. long before the commit causing gpio.c to not be
built at all. It did build at that time, but also, the missing
semicolon wasn't found when fa847bb409d ("test: Wrap assert macros
in ({ ... }) and fix missing semicolons") happened in 2023.
- Commit 592b6f394ae ("led: add function naming option from linux")
bumped sandbox,gpio-count for bank gpio_a in test.dts to 25, but
didn't update the expected global gpio numbers accordingly.
- The "lookup by label" test likely worked when it was added, but then I
inadvertently broke it when I noticed that dm_gpio_lookup_label()
seemed to be broken in commit 10e66449d7e ("gpio-uclass: fix gpio
lookup by label") - which landed in v2023.01-rc1, so after gpio.c
was no longer being built.
The "label" (which is a u-boot concept) that a "hogged gpio" gets is
<gpio hog node name>.gpio-hog, which is why it used to work with the
strncmp() but doesn't with strcmp().
We can either revert 10e66449d7e or append the ".gpio-hog" suffix as
done below. I don't really have a dog in that race; when I did 10e66449d7e, it was because I thought the "lookup by label" was
actually about the standardized gpio-line-names property, but then I
learnt it was not, so is not at all useful to me.
And it fails with the same differences (160/176) even if I
remove the three lines that actually exercise any of the gpio code,
i.e. make the whole function amount to
So I suspect that the leak is somewhere in the test framework
setup/teardown code - dm_leack_check_end() isn't really used
anywhere else except in a dm/core test. Bisecting to figure out
where that was introduced is somewhat of a hassle because of the
other bitrot, and because of the SWIG failure that makes it very
hard to build older U-Boots.
So since it's better to have most of the gpio tests actually
working instead of leaving all of gpio.c as dead code, #if 0 that
part out and leave it as an archeological exercise.
Tom Rini [Tue, 11 Nov 2025 20:53:33 +0000 (14:53 -0600)]
Merge patch series "rsa: fix dependency, rename and relocate RSASSA PSS symbols"
Quentin Schulz <foss+uboot@0leil.net> says:
While historically signature verification is mostly done for FIT such
FIT_SIGNATURE dependency for signature algorithm makes sense, it isn't
the only kind of file we can verify signatures of. It can also be done
manually with rsa_verify_hash() with an embedded public key.
Considering the impacted code is guarded by RSA_VERIFY, let's make the
symbol depend on that otherwise selecting it without RSA_VERIFY won't do
anything. The FIT_SIGNATURE dependency wasn't also enough before as it
only implied RSA_VERIFY.
Then, simply relocate the RSA SSA PSS padding with the other RSA symbols
in lib/rsa instead of in boot/ and rename it to remove the mention to
FIT.
Finally, add the PSS padding wherever PKCS1.5 padding is specified as
one or the other can be used.
Quentin Schulz [Fri, 31 Oct 2025 17:08:24 +0000 (18:08 +0100)]
rsa: update doxygen doc for RSA signature verification to mention PSS
While the verification step originally only supported PKCS1.5 as padding
algorithm for the signature, it was later extended to add support for
PSS but the doxygen doc wasn't updated to reflect that so let's fix
that oversight.
Fixes: 061daa0b61f0 ("rsa: add support of padding pss") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Quentin Schulz [Fri, 31 Oct 2025 17:08:23 +0000 (18:08 +0100)]
rsa: rename FIT_RSASSA_PSS to RSASSA_PSS and move symbols under lib/rsa
This renames FIT_RSASSA_PSS symbols to drop the FIT_ prefix to avoid
potential confusion since there's nothing FIT specific to those symbols.
It also isn't really related to booting, so boot/Kconfig is an odd place
for them to live. Since they make sense only in relation with RSA,
simply move them to lib/rsa where it makes more sense for them to
reside.
Quentin Schulz [Fri, 31 Oct 2025 17:08:20 +0000 (18:08 +0100)]
boot: fix incorrect dependency of FIT_RSASSA_PSS
This padding has nothing to do with FIT except that we can make use of
it when verifying the FIT signatures.
This padding can also be used to verify the signature "manually" e.g. by
calling rsa_verify_hash() directly with an embedded public key.
Additionally, this padding is only useful if RSA (and specifically
RSA_VERIFY) is enabled otherwise it's not used.
The only other place it's used is in rsa-sign.c which is only built for
the host tools and handled by TOOLS_FIT_RSASSA_PSS symbol instead, so no
need to care for that one.
Finally, the FIT_SIGNATURE dependency also wasn't enough because it only
implies RSA_VERIFY, meaning it can be disabled and still have
FIT_RSASSA_PSS enabled.
So add a dependency on RSA_VERIFY and reword the input prompt.
Tom Rini [Thu, 6 Nov 2025 23:28:35 +0000 (17:28 -0600)]
Gitlab: Optimize the job dependency list more
In general, we want to fail the whole pipeline as soon as we can if we
spot an error while also letting bigger jobs get started as soon as
possible. Currently we use the "Run binman, buildman, dtoc, Kconfig and
patman testsuites" job from the testsuite stage to unblock the next
stage as this test is complex enough that if it passes, likely the whole
stager will pass. Using this same logic, unblock the world build (and
sjg-lab) stages if "sandbox test.py" has completed as if there's no
failures here, there's likely not failures in the rest of the test.py
stages.
Bin Meng [Wed, 5 Nov 2025 11:07:24 +0000 (19:07 +0800)]
scsi: Fix the name string memory leak during scsi scan
There is a memory leak during the scsi scan process due to the
strdup'ed name string is never freed. Actually it is unnecessary
to pass a strdup'ed name string to blk_create_devicef() as we can
use the name string on the stack directly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
qfw: Fix segfault from uninitialized variables in sandbox
There are cases where qfw_read_entry() does not set the output parameter
passed by address. This occurs with qfw_sandbox_read_entry_dma, which
leaves the size variables uninitialized and causes a segfault when running
bootflow scan in U-Boot sandbox.
$ ./u-boot
...
U-Boot 2026.01-rc1-00199-gc2637036b8f0 (Nov 04 2025 - 10:32:21 +0100)
...
Hit any key to stop autoboot: 0
=> bootflow scan
efi_var_to_file() Cannot persist EFI variables without system partition
efi_tcg2_register() Missing TPMv2 device for EFI_TCG_PROTOCOL
efi_rng_register() Missing RNG device for EFI_RNG_PROTOCOL
scanning bus for devices...
[3] 1015761 segmentation fault (core dumped) ./u-boot
Initalize all these variables to 0 to fix this issue.
- Support scmi v3.2 CONFIG_SET for clock protocol
- A patchset from Marek to optimize the scmi clk booting time
- Fix scmi clk set_parent in non-CCF case
- Drop mmu_set_region_dcache_behaviour in firmware scmi
Tom Rini [Sat, 1 Nov 2025 15:32:01 +0000 (09:32 -0600)]
CI: Move to Ubuntu 24.04 'Noble' as the base
The changes here are that we need to ensure python setuptools are
in our build virtual environments as they will no longer come in via
python even in a virtual environment. As part of this ensure setuptools
is in our cache and also include pytest-azurepipelines as we should have
been doing. Next, we move away from using apt-key directly and move that
stanza towards the rest of the apt work. This also lets us drop
directly installing gnupg2. These steps are not strictly required for
24.04 but will be for later releases and are valid now. Finally, we drop
the unused PTYHONPATH ENV line.
In order to use these containers however, we need to stop running the
event_dump test as the 'addr2line' tool provided by binutils no longer
is able to decode those specific events in most cases. As this is a
problem with binutils and present for some time now, disabling the test
until someone has time to work with upstream this seems reasonable.
Tom Rini [Sun, 2 Nov 2025 20:08:12 +0000 (14:08 -0600)]
dm: Remove pre-schema tag support
Support for using "u-boot,dm-..." rather than "bootph-..." has been
deprecated since February 2023. Any platforms using this have had a
console message saying to migrate by 2023.07. Go and remove all support
here now, for the v2026.01 release.
The results of this change that aren't clear from the above are that we
still have a checkpatch.pl error message, and document in
doc/develop/spl.rst that they have been migrated since 2023. We also
change the key2dtsi.py tool to use the correct bootph phase rather than
the legacy phase.
Marek Vasut [Sun, 9 Nov 2025 01:35:09 +0000 (02:35 +0100)]
clk: scmi: Defer issue of SCMI_CLOCK_ATTRIBUTES
Instead of resolving clock control flags using SCMI_CLOCK_ATTRIBUTES
during probe for each and every clock, resolve the clock control
flags using SCMI_CLOCK_ATTRIBUTES when the clock control flags are
first used. Because most clock are never used by U-Boot, this allows
reducing the amount of SCMI_CLOCK_ATTRIBUTES considerably, and this
improve probe time of the scmi clock driver and U-Boot start up time.
On Renesas X5H, with 1700+ SCMI clock, the boot time improved by 1.7s .
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Sun, 9 Nov 2025 01:35:08 +0000 (02:35 +0100)]
clk: scmi: Postpone clock name resolution
The clock names are retrived via SCMI_CLOCK_ATTRIBUTES, called for each
clock ID. This may take a lot of time to complete and is not strictly
necessary. Register each clock as "scmi-%zu" instead, and let the first
call of SCMI_CLOCK_ATTRIBUTES fill in the actual clock name.
This has a side effect, which can be considered both an upside and also
a downside. Unused clock are never renamed and retain their placeholder
"scmi-%zu" name, which avoids empty clock names for nameless SCMI clock,
and avoids the name resolution and improves boot time. But for those
SCMI clock which do have name, that name is not listed until the clock
are used.
This is a preparatory patch for deferred issue of SCMI_CLOCK_ATTRIBUTES.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Sun, 9 Nov 2025 01:35:06 +0000 (02:35 +0100)]
clk: scmi: Bulk allocate all sub-driver instance data
Allocate all sub-driver instance data at once. The amount of data that
have to be allocated is known up front, so is the size of the data, so
there is no need to call malloc() in a loop, mallocate all data at once.
The upside is, less heap fragmentation and fewer malloc() calls overall,
and a faster boot time.
The downside is, if some of the clock fail to register, then the clock
driver cannot free parts of the bulk allocated sub-driver instance data.
Such a failure can only occur if clk_register() were to fail, and if that
happens, the system has more significant problems. Worse, if a core clock
driver fails to probe, the system has even bigger problem.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Vinh Nguyen [Wed, 5 Nov 2025 03:42:26 +0000 (04:42 +0100)]
firmware: scmi: Add clock v3.2 CONFIG_SET support
SCMI v3.2 introduces a new clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests. Add support to use such new format when
talking to a v3.2 compliant SCMI platform.
Support existing enable/disable operations across different clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.
No functional change for the SCMI drivers users of the related enable and
disable clock operations.
[Marek: Remodel after Linux e49e314a2cf7 ("firmware: arm_scmi: Add clock v3.2 CONFIG_SET support")
Support both old < 2.1 and new >= 2.1 protocol versions.
Update commit message based on Linux one]
Signed-off-by: Vinh Nguyen <vinh.nguyen.xz@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Alice Guo <alice.guo@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Sat, 25 Oct 2025 21:35:09 +0000 (23:35 +0200)]
firmware: scmi: Drop mmu_set_region_dcache_behaviour() misuse
MMU region cache behavior configuration for SCMI/SMT mailboxes is
platform specific. Even on ARM systems, the mailbox memory may not
even be located in any cacheable MMU region and may instead reside
in some SRAM. Remove this non-generic cache behavior configuration
code from generic code path.
It is unlikely that any platform is affected by this change if it
did configure its MMU regions correctly on start up. Platforms
which might be affected are i.MX94/95 and STM32MP.
Fixes: 240720e9052f ("firmware: scmi: mailbox/smt agent device") Fixes: 2a3f161c8b16 ("scmi: correctly configure MMU for SCMI buffer") Fixes: b2ae10970d40 ("firmware: scmi: use PAGE_SIZE alignment for ARM64") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Tested-by: Alice Guo <alice.guo@nxp.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
projects / thirdparty / u-boot.git / log
