On Mon, Dec 16, 2024 at 09:35:58PM +0200, Ilias Apalodimas wrote: > 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
and initr_mmc. But yes, you are right, it happens during memory allocation using lmb. So what I wrote is just wrong (sorry!). Francesco
