On February 19, 2026 thus sayeth Francesco Dolcini: > On Thu, Feb 19, 2026 at 04:10:20PM +0530, Suhaas Joshi wrote: > > On 19:46-20260218, 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. > > This is fixed with another patch, and I would confirm that this is > unrelated to the issue we are debugging here > > > > > 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 looked into that function. > > > > This is my current theory: > > > > The end address of 512MB RAM is 0x9FFFFFFF. This is the same as OPTEE's > > end address. > > > > If you look into the `spl_enable_cache()` function, you'll see that it > > is subtracting the size of page tables from the top of RAM, i.e. it is > > placing the page table at the end of RAM, i.e. it is placing the page > > table in OPTEE's memory region. Since this region wasn't protected by > > firewalls earlier, everything worked. But now the firewall disallows > > U-Boot's access to the page table. > > > > On 1GB and 2GB devices, there's a great deal of distance between the > > end addresses of RAM (0xBFFFFFFF and 0xFFFFFFFF respectively) and the > > end address of OPTEE. So we don't run into this issue. > > > > Francesco -- Just to confirm if this indeed is the case, could you > > change CONFIG_K3_OPTEE_LOAD_ADDR to any other free location, and check > > if the device boots? > > Any suggestion on a good address to use? > > I tried 0x83800000, and the result is not booting in different ways, > failing in different ways
Ah so for our am62 SiP package (which also has 512MB of DDR) we ended up moving OP-TEE down to 0x80080000[0] to let U-Boot relocate itself without crashing into OPTEE or TFA Because tiboot3.bin starts off the main domain by sending the A53 to TFA -> OPTEE -> SPL there isn't a great way to pass along the info to TFA on where to go next at run-time. So for this to work we will need to adjust the jump defaults in both TF-A and OP-TEE as well as modify the K3_OPTEE_LOAD_ADDR here. We're doing this in yocto here[1][2] [0] https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/conf/machine/am62xxsip-evm.conf#n7 [1] https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-ti.inc#n29 [2] https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-security/optee/optee-os-ti-overrides.inc#n9 With that updated it should allow us to get past the TFA init ~Bryan > > Sometime > > U-Boot SPL 2026.04-rc2-00035-g94764e8c861f-dirty (Feb 19 2026 - 19:21:39 > +0100) > SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)') > Set clock rates for '/a53@0', CPU: 800MHz at Speed Grade 'K' > 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 > > > and sometime Though this all assumes we're expecting OP-TEE init prints here and the board reset's itself after sometime because a watchdog went off. ~Bryan > > U-Boot SPL 2026.04-rc2-00035-g94764e8c861f-dirty (Feb 19 2026 - 19:21:39 > +0100) > SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)') > Set clock rates for '/a53@0', CPU: 800MHz at Speed Grade 'K' > 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! > Warning: Did not detect image signing certificate. Skipping authentication to > prevent boot failure. This will fail on Security Enforcing(HS- > SE) devices > Authentication passed > Starting ATF on ARM64 core... > > Francesco >
