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

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

[João Paulo Gonçalves]

Hello,

U-Boot is not able too boot on imx8mm and imx8mp and gives out of memory
errors:

U-Boot SPL 2025.01-rc4-00041-g50334151c020 (Dec 15 2024 - 14:02:46 +0000)
Training FAILED
DDR configured as single rank
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
SEC0:  RNG instantiated
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x4802f000, size 1116
Need continue download 1024
NOTICE:  Do not release JR0 to NS as it can be used by HAB
NOTICE:  BL31: v2.10.0	(release):android-14.0.0_2.2.0-rc2-0-g7c64d4e86-dirty
NOTICE:  BL31: Built : 10:35:32, Aug 29 2024
U-Boot 2025.01-rc4-00041-g50334151c020 (Dec 15 2024 - 14:02:46 +0000)
CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 24C
Reset cause: POR
DRAM:  4 GiB
Core:  183 devices, 31 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
out of memory
ERROR: Out of memory
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... out of memory
out of memory
Adding partition for mmc@30b60000.blk:1 failed
*** Warning - No block device, using default environment
out of memory
out of memory
Adding partition for mmc@30b60000.blk:1 failed

The regression was introduced with commit 1a48b0be93d4 ('lmb: prohibit
allocations above ram_top even from same bank'). Reverting it, allows U-Boot to
boot again. The issue seems to occur on modules with >=4Gb of RAM.

Do you have any idea what might be causing the issue? On our boards, the first
error occurs in efi_init_early() and then in initr_mmc(), and it happens during
memory allocation using lmb.

Best Regards,
João Paulo Gonçalves

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

[Sughosh Ganu]

On Mon, 16 Dec 2024 at 17:12, João Paulo Gonçalves
<jpaulo.silvagoncalves@gmail.com> wrote:
>
> Hello,
>
> U-Boot is not able too boot on imx8mm and imx8mp and gives out of memory
> errors:
>
> U-Boot SPL 2025.01-rc4-00041-g50334151c020 (Dec 15 2024 - 14:02:46 +0000)
> Training FAILED
> DDR configured as single rank
> WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
> SEC0:  RNG instantiated
> Normal Boot
> Trying to boot from BOOTROM
> Boot Stage: Primary boot
> Find img info 0x4802f000, size 1116
> Need continue download 1024
> NOTICE:  Do not release JR0 to NS as it can be used by HAB
> NOTICE:  BL31: v2.10.0  (release):android-14.0.0_2.2.0-rc2-0-g7c64d4e86-dirty
> NOTICE:  BL31: Built : 10:35:32, Aug 29 2024
> U-Boot 2025.01-rc4-00041-g50334151c020 (Dec 15 2024 - 14:02:46 +0000)
> CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> CPU:   Industrial temperature grade (-40C to 105C) at 24C
> Reset cause: POR
> DRAM:  4 GiB
> Core:  183 devices, 31 uclasses, devicetree: separate
> WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
> out of memory
> ERROR: Out of memory
> MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... out of memory
> out of memory
> Adding partition for mmc@30b60000.blk:1 failed
> *** Warning - No block device, using default environment
> out of memory
> out of memory
> Adding partition for mmc@30b60000.blk:1 failed
>
> The regression was introduced with commit 1a48b0be93d4 ('lmb: prohibit
> allocations above ram_top even from same bank'). Reverting it, allows U-Boot to
> boot again. The issue seems to occur on modules with >=4Gb of RAM.

Can you show the output of bdinfo. And also print the value of ram_top
while booting the board.

>
> Do you have any idea what might be causing the issue? On our boards, the first
> error occurs in efi_init_early() and then in initr_mmc(), and it happens during
> memory allocation using lmb.

We are not allowing allocations to be made from memory regions above
ram_top. So it would be good to know what ram_top is on your board.

-sughosh

>
> Best Regards,
> João Paulo Gonçalves
>

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

[João Paulo Gonçalves]

Hi Sughosh,

> Can you show the output of bdinfo. And also print the value of ram_top
> while booting the board.
>

Below are ram_top and bdinfo:

U-Boot 2025.01-rc4-00025-g4ff8ecd9b14e-dirty (Dec 16 2024 - 11:21:18 -0300)

CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 51C
Reset cause: POR
DRAM:  Ram top: FFFFFFFF
8 GiB
...
Verdin iMX8MP # bdinfo
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000040000000
-> size     = 0x00000000c0000000
DRAM bank   = 0x0000000000000001
-> start    = 0x0000000100000000
-> size     = 0x0000000140000000
flashstart  = 0x0000000000000000
flashsize   = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate    = 115200 bps
relocaddr   = 0x00000000ffece000
reloc off   = 0x00000000bfcce000
Build       = 64-bit
current eth = ethernet@30bf0000
ethaddr     = 6e:79:12:b6:72:24
IP addr     = <NULL>
fdt_blob    = 0x00000000ffab8450
lmb_dump_all:
 memory.count = 0x1
 memory[0]      [0x40000000-0x23fffffff], 0x200000000 bytes, flags: none
 reserved.count = 0x1
 reserved[0]    [0xffffffff-0x23fffffff], 0x140000001 bytes, flags: no-overwrite
devicetree  = separate
arch_number = 0x0000000000000000
TLB addr    = 0x00000000fffd0000
irq_sp      = 0x00000000ffab8440
sp start    = 0x00000000ffab8440
Early malloc usage: d620 / 10000


Best Regards,
João Paulo Gonçalves

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

[Francesco Dolcini]

Hello,

On Mon, Dec 16, 2024 at 11:28:42AM -0300, João Paulo Gonçalves wrote:
> Hi Sughosh,
> 
> > Can you show the output of bdinfo. And also print the value of ram_top
> > while booting the board.
> >
> 
> Below are ram_top and bdinfo:

We briefly discussed this off list, what is likely happen is that our
heap is after 0xFFFFFFFF, or said in a simpler way in the 64-bit address
space, while ram top is at the 4GB boundary.

The solution seems to either move the heap down or move ram top up.


> 
> U-Boot 2025.01-rc4-00025-g4ff8ecd9b14e-dirty (Dec 16 2024 - 11:21:18 -0300)
> 
> CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> CPU:   Industrial temperature grade (-40C to 105C) at 51C
> Reset cause: POR
> DRAM:  Ram top: FFFFFFFF
> 8 GiB
> ...
> Verdin iMX8MP # bdinfo
> boot_params = 0x0000000000000000
> DRAM bank   = 0x0000000000000000
> -> start    = 0x0000000040000000
> -> size     = 0x00000000c0000000
> DRAM bank   = 0x0000000000000001
> -> start    = 0x0000000100000000
> -> size     = 0x0000000140000000
> flashstart  = 0x0000000000000000
> flashsize   = 0x0000000000000000
> flashoffset = 0x0000000000000000
> baudrate    = 115200 bps
> relocaddr   = 0x00000000ffece000
> reloc off   = 0x00000000bfcce000
> Build       = 64-bit
> current eth = ethernet@30bf0000
> ethaddr     = 6e:79:12:b6:72:24
> IP addr     = <NULL>
> fdt_blob    = 0x00000000ffab8450
> lmb_dump_all:
>  memory.count = 0x1
>  memory[0]      [0x40000000-0x23fffffff], 0x200000000 bytes, flags: none
>  reserved.count = 0x1
>  reserved[0]    [0xffffffff-0x23fffffff], 0x140000001 bytes, flags: no-overwrite
> devicetree  = separate
> arch_number = 0x0000000000000000
> TLB addr    = 0x00000000fffd0000
> irq_sp      = 0x00000000ffab8440
> sp start    = 0x00000000ffab8440
> Early malloc usage: d620 / 10000
> 
> 
> Best Regards,
> João Paulo Gonçalves

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

[Sughosh Ganu]

On Tue, 17 Dec 2024 at 00:33, Francesco Dolcini <francesco@dolcini.it> wrote:
>
> Hello,
>
> On Mon, Dec 16, 2024 at 11:28:42AM -0300, João Paulo Gonçalves wrote:
> > Hi Sughosh,
> >
> > > Can you show the output of bdinfo. And also print the value of ram_top
> > > while booting the board.
> > >
> >
> > Below are ram_top and bdinfo:
>
> We briefly discussed this off list, what is likely happen is that our
> heap is after 0xFFFFFFFF, or said in a simpler way in the 64-bit address
> space, while ram top is at the 4GB boundary.
>
> The solution seems to either move the heap down or move ram top up.

I am not sure I understand. Isn't the heap memory part of the U-Boot
image, meaning it will always be below the ram_top? How do you have
this configuration where the heap is above ram_top? Can you point me
to the code where the heap is getting set above ram_top.

-sughosh

>
>
> >
> > U-Boot 2025.01-rc4-00025-g4ff8ecd9b14e-dirty (Dec 16 2024 - 11:21:18 -0300)
> >
> > CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> > CPU:   Industrial temperature grade (-40C to 105C) at 51C
> > Reset cause: POR
> > DRAM:  Ram top: FFFFFFFF
> > 8 GiB
> > ...
> > Verdin iMX8MP # bdinfo
> > boot_params = 0x0000000000000000
> > DRAM bank   = 0x0000000000000000
> > -> start    = 0x0000000040000000
> > -> size     = 0x00000000c0000000
> > DRAM bank   = 0x0000000000000001
> > -> start    = 0x0000000100000000
> > -> size     = 0x0000000140000000
> > flashstart  = 0x0000000000000000
> > flashsize   = 0x0000000000000000
> > flashoffset = 0x0000000000000000
> > baudrate    = 115200 bps
> > relocaddr   = 0x00000000ffece000
> > reloc off   = 0x00000000bfcce000
> > Build       = 64-bit
> > current eth = ethernet@30bf0000
> > ethaddr     = 6e:79:12:b6:72:24
> > IP addr     = <NULL>
> > fdt_blob    = 0x00000000ffab8450
> > lmb_dump_all:
> >  memory.count = 0x1
> >  memory[0]      [0x40000000-0x23fffffff], 0x200000000 bytes, flags: none
> >  reserved.count = 0x1
> >  reserved[0]    [0xffffffff-0x23fffffff], 0x140000001 bytes, flags: no-overwrite
> > devicetree  = separate
> > arch_number = 0x0000000000000000
> > TLB addr    = 0x00000000fffd0000
> > irq_sp      = 0x00000000ffab8440
> > sp start    = 0x00000000ffab8440
> > Early malloc usage: d620 / 10000
> >
> >
> > Best Regards,
> > João Paulo Gonçalves

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

[Francesco Dolcini]

On Tue, Dec 17, 2024 at 12:37:38AM +0530, Sughosh Ganu wrote:
> On Tue, 17 Dec 2024 at 00:33, Francesco Dolcini <francesco@dolcini.it> wrote:
> >
> > Hello,
> >
> > On Mon, Dec 16, 2024 at 11:28:42AM -0300, João Paulo Gonçalves wrote:
> > > Hi Sughosh,
> > >
> > > > Can you show the output of bdinfo. And also print the value of ram_top
> > > > while booting the board.
> > > >
> > >
> > > Below are ram_top and bdinfo:
> >
> > We briefly discussed this off list, what is likely happen is that our
> > heap is after 0xFFFFFFFF, or said in a simpler way in the 64-bit address
> > space, while ram top is at the 4GB boundary.
> >
> > The solution seems to either move the heap down or move ram top up.
> 
> I am not sure I understand. Isn't the heap memory part of the U-Boot
> image, meaning it will always be below the ram_top? How do you have
> this configuration where the heap is above ram_top? Can you point me
> to the code where the heap is getting set above ram_top.

I just guessed this, I might be plain wrong. I assume some malloc is failing,
maybe Joao can confirm.

Francesco

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

[Sughosh Ganu]

On Tue, 17 Dec 2024 at 00:59, Francesco Dolcini <francesco@dolcini.it> wrote:
>
> On Tue, Dec 17, 2024 at 12:37:38AM +0530, Sughosh Ganu wrote:
> > On Tue, 17 Dec 2024 at 00:33, Francesco Dolcini <francesco@dolcini.it> wrote:
> > >
> > > Hello,
> > >
> > > On Mon, Dec 16, 2024 at 11:28:42AM -0300, João Paulo Gonçalves wrote:
> > > > Hi Sughosh,
> > > >
> > > > > Can you show the output of bdinfo. And also print the value of ram_top
> > > > > while booting the board.
> > > > >
> > > >
> > > > Below are ram_top and bdinfo:
> > >
> > > We briefly discussed this off list, what is likely happen is that our
> > > heap is after 0xFFFFFFFF, or said in a simpler way in the 64-bit address
> > > space, while ram top is at the 4GB boundary.
> > >
> > > The solution seems to either move the heap down or move ram top up.
> >
> > I am not sure I understand. Isn't the heap memory part of the U-Boot
> > image, meaning it will always be below the ram_top? How do you have
> > this configuration where the heap is above ram_top? Can you point me
> > to the code where the heap is getting set above ram_top.
>
> I just guessed this, I might be plain wrong. I assume some malloc is failing,
> maybe Joao can confirm.

Ah okay. If it is some efi allocation that is failing, then the
allocation is not being done from heap. One thing that can be tried is
to have ram_top at 0x1_0000_0000 instead of 0xFFFF_FFFF.

-sughosh

>
> Francesco
>

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

[Ilias Apalodimas]

On Mon, 16 Dec 2024 at 21:32, Sughosh Ganu <sughosh.ganu@linaro.org> wrote:
>
> On Tue, 17 Dec 2024 at 00:59, Francesco Dolcini <francesco@dolcini.it> wrote:
> >
> > On Tue, Dec 17, 2024 at 12:37:38AM +0530, Sughosh Ganu wrote:
> > > On Tue, 17 Dec 2024 at 00:33, Francesco Dolcini <francesco@dolcini.it> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Mon, Dec 16, 2024 at 11:28:42AM -0300, João Paulo Gonçalves wrote:
> > > > > Hi Sughosh,
> > > > >
> > > > > > Can you show the output of bdinfo. And also print the value of ram_top
> > > > > > while booting the board.
> > > > > >
> > > > >
> > > > > Below are ram_top and bdinfo:
> > > >
> > > > We briefly discussed this off list, what is likely happen is that our
> > > > heap is after 0xFFFFFFFF, or said in a simpler way in the 64-bit address
> > > > space, while ram top is at the 4GB boundary.
> > > >
> > > > The solution seems to either move the heap down or move ram top up.
> > >
> > > I am not sure I understand. Isn't the heap memory part of the U-Boot
> > > image, meaning it will always be below the ram_top? How do you have
> > > this configuration where the heap is above ram_top? Can you point me
> > > to the code where the heap is getting set above ram_top.
> >
> > I just guessed this, I might be plain wrong. I assume some malloc is failing,
> > maybe Joao can confirm.
>
> Ah okay. If it is some efi allocation that is failing, then the
> allocation is not being done from heap. One thing that can be tried is
> to have ram_top at 0x1_0000_0000 instead of 0xFFFF_FFFF.

It was an EFI allocation that was failing by looking at the logs

Cheers
/Ilias
>
> -sughosh
>
> >
> > Francesco
> >

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

[Francesco Dolcini]

On Mon, Dec 16, 2024 at 09:35:58PM +0200, Ilias Apalodimas wrote:
> On Mon, 16 Dec 2024 at 21:32, Sughosh Ganu <sughosh.ganu@linaro.org> wrote:
> >
> > On Tue, 17 Dec 2024 at 00:59, Francesco Dolcini <francesco@dolcini.it> wrote:
> > >
> > > On Tue, Dec 17, 2024 at 12:37:38AM +0530, Sughosh Ganu wrote:
> > > > On Tue, 17 Dec 2024 at 00:33, Francesco Dolcini <francesco@dolcini.it> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Mon, Dec 16, 2024 at 11:28:42AM -0300, João Paulo Gonçalves wrote:
> > > > > > Hi Sughosh,
> > > > > >
> > > > > > > Can you show the output of bdinfo. And also print the value of ram_top
> > > > > > > while booting the board.
> > > > > > >
> > > > > >
> > > > > > Below are ram_top and bdinfo:
> > > > >
> > > > > We briefly discussed this off list, what is likely happen is that our
> > > > > heap is after 0xFFFFFFFF, or said in a simpler way in the 64-bit address
> > > > > space, while ram top is at the 4GB boundary.
> > > > >
> > > > > The solution seems to either move the heap down or move ram top up.
> > > >
> > > > I am not sure I understand. Isn't the heap memory part of the U-Boot
> > > > image, meaning it will always be below the ram_top? How do you have
> > > > this configuration where the heap is above ram_top? Can you point me
> > > > to the code where the heap is getting set above ram_top.
> > >
> > > I just guessed this, I might be plain wrong. I assume some malloc is failing,
> > > maybe Joao can confirm.
> >
> > Ah okay. If it is some efi allocation that is failing, then the
> > allocation is not being done from heap. One thing that can be tried is
> > to have ram_top at 0x1_0000_0000 instead of 0xFFFF_FFFF.
> 
> It was an EFI allocation that was failing by looking at the logs

and initr_mmc.

But yes, you are right, it happens during memory allocation using lmb. So what
I wrote is just wrong (sorry!).

Francesco

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

[Sughosh Ganu]

On Tue, 17 Dec 2024 at 01:10, Francesco Dolcini <francesco@dolcini.it> wrote:
>
> On Mon, Dec 16, 2024 at 09:35:58PM +0200, Ilias Apalodimas wrote:
> > On Mon, 16 Dec 2024 at 21:32, Sughosh Ganu <sughosh.ganu@linaro.org> wrote:
> > >
> > > On Tue, 17 Dec 2024 at 00:59, Francesco Dolcini <francesco@dolcini.it> wrote:
> > > >
> > > > On Tue, Dec 17, 2024 at 12:37:38AM +0530, Sughosh Ganu wrote:
> > > > > On Tue, 17 Dec 2024 at 00:33, Francesco Dolcini <francesco@dolcini.it> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > On Mon, Dec 16, 2024 at 11:28:42AM -0300, João Paulo Gonçalves wrote:
> > > > > > > Hi Sughosh,
> > > > > > >
> > > > > > > > Can you show the output of bdinfo. And also print the value of ram_top
> > > > > > > > while booting the board.
> > > > > > > >
> > > > > > >
> > > > > > > Below are ram_top and bdinfo:
> > > > > >
> > > > > > We briefly discussed this off list, what is likely happen is that our
> > > > > > heap is after 0xFFFFFFFF, or said in a simpler way in the 64-bit address
> > > > > > space, while ram top is at the 4GB boundary.
> > > > > >
> > > > > > The solution seems to either move the heap down or move ram top up.
> > > > >
> > > > > I am not sure I understand. Isn't the heap memory part of the U-Boot
> > > > > image, meaning it will always be below the ram_top? How do you have
> > > > > this configuration where the heap is above ram_top? Can you point me
> > > > > to the code where the heap is getting set above ram_top.
> > > >
> > > > I just guessed this, I might be plain wrong. I assume some malloc is failing,
> > > > maybe Joao can confirm.
> > >
> > > Ah okay. If it is some efi allocation that is failing, then the
> > > allocation is not being done from heap. One thing that can be tried is
> > > to have ram_top at 0x1_0000_0000 instead of 0xFFFF_FFFF.
> >
> > It was an EFI allocation that was failing by looking at the logs
>
> and initr_mmc.
>
> But yes, you are right, it happens during memory allocation using lmb. So what
> I wrote is just wrong (sorry!).

Okay. Please try changing the value of ram_top to 0x1_0000_0000
instead of 0xFFFF_FFFF. That should work.

-sughosh

>
> Francesco
>

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

[João Paulo Gonçalves]

> 
> 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@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@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@30880000
Out:   serial@30880000
Err:   serial@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@30be0000, eth0: ethernet@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.

Best Regards,
João Paulo Gonçalves

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

[Francesco Dolcini]

+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@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@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@30880000
> Out:   serial@30880000
> Err:   serial@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@30be0000, eth0: ethernet@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.

Francesco

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

[Sughosh Ganu]

On Tue, 17 Dec 2024 at 16:55, Francesco Dolcini <francesco@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@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@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@30880000
> > Out:   serial@30880000
> > Err:   serial@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@30be0000, eth0: ethernet@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
>
>

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

[Ilias Apalodimas]

Joao, there's 3 places that
'ERROR: Out of memory'. Since I don't have access to the board, can
you change the prints a bit and figure out where it comes from? I
assume it's from efi_console.c. Can we verify it?

Thanks
/Ilias

On Tue, 17 Dec 2024 at 13:18, João Paulo Gonçalves
<jpaulo.silvagoncalves@gmail.com> 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@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@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@30880000
> Out:   serial@30880000
> Err:   serial@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@30be0000, eth0: ethernet@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.
>
> Best Regards,
> João Paulo Gonçalves

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

[João Paulo Gonçalves]

On Tue, Dec 17, 2024 at 01:55:51PM +0200, Ilias Apalodimas wrote:
> Joao, there's 3 places that
> 'ERROR: Out of memory'. Since I don't have access to the board, can
> you change the prints a bit and figure out where it comes from? I
> assume it's from efi_console.c. Can we verify it?
> 
> Thanks
> /Ilias
> 
> On Tue, 17 Dec 2024 at 13:18, João Paulo Gonçalves
> <jpaulo.silvagoncalves@gmail.com> 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@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@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@30880000
> > Out:   serial@30880000
> > Err:   serial@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@30be0000, eth0: ethernet@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.
> >
> > Best Regards,
> > João Paulo Gonçalves

Yes, it is coming from efi_console.c in the efi_console_register(). The
first 'out of memory' occurs in efi_alloc() within efi_dp_from_uart().
As a result, efi_console_register() fails in efi_dp_from_uart() and
returns 'ERROR: Out of memory'." 

João Paulo