[REGRESSION] Out of memory error: unable to boot on imx8mp/imx8mm

[Sughosh Ganu]

On Tue, 17 Dec 2024 at 16:55, Francesco Dolcini <francesco at dolcini.it> wrote:
>
> +Fabio, Marex, Peng, Frieder
>
> On Tue, Dec 17, 2024 at 08:18:50AM -0300, João Paulo Gonçalves wrote:
> > >
> > > Okay. Please try changing the value of ram_top to 0x1_0000_0000
> > > instead of 0xFFFF_FFFF. That should work.
> > >
> >
> > Changing ram_top to 0x1_0000_0000 worked:
> >
> > U-Boot SPL 2025.01-rc4-00025-g100a40dd79f8 (Dec 17 2024 - 08:05:06 -0300)
> > DDR configured as dual rank
> > WDT:   Started watchdog at 30280000 with servicing every 1000ms (60s timeout)
> > SEC0:  RNG instantiated
> > Normal Boot
> > Trying to boot from BOOTROM
> > Boot Stage: Primary boot
> > Find img info 0x4802d400, size 1116
> > Need continue download 1024
> > NOTICE:  BL31: v2.6(release):lf_v2.6-g3c1583ba0a
> > NOTICE:  BL31: Built : 11:00:38, Nov 21 2022
> >
> >
> > U-Boot 2025.01-rc4-00025-g100a40dd79f8 (Dec 17 2024 - 08:05:06 -0300)
> >
> > CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> > CPU:   Industrial temperature grade (-40C to 105C) at 54C
> > Reset cause: POR
> > DRAM:  Ram top: 100000000
> > 8 GiB
> > Core:  183 devices, 31 uclasses, devicetree: separate
> > WDT:   Started watchdog at 30280000 with servicing every 1000ms (60s timeout)
> > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... Reading from MMC(2)... OK
> > In:    serial at 30880000
> > Out:   serial at 30880000
> > Err:   serial at 30880000
> > Model: Toradex 0070 Verdin iMX8M Plus Quad 8GB WB IT V1.1A
> > Serial#: 15207893
> > Carrier: Toradex Dahlia V1.1C, Serial# 11060859
> > SEC0:  RNG instantiated
> > Setting variant to wifi
> > Net:   eth1: ethernet at 30be0000, eth0: ethernet at 30bf0000 [PRIME]
> > Hit any key to stop autoboot:  0
> > MMC: no card present
> > switch to partitions #0, OK
> > mmc2(part 0) is current device
> > Scanning mmc 2:1...
> > Found U-Boot script /boot.scr
> > 5974 bytes read in 1 ms (5.7 MiB/s)
> > ## Executing script at 50280000
> > Loading DeviceTree: imx8mp-verdin-wifi-dev.dtb
> > ...
> > Starting kernel ...
> >
> > The change is shown in the patch below, but I am unsure if this is the
> > correct solution. Should ram_top be the last valid address or the upper
> > bound?
> >
> > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
> > index 9588b8b28bf2..e01774ebc8a4 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, 0x100000000);
> >
> >         /*
> >          * rom_pointer[0] stores the TEE memory start address.
>
> see commit e27bddff4b97 ("imx8m: Restrict usable memory to space below 4G boundary").
>
> I assume such a change might introduce regressions.

I am not sure which commit you mean, since the above commit is
actually restricting the ram_top to 0x8000_0000. This is a corner case
of the bank end being above the value of ram_top. With the current
values, a single byte at 0xffff_ffff is getting reserved. And this
causes the lmb to not reserve the u-boot image region and also causes
the future allocations to fail. With the value of ram_top set to
0x1_0000_0000, the single byte reservation does not happen, and the
issue is not seen.

There is another way that this can be handled in the lmb code, but I
want to send that change after this release as we are pretty close to
this release. For the meantime, for this release, can you bump up the
value of ram_top by 1. I understand that the value of ram_top is one
more than the highest address that is to be used on the platform.

-sughosh

>
> Francesco
>
>