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