On Mon, Feb 23, 2026 at 04:58:21PM +0100, Francesco Dolcini wrote: > On Fri, Feb 20, 2026 at 07:23:42AM -0600, Bryan Brattlof wrote: > > On February 20, 2026 thus sayeth Francesco Dolcini: > > > On Thu, Feb 19, 2026 at 07:05:27PM -0600, Bryan Brattlof wrote: > > > > 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 > > > > > > Some progress ... > > > > > > I had to review also the U-Boot configuration, the whole memory map must > > > be revised ... > > > > > > With that sometime it works ... > > > > Nice! > > > > > > > > U-Boot SPL 2026.04-rc2-00038-g2d83c0fbbfed-dirty (Feb 20 2026 - 11:23:36 > > > +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-ge0c4d3903b38 > > > NOTICE: BL31: Built : 10:24:51, Feb 20 2026 > > > I/TC: > > > I/TC: OP-TEE version: 4.9.0-34-g33919ffbd54a (gcc version 14.2.0 (Debian > > > 14.2.0-19)) #2 Fri Feb 20 09:27:46 UTC 2026 aarch64 > > > I/TC: WARNING: This OP-TEE configuration might be insecure! > > > I/TC: WARNING: Please check > > > https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html > > > I/TC: Primary CPU initializing > > > I/TC: GIC redistributor base address not provided > > > I/TC: Assuming default GIC group status and modifier > > > I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)') > > > I/TC: HUK Initialized > > > I/TC: Disabling output console > > > > > > U-Boot SPL 2026.04-rc2-00038-g2d83c0fbbfed-dirty (Feb 20 2026 - 11:23:59 > > > +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-rc2-00038-g2d83c0fbbfed-dirty (Feb 20 2026 - 11:23:59 > > > +0100) > > > > > > SoC: AM62X SR1.0 HS-FS > > > Reset reason: POR > > > DRAM: 512 MiB > > > optee optee: OP-TEE: revision 4.9 (33919ffbd54a7cea) > > > 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 > > > Err: serial@2800000 > > > Model: Toradex 0071 Verdin AM62 Solo 512MB V1.2A > > > Serial#: 15412819 > > > Carrier: Toradex Verdin Development Board V1.1D, Serial# 10996055 > > > Net: am65_cpsw_nuss ethernet@8000000: K3 CPSW: nuss_ver: 0x6BA01103 > > > cpsw_ver: 0x6BA81103 ale_ver: 0x00290105 Ports:2 > > > am65_cpsw_nuss_port ethernet@8000000port@1: RGMII mode without internal > > > TX delay unsupported; please fix your Device Tree > > > > > > Warning: ethernet@8000000port@1 MAC addresses don't match: > > > Address in ROM is 64:1c:10:2a:6d:c2 > > > Address in environment is 00:14:2d:eb:2e:53 > > > eth0: ethernet@8000000port@1 [PRIME]am65_cpsw_nuss_port > > > ethernet@8000000port@2: RGMII mode without internal TX delay unsupported; > > > please > > > fix your Device Tree > > > , eth1: ethernet@8000000port@2 > > > Hit any key to stop autoboot: 0 > > > Verdin AM62 # > > > > > > > > > however, sometime it just crashes somewhere ... > > > > > > Verdin AM62 # reset > > > resetting ... > > > > > > U-Boot SPL 2026.04-rc2-00038-g2d83c0fbbfed-dirty (Feb 20 2026 - 11:23:36 > > > +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 > > > > How strange. It's odd U-Boot on some boots finds a certificate with the > > binaries and on others attempts it does not. If the image inside the > > tispl.bin was corrupted I would expect the SPL to reject the image. > > Some more updates ... > > I was not able to verify this yet, but it seems that since commit > ba20b2443c29 ("arm: mach-k3: common: Reserve video memory from end of > the RAM") the ram top is overwritten and our > verdin-am62.c:board_get_usable_ram_top() is ignored :-( > > So, the change from devarsh broke it, but before the addition of the > memory firewall the memory corruption was not leading to a crash ...
Some small progress. I can confirm that the issue is around the board_init_f() that is overridden on the k3 architecture and spl_enable_cache(). It messes up with gd->*ram* variables ignoring various config options, including verdin-am62.c:board_get_usable_ram_top(). Any comment on this? Trying to get out of this regression, one solution would be to move the whole memory map as it was done on the pocket beagle2, as it was suggested a few email ago. Or fix the spl_enable_cache() implementation. Bryan, and TI folks, what's your suggestion on the next steps here? In addition to that, no matter if I do a quick and dirty hack on spl_enable_cache(), or if I move the optee at the beginning of the ram, I get this error once every few resets ``` ... 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 ``` and after that a freeze. I am starting to think that this is another, unrelated issue. Thanks for the support, Francesco
