[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 at linaro.org> wrote:
>
> On Tue, 17 Dec 2024 at 00:59, Francesco Dolcini <francesco at 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 at 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
> >