A last minute fix for the release, the UFS controller on the new Milos
SoC (used in the Fairphone Gen. 6) needs a stub driver for it's ref
clock (similar to SM8650 before) and a handful of other clocks to get
the UFS controller probed.
Ye Li [Fri, 26 Jun 2026 10:44:49 +0000 (18:44 +0800)]
clk: imx: imx8mq: Fix iMX8MQ PLL issue
The fractional PLL used on iMX8MQ is not pll14xx, it is different
PLL and not exist in u-boot. Add this fractional PLL driver and
update iMX8MQ clock driver to adapt this fraction PLL.
Fixes: 11c8ab01f3ed ("clk: imx8mq: Add a clock driver for the imx8mq") Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Thu, 18 Jun 2026 01:17:47 +0000 (09:17 +0800)]
imx9: scmi: Fix SPL trampoline buffer for 1GB DDR
After supporting get DRAM size from SM, the trampoline buffer address
still depends on PHYS_SDRAM_SIZE. If the real DDR size is less than
PHYS_SDRAM_SIZE, the trampoline buffer address is invalid and SPL will
crash. So use board_phys_sdram_size to get real DDR size to calculate
correct address.
Fixes: e1cc7117b630 ("imx9: scmi: Get DDR size through SM SCMI API") Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Tested-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Alexey Charkov [Tue, 12 May 2026 13:55:28 +0000 (17:55 +0400)]
usb: onboard-hub: Add support for Corechips SL6341 USB 2.0/3.0 hub controller
Corechips SL6341 is a 4-port USB 2.0 and 3.0 hub controller. It always
requires external 1V1 power and can optionally use external 3V3 power
(or alternatively it has a 5V->3V3 LDO built in to derive 3V3 power from
VBUS). It also exposes a reset pin.
Device tree bindings are merged for upstream release with Linux 7.1 as
commit bfcb86e58f3a ("dt-bindings: usb: Add Corechips SL6341 USB2.0/3.0
hub controller") [1]
Use board_get_usable_ram_top() instead of get_effective_memsize() to
limit gd->ram_top.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b9e6281632a8 ("arm: mediatek: mt8512:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. Overriding gd->bd->bi_dram[0].size was a bit
confusing since it isn't easily apparent which order the functions that
set it are called.
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit d83bd9729d75 ("arm: mediatek: mt8195:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit af4cba9a05aa ("arm: mediatek: mt8195: fix gd->ram_top limit")
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b3467e51e92b ("arm: mediatek: mt8188:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit 7518e10cd235 ("arm: mediatek: mt8188: fix gd->ram_top limit").
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit bddd6bbef3dc ("arm: mediatek: mt7988:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
Reported-by: Rudy Andram <rmandrad@gmail.com> Closes: https://lore.kernel.org/u-boot/20260602162233.2418471-1-rmandrad@gmail.com/ Fixes: bddd6bbef3dc ("arm: mediatek: mt7988: drop dram_init_banksize()") Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-4-f72cfc52ce58@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit 56183fb025c2 ("arm: mediatek: mt7987: drop
dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
On mt7987, there is already an implementation of
board_get_usable_ram_top() for other reasons, so it is modified to
also limit ram_top to 4GiB (mt7987 is currently the only thing that
sets CONFIG_MTK_TZ_MOVABLE=y so it is safe to change this here without
unintentional side-effects).
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
David Lechner [Mon, 15 Jun 2026 19:23:32 +0000 (14:23 -0500)]
net: mtk_eth: select LMB_LIMIT_DMA_BELOW_RAM_TOP
Default to CONFIG_LMB_LIMIT_DMA_BELOW_RAM_TOP=y when MEDIATEK_ETH is
enabled. The MediaTek Ethernet controller can only access the first 4GB
of RAM when DMA is used.
David Lechner [Mon, 15 Jun 2026 19:23:31 +0000 (14:23 -0500)]
mmc: mtk-sd: select LMB_LIMIT_DMA_BELOW_RAM_TOP
Default to CONFIG_LMB_LIMIT_DMA_BELOW_RAM_TOP=y when CONFIG_MTK_SD is
enabled. The MediaTek SD controller can only access the first 4GB of RAM
when DMA is used. "imply" is used rather than "select" in case someone
want's to turn off the option when DMA is not used.
David Lechner [Fri, 12 Jun 2026 00:12:20 +0000 (19:12 -0500)]
arm64: dts: mediatek: mt6359: give regulators unique names
Change the regulator-name properties to be unique for all regulators.
U-Boot cannot handle duplicate names.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
[ upstream commit: d91639d0ab3223b61c00442021dc639c9ddc2b76 ]
For AST2600 SPL with CONFIG_SPL_SEPARATE_BSS=y and
CONFIG_OF_SEPARATE=y, fdt_find_separate() expects the appended control
DTB at _image_binary_end.
The AST2600 SPL linker script aligned _image_binary_end via the
.binman_sym_table section. In builds where that section has no emitted
contents, objcopy -O binary does not include the alignment bytes in
spl/u-boot-spl-nodtb.bin. This causes the nodtb binary to end before
_image_binary_end, so the appended DTB is placed too early.
Piyush Paliwal [Fri, 12 Jun 2026 07:47:30 +0000 (13:17 +0530)]
net: cdp: reject CDP TLVs with a length below the 4-byte header
cdp_receive() reads a 16-bit TLV length (tlen) from the packet and only
checks that it does not exceed the remaining buffer (tlen > len). It then
unconditionally does "tlen -= 4" to skip the TLV header. As tlen is a
u16, a crafted TLV with a length of 0..3 underflows tlen to ~65532-65535.
For a CDP_APPLIANCE_VLAN_TLV the underflowed length then drives the inner
"while (tlen > 0)" loop, which walks ~64KB past the receive buffer reading
*ss each step -> out-of-bounds read (crash / info-influence). A length of
0 additionally fails to advance pkt/len, hanging the parse loop.
Reject any TLV whose declared length is smaller than its own 4-byte
header. This is the same class of bug as the recent bootp/dhcpv6/sntp/nfs
fixes (unchecked length field), in a sibling LAN parser that was missed.
Verified with a standalone AddressSanitizer harness using the verbatim
cdp_receive()/cdp_compute_csum() routines: a 16-byte CDP frame with an
appliance-VLAN TLV of length 3 triggers a heap-buffer-overflow READ that
the check eliminates.
Fixes: f575ae1f7d39 ("net: Move CDP out of net.c") Cc: stable@vger.kernel.org Signed-off-by: Piyush Paliwal <piyushthepal@gmail.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
David Lechner [Thu, 11 Jun 2026 23:36:10 +0000 (18:36 -0500)]
net: lwip: introduce net_lwip_eth_stop() function
Add a introduce net_lwip_eth_stop() function and use that to stop the
network interface after each command that uses the network.
This makes the behavior the same as the legacy net code and avoids
potential issues with the network interface being left in an active
state after a command finishes.
The start/stop is reference-counted since there is at least one command
(dhcp) that calls another command (tftp) to avoid starting and stopping
the network interface multiple times in a single command.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
David Lechner [Thu, 11 Jun 2026 23:36:09 +0000 (18:36 -0500)]
net: lwip: wget: return errno codes from wget_do_request()
Change the return values of the lwip implementation of wget_do_request()
to be errno codes instead of command return codes.
wget_do_request() is not a command, so it does not make sense to return
command return codes from it. Also, the legacy network implementation of
wget_do_request() already returns errno codes so it is logical for the
lwip implementation to do the same.
This fixes a bug in try_load_from_uri_path() in efi_manager.c where it
checks that the return value of wget_do_request() is < 0. Before this
change, CMD_RET_FAILURE would not be considered an error since it has a
value of 1.
The value of ENODEV is used in places where there could actually be a
number of different causes of failure and it isn't possible to
discriminate (i.e. failing function returns NULL for all errors). Since
all callers of wget_do_request() don't propagate the error code, it
doesn't matter so much that this is not ideal, at least at this point in
time.
David Lechner [Thu, 11 Jun 2026 23:36:08 +0000 (18:36 -0500)]
net: lwip: wget: fix error handling in wget_do_request()
Split wget_do_request() into two functions to make error handling less
error-prone.
After a successful call to net_lwip_new_netif(), net_lwip_remove_netif()
must always be called to prevent leaks. This was missed in the CACERT
section of the code where we returned on error without cleaning up.
Instead of adding more calls to net_lwip_remove_netif(), refactor the
code into two functions. The outer function handles managing the netif
lifecycle. The inner function no longer has to worry about cleaning up
before returning on error.
To keep things simple, the `path` local variable is removed during the
refactoring. Instead, ctx.path is used directly everywhere.
Mateusz Furdyna [Wed, 10 Jun 2026 14:25:34 +0000 (16:25 +0200)]
test: net: add IP defragmentation duplicate-fragment regression test
Add a unit test for the IP datagram reassembler (CONFIG_IP_DEFRAG) that
covers the duplicate-last-fragment scenario.
Without the fix the last fragment will re-trigger datagram delivery,
increasing udp_rx_count to 2 and effectively failing the test; with it
applied the test passes with udp_rx_count == 1.
Signed-off-by: Mateusz Furdyna <mateusz.furdyna@nokia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Mateusz Furdyna [Wed, 10 Jun 2026 14:25:33 +0000 (16:25 +0200)]
net: clear IP defragmentation state after returning a complete packet
During the IP defragmentation process, after the reassembly is finished
with the last packet arriving with MF=0, the reassembly state wrt.
static counters is not cleared. In case this last arriving packet with
MF=0 gets duplicated, payload bytes are mistakenly treated as hole data.
A malicious actor who can deliver fragmented IP traffic to a U-Boot
instance with CONFIG_IP_DEFRAG=y can corrupt memory via out-of-bound
writes and redirect control flow into attacker-supplied payload bytes
that already sit in `pkt_buff[]`.
Publicly available AI models are able to generate a reproducer based
on the provided information.
Fix: once the assembled packet has been handed back to the caller, mark
the reassembly state empty so that any further fragment (duplicate,
replay, or a brand-new datagram that happens to reuse the `ip_id`) goes
through the normal re-init path and rebuilds a clean hole list instead
of dereferencing payload bytes as struct hole.
net: airoha_eth: fix mt7531 mdio related initialization bug
Private data isn't ready during bind time. The call of dev_get_priv()
function will return NULL. Thus we can't save mdio device pointer and
use it later during probe.
To solve an issue, we will move mt7531 mdio device binding to the probing
function of 'airoha-eth' driver.
All GDM ports (except of GDM1) are connected directly to their PHYs, so
corresponding mdio bus will be automatically probed during PHY setup.
GDM1 ports differ from other GDM ports. It connected to the airoha switch
device. The mt7531 mdio bus is used to manage link state of airoha switch
device ports (LAN ports 1-4 corresponds to PHYs 0x09-0x0C). Therefore,
manual probing of mt7531 mdio bus is required to be able set/query states
of corresponding LAN ports.
Fixes: 96d9e7c46425 ("net: airoha: use mt7531 mdio for GDM1") Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
* bootdev: fix typos
* board: renesas: Document Renesas RZ/N1D and RZ/N1S as arm
* board: renesas: Document Renesas Geist board support
* board: renesas: Document Renesas Gray Hawk board support
* board: renesas: Document Renesas Ironhide board support
* android: fastboot: Document halt behaviour
UEFI:
* fix memory leak in efi_var_collect()
* set revision field in block IO protocol
* fix guid comparison in efi_selftest_loaded_image.c
* fix use-after-free in efi_selftest_memory.c
Vincent Stehlé [Thu, 11 Jun 2026 06:59:50 +0000 (08:59 +0200)]
efi_selftest: fix use-after-free
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed57 ("efi_selftest: check fdt is marked as runtime data") Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Vincent Stehlé [Tue, 9 Jun 2026 08:07:04 +0000 (10:07 +0200)]
lib/efi_loader: fix block io revision
The Revision field of the EFI_BLOCK_IO_PROTOCOL structure must be set to
one of the two valid values [1], but this is not initialized in the
efi_loader; fix it.
Link: https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html#efi-block-io-protocol Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Vincent Stehlé [Mon, 15 Jun 2026 10:56:15 +0000 (12:56 +0200)]
efi_selftest: fix guid comparison
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0de0 ("efi_selftest: test for loaded image protocol") Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Cc: Alexander Graf <agraf@csgraf.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Peng Fan [Thu, 18 Jun 2026 06:48:48 +0000 (14:48 +0800)]
usb: tcpm: fix inverted poll condition in tcpm_pd_transmit()
The read_poll_timeout() macro breaks out of its loop when the condition
evaluates to true. The current code uses "!tx_complete" as the
condition, which means it exits immediately when tx_complete is false
(i.e., transmission has NOT completed yet), rather than waiting for
completion.
Fix the condition to "tx_complete" so that the poll loop waits until
the TCPC signals transmission success/failure/discard before
proceeding.
Without this fix, tcpm_pd_transmit() returns before the TCPC has
finished transmitting, causing the PD state machine to proceed with
stale tx_status values.
Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Tue, 16 Jun 2026 23:01:20 +0000 (17:01 -0600)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh
This is a DRAM controller driver for the R-Car X5H and its enablement.
This makes the U-Boot on RSIP usable beyond U-Boot shell running on
Cortex-M33, as the U-Boot on RSIP can now load not only SCP firmware
into the SCP core STCM, but also TFA BL31, OPTEE-OS and U-Boot into DRAM
and start them on the Cortex-A720AE core. This is self-contained and
affects only the R-Car X5H and a bit of R-Car V4H, besides it went
through rounds of testing until now, therefore it is safe to include it
this late in the release cycle. I know this will make rc5 massive, sorry
about that.
Rasmus Villemoes [Thu, 11 Jun 2026 14:08:57 +0000 (16:08 +0200)]
Makefile: let 'make clean' remove files created by DEVICE_TREE_DEBUG
Originally, 'make DEVICE_TREE_DEBUG=1' only generated extra output on
the console. But since 6cdd7597a2f ("kbuild: Produce diff between base
DT and U-Boot augmented DT if DEVICE_TREE_DEBUG=1"), that has also
left behind lots of files that clutter the repo and are hard to get
rid of manually.
Make sure that a 'make clean' will remove those files, and add them to
.gitignore.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Wed, 10 Jun 2026 18:20:59 +0000 (20:20 +0200)]
arm: dts: renesas: Enable DBSC5 on R-Car R8A78000 X5H Cortex-M33 RSIP port
Bind the DBSC5 DRAM controller driver on boot in board_early_init_r(),
which brings up the DBSC5 DRAM controller and its PHY and which enables
access to DRAM present on this system.
Add default boot command which loads additional bootloader components
from HF and UFS storage into SRAM and DRAM, and starts those components
on SCP and AP core 0. The system is then capable of reaching U-Boot on
the AP core 0. Specifically, the following components are loaded:
- SCP firmware, 384 kiB from HF offset 0x4c0000 to SCP STCM
- TFA BL31, 256 kiB from UFS0 offset 0x5000 * 4 kiB sectors to DRAM 0x8c200000
- TEE, 2 MiB from UFS0 offset 0x5200 * 4 kiB sectors to DRAM 0x8c400000
- U-Boot, 1 MiB from UFS0 offset 0x7200 * 4 kiB sectors to DRAM 0x8c300000
- IPL parameters table is generated at DRAM address 0x8c100000
Enable pstore command support to allow dumping kernel console from
pstore/ramoops, which is convenient for debugging. Use as follows:
=> pstore set 0x80000000 0x10000 0x400 0x8000 0 0 0
=> pstore display console
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add Renesas R-Car Gen5 DBSC5 DRAM controller driver. This driver is currently
capable of bringing LPDDR5X DRAM on Renesas R-Car X5H Ironhide board. Further
boards can be supported by supplying board specific DRAM configuration data
via dbsc5_get_board_data().
The driver reuses parts of previous DBSC5 driver, but due to hardware changes,
can not be fully integrated into existing DBSC and DRAM driver, therefore the
currentl DBSC and DRAM drivers are moved into R8A779G0 V4H specific files, and
the R8A78000 X5H files are added in parallel.
The Gen5 DBSC driver is meant to be used in RSIP context, while the Gen4 DBSC
driver is meant to be used in SPL, therefore the Kconfig conditionals have been
adjusted to match.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Wed, 10 Jun 2026 18:20:57 +0000 (20:20 +0200)]
ram: renesas: rtvram: Add support for Renesas R-Car Gen5
Add support for Renesas R-Car Gen5 R8A78000 SoC into RT-VRAM
initialization driver. The changes are only a slight adjustment
to the register programming, therefore reuse the existing RT-VRAM
driver and parametrize those changes using driver data.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Heiko Stuebner [Sat, 13 Jun 2026 17:24:44 +0000 (19:24 +0200)]
lmb: Add the Rockchip architecture as requiring DMA below 4G
Loading EFI parts like a Debian-Installer on Rockchip SoCs creates
interesting results, in that on some boards the Grub bootloader can't
find any partitions on a USB-Stick, or loading a kernel from Grub spews
EHCI fail timeout STS_IAA set
messages before failing and on others the loading something like efivars
from an eMMC creates read errors and making the MMC vanish from U-Boot.
This only affected boards with at least 4GB of RAM.
These boards have at least 256MB of memory placed above the actual 4GB
address space (due to the iomem being in between) and while kernel,
initramfs, dt are generally loaded to predefined addresses, additional
EFI parts (efivars, etc) are likely just loaded "somewhere" and it seems
this always landed in that higher up memory part.
Also in the Linux-kernel peripherals like EMMC, USB, etc already run
with a 32bit dma-mask set.
So far, I've seen this on RK3568 and RK3588, but as the same peripherals
are used on most Rockchip SoCs, it makes sense to limit this on all.
So add ARCH_ROCKCHIP to the default-y list of LMB_LIMIT_DMA_BELOW_RAM_TOP.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Tom Rini [Mon, 15 Jun 2026 18:50:04 +0000 (12:50 -0600)]
Merge patch series "Repair boards broken by the 6.1 kbuild bump"
Simon Glass <sjg@chromium.org> says:
Commit bd3f9ee679b4 added FORCE to several if_changed rules whose
recipes expand $^, so FORCE leaks in as a stray argument and the
command fails. Use $< to restore the Edison and i.MX23/28 images.
Simon Glass [Sat, 13 Jun 2026 13:05:13 +0000 (07:05 -0600)]
arm: mxs: Avoid passing FORCE to commands
Commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") adds FORCE
as a prerequisite to the if_changed rules here, but the commands use $^
so FORCE leaks in as a stray operand. The dd in cmd_mkalign_mxs fails
(silently, since its stderr is discarded) and the binary is never
aligned, stat in cmd_mkivt_mxs emits an error and cst receives a bogus
argument.
Use $< and $(real-prereqs) instead, which exclude FORCE.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sat, 13 Jun 2026 13:05:12 +0000 (07:05 -0600)]
x86: edison: Avoid passing FORCE to the align command
Commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") adds FORCE
as a prerequisite to the u-boot-align.bin rule, but cmd_mkalign_eds
expands $^, so FORCE leaks in as a stray operand. The dd then fails
(silently, since its stderr is discarded) and the following mv never
runs, so u-boot.bin never gains its 4096-byte zero prefix. The mask ROM
enters U-Boot 0x1000 (4KB) into the image and the board never starts,
sitting in BootROM download mode (DnX).
Use $< instead of $^, which excludes FORCE and restores the prefix.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The boot selection rules state that a slot is bootable if it is not
corrupted and either has tries remaining or has already booted
successfully. However, slots that have tries_remaining == 0 and
successful_boot == 1 will be disregarded when picking the slot to
attempt.
Updates the selection logic so slots marked successful remain eligible
even when their tries counter is zero. Debug message now also includes
the successful_boot value.
Francois Berder [Sun, 24 May 2026 19:25:47 +0000 (21:25 +0200)]
fastboot: Fix blk_dwrite error checking
blk_dwrite() returns the number of blocks written.
The code was only checking if the return value was different
than 0. Hence, partial writes were considered successful.
Fix blk_dwrite error handling by checking that all blocks
are written.
Marek Vasut [Sun, 14 Jun 2026 01:52:21 +0000 (03:52 +0200)]
arm64: renesas: Initialize GIC600 fully on R-Car S4/V4H/V4M
ARM GIC-600 IP complies with ARM GICv3 architecture, but among others,
implements a power control register in the Redistributor frame. This
register must be programmed to mark the frame as powered on, before
accessing other registers in the frame.
Before the switch to generic lowlevel_init function, this did not pose
a problem as the previous custom lowlevel_init did not access the GICR
registers. The generic function does and that does lead to a hang early
in SPL. Enable the GIC600 initialization variant to mitigate the hang.
Fixes: 37997a214ed1 ("arm: renesas: Use stock lowlevel_init function and remove s_init") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Sun, 14 Jun 2026 01:52:08 +0000 (03:52 +0200)]
arm64: renesas: Fold mach_cpu_init into board_init_f on R-Car S4/V4H/V4M SPL
The mach_cpu_init() function is not invoked in SPL. Instead of
having two functions, fold mach_cpu_init() into board_init_f(),
which is called very early in the boot process and assures that
the CPG and APMU setup will be invoked before DM is brought up.
Fixes: 37997a214ed1 ("arm: renesas: Use stock lowlevel_init function and remove s_init") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Thu, 11 Jun 2026 18:05:58 +0000 (20:05 +0200)]
arm: renesas: Make R-Car Gen5 u-boot-elf.shdr compatible with SDK flash_writer
The SDK 4.32 flash_writer tool, built from the SDK IPL source, requires
SREC S7 "Start address (termination)" record [1] at the end of the SREC
file that is sent to it during installation of content into storage,
otherwise the tool waits for the S7 record indefinitelly and the payload
does not get installed into storage.
Specifically, the tool considers SREC S3 and S7 records as mandatory,
S0, S5, S6 as ignored, and any other records as unsupported.
Configure srec_cat such that it explicitly generates the trailing S7
record, and also that it never generates the ignored S5 Count record.
This fixes installation of u-boot-elf.shdr using the flash_writer tool,
which can not finish successfully without the trailing S7 record.
Marek Vasut [Thu, 11 Jun 2026 18:04:26 +0000 (20:04 +0200)]
arm: renesas: Build u-boot-elf.shdr for R-Car X5H Cortex-M33 RSIP port
Currently, the default build target for all R-Car Gen3/4/5 is the
u-boot-elf.srec, which depends on u-boot.bin and other vital build
artifacts, which get built as prerequisites. The R-Car Gen5 RSIP
port benefits from u-boot-elf.shdr being built as well, because the
u-boot-elf.shdr contains header used by the BootROM to load and
start U-Boot on the RSIP core. Because u-boot-elf.shdr depends on
u-boot-elf.srec, switch the default build target for R-Car Gen5
RSIP port to u-boot-elf.shdr. This way, both u-boot-elf.shdr and
u-boot-elf.srec are built for R-Car Gen5 RSIP port.
Tom Rini [Fri, 12 Jun 2026 14:45:32 +0000 (08:45 -0600)]
Merge patch series "configs: imx95: enable PCI_INIT_R for Toradex modules"
Franz Schnyder <fra.schnyder@gmail.com> says:
Currently, on the Toradex SMARC iMX95 and the Verdin iMX95 the ENETC
device is not enumerated before network initialization because
pci_init() is not called. As a result, no Ethernet device is registered.
Enable CONFIG_PCI_INIT_R so the PCI buses are enumerated early enough
for the Ethernet Controller to be detected and used.
Franz Schnyder [Fri, 12 Jun 2026 08:59:01 +0000 (10:59 +0200)]
configs: verdin-imx95: enable PCI_INIT_R
Currently, the ENETC device on iMX95 is not enumerated before network
initialization because pci_init() is not called. As a result, no
Ethernet device is registered.
Enable CONFIG_PCI_INIT_R so the PCI buses are enumerated early enough
for the Ethernet Controller to be detected and used.
Fixes: 60d8255d8dc0 ("board: toradex: add Toradex Verdin iMX95") Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Franz Schnyder [Fri, 12 Jun 2026 08:59:00 +0000 (10:59 +0200)]
configs: toradex-smarc-imx95: enable PCI_INIT_R
Currently, the ENETC device on iMX95 is not enumerated before network
initialization because pci_init() is not called. As a result, no
Ethernet device is registered.
Enable CONFIG_PCI_INIT_R so the PCI buses are enumerated early enough
for the Ethernet Controller to be detected and used.
Fixes: ff0540fcfe49 ("board: toradex: add Toradex SMARC iMX95") Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Please pull the updates for rockchip platform:
- New Board support: rk3588 FriendlyElec NanoPi R76S
- UFS boot from SPL for rk3576 (NanoPi M5, ROCK 4D)
- Clock support for RK3576 GMAC 25MHz output and RK3528/RK3576 USB3 OTG
- Switch rk3128/rk3229 boards to upstream devicetree
- MAINTAINERS update for upstream devicetree references
- rk3588-rock-5b: Remove USB-C controller from u-boot.dtsi
- Define memory map for lemans-evk (pending SMEM)
- Fix CONFIG_SYS_INIT_SP_BSS_OFFSET in db410c chainloaded fragment
- Fix the "dump bootargs" command in the qcom-phone boot menu
- Fix a bug in the rpmh-regulator driver where the regulator mode may
not be set during enable.
- Enable watchdog autostart for Dragonwing boards
- Fix serial console init on ipq5424-rdp466
arm: dts: ipq5424-rdp466: add chosen node for serial console
Add a /chosen node with stdout-path pointing to serial0 (uart1) to
enable the DT-driven console discovery path in
serial_find_console_or_panic().
Without this node, the live DT path in serial_find_console_or_panic()
is skipped and the fallback path is used. Adding the /chosen node makes
the console selection explicit and deterministic, ensuring the correct
serial device is always selected as the console.
Petr Hodina [Fri, 5 Jun 2026 15:09:07 +0000 (17:09 +0200)]
gpio: qcom_spmi_gpio: move PM8998 GPIO from legacy pmic driver
Move the "qcom,pm8998-gpio" compatible from the legacy driver
qcom_pmic_gpio.c to qcom_spmi_gpio.c. Enables on PM8998-based boards
(sdm845: SHIFT 6mq, Pixel 3, OnePlus 6, Poco F1, Sony Xperia Akatsuki)
the Volume UP gpio-key.
Tom Rini [Tue, 9 Jun 2026 16:26:36 +0000 (10:26 -0600)]
Merge patch series "ti: j7: Update to v0.12.0 of DDR config tool"
Neha Malcom Francis <n-francis@ti.com> says:
Update all DDR configuration DTSIs to the latest auto-generated output of
the Sysconfig Tool (DDR Configuration for TDA4x, DRA8x, AM67x, AM68x,
AM69x (0.12.00.0000)) [0]
The auto-generated files must not be modified, but effort will be taken to
change the tool output to adhere to the latest checkpatch.pl rules. J722S
and J721E will also be updated in a subsequent series.
All the changes have been kernel boot tested and memtester has passed (same
as v1, as no functional changes made).
Johan Jonker [Sun, 17 May 2026 23:24:13 +0000 (01:24 +0200)]
rockchip: MAINTAINERS: upstream devicetree update
Most Rockchip boards are now using the upstream device tree.
Some MAINTAINERS files still contain a reference to
no longer available files. Update and where possible
streamline with '*' ending.
Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Alexey Charkov [Mon, 4 May 2026 13:45:08 +0000 (17:45 +0400)]
rockchip: clk: clk_rk3576: Add support for RK3576 GMAC 25MHz clock output
Rockchip RK3576 SoC has two built-in GMACs which connect to external PHYs
via RGMII interface. The RGMII link can be clocked by either the PHY or
the SoC. When the SoC is the master, as is the case on the RK3576 EVB1,
the output clock needs to be configured in the CRU.
Add the respective logic for getting and setting the RGMII reference clock
output for both GMAC0 and GMAC1.
Tom Rini [Mon, 8 Jun 2026 21:37:38 +0000 (15:37 -0600)]
Merge patch series "mailbox: mpfs-mbox: fixes and syscon support"
Jamie Gibbons <jamie.gibbons@microchip.com> says:
This series updates the Microchip PolarFire SoC (MPFS) mailbox driver in
U-Boot.
The first three patches contain a set of bug fixes and cleanups to the
existing driver, fixing MMIO size calculations, and removing invalid
mailbox channel and private-data handling. These changes are independent
of any devicetree updates and fix issues present in the legacy driver.
The final patch adds support for the corrected, syscon-based devicetree
bindings for the MPFS mailbox. Linux has moved to this binding to more
accurately model the hardware, and U-Boot already supports the same
approach for the MPFS clock controller. This patch updates the mailbox
driver accordingly, while retaining support for the legacy binding for
backwards compatibility.
The final patch is required ASAP as boot is currently broken on master
for MPFS generic boards.
Jamie Gibbons [Mon, 18 May 2026 14:17:12 +0000 (15:17 +0100)]
mailbox: mpfs-mbox: support new syscon based devicetree configuration
The original PolarFire SoC mailbox devicetree bindings described the
control/status and interrupt registers as standalone reg regions of the
mailbox device. This was incorrect, as these registers are shared system
control blocks and should instead be modeled as syscon devices.
Linux has since corrected this by introducing syscon-based bindings for
the MPFS mailbox and updating the mailbox driver to access the control
and interrupt registers via syscon/regmap. U-Boot, however, continued to
expect the legacy binding, causing mailbox access to fail when using
Linux-aligned devicetrees.
Update the U-Boot MPFS mailbox driver to support the new syscon-based
bindings by resolving the control and sysreg syscon nodes and accessing
the registers through regmap. Support for the legacy mailbox binding is
retained for backwards compatibility with existing firmware-provided
devicetrees.
This brings the U-Boot mailbox driver in line with the corrected hardware
description and matches the behavior of the Linux mailbox driver.
Jamie Gibbons [Mon, 18 May 2026 14:17:11 +0000 (15:17 +0100)]
mailbox: mpfs-mbox: fix driver bug and cleanup
Remove an unused and invalid struct mbox_chan pointer from the private
data and fix incorrect memory handling in the probe path, where the
private data structure was allocated.
This change corrects a functional bugs and cleans up the driver without
altering its behavior.
Jamie Gibbons [Mon, 18 May 2026 14:17:10 +0000 (15:17 +0100)]
mailbox: mpfs-mbox: fix Driver Model private data handling
The MPFS mailbox driver declares priv_auto but also allocates a second
private data structure in the legacy probe path and overwrites the
device’s private pointer using dev_set_priv().
This results in leaking the auto-allocated private data and replacing
the driver’s private state mid-probe, which is incorrect usage of the
U-Boot Driver Model and can lead to undefined behavior.
Remove the redundant allocation and dev_set_priv() call so that the
driver consistently uses the auto-allocated private data provided by
U-Boot.
Frank Böwingloh [Fri, 5 Jun 2026 07:33:31 +0000 (09:33 +0200)]
smbios: Fix wrong sysinfo ID for Type 3 enclosure asset tag
smbios_write_type3() uses SYSID_SM_BASEBOARD_ASSET_TAG (Type 2) instead
of SYSID_SM_ENCLOSURE_ASSET_TAG (Type 3) for the enclosure asset tag.
This causes the enclosure's asset tag to be read from the baseboard
sysinfo field rather than the enclosure-specific one.
Fixes: bcf456dd ("smbios: add detailed smbios information") Signed-off-by: Frank Böwingloh <f.boewingloh@beckhoff.com> Cc: Raymond Mao <raymondmaoca@gmail.com> Cc: Tom Rini <trini@konsulko.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
projects / thirdparty / u-boot.git / log
