Subject: [PATCH] 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 sughosh.ganu@linaro.org Fixes: commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank") Signed-off-by: Ilias Apalodimas ilias.apalodimas@linaro.org
Reviewed-by: Peng Fan peng.fan@nxp.com