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>
Tom Rini [Fri, 7 Nov 2025 22:10:49 +0000 (16:10 -0600)]
Merge patch series "Add support for TI AM6254atl SiP"
Anshul Dalal <anshuld@ti.com> says:
This patch series adds support for AM6254atl SiP (or AM62x SiP for
short) to U-Boot.
The OPN (Orderable Part Number) 'AM6254atl' expands as follows[1]:
AM6254atl
||||
|||+-- Feature Lookup (L indicates 512MiB of integrated LPDDR4)
||+--- Device Speed Grade (T indicates 1.25GHz on A53 cores)
|+---- Silicon PG Revision (A indicates SR 1.0)
+----- Core configuration (4 indicates A53's in Quad core config)
AM62x SiP provides the existing AM62x SoC with 512MiB of DDR
integrated in a single packages. The first 4 patches in the series
are cherry-picked from the devicetree-rebasing repository at
'v6.18-rc2-dts'.
Tom Rini [Fri, 7 Nov 2025 22:09:39 +0000 (16:09 -0600)]
Merge patch series "Add PCIe Endpoint controller support for TI J784S4 SoC"
Hrushikesh Salunke <h-salunke@ti.com> says:
This series enables PCIe Endpoint mode on TI's J784S4 SoC. The J784S4
SoC features two Cadence PCIe controller instances (PCIe0 and PCIe1)
that can operate in endpoint mode. This series adds support for
configuring these controllers with up to 4 lanes.
Key changes include:
- Adding a stabilization delay after power domain reset to prevent
timing-related initialization issues
- SERDES mux configuration support for proper lane routing, which is
essential for SoCs where SERDES lanes are shared between multiple
controllers (PCIe, USB, etc.) with different configurations across
boot phases
- J784S4 SoC endpoint configuration with 4-lane support
- Disabling unconfigured endpoint functions to prevent enumeration
issues on the Root Complex side
This series has been tested on J784S4 EVM with PCIe endpoint boot
configuration. Following are the corresponding test logs.
Tom Rini [Fri, 7 Nov 2025 22:08:37 +0000 (16:08 -0600)]
Merge patch series "board: ti: am62x: Add EEPROM support and refactor board detection"
Guillaume La Roque (TI.com) <glaroque@baylibre.com> says:
This series adds EEPROM board detection support for AM62x and refactors
the board detection code across AM6x family boards to eliminate code
duplication.
The series introduces two new generic functions for AM6x boards:
- do_board_detect_am6(): Reads the on-board EEPROM with fallback logic
to alternate I2C addresses
- setup_serial_am6(): Sets up the serial number environment variable
from EEPROM data
This patch series adds basic support for the boards based on Airoha
EN7523/EN7529/EN7562 SoCs. Due to ATF restrictions these boards are
able to run 32-bit OS only.
This patch series adds support for the following hardware:
* console UART
* ethernet controller/switch
* spinand flash (in non-dma mode)
The following issues may be expected:
* Extra slow UBI attaching in U-Boot (up to 20 sec with fastmap enabled).
This is caused by the lack of DMA support in the U-Boot airoha-snfi driver.
* Linux airoha-snfi driver in some cases might damage you flash data
(see: https://lore.kernel.org/lkml/20251012121707.2296160-15-mikhail.kshevetskiy@iopsys.eu/)
* Latest linux kernel is recommended to properly support flashes
with more than one plane per lun
(see: https://lore.kernel.org/lkml/20251012121707.2296160-7-mikhail.kshevetskiy@iopsys.eu/)
* It's NOT recommended to use flashes working in continuous mode because
U-Boot airoha-snfi driver does not support such flashes properly.
The patches was tested on the board:
- SoC: Airoha EN7562
- RAM: 512 MB
- SPI NAND: 4 Gbit, made by Toshiba
- Linux boot: was NOT tested
The U-Boot was chain-loaded from the running U-Boot. Airoha ATF-2.3 does
not allow easily chain-loading of U-Boot from U-Boot, so a special FIT
image (mimic linux kernel) was created
1) Create u-boot.its file with the following contents:
Anshul Dalal [Sat, 25 Oct 2025 02:48:11 +0000 (08:18 +0530)]
ti: add support for AM6254atl SiP
TI's AM6254atl (or AM62x SiP for short) provides the existing AM62x SoC
with 512MiB of DDR integrated in a single package.
This patch adds the necessary U-Boot devie tree files, the required
defconfigs along with the documentation for the AM62x SiP EVM.
AM62x SiP differs from the already supported AM62x in following ways:
- OP-TEE for the AM62x resides from 0x9e800000 to 0xa0000000 which needs
to be moved to 0x80080000 to free up space at end of DDR in AM62x SiP
with 512MiB of memory. This is required to allow U-Boot to relocate to
end of DDR before booting to the kernel.
- Changes to the env:
1. splashimage address updated from 0x80200000 to 0x81a00000
2. DFU addresses updated to match updated TEXT_BASE for SPL and U-Boot
Anshul Dalal [Sat, 25 Oct 2025 02:48:10 +0000 (08:18 +0530)]
arm64: dts: ti: Add support for AM6254atl SiP SK
This patch adds the dt for SK-AM62-SIP, which uses the existing
SK-AM62 board design with the new AM6254atl SiP. This changes the
location of memory node from the board dts to SoC level dtsi
(k3-am6254atl in our case).
Therefore this patch introduces the new 'k3-am625-sk-common.dtsi'
which represents the common hardware used for both 'am625-sk' and
'am6254atl-sk' boards with the inheritance hierarchy modified to:
Anshul Dalal [Sat, 25 Oct 2025 02:48:08 +0000 (08:18 +0530)]
arm64: dts: ti: k3-am62*: remove SoC dtsi from common dtsi
The k3-am62x-sk-common dtsi represents the common hardware used across
am62x EVMs which can be configured with various DDR sizes or none (with
DDR integrated in the package) based on the specific am62x SoC used.
Therefore this patch moves the memory node and the SoC specific k3-am625
dtsi out of sk-common and into the board dts files. No functional change
is intended from this patch. The device-tree inheritance is changed as
follows:
Beleswar Padhi [Sat, 25 Oct 2025 02:48:07 +0000 (08:18 +0530)]
arm64: dts: ti: k3-am6*-boards: Add label to reserved-memory node
Add the label name 'reserved_memory' to the reserved-memory node in all
K3 AM6* board level dts files. This is done so that the node can be
referenced and extended to add more carveout entries as needed in future
refactoring patches.
configs: j784s4_evm_a72_defconfig: Enable configs for PCI Endpoint mode
TI's J784S4 SoC has two instances of PCIe Controller namely PCIe0 and
PCIe1 which are Cadence PCIe Controllers. Enable corresponding configs
to support PCIe Endpoint mode of operation on these instances.
pci_endpoint: pci_cdns_ti_ep: Enable PCIe Endpoint mode in J784S4 SoC
TI's J784S4 SoC has two instances of PCIe Controller namely PCIe0 and
PCIe1 which are Cadence PCIe Controllers. Add support to configure PCIe
instances in Endpoint mode of operation.
While at it disable all endpoint functions except function 0 during
probe to prevent the Root Complex from enumerating unconfigured
functions. This ensures only properly configured endpoint functions
are visible to the host and avoids enumeration issues with
multi-function devices.
pci_endpoint: pci_cdns_ti_ep: Add SERDES mux configuration support
Probe the mux device early in the SERDES configuration flow to ensure
proper lane routing before PHY initialization. This is required for SoCs
where SERDES lanes can be muxed between different controllers
(PCIe, USB, etc), and different mux configurations are required between
different boot phases.
pci_endpoint: pci_cdns_ti_ep: Add delay after power domain reset
Add a 1ms delay after powering on the PCIe power domain to ensure
the controller stabilizes before subsequent operations. This prevents
potential timing issues during PCIe endpoint initialization.
The delay allows sufficient time for the power domain to fully come
up and the hardware to be in a stable state before configuration
begins.
board: am65x: Use generic AM6x board detection function
Replace the board-specific implementation of do_board_detect()
with a call to the generic do_board_detect_am6() function to
avoid code duplication across AM6x family boards.
The generic function provides the same functionality with
additional fallback logic to try alternate EEPROM addresses.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
board: am64x: Use generic AM6x board detection functions
Replace the board-specific implementation of do_board_detect() and
setup_serial() with calls to the generic do_board_detect_am6() and
setup_serial_am6() functions.
The generic function provides the same functionality with
additional fallback logic to try alternate EEPROM addresses.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
I2C EEPROM data contains the board name and its revision.
Add support for:
- Reading EEPROM data and store a copy at end of SRAM
- Updating env variable with relevant board info
- Printing board info during boot
Use the generic do_board_detect_am6() and setup_serial_am6()
functions to avoid code duplication across AM6x family boards.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Add two new generic functions for AM6x family boards to simplify
board-specific implementations:
- do_board_detect_am6(): Generic board detection function that reads
the on-board EEPROM. It first attempts to read at the configured
address, and if that fails, tries the alternate address
(CONFIG_EEPROM_CHIP_ADDRESS + 1). This provides a common
implementation that can be used across different AM6x boards.
- setup_serial_am6(): Sets up the serial number environment variable
from the EEPROM data. The serial number is converted from
hexadecimal string format to a 16-character hexadecimal
representation and stored in the "serial#" environment variable.
Both functions are protected by CONFIG_IS_ENABLED(TI_I2C_BOARD_DETECT)
and are designed to be used by AM62x, AM64x, AM65x, and other AM6x
family boards.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
projects / thirdparty / u-boot.git / log
