Suhaas Joshi [Thu, 12 Feb 2026 10:28:47 +0000 (15:58 +0530)]
board: toradex: Make A53 get RAM size from DT in K3 boards
`dram_init()` is called by R5 SPL and U-Boot, both. It starts by
computing the size of the RAM. In verdin-am62(p), it does so by calling
`get_ram_size()`. This function computes the size of the RAM by writing
over the RAM.
When R5 computes the size of the RAM, it does not update the DT with
this size. As a result, when A53 invokes `dram_init()` again, it has to
compute the size through `get_ram_size()` again.
Commit 13c54cf588d82 and 0c3a6f748c9 add firewall over ATF's and OPTEE's
regions. This firewall is added during the R5 SPL stage of boot. So when
A53 attempts to write over RAM in `get_ram_size()`, it writes over the
protected region. Since A53 is a non-secure core, this is blocked by the
firewall.
To fix this, do the following:
* Implement `spl_perform_board_fixups()` function for verdin-am62
and verdin-am62p. Make this function call `fixup_memory_node()`,
which updates the DT.
* Add an if-block in `dram_init()`, to ensure that only R5 is able
to call `get_ram_size()`, and that A53 reads this size from the
DT.
Signed-off-by: Suhaas Joshi <s-joshi@ti.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
USB Gadget:
* dwc3: Support ip and version type
* dwc3: Increase controller halt timeout
* dwc3: Don't send unintended link state change
* dwc3: Improve reset sequence
* dwc2: Move dr_mode check to bind to support RK3288/RK3506 with
2 DWC2 controllers
Heiko Schocher [Fri, 23 Jan 2026 02:25:51 +0000 (03:25 +0100)]
lib: sm3: fix coverity error
Coverity scan reported:
CID 449815: Memory - illegal accesses (OVERRUN)
Overrunning array of 64 bytes at byte offset 64 by dereferencing pointer
"sctx->buffer + partial". [Note: The source code implementation of the
function has been overridden by a builtin model.]
In line: 252
memset(sctx->buffer + partial, 0, SM3_BLOCK_SIZE - partial);
Pranav Tilak [Thu, 29 Jan 2026 08:10:54 +0000 (13:40 +0530)]
net: phy: mscc: Enable RMII clock output for VSC8541 PHY
Set RMII reference clock output to enabled (1) by default for VSC8541
PHY in RMII mode. The RMII specification requires a 50MHz reference
clock, and many board designs expect the PHY to provide this clock to
the MAC controller.
Previously, the driver defaulted rmii_clk_out to 0 (disabled) for all
interface modes, which caused the PHY to not output the required 50MHz
clock. This resulted in MAC-PHY communication failures and prevented
network operations like DHCP from working on RMII-configured boards.
This change alligns with the hardware power-up default behavior and
aligns with both the generic PHY driver and Linux MSCC PHY driver
implementations.
arm64: versal2: fix GICD/GICR base addresses for Versal Gen 2
Versal2 was using wrong GIC base mappings, causing GICR_TYPER reads to
not match EL1 MPIDR. This led U-Boot to walk beyond the per-CPU GICR
frames, access out-of-range addresses, and hit a synchronous exception
during early gic init percpu while booting up on alternate core
i.e., non cpu0.
Update Versal Gen 2 headers to the correct Versal Gen 2 bases.
Tom Rini [Tue, 10 Feb 2026 18:57:02 +0000 (12:57 -0600)]
Merge patch series "Update DDR Configurations"
Santhosh Kumar K <s-k6@ti.com> says:
This series updates the DDR Configurations according to the SysConfig DDR
Configuration tool v0.10.32 for the following devices [1]
- AM64x EVM
- AM62x SK
- AM62x LP SK
- AM62Ax SK
- AM62Px SK
Testing:
memtester - 50% of memory for 10 loops - PASSED
Peter Korsgaard [Mon, 19 Jan 2026 09:54:37 +0000 (10:54 +0100)]
drivers/clk/clk_zynqmp.c: get rid of compiler warning for !CONFIG_CMD_CLK builds
When built without CONFIG_CMD_CLK, we get a warning about the unused
clk_names variable:
../drivers/clk/clk_zynqmp.c:153:27: warning: ‘clk_names’ defined but not used [-Wunused-const-variable=]
153 | static const char * const clk_names[clk_max] = {
So also guard it with CONFIG_CMD_CLK to get rid of that.
Tom Rini [Thu, 5 Feb 2026 23:41:58 +0000 (17:41 -0600)]
arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
Historically, when we have an appended device tree and also our
resulting binary will contain the BSS section, we have ensured that
everything will be where it's expected to be by declaring that the BSS
is overlayed with a symbol matches the end of the port of the ELF binary
that is objcopy'd to the binary we concatenate with. This in turn means
that the logic to generate a "pad" file, which is the size found in the
__bss_size symbol, will be correct and then we can concatenate the
device tree and it will begin at __bss_size at run time.
With commit 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
we removed this overlay as part of trying to ensure that we met both the
requirements of the device tree to be 8 byte aligned as well as that our
logic to generate the -pad file would match what ended up in the
resulting binary. While it was correct to remove an unused section it
did not solve ultimately solve the problem for all cases.
To really fix the problem, we need to do two things. First, our final
section prior to _image_binary_end must be 8 byte aligned (for the case
of having a separate BSS and so our appended DTB exists at this
location). This cannot be '.binman_sym_table' as it may be empty, and in
turn the ELF type would be NOBITS and so not copied with objcopy. The
__u_boot_list section will never be empty, so it is our final section,
and ends with a '. = ALIGN(8)' statement. Second, as this is the end of
our copied data it is safe to declare that the BSS starts here, so use
the OVERLAY keyword to place the BSS here.
Fixes: 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts") Reported-by: Brian Sune <briansune@gmail.com> Reported-by: Phil Phil Sutter <phil@nwl.cc> Tested-by: Brian Sune <briansune@gmail.com> Tested-by: Phil Sutter <phil@nwl.cc> Tested-by: Greg Malysa <malysagreg@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Bryan Brattlof [Wed, 28 Jan 2026 12:36:21 +0000 (18:06 +0530)]
arm: mach-k3: r5: j721e: clk-data: manually set the main_pll3 frequency
Moving forward, DM firmware will no longer mess with the MAIN_PLL3.
This means MAIN_PLL3 will need to be manually set to 2GHz in order for
the CPSW9G HSDIV to have the correct 250MHz output for RGMII.
Tom Rini [Sat, 7 Feb 2026 17:51:14 +0000 (11:51 -0600)]
Merge patch series "Firewall ATF and OP-TEE memory regions in Sitara"
Suhaas Joshi <s-joshi@ti.com> says:
This series starts by replacing hard-coded addresses in firewall
templates that are defined in k3-binman.dtsi, by Kconfigs. Using
Kconfigs makes it easier for someone to move ATF and OP-TEE to another
location, since they wouldn't have to fiddle with the firewall
configurations in dtsi files.
The rest of the commits in this series add firewall configs to each
device's dtsi files.
I have only tested this patch series with TI boards. For non-TI Sitara
boards, respective board maintainers are requested to test the relevant
patch and confirm whether it works.
To test this, I used `k3conf <read|write> <address> [<value>]`. Both of
these operations were disallowed, as expected.
Suhaas Joshi [Tue, 27 Jan 2026 08:16:43 +0000 (13:46 +0530)]
arm: dts: k3-binman: Use configs for ATF/OPTEE addresses
Instead of hard-coding ATF and OPTEE addresses in firewall configuration
templates, use K3_*_LOAD_ADDR. Doing so ensures that if someone moves
ATF/OPTEE regions, the change gets picked up by binman without
explicitly having to modify dts files.
Signed-off-by: Suhaas Joshi <s-joshi@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Add include to avoid following build error with imx93_qsb, when
AHAB_BOOT is enabled:
.../arch/arm/mach-imx/ele_ahab.c:262:24: error: 'IMG_CONTAINER_BASE' undeclared (first use in this function); did you mean 'IMG_CONTAINER_END_BASE'?
.../arch/arm/mach-imx/ele_ahab.c:477:20: error: 'FSB_BASE_ADDR' undeclared (first use in this function); did you mean 'WDOG_BASE_ADDR'?
.../arch/arm/mach-imx/ele_ahab.c:543:20: error: 'FSB_BASE_ADDR' undeclared (first use in this function); did you mean 'WDOG_BASE_ADDR'?
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Peng Fan [Mon, 2 Feb 2026 02:57:45 +0000 (10:57 +0800)]
remoteproc: imx: Add i.MX95 support
i.MX95 uses System Manager(sm) API to start/stop logical machine or cpu.
There are two modes:
M7 in a dedicated logical machine, use LMM API
M7 and A55 in same logical machine, use CPU API
Extend the driver to using LMM and CPU protocol to manage the M7 core:
- Detect using LMM or CPU API in probe using API scmi_imx_lmm_info().
- Compare linux LM ID(got using scmi_imx_lmm_info) and M7 LM ID(the ID
is fixed as 1 in SM firmware if M7 is in a separate LM),
if Linux LM ID is not same as M7 LM ID(linux and M7 in same LM), use
LMM protocol to start/stop. Whether using CPU or LMM protocol to
start/stop, the M7 status detection could use CPU protocol to detect
started or not. So in imx_rproc_is_running, use scmi_imx_cpu_started to
check the status of M7.
- For above case (2), Use scmi_imx_lmm_power_boot to detect whether
the M7 LM is under control of A55 LM.
- For above case , after using SCMI_IMX_LMM_POWER_ON to check
permission, scmi_imx_lmm_shutdown API should be called to shutdown
the M7 LM.
- Add a new ops imx_rproc_ops_sm.
Peng Fan [Mon, 2 Feb 2026 02:57:44 +0000 (10:57 +0800)]
remoteproc: imx: Support ECC initialization
Add a new flag ATT_ECC which indicates the memory region needs ECC
initialization. If the flag is set, clearing the whole memory region to
initialize ECC. If ECC is not initialized, remote core will crash if
directly access the area.
Marek Vasut [Thu, 29 Jan 2026 00:44:28 +0000 (01:44 +0100)]
arm: renesas: Enable wget command and TCP on all R-Car systems
Enable the 'wget' command and TCP protocol support on all Renesas R-Car
systems. This allows users to download content from local HTTP server,
which may sometimes be more accessible than TFTP server. Enable TCP SACK
support to improve download performance.
The usage is similar to the TFTP command. To download file from server
http://192.ser.ver.ip/file/path/on/local/server , invoke wget as follows:
"
=> wget $loadaddr 192.ser.ver.ip:/file/path/on/local/server
"
In case the HTTP server listens on port other than default port 80,
set the 'httpdstp' environment variable to download file from server
http://192.ser.ver.ip:8088/file/path/on/local/server
"
=> env set httpdstp 8088
=> wget $loadaddr 192.ser.ver.ip:/file/path/on/local/server
"
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
* Remove pip from requirements.txt
* develop/process: Clarify name usage in the Signed-off-by line
UEFI:
* Improve EFI variable load message
* Fix use after free in efi_exit() with tcg2
* Fix efi_debug_image_info_normal allocation
* Add missing EFI_CALL in efi_net
net: airoha_eth: use proper switch node for en7523 case
Commit d2145a89bcf6 ("net: airoha: bind MDIO controller on Ethernet load")
uses "airoha,en7581-switch" dts node for finding MDIO childs. This is wrong
for EN7523 SoC. The correct node name should be used instead.
net: airoha_eth: fix mdio binding to switch device
Commit d2145a89bcf6 ("net: airoha: bind MDIO controller on Ethernet load")
refers to non-present CONFIG_MDIO_MT7531 and non-present "mt7531-mdio"
driver. It should use CONFIG_MDIO_MT7531_MMIO and "mt7531-mdio-mmio"
instead.
Jonas Karlman [Thu, 29 Jan 2026 21:01:51 +0000 (21:01 +0000)]
net: dwc_eth_qos: Start DMA and MAC after tail pointers are initialized
The DesignWare Cores Ethernet Quality-of-Service databook state that
receive and transmit descriptor list address and also transmit and
receive tail pointer registers should be initialized before the receive
and transmit DMAs are started.
It also state to enable the MAC receiver only after the DMA is active.
Otherwise, received frames can fill the Rx FIFO and overflow.
Move the activation of receive and transmit DMA and MAC receiver until
after tail pointer registers have been initialized.
Jonas Karlman [Thu, 29 Jan 2026 21:01:50 +0000 (21:01 +0000)]
net: dwc_eth_qos: Initialize the transmit tail pointer in eqos_start()
The DesignWare Cores Ethernet Quality-of-Service databook state that
descriptors up to one location less than the one indicated by the
descriptor tail pointer are owned by the DMA. The DMA continues to
process the descriptors until the following condition occurs:
Current Descriptor Pointer == Descriptor Tail Pointer
The DMA goes into suspend mode when this condition occurs, and updating
the tail pointer resume the DMA processing.
Configure the transmit tail pointer to the first (current) descriptor
pointer so that the tail pointer is a valid address instead of being
initialized to NULL when transmit DMA is started.
Also update the receive tail pointer comment to state that by pointing
to the last descriptor we are actually implying that all receive
descriptors are owned by and can be processed by the DMA.
Jonas Karlman [Thu, 29 Jan 2026 21:01:49 +0000 (21:01 +0000)]
net: dwc_eth_qos: Use lower_32_bits() for tail pointers
The DesignWare Cores Ethernet Quality-of-Service databook state that the
descriptor address from the start to the end of the ring must not cross
the 4GB boundary.
Use lower_32_bits() to write the lower 32 bits of descriptor addresses,
including the 32-bit tail pointers, consistently. No functional change
is intended.
Marek Vasut [Thu, 29 Jan 2026 00:23:29 +0000 (01:23 +0100)]
net: lwip: wget: rework the '#' printing
Currently, the LWIP wget command prints excessive amount of progress
indicator '#' for very long file downloads, limit this to one line
that scales according to transfer size.
The HTTP server does report the size of the entire file in protocol
headers, which are received before the actual data transfer. Cache
this information and use it to adaptively print progress indicator
'#' until it fills one entire line worth of '#', which indicates the
transfer has completed. This way, long transfers don't print pages of
'#', but every transfer will print exactly one line worth of '#'. The
algorithm for '#' printing is the same as TFTP tsize one.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Acked-by: Jerome Forissier <jerome.forissier@rm.com>
Marek Vasut [Wed, 28 Jan 2026 23:43:45 +0000 (00:43 +0100)]
net: lwip: tftp: add support of tsize option to client
The TFTP server can report the size of the entire file that is about to
be received in the Transfer Size Option, this is described in RFC 2349.
This functionality is optional and the server may not report tsize in
case it is not supported.
Always send tsize request to the server to query the transfer size,
and in case the server does respond, cache that information locally
in tftp_state.tsize, otherwise cache size 0. Introduce new function
tftp_client_get_tsize() which returns the cached tftp_state.tsize so
clients can determine the transfer size and use it.
Update net/lwip/tftp.c to make use of tftp_client_get_tsize() and
avoid excessive printing of '#' during TFTP transfers in case the
transfer size is reported by the server.
Yuya Hamamachi [Thu, 29 Jan 2026 22:30:19 +0000 (23:30 +0100)]
net: tftp: Fix TFTP Transfer Size data type
The TFTP transfer size is unsigned integer, update the data type
and print formating string accordingly to prevent an overflow in
case the file size is longer than 2 GiB.
TFTP transfer of a 3 GiB file, before (wrong) and after (right):
Loading: ################################################# 16 EiB
Loading: ################################################## 3 GiB
Signed-off-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Yuya Hamamachi [Thu, 29 Jan 2026 22:30:18 +0000 (23:30 +0100)]
net: Stop conflating return value with file size in net_loop()
The net_loop() currently conflates return value with file size
at the end of successful transfer, in NETLOOP_SUCCESS state.
The return type of net_loop() is int, which makes this practice
workable for file sizes below 2 GiB, but anything above that will
lead to overflow and bogus negative return value from net_loop().
The return file size is only used by a few sites in the code base,
which can be easily fixed. Change the net_loop() return value to
always be only a return code, in case of error the returned value
is the error code, in case of successful transfer the value is 0
or 1 instead of 0 or net_boot_file_size . This surely always fits
into a signed integer.
By keeping the return code 0 or 1 in case of successful transfer,
no conditionals which depended on the old behavior are broken, but
all the sites had to be inspected and updated accordingly.
Fix the few sites which depend on the file size by making them
directly use the net_boot_file_size variable value. This variable
is accessible to all of those sites already, because they all
include net-common.h .
Signed-off-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tom Rini [Fri, 30 Jan 2026 21:57:22 +0000 (15:57 -0600)]
CI: Update to using grub-2.14 for our tests
When building grub-2.12 with a newer GCC, we run in to warings (treated
as errors). The simple fix here is to move to the latest release tag. In
order to build a newer grub from source we need the autoconf-archive
package to be installed.
Marek Vasut [Wed, 28 Jan 2026 19:40:40 +0000 (20:40 +0100)]
gunzip: Fix len parameter in function signature
The only call site of gzwrite() is cmd/unzip.c do_gzwrite(), where
the 'len' parameter passed to gzwrite(..., len, ...) function is of
type unsigned long. This usage is correct, the 'len' parameter is
an unsigned integer, and the gzwrite() function currently supports
input data 'len' of up to 4 GiB - 1 .
The function signature of gzwrite() function in both include/gzip.h
and lib/gunzip.c does however list 'len' as signed integer, which
is not correct, and ultimatelly limits the implementation to only
2 GiB input data 'len' .
Fix this, update gzwrite() function parameter 'len' data type to
size_t consistently in include/gzip.h and lib/gunzip.c .
Furthermore, update gzwrite() function 'szwritebuf' parameter in
lib/gunzip.c from 'unsigned long' to 'size_t' to be synchronized
with include/gzip.h . Rewrite the other parameters to size_t and
off_t and propagate the change too.
Since the gzwrite() function currently surely only supports input
data size of 4 GiB - 1, add input data size check. The limitation
comes from the current use of zlib z_stream .avail_in parameter,
to which the gzwrite() function sets the entire input data size,
and which is of unsigned int type, which cannot accept any number
beyond 4 GiB - 1. This limitation will be removed in future commit.
Reported-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Jamie Gibbons [Tue, 20 Jan 2026 15:33:13 +0000 (15:33 +0000)]
configs: microchip_mpfs_generic: fix boot failure
Recent changes to device resource management (DEVRES) increased early
memory requirements during boot. The previous value was insufficient,
resulting in boot failures. Increase CONFIG_SYS_MALLOC_F_LEN to provide
enough early malloc pool for successful boot and device initialisation.
To reproduce the issue, define LOG_DEBUG in lib/efi_loader/efi_boottime.c
and build u-boot for your platform. Then, boot the U-Boot helloworld.efi
application over the network. Example commands (adjust the URL and boot
entry number):
=> efidebug boot add -u 0 net http://10.0.2.2:8000/helloworld.efi
=> efidebug boot order 0
=> bootefi bootmgr
Fixes: dd5d82a59995 ("efi_loader: efi_net: Add device path cache") 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: Adriano Cordova <adrianox@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Tue, 3 Feb 2026 19:16:20 +0000 (13:16 -0600)]
doc: develop/process: Clarify name usage in the Signed-off-by line
Long ago we took the Linux Kernel documentation about adding a
Signed-off-by line and adjusted it slightly for how we organized things.
In 2003 Linus clarified the intent and then re-worded what the name
portion of the Signed-off-by line can be. Mirror that change here.
When adding a new EFI Debug Image Info entry, we allocate memory for a new
EFI Debug Image Info Normal structure and we add a new entry into the EFI
Debug Image Info Table, which is in fact just a pointer to the allocated
structure.
However, when allocating memory for the new structure we allocate memory
for the wrong type, leading to allocating memory for just a pointer instead
of the desired structure.
Fix the type used during allocation.
Fixes: 146546138af5 ("efi: add EFI_DEBUG_IMAGE_INFO for debug") 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: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Pranav Tilak [Mon, 2 Feb 2026 11:37:17 +0000 (17:07 +0530)]
efi_loader: Improve EFI variable load message
Change the EFI variable load message from log_err() to log_info() with
neutral wording. The previous "Failed to load" message caused customer
confusion as it appeared to indicate an error condition.
The efi_var_from_file() function deliberately returns EFI_SUCCESS in
this case to allow the boot process to continue normally. This is
documented in the function's comment block but was not reflected in
the log message level or content.
The message now uses informational wording to reflect that this is
normal behavior when the ubootefi.var file does not yet exist.
Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Vincent Stehlé [Tue, 27 Jan 2026 16:18:43 +0000 (17:18 +0100)]
efi_loader: fix use after free in efi_exit() with tcg2
The efi_exit() function frees the loaded image memory by calling
efi_delete_image(). However, when CONFIG_EFI_TCG2_PROTOCOL is enabled, the
image_obj->image_type structure member is accessed after the memory has
been freed.
Fix this by performing the tcg2 measurement before the image deletion.
Fixes: 8fc4e0b4273a ("efi_loader: add boot variable measurement") Suggested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Masahisa Kojima <kojima.masahisa@socionext.com> Acked-by: Masahisa Kojima <kojima.masahisa@socionext.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>