OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Pull request efi-2026-01-rc3
CI:
* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28355
Documentation:
* 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
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>
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>
Memset() must return a pointer to the start of the updated memory block.
Fixes: 476476e73b ("efi: Add support for loading U-Boot through an EFI stub")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Convert function comments in efi_selftest_console.c to match
Sphinx style.
Correct function name in print_uuid() comment.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add missing dependencies to the pytest usage documentation and correct
the device tree compiler package name from 'dtc' to 'device-tree-compiler'.
This ensures users have the complete list of dependencies needed to run
the pytest test suite without errors.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
i2c_mux_select/deselect() are not called out of i2c-mux-uclass.c that's why
they should be static.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
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>
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.
Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
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.
Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
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.
Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
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>
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>
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>
The DWC2 OTG driver depends on an ARM-specific header file to compile,
so make it depend on ARM.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
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>
The USB_OMAP3 driver was (re)added in commit e74e9f620a 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>
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>
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.
Link: https://www.ti.com/lit/ds/symlink/am62a7.pdf
Link: https://lore.kernel.org/r/20251030-ti_speed_grade_fix-v1-0-703e4189640a@ti.com
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.
Reference:
Device Speed Grades (Table 6-1) in AM62a7 Datasheet
https://www.ti.com/lit/ds/symlink/am62a7.pdf (Page#82)
Signed-off-by: Anshul Dalal <anshuld@ti.com>
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.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Aniket Limaye <a-limaye@ti.com>
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: 8d05cbef73 ("arm: mach-k3: am62p: Fixup a53 max cpu frequency by speed-grade")
Signed-off-by: Anshul Dalal <anshuld@ti.com>
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
Link: https://lore.kernel.org/r/20251104174458.3385564-1-ravi@prevas.dk
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).
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Commit ebaa3d053e ("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 9bf87e256c ("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 fa847bb409 ("test: Wrap assert macros
in ({ ... }) and fix missing semicolons") happened in 2023.
- Commit 592b6f394a ("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 10e66449d7 ("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 10e66449d7 or append the ".gpio-hog" suffix as
done below. I don't really have a dog in that race; when I did
10e66449d7, 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.
- The leak check now fails.
Test: gpio_leak: gpio.c
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a95b0 (2790832), got 0x2a9650 (2790992)
test/dm/gpio.c:328, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
Test: gpio_leak: gpio.c (flat tree)
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a9650 (2790992), got 0x2a9700 (2791168)
test/dm/gpio.c:328, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
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
ut_assertok(dm_leak_check_end(uts));
Test: gpio_leak: gpio.c
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a95b0 (2790832), got 0x2a9650 (2790992)
test/dm/gpio.c:325, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
Test: gpio_leak: gpio.c (flat tree)
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a9650 (2790992), got 0x2a9700 (2791168)
test/dm/gpio.c:325, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
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.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
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.
Link: https://lore.kernel.org/r/20251031-rsa-pss-always-v2-0-a29184ea064d@cherry.de
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: 061daa0b61 ("rsa: add support of padding pss")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
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.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
It's defined a bit later in the same file, so let's remove the
duplicated entry.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
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.
Signed-off-by: Tom Rini <trini@konsulko.com>
