From: Ilias Apalodimas Date: Wed, 18 Dec 2024 09:00:06 +0000 (+0200) Subject: imx: Fix usable memory ranges for imx8m SOCs X-Git-Url: http://git.dujemihanovic.xyz/img/static/%7B%7B%20%24style.RelPermalink%20%7D%7D?a=commitdiff_plain;h=0b7f4c7cf3270103a9aa8ffe2c2fb43d09b4ced5;p=u-boot.git imx: Fix usable memory ranges for imx8m SOCs commit e27bddff4b97 ("imx8m: Restrict usable memory to space below 4G boundary") tried to adjust the usable memory limits on a 4GB boundary. ram_top is described as 'top address of RAM used by U-Boot' and we want to preserve that. This is defined as a phys_addr_t and unfortunately its size differs across architectures. This has lead us to a weird state where 32bit boards define it 'SZ_4GB - 1' and 64bit boards as 'SZ_4GB' unless it was otherwise defined. With some recent LMB changes and specifically commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank") the board fails to boot properly although the commit above is correct since it's making sure that no memory above ram_top is usable -- but added to our memory map so EFI can hand it over to the booted OS. The reason for that is that during the LMB init we add all usable memory in lmb_add_memory(). In that function any memory above ram_top gets added as 'reserved' for LMB. With the current values tha's set to 0xFFFF_FFFF for this board. Later LMB is trying to protect the memory area U-Boot lives in with lmb_reserve_common(). The latter fails though since it tries to add U-Boot top (which is 0xFFFF_FFFF as well) to U-Boot 'bottom'. This call will fail since 1 byte of that memory range is already marked as 'reserved'. Since we are close to the release, LMB seems to assume that the address is rounded up and is the 'next address' and so does parsing and adding memory ranges from DT files, bump the ram_top of the board by 1byte. In the long run we should change all of the above and have 32b and 64b platforms define ram_top identically. Add a Fixes tag although the commit is correct, so people can figure out the broken scenarios in the future. Suggested-by: Sughosh Ganu Fixes: commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank") Signed-off-by: Ilias Apalodimas Reviewed-by: Frieder Schrempf Reported-by: João Paulo Gonçalves Closes: https://lore.kernel.org/all/20241216114231.qpfwug3zfqkxn3d5@joaog-nb.corp.toradex.com/ Reviewed-by: Peng Fan Fixes: 74f88b72219e ("ARM: imx: imx8m: Fix board_get_usable_ram_top()") --- diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 9588b8b28b..85dc8b51a1 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -362,7 +362,7 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size) * space below the 4G address boundary (which is 3GiB big), * even when the effective available memory is bigger. */ - top_addr = clamp_val((u64)PHYS_SDRAM + gd->ram_size, 0, 0xffffffff); + top_addr = clamp_val((u64)PHYS_SDRAM + gd->ram_size, 0, SZ_4G); /* * rom_pointer[0] stores the TEE memory start address.