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>
Sean Anderson [Wed, 3 Dec 2025 21:03:35 +0000 (16:03 -0500)]
clk: Remove myself as a maintainer
Unfortunately I don't really have time to review clock patches. When I
initially started maintaining this subsystem I had more free time than I do
now. But I also found it hard to motivate myself to review patches. Many
clock patches add support for new SoCs and they are time consuming to
review properly. You effectively have to spend a few hours reading the
reference manual (if it's public!) and reviewing drivers is no small feat
either. This is made more difficult since clocking is often very different
between SoCs and it can be difficult to determine whether something is a
bug in the driver or a workaround for some hardware behavior. I mostly
don't care about any given SoC unless I'm hacking on it so I ended up with
a ton (more than 7000) of unreviewed patches piling up in my inbox. I'd
love to be more active, but I have a day job and I usually want to work on
something more interesting when I get home. I still think the clock
subsystem is a major mess but I don't care enough to fix it :l
The subsystem itself should probably get orphaned since AFAICT all patches
go through the mach/arch maintainer or to Tom.
Sean Anderson [Wed, 3 Dec 2025 20:46:40 +0000 (15:46 -0500)]
test: strlcat: Fix SPDX license
When I modified this code I meant to accept the LGPL offer to convert the
license to GPL. However, while there is an LGPL 2.1, the next version of
the GPL after 2.0 is 3.0. Fix the license version
Fixess: c4ac52f55d9 ("test: Add test for strlcat") Signed-off-by: Sean Anderson <seanga2@gmail.com>
Chukun Pan [Tue, 2 Dec 2025 10:00:00 +0000 (18:00 +0800)]
binman: fallback to importlib_resources on Python 3.8
Python 3.7 and 3.8 lack the files attribute in importlib.resources.
Use importlib_resources to fix build errors with Python 3.8:
binman: module 'importlib.resources' has no attribute 'files'
Fixes: 538719cb6a77 ("binman: migrate from pkg_resources to importlib") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
[trini: Re-add # pragma: no cover line] 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().
Andrew Goodbody [Tue, 21 Oct 2025 16:08:30 +0000 (17:08 +0100)]
timer: imx-gpt: Fix error detection
Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:29 +0000 (17:08 +0100)]
i2c: imx_lpi2c: Fix error detection
Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Heiko Schocher <hs@nabladev.com>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:28 +0000 (17:08 +0100)]
i2c: npcm: Fix error detection
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Heiko Schocher <hs@nabladev.com>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:27 +0000 (17:08 +0100)]
clk: microchip: mpfs: Fix error detection
clk_register() will return standard error codes so the use of ERR_PTR()
is incorrect. Furthermore the code was ineffective as it lacked a return
statement that would have actually made use of the result. Add the
return statement and remove the use of ERR_PTR to correct this.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:26 +0000 (17:08 +0100)]
mmc: fsl_esdhc_imx: Cannot test unsigned to be < 0
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:25 +0000 (17:08 +0100)]
mmc: hi6220_dw_mmc: Fix error detection for clk_get_rate
clk_get_rate() returns a ulong and that return value is assigned to a
member of a struct that is an unsigned int. So testing this value to <=
0 will only detect a return of 0. Also the code in the if block assumes
ret holds the return value when it does not. So update the test to one
that will work as intended and update the if block to actually refer to
the return value.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Tom Rini [Wed, 3 Dec 2025 17:04:32 +0000 (11:04 -0600)]
Merge patch series "led: remove u-boot,boot-led and u-boot,error-led + add cmd doc"
Quentin Schulz <foss+uboot@0leil.net> says:
u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).
For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.
For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.
The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/94ed1988-13e8-4fe3-bdff-ba2c9973c556@foss.st.com/
and
https://lore.kernel.org/u-boot/2a3aa43a-ce19-41e1-ab56-556629ce5cf9@foss.st.com/
After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?
The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.
In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.
The help text for the blink subcommand of the led command was misleading
so this is now fixed.
This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.
This also gets rid of dt-binding that we already have in dts/upstream.
Finally, this adds documentation for the led shell command.
Quentin Schulz [Wed, 12 Nov 2025 17:48:16 +0000 (18:48 +0100)]
doc: remove u-boot,boot-led and u-boot,error-led from "binding"
We're aiming to reduce the amount of U-Boot-specific and out-of-spec
Device Tree additions.
Those two properties haven't been doing anything for a long time
already, except when read by board files manually. This is still the
case for STM32 boards but those will be migrated in the near future
according to their maintainer. In any case, let's not encourage people
to add either of these properties to new or existing Device Trees and
remove it from the bindings.
Quentin Schulz [Wed, 12 Nov 2025 17:48:15 +0000 (18:48 +0100)]
sam9x60-curiosity: migrate Boot LED setup to use /options/u-boot/boot-led
This board is one of the last users of /config/u-boot,boot-led property
which is a U-Boot property out of the DT spec.
Let's migrate it to use the in-spec /options/u-boot/boot-led property.
When enabling LED_BOOT, U-Boot proper will lit the LED right before
entering the main loop, so nothing needs to be done in board files.
As explained in the commit adding support for this u-boot,boot-led
property, let's keep backward compatibility in case LED_BOOT isn't
selected.
Note that this is not tested as I do not own this device.
Cc: Alexander Dahl <ada@thorsis.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Tested-by: Alexander Dahl <ada@thorsis.com>
Additionally, if we ever want to enable this LED as Boot LED, we should
instead be using boot-led phandle property in /options/u-boot[1] Device
Tree node with the "new" LED UCLASS devices.
So let's simply remove this unused property to not mislead users.
Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.
This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34
If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.
Considering it hasn't worked in many years (if ever), let's just remove
it.
Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.
This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34
If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.
Considering it hasn't worked in many years, let's just remove it.
Quentin Schulz [Wed, 12 Nov 2025 17:48:11 +0000 (18:48 +0100)]
rockchip: rk3188: remove setup_led from xPL
There's not a single device making use of that code and it anyway
shouldn't be using the old deprecated u-boot,boot-led /config property
anymore but rather boot-led from /options/u-boot[1] Device Tree node.
Because spl_board_init() is only present to call this now removed
function, we can remove it as well as SPL_BOARD_INIT which is the symbol
guarding calls to spl_board_init() (which is now also removed).
This property is only read in arch/arm/mach-rockchip/rk3188/rk3188.c
when CONFIG_SPL_LED is enabled, which isn't the case for this board, so
let's remove dead code.
Additionally, if we ever want to enable this LED as Boot LED, we should
instead be using boot-led phandle property in /options/u-boot[1] Device
Tree node with the "new" LED UCLASS devices.
Quentin Schulz [Wed, 12 Nov 2025 17:48:09 +0000 (18:48 +0100)]
doc: dt-bindings: remove duplicates with dts/upstream
doc/device-tree-bindings/leds/leds-bcm6328.txt can be found at
dts/upstream/Bindings/leds/leds-bcm6328.yaml.
doc/device-tree-bindings/leds/leds-bcm6358.txt can be found at
dts/upstream/Bindings/leds/leds-bcm6358.txt.
doc/device-tree-bindings/leds/leds-gpio.txt can be found at
dts/upstream/Bindings/leds/leds-gpio.yaml.
doc/device-tree-bindings/leds/leds-lp5562.txt can be found at
dts/upstream/Bindings/leds/leds-lp55xx.yaml.
Only two LED dt-bindings are left in U-Boot: leds-bcm6858.txt and
leds-pwm.txt. The former is partially supported by
dts/upstream/Bindings/leds/leds-bcm63138.yaml but is lacking all
optional properties we have listed in "downstream" dt-binding in U-Boot.
However, there doesn't seem to exist any user of that compatible.
The latter is partially supported by
dts/upstream/Bindings/leds/leds-pwm.yaml but is missing the
u-boot,default-brightness property, which is used by
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi at the moment. The
default-brightness property is probably not what we want here as it
defaults to max-brightness if missing. I'm assuming we want a different
value for U-Boot (127) and the kernel (255 via max-brightness as a
default), which would prevent us from upstreaming this property, which
doesn't change the status quo, so let it be for now.
Quentin Schulz [Wed, 12 Nov 2025 17:48:07 +0000 (18:48 +0100)]
doc: move legacy API documented in README.LED to doc/api/led.rst
This moves the content of the legacy LED API from doc/READ.LED to
doc/api/led.rst, applying minimal cosmetic changes to "nicely" integrate
it with the current docs and adding a small introduction to the legacy
API section.
Tom Rini [Wed, 3 Dec 2025 14:30:18 +0000 (08:30 -0600)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh
This is R-Car X5H support. It was originally posted before rc1 and the
changes are well isolated. This is the final patchset which enables the
Gen5 drivers that are already in tree. I waited with this a bit until
the SCMI ID discussion stabilized and TFA X5H support landed. So now, I
can add the final piece into U-Boot too.
Note that this is still very much experimental, the X5H upstreaming is
in very early stages. The OF_UPSTREAM conversion will happen likely in
2026.04 or 2026.07 window, depending on when the Linux DTs land. The
compound-clock.c is surely going to go away once SCP gets updated and
the MFIS mailbox will be reworked once upstream bindings get developed.
Hai Pham [Mon, 27 Oct 2025 17:22:55 +0000 (18:22 +0100)]
arm64: renesas: Extend stub PSCI implementation to R-Car Gen5
Extend the stub PSCI implementation with support for R-Car Gen5.
R-Car Gen5 uses different register to perform reset, therefore
add a compile-time conditional. This is __secure code, therefore
the runtime SoC detection parts are not available to it, hence
the compile time conditional.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Tweak commit message
Add initial support for Renesas R-Car X5H R8A78000 Ironhide board.
This consists mainly of DTs, Makefile and Kconfig entries and board
specific configuration files.
The DTs will be gradually switched over to Linux DTs via OF_UPSTREAM
once Linux DTs become available upstream, as upstreaming progresses.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add initial device trees for Renesas R-Car X5H R8A78000 SoC.
Include very basic clock, reset, power domain headers which
are used to control supported peripherals via SCMI / SCP. The
headers are currently kept limited to avoid possible ABI break.
A lot of clock are still stubbed via fixed-clock, this is going
to be gradually removed over time, as more of the platform is
upstreamed.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Khanh Le <khanh.le.xr@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add initial changes to support Renesas R-Car Gen5 SoC.
Introduce Kconfig entries, architecture headers and PRR IDs for Renesas
R-Car Gen5 and R-Car X5H R8A78000 SoC. Add Makefile change to produce
u-boot-elf.srec with correct offset for installation tooling. Update
MAINTAINERS entry to cover both r8a77nnn and r8a78nnn .
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add support for the Renesas MFIS mailbox, which provides an interface
between the different CPU Cores, such as AP System Core domain and the
Realtime Core domain, SCP Core domain and AP System Core domain or
Realtime Core domain and AP System Core domain or Realtime Core domain.
Signed-off-by: Tuyen Dang <tuyen.dang.xa@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Update the driver
[Marek: Rename the driver to renesas-mfis, simplify the driver.
Always use only one TX channel and no RX channel, drop all
unnecessary code. Perform 1ms delay in send callback which
is perfectly fine to do in U-Boot which does RX polling]
Marek Vasut [Mon, 27 Oct 2025 16:33:07 +0000 (17:33 +0100)]
clk: renesas: Introduce temporary compound clock for SCP compatibility
The current state of SCP on Renesas R-Car Gen5 is not yet final and
is still missing full clock control, the clock control is exposed as
separate enable/disable and rate controls.
Temporarily introduce custom local compound clock, which are used as
an adaptation layer between U-Boot clock tree and current state of
SCP, and which bind two SCP clock into a single compound clock, which
provides both enable/disable and rate controls.
This is mainly meant to be used by SD/eMMC controller, to allow the
driver to both turn its clock on and off, and also obtain the current
clock rate. This is going to be removed once the SCP clock protocol
solidifies.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Wed, 19 Nov 2025 17:44:36 +0000 (18:44 +0100)]
sh: Assure end of U-Boot is at 8-byte aligned offset
Make sure the end of U-Boot is at 8-byte aligned offset, not 4-byte
aligned offset. This allows safely appending DT at the end of U-Boot
with the guarantee that the DT will be at 8-byte aligned offset. This
8-byte alignment is now checked by newer libfdt 1.7.2 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Adriana Nicolae [Thu, 27 Nov 2025 16:28:34 +0000 (08:28 -0800)]
boot/bootfdt: Add smbios3-entrypoint to FDT for non-EFI boots
The Linux kernel can discover SMBIOS tables through two primary methods:
1. Via EFI tables, when using EFI boot;
2. Via the 'smbios3-entrypoint' property in the /chosen node of the
device tree.
When U-Boot boots a Linux kernel using a non-EFI command ("bootm",
"bootz", or "booti"), the kernel relies on the device tree to detect
the hardware. If SMBIOS tables are available in U-Boot, they should
be passed to the kernel via this device tree property.
This patch modifies boot_fdt_prepare(), to inject the SMBIOSv3 table
address into the device tree if there is a table generated by U-boot.
The "board_fdt_chosen_smbios" is weak in order to leave the possibilty
for specific boards to select custom SMBIOS addresses.
The changes in this patch are added in the context of supporting this
device tree property in linux kernel:
https://lkml.org/lkml/2025/10/24/1393
Device tree schema was updated to include the "smbios3-entrypoint" node
in pull request: https://github.com/devicetree-org/dt-schema/pull/177
Signed-off-by: Adriana Nicolae <adriana@arista.com>
projects / thirdparty / u-boot.git / log
