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

Thu Feb 19 11:30:49 CET 2026


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 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?
>>>
>>> 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 at fa10000: 0, mmc at fa00000: 1
>> Loading Environment from MMC... Reading from MMC(0)... OK
>> In:    serial at 2800000
>> Out:   serial at 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 at 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 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 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 at 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 at 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