diff options
| author | Devarsh Thakkar <[email protected]> | 2026-02-24 19:15:57 +0530 |
|---|---|---|
| committer | Tom Rini <[email protected]> | 2026-02-24 10:28:21 -0600 |
| commit | 26048cdb4ce35b4119e82df2aafb1ebf3f611480 (patch) | |
| tree | 275d45859eaed9d72b8d1b3d50371a2e430ba173 /doc/develop | |
| parent | afa8f076db3e4ff322455e4b13b796f39c30eb14 (diff) | |
arm: mach-k3: common: Clamp RAM end address to board-usable region in spl_enable_cache()
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]>
Tested-by: Francesco Dolcini <[email protected]> # Verdin AM62 512MB
Diffstat (limited to 'doc/develop')
0 files changed, 0 insertions, 0 deletions
