On Mon, 16 Dec 2024 at 21:32, Sughosh Ganu <[email protected]> wrote: > > On Tue, 17 Dec 2024 at 00:59, Francesco Dolcini <[email protected]> wrote: > > > > On Tue, Dec 17, 2024 at 12:37:38AM +0530, Sughosh Ganu wrote: > > > On Tue, 17 Dec 2024 at 00:33, Francesco Dolcini <[email protected]> > > > 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 > >
