On Wed Oct 8, 2025 at 8:33 PM IST, Bryan Brattlof wrote: > On October 6, 2025 thus sayeth Anshul Dalal: >> With the memory map configuration being done dynamically, reserve extra >> space during U-Boot relocation to ensure we have enough for the fixups. >> >> Signed-off-by: Anshul Dalal <[email protected]> >> --- >> arch/arm/mach-k3/arm64/arm64-mmu.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm/mach-k3/arm64/arm64-mmu.c >> b/arch/arm/mach-k3/arm64/arm64-mmu.c >> index 479451452a2..f999af143fb 100644 >> --- a/arch/arm/mach-k3/arm64/arm64-mmu.c >> +++ b/arch/arm/mach-k3/arm64/arm64-mmu.c >> @@ -41,3 +41,8 @@ struct mm_region k3_mem_map[K3_MEM_MAP_LEN] = { >> }; >> >> struct mm_region *mem_map = k3_mem_map; >> + >> +u64 get_page_table_size(void) >> +{ >> + return SZ_128K; >> +} > > How are we calculating this size? With 2^39 addresses this should bring > us into the MBs of TLB data. > > I see we limit U-Boot to 512 entries, but that doesn't match this either >
Of the current K3 devices, the largest reported size for the fixed up memory maps was ~32KiB with AM62 SiP (TFA@80000000 and TEE@80080000). With the carveouts not aligned to 2MiB, maximum size I saw was ~64KiB. So with an added 2x margin of safety, I arrived at 128KiB ;) This is enough for all current K3 devices and we can always increase it later if need be. As the panic we would get is pretty self explanatory: Insufficient RAM for page table: 0x3000 > 0x2000. Please increase the size in get_page_table_size() Regards, Anshul
