Fedor Ross [Mon, 1 Dec 2025 16:08:06 +0000 (17:08 +0100)]
imx9: scmi: soc: USB instance number change for silicon revision B0
For silicon revision A1, the USB instance number for USB1 is 3 and for
USB2 it is 4. This changed for revision B0 where the USB instance number
for USB1 is 0 and for USB2 it is 1, which is the intended instance
number. Select the correct numbering according to the selected SoC
(IMX95) and its revision.
This patch is based on the information provided by:
"AN14750 Migration Guide from i.MX 95 A1 to B0; Rev. 1.0" .
Reviewed-by: Alice Guo <alice.guo@nxp.com> Signed-off-by: Fedor Ross <fedor.ross@ifm.com> Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Tom Rini [Fri, 5 Dec 2025 23:03:36 +0000 (17:03 -0600)]
Merge patch series "clk: Return value calculated by ERR_PTR"
Andrew Goodbody <andrew.goodbody@linaro.org> says:
Smatch reported an error where a value calculated by ERR_PTR was not
used. Fixing this to return the generated value led to a test failure
which meant updating the sandbox clock code so that it would still cause
the tests to pass with the above correction.
Debugging this problem led to a SIGSEGV which is addressed in 1/3.
Possible memory leaks noticed are addressed in 3/3.
Andrew Goodbody [Fri, 21 Nov 2025 17:34:33 +0000 (17:34 +0000)]
clk: Prevent memory leak on error
In clk_set_default_rates() memory is allocated to store the clock rates
that are read. Direct returns fail to free this memory leading to a
memory leak so instead use 'goto fail;' which will then perform the free
before exiting the function.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Fri, 21 Nov 2025 17:34:32 +0000 (17:34 +0000)]
clk: Return value calculated by ERR_PTR
In clk_set_default_get_by_id ret is passed to ERR_PTR but nothing is
done with the value that this calculates which is obviously not the
intention of the code. This is confirmed by the code around where this
function is called.
Instead return the value from ERR_PTR.
Then fixup the sandbox code so that the test dm_test_clk does not fail
as it relied on the broken behaviour.
Finally disable part of the test that does not work correctly with
CLK_AUTO_ID
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Fri, 21 Nov 2025 17:34:31 +0000 (17:34 +0000)]
clk: Prevent SIGSEGV on debug
If LOG_DEBUG is defined and a NULL clk is passed to clk_enable or
clk_disable then an attempt is made to dereference NULL in the debug
statement. Guard against this.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Thu, 20 Nov 2025 04:15:30 +0000 (05:15 +0100)]
boot: Check noffset before use
If noffset is negative, do not pass it to fit_get_name() and then further to
libfdt, this will crash sandbox with SIGSEGV because libfdt can not handle
negative node offsets without full tree check, which U-Boot inhibits to keep
size lower.
Instead, always check noffset before use, and if the return value indicates
failure, exit right away.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Anshul Dalal [Thu, 20 Nov 2025 09:31:27 +0000 (15:01 +0530)]
configs: am64x, am65x: add CONFIG_DA8XX_GPIO
The DA8xx GPIO driver was not being built as part of the A53 U-Boot
image on AM64x and AM65x. This meant only i2c GPIO expanders were
accessible to the users from the U-Boot prompt.
Marian Cingel [Sat, 8 Nov 2025 23:23:25 +0000 (23:23 +0000)]
board: ti: CAT24C256WI-GT3 require min. 5ms delay (tWR) between write/read
Otherwise the custom-cape eeprom (at address 57) reports NACK which
results into "i2c_write: error waiting for data ACK (status=0x116)" and
terminates further scanning.
Signed-off-by: Marian Cingel <cingel.marian@gmail.com>
Sam Protsenko [Mon, 27 Oct 2025 00:24:58 +0000 (19:24 -0500)]
autoboot: Fix inconsistent countdown output
Commit 5f70be08b015 ("Fix autoboot countdown printing wrong") introduces
inconsistency in how the countdown is displayed. For example, in case
when BOOTDELAY=5, the next output is observed during the boot:
Hit any key to stop autoboot: 5
Hit any key to stop autoboot: 4
Hit any key to stop autoboot: 3
That happens due to different printf format (%2d vs %1d). Moreover, the
mentioned commit fails to handle the case when the user is holding some
key before the countdown is shown. E.g. if BOOTDELAY=101, the next
malformed output is being produced:
Hit any key to stop autoboot: 1 0
That's because the fast path code wasn't modified accordingly, and still
tries to erase the number using '\b\b\b' format.
Fix both issues by introducing a dedicated routine for printing the
whole countdown line.
Fixes: 5f70be08b015 ("Fix autoboot countdown printing wrong") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: David Zang <davidzangcs@gmail.com>
Tom Rini [Mon, 6 Oct 2025 15:38:59 +0000 (09:38 -0600)]
clk: ti: Tighten some TI clock driver dependencies
Attempting to build with "allyesconfig" means that we try and build all
available options for the sandbox platforms. Doing so exposes that the
drivers under drivers/clk/ti/ can only be compiled or linked on
ARCH_OMAP2PLUS platforms as some drivers require platform specific
headers while other drivers depend on these first drivers to link.
Express those requirements in Kconfig as well.
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Fri, 26 Sep 2025 15:31:40 +0000 (09:31 -0600)]
mtd: Tighten some driver dependencies
The ALTERA_QSPI driver conflicts with the regular FLASH_CFI_DRIVER as
both implement the same high level functionality and so use the same
global namespace. In a similar fashion, all NAND drivers are mutually
exclusive due to namespace collisions. For the remaining drivers which
did not already have some architecture specific dependency, add them.
Tom Rini [Fri, 5 Dec 2025 19:38:32 +0000 (13:38 -0600)]
Merge patch series "led: remove unused legacy LED code"
Quentin Schulz <quentin.schulz@cherry.de> says:
Only the Siemens corvus board seems to be using these two status LEDs
from the legacy LED API.
Since we're trying to get rid of the last users of the legacy LED API,
let's migrate Corvus to the modern LED API instead, which uses DM. For
Corvus's case, it also uses DM_GPIO (already enabled in defconfig).
Since there was no use for the green status_led (not compiled in), it
simply is removed without migrating it to the modern API. If need be, we
can always add a new gpio-led in the FDT.
Note that I do not own a Siemens Corvus board so it's a bit of a shot in
the dark whether it'll work on the first try, only build tested.
The red LED should be on whenever reaching U-Boot proper CLI, if not we
have an issue.
The LED should be controllable with the led command from U-Boot proper
CLI.
Quentin Schulz [Wed, 19 Nov 2025 17:01:15 +0000 (18:01 +0100)]
led: remove support for red LED in legacy API
To the exception of red_led_on in the arm-specific assembly code, all
code interacting with the red status LED was guarded by the
CONFIG_LED_STATUS_RED symbol, which is enabled in none of the upstream
defconfigs.
Since the last board which overrode the weak red_led_on function got
migrated to the new LED mechanism, there's also no user of the
arm-specific assembly code anymore, therefore it can be removed along
the other unreachable code sections.
Quentin Schulz [Wed, 19 Nov 2025 17:01:14 +0000 (18:01 +0100)]
corvus: migrate red LED to the modern API
red_led_on is either called from the legacy LED shell command (which is
disabled for corvus) or from arm-specific assembly code right before
jumping into board_init_r() in U-Boot proper.
Let's migrate to use the more modern LED subsystem by migrating to DM.
The default-state is set to on to mimic red_led_on() from the
arm-specific assembly code as a missing default-state FDT property
currently means the LED is not probed except if explicitly done via the
led shell command. Note though that this is running much later in the
boot process, once DM is started.
Quentin Schulz [Wed, 19 Nov 2025 17:01:12 +0000 (18:01 +0100)]
corvus: remove green led support
green_led_on and green_led_off are only called by the legacy LED command
(CONFIG_LED_STATUS_CMD) when CONFIG_LED_STATUS_GREEN is enabled, both of
which aren't enabled for corvus, so let's simply remove it as it's dead
code.
Tom Rini [Fri, 5 Dec 2025 16:35:49 +0000 (10:35 -0600)]
Merge patch series "led: remove unused legacy LED code"
Quentin Schulz <quentin.schulz@cherry.de> says:
This is a follow-up to:
- https://lore.kernel.org/u-boot/20251112-led-old-dt-v1-0-2892d49517db@cherry.de/
- https://lore.kernel.org/u-boot/20251114162417.4054006-1-patrice.chotard@foss.st.com/
to continue the effort of getting rid of the legacy LED API. This series
depends on the series listed above.
Quentin Schulz [Wed, 19 Nov 2025 16:43:48 +0000 (17:43 +0100)]
net: remove unreachable legacy LED code
The code is guarded by a condition none of the defconfigs meet (that is
CONFIG_SYS_FAULT_ECHO_LINK_DOWN and CONFIG_LED_STATUS_RED both enabled),
so we can remove the unreachable code sections.
When doing that, there's no caller for miiphy_link anymore, so it can be
removed.
This in turns makes CONFIG_SYS_FAULT_ECHO_LINK_DOWN and
CONFIG_SYS_FAULT_MII_ADDR unused so they are removed as well.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Tom Rini <trini@konsulko.com>
Quentin Schulz [Wed, 19 Nov 2025 16:43:47 +0000 (17:43 +0100)]
arm: omap3: remove leftover from CM_T35 support removal
Commit 76386d6195a1 ("arm: Remove cm_t35 board") removed support for the
board that was built when TARGET_CM_T35 is selected, but removal of the
symbol was forgotten, so let's fix this oversight.
While at it, update the README for omap3 to remove the last mention of
cm_t35.
malta: increase SYS_MALLOC_F_LEN and SYS_MALLOC_LEN
If CONFIG_CONSOLE_RECORD_INIT_F=y we need additional memory according to
CONFIG_CONSOLE_RECORD_OUT_SIZE_F. Similarly CONFIG_SYS_MALLOC_LEN must be
increased by CONSOLE_RECORD_OUT_SIZE.
Go with the default values for CONFIG_CONSOLE_RECORD_INIT_F and
CONFIG_SYS_MALLOC_LEN.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We invoke the ut command in test_ut.py. Currently we only check for
failures. Instead we should also indicate if sub-tests were skipped.
With this change we will get output like the following for skipped tests:
test/py/tests/test_ut.py ..sssss......ss..............s.sssss.s.s...
================================ short test summary info ================================
SKIPPED [1] test/py/tests/test_ut.py:597: Test addrmap addrmap_test_basic has 1 skipped sub-test(s).
SKIPPED [1] test/py/tests/test_ut.py:597: Test bdinfo bdinfo_test_eth has 4 skipped sub-test(s).
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
_ update LED management for STMicroelectronics boards
_ Add 1 GiB DRAM support for STM32MP13x DHCOR SoM
_ Fix 512 MiB DRAM support for STM32MP13x DHCOR SoM
_ Fix handling OPTEE in middle of the DRAM
_ Add missing debug UART build for STM32MP1 DHSOM
Patrice Chotard [Fri, 14 Nov 2025 16:23:55 +0000 (17:23 +0100)]
ARM: dts: stm32: Drop "u-boot-led" and "error-led" from stm32mp157c-ed1-u-boot
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157cf-ed1-u-boot.dtsi.
Remove led-red and led-blue nodes which are available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Patrice Chotard [Fri, 14 Nov 2025 16:23:54 +0000 (17:23 +0100)]
ARM: dts: stm32: Drop "u-boot-led" and "error-led" from stm32mp157c-ed1-scmi-u-boot
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157c-ed1-scmi-u-boot.dtsi.
Remove led-red and led-blue nodes which are available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Patrice Chotard [Fri, 14 Nov 2025 16:23:36 +0000 (17:23 +0100)]
board: st: Update LED management for stm32mp1
Remove get_led() and setup_led() which became obsolete since
led_boot_on() introduction. led_boot_on() is automatically called
from board_r.c
Regarding "u-boot,error-led" property can't be used anymore since commit
Since commit 516a13e8db32 ("led: update LED boot/activity to new property implementation")
Instead get the LED labeled "red:status".
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Marek Vasut [Tue, 18 Nov 2025 23:17:23 +0000 (00:17 +0100)]
ARM: stm32: Add missing build of debug UART init code on DH STM32MP1 DHSOM
Commit c37a6684818d ("stm32mp: fix compilation issue with DEBUG_UART")
split the debug UART initialization code into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
until debug UART is enabled, which is not the default. Update the
Makefile accordingly to allow debug UART to work.
Fixes: c37a6684818d ("stm32mp: fix compilation issue with DEBUG_UART") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Tue, 18 Nov 2025 23:19:36 +0000 (00:19 +0100)]
ARM: dts: stm32: Add 1 GiB DRAM settings for DH STM32MP13xx DHCOR SoM
Add DRAM settings for 1 GiB variant of DH STM32MP13xx DHCOR SoM
and support for SoM DRAM coding HW straps decoding and automatic
DRAM configuration selection. Enable CONFIG_BOARD_EARLY_INIT_F on
all STM32MP1 DHSOM, as it is required for the HW straps decoding.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Tue, 18 Nov 2025 23:17:14 +0000 (00:17 +0100)]
stm32mp: Fix handling of OPTEE in the middle of DRAM
STM32MP13xx may have OPTEE-OS at 0xdd000000 even on systems with 1 GiB
of DRAM at 0xc0000000, which is not the end of DRAM anymore. This puts
the OPTEE-OS in the middle of DRAM. Currently, the code sets RAM top to
0xdd000000 and prevents the DRAM range past OPTEE at 0xe0000000..0xffffffff
from being set as cacheable and from being usable. The code also sets the
area over OPTEE as invalid region in MMU tables, which is not correct.
Adjust the code such, that it only ever sets RAM top just before OPTEE
in case the OPTEE is really at the end of DRAM, mainly to be backward
compatible. Furthermore, adjust the MMU table configuration such, that
the regions over the OPTEE are simply skipped and not reconfigured, and
the regions between end of OPTEE and RAM top are set as cacheable, if
any actually exist.
Tom Rini [Wed, 19 Nov 2025 14:55:41 +0000 (08:55 -0600)]
vexpress_aemv8: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:33 +0000 (08:55 -0600)]
pcm052: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:32 +0000 (08:55 -0600)]
omap3_evm: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:27 +0000 (08:55 -0600)]
hikey960: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:25 +0000 (08:55 -0600)]
hikey: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:22 +0000 (08:55 -0600)]
bcmstb: Make use of bootm_size rather than fdt_high
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS. However, this platform also has a large comment
block that explains that given previous stage loaders and other parts of
the memory map (that may not be in the device tree we see?), adjust this
to use bootm_size to restrict relocation to be below the CMA area and
update the comment to match.
Tom Rini [Wed, 19 Nov 2025 14:55:20 +0000 (08:55 -0600)]
am335x_shc: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Reviewed-by: Heiko Schocher <hs@nabladev.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 19 Nov 2025 14:55:17 +0000 (08:55 -0600)]
qemu-arm-sba: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Tue, 18 Nov 2025 14:26:40 +0000 (08:26 -0600)]
adi: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tested-by: Greg Malysa <malysagreg@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Tue, 2 Dec 2025 21:20:33 +0000 (15:20 -0600)]
boot/image-fit.c: Use aligned_alloc(...) not memalign(...)
With the changes in commit 8fbcc0e0e839 ("boot: Assure FDT is always at
8-byte aligned address") to call memalign(...) we now always call
memalign(...) rather than malloc(...) when allocating a buffer that may
contain a device tree. However, memalign(...) is not portable among all
of the host OSes we support. The C11 standard does require that
aligned_alloc(...) exist and it takes the same parameters as
memalign(...) does. Change this file to call aligned_alloc rather than
memalign, and for the non-USE_HOSTCC case define that function back to
memalign.
Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
Maksim Kiselev [Fri, 29 Aug 2025 08:25:00 +0000 (11:25 +0300)]
clk: Only enable the parent clock if the clock was enabled before reparenting
The current implementation of clk_set_parent() unconditionally enables
the new parent clock, even if the target clock was not previously enabled.
To avoid this implicit behavior, this patch adds a check for whether
the target clock has been enabled before parent enabling..
Fixes: ac30d90f336 ("clk: Ensure the parent clocks are enabled while reparenting") Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tom Rini [Thu, 4 Dec 2025 15:39:11 +0000 (09:39 -0600)]
Merge patch series "Add support for SM3 secure hash"
Heiko Schocher <hs@nabladev.com> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Heiko Schocher [Tue, 18 Nov 2025 04:30:38 +0000 (05:30 +0100)]
lib: import sm3 256 hash parts from linux
Implement SM3_256 Hash algorithm, based on
linux commit f83a4f2a4d8c: ("Merge tag 'erofs-for-6.17-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs")
Tom Rini [Thu, 4 Dec 2025 15:38:46 +0000 (09:38 -0600)]
Merge patch series "clk: Fix some error detection"
Andrew Goodbody <andrew.goodbody@linaro.org> says:
The function clk_get_rate() returns a ulong with 0 meaning an invalid
clock rate and also negative error codes being returned for other
errors. But being an unsigned return value this cannot simply be tested
for with a < 0 test. Instead use the IS_ERR_VALUE() macro to check for
negative errors appearing as very large positive values. Fix those
places that test for <= 0. Also fix some places checking the return of
clk_register() that incorrectly used ERR_PTR().
projects / thirdparty / u-boot.git / log
