[REGRESSION] lmb: add and reserve memory above ram_top

[Sughosh Ganu]

On Fri, 6 Dec 2024 at 09:55, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> Hi Sughosh,
>
> Commit eb052cbb896f ("lmb: add and reserve memory above ram_top")
> causes a regression on the E850-96 board. It looks like it could be
> not E850-96 specific though. During U-Boot boot (the most recent
> master branch, with this commit present), before U-Boot shell appears,
> I observe the next error message, which doesn't happen before this
> patch:
>
>     ERROR: reserving fdt memory region failed (addr=f0000000
> size=200000 flags=4)
>
> The memory node [1] is defined like this in the E850-96 dts:
>
>     memory at 80000000 {
>         device_type = "memory";
>         reg = <0x0 0x80000000 0x3ab00000>,
>                  <0x0 0xc0000000 0x40000000>,
>                  <0x8 0x80000000 0x80000000>;
>     };
>
> And the reserved-memory node [2] has only one entry:
>
>     ramoops at f0000000 {
>         reg = <0x0 0xf0000000 0x200000>;
>         ...
>     };
>
> Here is the relevant part of 'bdinfo' output:
>
>     lmb_dump_all:
>      memory.count = 0x3
>      memory[0]      [0x80000000-0xbaafffff], 0x3ab00000 bytes, flags: none
>      memory[1]      [0xc0000000-0xffffffff], 0x40000000 bytes, flags: none
>      memory[2]      [0x880000000-0x8ffffffff], 0x80000000 bytes, flags: none
>      reserved.count = 0x4
>      reserved[0]    [0xb922d000-0xb922ffff], 0x3000 bytes, flags:
> no-notify, no-overwrite
>      reserved[1]    [0xb9230e10-0xbaafffff], 0x18cf1f0 bytes, flags:
> no-overwrite
>      reserved[2]    [0xc0000000-0xffffffff], 0x40000000 bytes, flags:
> no-overwrite
>      reserved[3]    [0x880000000-0x8ffffffff], 0x80000000 bytes,
> flags: no-overwrite
>
> The same error also occurs when I'm trying to boot Linux with 'booti' command:
>
>     Working FDT set to 8a000000
>     ERROR: reserving fdt memory region failed (addr=f0000000
> size=200000 flags=4)
>        Loading Device Tree to 00000000b912a000, end 00000000b922cfff ... OK
>
> Although I think the device tree portion above is valid, I also tried
> to cleanup the 'memory' and 'reserved-memory' nodes like this, to see
> if that was going to help working around the issue:
>
>     memory at 80000000 {
>         device_type = "memory";
>         reg = <0x0 0x80000000 0x80000000>,
>                  <0x8 0x80000000 0x80000000>;
>     };
>
>     reserved-memory {
>         ...
>         secure_reserved: secure-os at bab00000 {
>             reg = <0x0 0xbab00000 0x5500000>;
>             no-map;
>         };
>
>         ramoops at f0000000 {
>             reg = <0x0 0xf0000000 0x200000>;
>             ...
>         };
>     };
>
> It made the first error message (during the U-Boot boot) go away, but
> the later errors (when trying to boot the kernel) still persist. Here
> is the relevant 'bdinfo' output with my dts change above applied:
>
>     lmb_dump_all:
>      memory.count = 0x2
>      memory[0]      [0x80000000-0xffffffff], 0x80000000 bytes, flags: none
>      memory[1]      [0x880000000-0x8ffffffff], 0x80000000 bytes, flags: none
>      reserved.count = 0x5
>      reserved[0]    [0xbab00000-0xbfffffff], 0x5500000 bytes, flags: no-map
>      reserved[1]    [0xf0000000-0xf01fffff], 0x200000 bytes, flags: no-overwrite
>      reserved[2]    [0xfe72d000-0xfe72ffff], 0x3000 bytes, flags:
> no-notify, no-overwrite
>      reserved[3]    [0xfe730dd0-0xffffffff], 0x18cf230 bytes, flags:
> no-overwrite
>      reserved[4]    [0x880000000-0x8ffffffff], 0x80000000 bytes,
> flags: no-overwrite
>
> The error messages I'm observing after issuing the 'booti' command are
> as follows:
>
>     ERROR: reserving fdt memory region failed (addr=bab00000
> size=5500000 flags=2)
>     ERROR: reserving fdt memory region failed (addr=f0000000
> size=200000 flags=4)
>
> It looks like all mentioned error messages are harmless, in a way that
> I'm still able to boot Linux, and U-Boot reserved areas still seem to
> exist in 'bdinfo'. But seeing error messages like that is definitely a
> nuisance by itself, and might be an indicator of some actual issues.
> Do you have any remedy for that by chance? Please let me know if you
> need more debug input from my side.

This seems to be happening because the board is trying to reserve
memory above ram_top with no-map or no-overwrite attributes. To
confirm, you can print the value of ram_top in setup_dest_addr().

-sughosh

>
> Thanks!
>
> [1] https://source.denx.de/u-boot/u-boot/-/blob/master/dts/upstream/src/arm64/exynos/exynos850-e850-96.dts#L55
> [2] https://source.denx.de/u-boot/u-boot/-/blob/master/dts/upstream/src/arm64/exynos/exynos850-e850-96.dts#L144