Re: [REGRESSION] Verdin AM62/62P not booting with 42b3ee7fa524

[Francesco Dolcini <francesco@dolcini.it>]

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