On Wed, Dec 18, 2024 at 11:00:06AM +0200, Ilias Apalodimas wrote:
> 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>
Reported-by: João Paulo Gonçalves <jpaulo.silvagoncal...@gmail.com>
Closes:
https://lore.kernel.org/all/20241216114231.qpfwug3zfqkxn...@joaog-nb.corp.toradex.com/
Thanks,
Francesco
