On 2/19/26 3:46 AM, Bryan Brattlof wrote:
On February 18, 2026 thus sayeth Francesco Dolcini:
Hello Suhaas,
On Wed, Feb 18, 2026 at 07:59:20AM +0100, Francesco Dolcini wrote:
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.
The issue is still there, and it seems again related with your changes.
Can you help? Any test that I should do?
v2026.01 booting fine
=====================
U-Boot SPL 2026.01 (Feb 18 2026 - 12:12:15 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
Changed A53 CPU frequency to 800000000Hz (K grade) in DT
SPL initial stack usage: 13512 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.01 (Feb 18 2026 - 12:12:38 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
SPL initial stack usage: 2048 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
U-Boot 2026.01 (Feb 18 2026 - 12:12:38 +0100)
SoC: AM62X SR1.0 HS-FS
Reset reason: POR
DRAM: 512 MiB
optee optee: OP-TEE: revision 4.7 (a9690ae39995af36)
Core: 159 devices, 34 uclasses, devicetree: separate
MMC: mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... Reading from MMC(0)... OK
In: serial@2800000
Out: serial@2800000
2026.04, commit 3243a73102c3 ("Merge branch 'master' of
https://source.denx.de/u-boot/custodians/u-boot-sh";), booting fine
=================================================================
U-Boot SPL 2026.04-rc1-00199-g3243a73102c3 (Feb 18 2026 - 15:38:33 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
Failed to set clock rates for '/a53@0': -22
SPL initial stack usage: 13512 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-rc1-00199-g3243a73102c3 (Feb 18 2026 - 15:38:57 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
SPL initial stack usage: 2048 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
U-Boot 2026.04-rc1-00199-g3243a73102c3 (Feb 18 2026 - 15:38:57 +0100)
SoC: AM62X SR1.0 HS-FS
Reset reason: POR
DRAM: 512 MiB
optee optee: OP-TEE: revision 4.7 (a9690ae39995af36)
Core: 160 devices, 35 uclasses, devicetree: separate
MMC: mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... Reading from MMC(0)... OK
In: serial@2800000
Out: serial@2800000
Err: serial@2800000
Model: Toradex 0071 Verdin AM62 Solo 512MB V1.2A
2026.04, current master, commit 8666b16015d4, NOT working
=========================================================
U-Boot SPL 2026.04-rc2-00033-g8666b16015d4 (Feb 18 2026 - 15:05:31 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
Failed to set clock rates for '/a53@0': -22
Hmm It's interesting to see this start to fail.
I have sent out a fix patch to drop the a53 clock overrides from the
board files,
https://lists.denx.de/pipermail/u-boot/2026-February/610466.html
With that fixed the boards will now show
Set clock rates for '/a53@0', CPU: 1250MHz at Speed Grade 'T'
SPL initial stack usage: 13464 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-00033-g8666b16015d4 (Feb 18 2026 - 15:05:54 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
I'm suspicious of the spl_enable_cache(). I've witnessed issues if we
add MMU entries that are not backed by DRAM which can cause the MMU to
crash the CPU.
I wonder (complete guess right now) if we're passing the correct DRAM
density to the A53 SPL?
~Bryan
