On Tue, Feb 17, 2026 at 06:51:50PM +0530, Suhaas Joshi wrote: > On 11:20-20260213, Francesco Dolcini wrote: > > 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@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?
This is a regression with 2026.04. 2026.04-rc never booted on this device, and before commit f9ffeec4bdcf1da655a0ffea482062adde78fee8 none of the verdin am62[p] variants were booting for multiple bugs that were present in the release. 2026.01 is booting fine on this device, with plain vanilla U-Boot. Francesco
