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

[Suhaas Joshi]

On 11:20-20260213, Francesco Dolcini wrote:
> Hello Suhaas, Bryan, all
> 
> On Wed, Feb 11, 2026 at 04:51:09PM +0530, Suhaas Joshi wrote:
> > On 11:11-20260211, Francesco Dolcini wrote:
> > > 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?
> > 
> > Yes, this does seem to be the issue, even in my digging. I have sent a
> > patch to fix this. But since I don't have boards, I have not tested
> > this. Could you please test this and let us know if it works, or if
> > there are any other issues that pop up?
> 
> With commit f9ffeec4bdcf ("board: toradex: Make A53 get RAM size from DT
> in K3 boards") merged we had our CI running on our whole board farm
> last night.
> 
> Good news: the issue is confirmed to be fixed on Verdin AM62P and Verdin
> AM62 [Quad|Dual] with [1|2]GB RAM.

That's great!
> 
> Bad news: we we do still have a boot failure regression on Verdin AM62
> single core with 512MB RAM. I have no idea if this is the same issue or
> a different one, but from the logs it look different (despite that I
> decided to keep using this email thread and not start a new one).
> 
> The failing board from the logs uses a AM6231ASGGHAALW SoC, maximum
> frequency 1GHz, we also have another device failing, single core again,
> with maximum frequency 800MHz, the working one have 1.4GHz max
> frequency.
> 
> Worth noticing the errors
>   Failed to set clock rates
> 
> These are new compared to the previous U-Boot release, it affects also
> other boards, and I have no idea if this is related to this issue or not.
> 
> Logs of the failing device (U-Boot is commit f9ffeec4bdcf1da655a0ffea482062adde78fee8)
> 
> U-Boot SPL 2026.04-rc2-0.0.0-devel+git.f9ffeec4bdcf (Feb 12 2026 - 14:12:09 +0000)
> SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.9--v11.02.09 (Fancy Rat)')
> Failed to set clock rates for '/a53 at 0': -22
> SPL initial stack usage: 13456 bytes
> Trying to boot from MMC1
> Authentication passed
> Authentication passed
> Authentication passed
> Loading Environment from nowhere... OK
> init_env from device 9 not supported!
> Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices
> 

I don't think this one is related to the firewall series. Not really
sure what the issue is. Just to rule this series out -- could you drop
my patch(es) and check if this specific device boots?

Was this device booting earlier? Could it be a build misconfig, since it
says that it can't detect an image signing certificate?

Regards
Suhaas

> 
> Logs of the booting device
> 
> U-Boot SPL 2026.04-rc2-0.0.0-devel+git.f9ffeec4bdcf (Feb 12 2026 - 14:12:09 +0000)
> SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.9--v11.02.09 (Fancy Rat)')
> Failed to set clock rates for '/a53 at 0': -22
> SPL initial stack usage: 13456 bytes
> Trying to boot from MMC1
> Authentication passed
> Authentication passed
> Authentication passed
> Loading Environment from nowhere... OK
> init_env from device 9 not supported!
> Authentication passed
> Authentication passed
> Starting ATF on ARM64 core...
> NOTICE:  BL31: v2.13.0(release):v2.13.0-259-ge0c4d3903b-dirty
> NOTICE:  BL31: Built : 07:01:36, Jul  1 2025
> U-Boot SPL 2026.04-rc2-0.0.0-devel+git.f9ffeec4bdcf (Feb 12 2026 - 14:12:09 +0000)
> SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.9--v11.02.09 (Fancy Rat)')
> SPL initial stack usage: 2048 bytes
> Trying to boot from MMC1
> Authentication passed
> Authentication passed
> U-Boot 2026.04-rc2-0.0.0-devel+git.f9ffeec4bdcf (Feb 12 2026 - 14:12:09 +0000)
> SoC:   AM62X SR1.0 HS-FS
> Reset reason: POR
> DRAM:  1 GiB
> optee optee: OP-TEE: revision 4.7 (a9690ae39995af36)
> Core:  160 devices, 35 uclasses, devicetree: separate
> MMC:   mmc at fa10000: 0, mmc at fa00000: 1
> Loading Environment from MMC... Reading from MMC(0)... OK
> In:    serial at 2800000
> Out:   serial at 2800000
> Err:   serial at 2800000
> Model: Toradex 0073 Verdin AM62 Dual 1GB ET V1.2A
> Serial#: 15412849
> Carrier: Toradex Dahlia V1.1D, Serial# 11287113
> 
> 
> Unfortunately I do not have a single core board to test readily
> available now, and I will be out of office a couple of days, but
> I decided to share this immediately so that we can try to understand
> what's going on. Middle of next week I should be able to do more tests.
> 
> Thanks for the support,
> Francesco
>