On Tue, Feb 24, 2026 at 07:15:57PM +0530, Devarsh Thakkar wrote:
> commit ba20b2443c29 ("arm: mach-k3: common: Reserve video memory from
> end of the RAM") switched spl_enable_cache() to use gd->ram_top directly
> but omitted the board_get_usable_ram_top() call that limits RAM
> configuration and provides updated RAM end address per memory map
> used by board and impacts subsequent allocations and reservations.
> For e.g. here it impacts how high the TLB may be placed.
>
> On Verdin AM62 (512 MiB), the raw end of RAM (0xA0000000) is inside
> OP-TEE's region. board_get_usable_ram_top() in verdin-am62.c returns
> 0x9C000000 to keep relocations below it, but spl_enable_cache() never
> called it. commit 42b3ee7fa524 ("arm: mach-k3: am62x: Enable memory
> firewall support") then enforced the OP-TEE firewall, turning the silent
> corruption into a hard hang.
>
> Fix by calling board_get_usable_ram_top() after computing raw ram_top,
> consistent with setup_dest_addr() in board_f.c. A weak default is
> provided for boards that do not need to restrict the RAM top.
>
> Fixes: ba20b2443c29 ("arm: mach-k3: common: Reserve video memory from end of
> the RAM")
> Reported-by: Francesco Dolcini <[email protected]>
> Link: https://lore.kernel.org/all/20260224102121.GB340942@francesco-nb/
> Signed-off-by: Devarsh Thakkar <[email protected]>
Thanks Devarsh,
Tested-by: Francesco Dolcini <[email protected]> # Verdin AM62 512MB
