On Tue, Feb 10, 2026 at 11:50:14AM +0100, Francesco Dolcini wrote: > On Mon, Feb 09, 2026 at 02:20:01PM -0600, Bryan Brattlof wrote: > > Do you mind copying a boot log to a pastebin for me? I thought I had one > > of these boards but I'm still digging around for it. 0x80000000 should > > be where we load TFA now days unless some boards have opted out of > > letting U-Boot move it to the bottom of DRAM > > Here some more logs > > https://gist.github.com/dolcini/aa4b669c6349cc6da1b9e7b19cf53fed > > The files are named with the commit sha that is tested. > > On Tue, Feb 10, 2026 at 02:56:46PM +0530, Suhaas Joshi wrote: > > Verdin boards are the only ones that are reporting this issue. Is it > > alright if we revert only the two Verdin-specific commits, and let the > > rest (TI and PhyCore ones) stay as they are? The patches are pretty > > un-connected to each other. > > Verdin AM62 should not have anything special, the code is all there for > everyone to see, including the defconfig, the DT and so on, and the changes > we are talking about to me are self contained withing the SoC. Something > is wrong, and we are not understanding what yet. > > I just retested once more 42b3ee7fa524 and it just hung, you never know > if I did something wrong. And for what matter this was spotted by our > CI. > > > We are working on figuring out why Verdin is seeing these issues, in the > > meantime. > > Anything I can do let me know. > > If it matter the board that I am currently testing has 1GiB DDR RAM, and > the SoC is a AM6252ATCGHAALW.
I was able to trace the issue to the get_ram_size() in verdin-am62.c:dram_init(). That function walks the addressable memory range to dynamically detect how much memory is available. Not sure on the proper way to fix it however, Bryan? Suhaas? Francesco
