u-boot.git/board/ti, branch next

Kconfig: board: restyle

2026-06-25T20:06:55Z

Restyle all Kconfigs: Menu entries : no space left Menu attributes: 1 TAB Help text : 1 TAB + 2 spaces Signed-off-by: Johan Jonker Reviewed-by: Tom Rini

treewide: move bi_dram[] from bd to gd

2026-06-25T00:13:24Z

Currently, the bi_dram[] information is stored in the board info structure (bd). Because bd is only valid after reserve_board(), dram_init_banksize() must be called late in the initialization process. This limitation is problematic, as it forces us to rely on a variety of bespoke functions to determine board RAM, bank memory sizes, and other early setup requirements. By moving bi_dram[] into the global data (gd), we can run it earlier. This is particularly convenient since boards define their own dram_init_banksize() routines, which do not always rely on parsing Device Tree (DT) memory nodes. Additionally, U-Boot defaults to relocating to the top of the first memory bank. While boards currently use custom functions to override this behavior, having the DRAM bank information available earlier in gd makes relocating to a different bank trivial and standardizes the process. Reviewed-by: Anshul Dalal Tested-by: Michal Simek # Versal Gen 2 Vek385 Tested-by: Anshul Dalal Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP)

board: ti: am62ax: tifs-rm-cfg/rm-cfg: Update DMA resource sharing for CPSW

2026-06-11T17:58:49Z

The CPSW3G instance of CPSW on AM62AX SoC provides Ethernet functionality. Currently, Ethernet is supported on Linux which runs on the A53 core on the SoC, by allocating all of the DMA resources associated with CPSW to A53_2. In order to enable use-cases where the Ethernet traffic is sent from or consumed by various CPU cores on the SoC simultaneously, while at the same time, maintaining backward compatibility with the existing use-case of A53 being the sole entity that exchanges traffic with CPSW via DMA, update the DMA resource sharing scheme on AM62AX SoC to the following: --------------- -------------- ------------- ---------------- Resource WKUP_R5 MCU_R5 A53_2 --------------- -------------- ------------- ---------------- TX Channels [8] => 4 (Primary) 4 (Primary) 8 (Secondary) TX Rings [64] => 32 (Primary) 32 (Primary) 64 (Secondary) RX Channels [1] => 1 (Primary) 0 1 (Secondary) RX Flows [16] => 6 (Primary) 10 (Primary) 16 (Secondary) In the absence of primary owners of resources (existing use-case where A53 owns all of the CPSW DMA resources), the secondary owner can claim all of the resources as its own. For shared use-cases, the resources that are not claimed by the primary are communicated to the secondary owner allowing it to claim them. This ensures that Linux on A53_2 can continue claiming all DMA resources associated with CPSW in the absence of primary owners, while at the same time providing users the flexibility to share CPSW DMA resources across various CPU cores listed above if needed. While Linux has been mentioned as the Operating System running on A53, there is no dependency between the Operating System running on A53 and its ability to claim the CPSW DMA resources listed above. Signed-off-by: Siddharth Vadapalli Acked-by: Anshul Dalal

board: ti: j722s: add processor ACL entry for wkup_r5

2026-05-29T20:17:14Z

On the j722s platform, the DM firmware resets the wkup_r5 core at boot to enable both of its TCM memories. This reset sequence involves three steps: - Acquiring processor ownership of wkup_r5 - Configuring the core and requesting a reset via TIFS - Releasing ownership. When the Linux remoteproc driver comes up, it acquires ownership of wkup_r5 to query its state, making A53_2 the new owner. During system suspend, TIFS saves the processor ACL[1] table to DDR as part of its context. On resume, TIFS restores the ACL table, leaving A53_2 as the owner of wkup_r5. At this point, DM (WKUP_0_R5_0 host[2]) no longer has ownership and is therefore unable to perform the reset sequence it needs, causing it to crash. To fix this, configure the wkup_r5[3] processor with dual ownership: - WKUP_0_R5_0 (Secure) as primary owner. - A53_2 (Non-Secure) as secondary owner. [1] https://software-dl.ti.com/tisci/esd/latest/3_boardcfg/BOARDCFG_SEC.html#pub-boardcfg-proc-acl [2] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j722s/hosts.html [3] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j722s/processors.html Signed-off-by: Abhash Kumar Jha Reviewed-by: Neha Malcom Francis

Merge patch series "Update envs to use Kconfig values"

2026-05-29T20:04:00Z

Anshul Dalal says: Some minor fixes to K3's env to avoid using hardcoded addresses but instead move to Kconfig symbols. Link: https://lore.kernel.org/r/20260518-env_to_kconfig_migration-v1-0-24c8fba75ad3@ti.com

env: ti: k3_dfu: use Kconfig options for addresses

2026-05-29T20:02:18Z

The load addresses for DFU download binaries were hardcoded for K3 devices which required redefinition of such env for boards that deviated from the expected K3 memory map (such as AM6254atl EMV). This patch replaces the hardcoded addresses with their corresponding Kconfig options making the k3_dfu.env more general. Signed-off-by: Anshul Dalal

env: ti: k3_dfu: load only the next stage binary

2026-05-29T20:02:18Z

In the TI's K3 bootflow of tiboot3.bin -> tispl.bin -> u-boot.img: (R5 SPL) (A53 SPL) We currently provide a common dfu_alt_info_ram for both R5 SPL and A53 SPL which is not intuitive in a regular bootflow where each binary should only request it's immediate next stage. This patch updates dfu_alt_info_ram such that the R5 SPL would only request for tispl.bin and A53 SPL would only request u-boot.img. Signed-off-by: Anshul Dalal

Merge tag 'v2026.07-rc3' into next

2026-05-25T17:35:35Z

Prepare v2026.07-rc3

am57xx: restore bootm_size for ARMv7 HighMem constraint

2026-05-25T15:29:30Z

babae80169d removed bootm_size from ti_common.env to allow K3 boards to process images larger than 256MB, but preserved it in ti_armv7_keystone2.env for ARMv7 Keystone2 boards. AM57xx (also ARMv7) was not covered by that preservation. Without bootm_size, env_get_bootm_size() falls back to gd->ram_size, causing initrd_high to be computed as the top of all RAM. On ARM32 boards with more RAM than the DMA zone (e.g. AM572x IDK with 2GiB), this places the ramdisk above 0xafe00000 (HighMem), which is not directly accessible by the kernel after MMU setup, causing a silent crash. With bootm_size=0x10000000, initrd_high is constrained to 0x80000000 + 0x10000000 = 0x90000000, keeping the ramdisk in the DMA zone and allowing the kernel to access it correctly. Fixes: babae80169dd ("include: env: ti_common: remove bootm_size") Reviewed-by: Neha Malcom Francis Signed-off-by: Moteen Shah

board: ti: am335x: Conditional MDIO PAD configuration instead of static for AM335_ICE

2026-05-14T21:41:07Z

This patch removes the static MDIO pinmux configuration from rmii1_pin_mux[] and instead configures the MDIO pins conditionally during board_init(). Previously, the MDIO_CLK and MDIO_DATA pins were always configured for CPSW in mux.c, which could lead to unnecessary pin ownership and conflicts in scenarios where CPSW is not used. With this change, the MDIO pins are configured only when required, ensuring that CPSW Ethernet functionality in U-Boot remains unaffected. This approach keeps Ethernet boot behavior intact and provides cleaner separation between CPSW and other Ethernet use cases. Reviewed-by: Markus Schneider-Pargmann (TI) Signed-off-by: Parvathi Pudi