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

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

[Francesco Dolcini]

Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
everything was fine with b5213bbfdcb1.

Looking at the commits between the two revision, I would say that the
issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/

Suhaas: Can you help?

Failure::

U-Boot SPL 2026.04-rc1-0.0.0-devel+git.42b3ee7fa524 (Feb 08 2026 - 16:14:45 +0000)
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: 13504 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-0.0.0-devel+git.42b3ee7fa524 (Feb 08 2026 - 16:14:45 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')

## ... and after that just no logs at all.

Success::

U-Boot SPL 2026.04-rc1-0.0.0-devel+git.b5213bbfdcb1 (Feb 04 2026 - 16:41:48 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
Failed to set clock rates for '/a53@0': -61
SPL initial stack usage: 13504 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-0.0.0-devel+git.b5213bbfdcb1 (Feb 04 2026 - 16:41:48 +0000)
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-0.0.0-devel+git.b5213bbfdcb1 (Feb 04 2026 - 16:41:48 +0000)
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
Serial#: 15412814
Carrier: Toradex Dahlia V1.1D, Serial# 11287147


Thanks,
Francesco

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

[Francesco Dolcini]

+ Bryan, Anshul

On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> everything was fine with b5213bbfdcb1.
> 
> Looking at the commits between the two revision, I would say that the
> issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/

We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
nodes to k3-*-r5.dtsi") that might be the root cause for this issue.


Francesco

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

[Suhaas Joshi]

On 09:45-20260209, Francesco Dolcini wrote:
> + Bryan, Anshul
> 
> On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> > everything was fine with b5213bbfdcb1.
> > 
> > Looking at the commits between the two revision, I would say that the
> > issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
> 
> We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
> nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
> 

Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
so I cannot reproduce this issue. This is also why I wasn't able to test
my series on my end and had requested board-specific maintainers do the
same.

Since I don't have the boards, could you run the following test to help
us ascertain which of the 2 suspected commits actually broke the boot?

* First drop my AM625 Verdin patch, and compile and copy the binaries,
  and boot.
* Then let my patch remain in the tree, and remove Anshul's refactor
  patch, and try the same thing again.

This could help us ascertain which commit broke boot, and we can try
fixing from that commit.

Thanks
Suhaas

> 
> Francesco
> 

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

[Francesco Dolcini]

On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
> On 09:45-20260209, Francesco Dolcini wrote:
> > + Bryan, Anshul
> > 
> > On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > > Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> > > everything was fine with b5213bbfdcb1.
> > > 
> > > Looking at the commits between the two revision, I would say that the
> > > issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
> > 
> > We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
> > nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
> > 
> 
> Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
> so I cannot reproduce this issue. This is also why I wasn't able to test
> my series on my end and had requested board-specific maintainers do the
> same.
> 
> Since I don't have the boards, could you run the following test to help
> us ascertain which of the 2 suspected commits actually broke the boot?
> 
> * First drop my AM625 Verdin patch, and compile and copy the binaries,
>   and boot.
> * Then let my patch remain in the tree, and remove Anshul's refactor
>   patch, and try the same thing again.
> 
> This could help us ascertain which commit broke boot, and we can try
> fixing from that commit.

Sure, I can bisect it. 

Do this difference in the logs

Failed to set clock rates for '/a53@0': -22

  vs

Failed to set clock rates for '/a53@0': -61

ring any bell?

Francesco

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

[Francesco Dolcini]

On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
> On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
> > On 09:45-20260209, Francesco Dolcini wrote:
> > > + Bryan, Anshul
> > > 
> > > On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > > > Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> > > > everything was fine with b5213bbfdcb1.
> > > > 
> > > > Looking at the commits between the two revision, I would say that the
> > > > issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
> > > 
> > > We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
> > > nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
> > > 
> > 
> > Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
> > so I cannot reproduce this issue. This is also why I wasn't able to test
> > my series on my end and had requested board-specific maintainers do the
> > same.
> > 
> > Since I don't have the boards, could you run the following test to help
> > us ascertain which of the 2 suspected commits actually broke the boot?
> > 
> > * First drop my AM625 Verdin patch, and compile and copy the binaries,
> >   and boot.
> > * Then let my patch remain in the tree, and remove Anshul's refactor
> >   patch, and try the same thing again.
> > 
> > This could help us ascertain which commit broke boot, and we can try
> > fixing from that commit.
> 
> Sure, I can bisect it. 
> 
> Do this difference in the logs
> 
> Failed to set clock rates for '/a53@0': -22
> 
>   vs
> 
> Failed to set clock rates for '/a53@0': -61
> 
> ring any bell?

The boot failure start with commit 2ffab9da9142 ("Merge patch series
"Firewall ATF and OP-TEE memory regions in Sitara"").

With commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for
ATF/OPTEE addresses") the board still boots fine.
I have some concern that this commit is changing something, however
CONFIG_K3_ATF_LOAD_ADDR is 0x80000000, while before in the dtsi file it
was 0x70000000. I tried changing it back without any positive result,
I just got an EL3 exception.

Any more test I should do?

Francesco

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

On Mon, Feb 09, 2026 at 06:25:46PM +0100, Francesco Dolcini wrote:
> On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
> > On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
> > > On 09:45-20260209, Francesco Dolcini wrote:
> > > > + Bryan, Anshul
> > > > 
> > > > On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > > > > Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> > > > > everything was fine with b5213bbfdcb1.
> > > > > 
> > > > > Looking at the commits between the two revision, I would say that the
> > > > > issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
> > > > 
> > > > We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
> > > > nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
> > > > 
> > > 
> > > Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
> > > so I cannot reproduce this issue. This is also why I wasn't able to test
> > > my series on my end and had requested board-specific maintainers do the
> > > same.
> > > 
> > > Since I don't have the boards, could you run the following test to help
> > > us ascertain which of the 2 suspected commits actually broke the boot?
> > > 
> > > * First drop my AM625 Verdin patch, and compile and copy the binaries,
> > >   and boot.
> > > * Then let my patch remain in the tree, and remove Anshul's refactor
> > >   patch, and try the same thing again.
> > > 
> > > This could help us ascertain which commit broke boot, and we can try
> > > fixing from that commit.
> > 
> > Sure, I can bisect it. 
> > 
> > Do this difference in the logs
> > 
> > Failed to set clock rates for '/a53@0': -22
> > 
> >   vs
> > 
> > Failed to set clock rates for '/a53@0': -61
> > 
> > ring any bell?
> 
> The boot failure start with commit 2ffab9da9142 ("Merge patch series
> "Firewall ATF and OP-TEE memory regions in Sitara"").
> 
> With commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for
> ATF/OPTEE addresses") the board still boots fine.
> I have some concern that this commit is changing something, however
> CONFIG_K3_ATF_LOAD_ADDR is 0x80000000, while before in the dtsi file it
> was 0x70000000. I tried changing it back without any positive result,
> I just got an EL3 exception.
> 
> Any more test I should do?

Should I revert that firewall series, at this point?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Francesco Dolcini]

On Mon, Feb 09, 2026 at 11:43:08AM -0600, Tom Rini wrote:
> On Mon, Feb 09, 2026 at 06:25:46PM +0100, Francesco Dolcini wrote:
> > On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
> > > On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
> > > > On 09:45-20260209, Francesco Dolcini wrote:
> > > > > + Bryan, Anshul
> > > > > 
> > > > > On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > > > > > Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> > > > > > everything was fine with b5213bbfdcb1.
> > > > > > 
> > > > > > Looking at the commits between the two revision, I would say that the
> > > > > > issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
> > > > > 
> > > > > We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
> > > > > nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
> > > > > 
> > > > 
> > > > Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
> > > > so I cannot reproduce this issue. This is also why I wasn't able to test
> > > > my series on my end and had requested board-specific maintainers do the
> > > > same.
> > > > 
> > > > Since I don't have the boards, could you run the following test to help
> > > > us ascertain which of the 2 suspected commits actually broke the boot?
> > > > 
> > > > * First drop my AM625 Verdin patch, and compile and copy the binaries,
> > > >   and boot.
> > > > * Then let my patch remain in the tree, and remove Anshul's refactor
> > > >   patch, and try the same thing again.
> > > > 
> > > > This could help us ascertain which commit broke boot, and we can try
> > > > fixing from that commit.
> > > 
> > > Sure, I can bisect it. 
> > > 
> > > Do this difference in the logs
> > > 
> > > Failed to set clock rates for '/a53@0': -22
> > > 
> > >   vs
> > > 
> > > Failed to set clock rates for '/a53@0': -61
> > > 
> > > ring any bell?
> > 
> > The boot failure start with commit 2ffab9da9142 ("Merge patch series
> > "Firewall ATF and OP-TEE memory regions in Sitara"").
> > 
> > With commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for
> > ATF/OPTEE addresses") the board still boots fine.
> > I have some concern that this commit is changing something, however
> > CONFIG_K3_ATF_LOAD_ADDR is 0x80000000, while before in the dtsi file it
> > was 0x70000000. I tried changing it back without any positive result,
> > I just got an EL3 exception.
> > 
> > Any more test I should do?
> 
> Should I revert that firewall series, at this point?

I did one more test.

It seems that the issue is some interaction between the firewall series
and commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for ATF/OPTEE
addresses").

If I keep the firewall series in, and revert 24338c81ec2f, it boots.

IMO, unless we understand what is going on exactly, we should revert
both.

Suhaas: is current master working for you on the am62 SK or beagle play?

Francesco

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3469 bytes --]

On Mon, Feb 09, 2026 at 07:07:26PM +0100, Francesco Dolcini wrote:
> On Mon, Feb 09, 2026 at 11:43:08AM -0600, Tom Rini wrote:
> > On Mon, Feb 09, 2026 at 06:25:46PM +0100, Francesco Dolcini wrote:
> > > On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
> > > > On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
> > > > > On 09:45-20260209, Francesco Dolcini wrote:
> > > > > > + Bryan, Anshul
> > > > > > 
> > > > > > On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > > > > > > Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> > > > > > > everything was fine with b5213bbfdcb1.
> > > > > > > 
> > > > > > > Looking at the commits between the two revision, I would say that the
> > > > > > > issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
> > > > > > 
> > > > > > We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
> > > > > > nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
> > > > > > 
> > > > > 
> > > > > Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
> > > > > so I cannot reproduce this issue. This is also why I wasn't able to test
> > > > > my series on my end and had requested board-specific maintainers do the
> > > > > same.
> > > > > 
> > > > > Since I don't have the boards, could you run the following test to help
> > > > > us ascertain which of the 2 suspected commits actually broke the boot?
> > > > > 
> > > > > * First drop my AM625 Verdin patch, and compile and copy the binaries,
> > > > >   and boot.
> > > > > * Then let my patch remain in the tree, and remove Anshul's refactor
> > > > >   patch, and try the same thing again.
> > > > > 
> > > > > This could help us ascertain which commit broke boot, and we can try
> > > > > fixing from that commit.
> > > > 
> > > > Sure, I can bisect it. 
> > > > 
> > > > Do this difference in the logs
> > > > 
> > > > Failed to set clock rates for '/a53@0': -22
> > > > 
> > > >   vs
> > > > 
> > > > Failed to set clock rates for '/a53@0': -61
> > > > 
> > > > ring any bell?
> > > 
> > > The boot failure start with commit 2ffab9da9142 ("Merge patch series
> > > "Firewall ATF and OP-TEE memory regions in Sitara"").
> > > 
> > > With commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for
> > > ATF/OPTEE addresses") the board still boots fine.
> > > I have some concern that this commit is changing something, however
> > > CONFIG_K3_ATF_LOAD_ADDR is 0x80000000, while before in the dtsi file it
> > > was 0x70000000. I tried changing it back without any positive result,
> > > I just got an EL3 exception.
> > > 
> > > Any more test I should do?
> > 
> > Should I revert that firewall series, at this point?
> 
> I did one more test.
> 
> It seems that the issue is some interaction between the firewall series
> and commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for ATF/OPTEE
> addresses").

That's the first part of the series, and to be clear I'd revert the
whole series.

> If I keep the firewall series in, and revert 24338c81ec2f, it boots.
> 
> IMO, unless we understand what is going on exactly, we should revert
> both.
> 
> Suhaas: is current master working for you on the am62 SK or beagle play?

These changes boot and some pytests run on am64x_evm_a53, am62x_evm_a53
and am62x_beagleplay_a53

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Bryan Brattlof]

On February  9, 2026 thus sayeth Francesco Dolcini:
> On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
> > On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
> > > On 09:45-20260209, Francesco Dolcini wrote:
> > > > + Bryan, Anshul
> > > > 
> > > > On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > > > > Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> > > > > everything was fine with b5213bbfdcb1.
> > > > > 
> > > > > Looking at the commits between the two revision, I would say that the
> > > > > issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
> > > > 
> > > > We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
> > > > nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
> > > > 
> > > 
> > > Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
> > > so I cannot reproduce this issue. This is also why I wasn't able to test
> > > my series on my end and had requested board-specific maintainers do the
> > > same.
> > > 
> > > Since I don't have the boards, could you run the following test to help
> > > us ascertain which of the 2 suspected commits actually broke the boot?
> > > 
> > > * First drop my AM625 Verdin patch, and compile and copy the binaries,
> > >   and boot.
> > > * Then let my patch remain in the tree, and remove Anshul's refactor
> > >   patch, and try the same thing again.
> > > 
> > > This could help us ascertain which commit broke boot, and we can try
> > > fixing from that commit.
> > 
> > Sure, I can bisect it. 
> > 
> > Do this difference in the logs
> > 
> > Failed to set clock rates for '/a53@0': -22
> > 
> >   vs
> > 
> > Failed to set clock rates for '/a53@0': -61
> > 
> > ring any bell?
> 
> The boot failure start with commit 2ffab9da9142 ("Merge patch series
> "Firewall ATF and OP-TEE memory regions in Sitara"").
> 
> With commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for
> ATF/OPTEE addresses") the board still boots fine.
> I have some concern that this commit is changing something, however
> CONFIG_K3_ATF_LOAD_ADDR is 0x80000000, while before in the dtsi file it
> was 0x70000000. I tried changing it back without any positive result,
> I just got an EL3 exception.
> 
> Any more test I should do?
> 

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

~Bryan

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

[Suhaas Joshi]

On 12:13-20260209, Tom Rini wrote:
> On Mon, Feb 09, 2026 at 07:07:26PM +0100, Francesco Dolcini wrote:
> > On Mon, Feb 09, 2026 at 11:43:08AM -0600, Tom Rini wrote:
> > > On Mon, Feb 09, 2026 at 06:25:46PM +0100, Francesco Dolcini wrote:
> > > > On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
> > > > > On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
> > > > > > On 09:45-20260209, Francesco Dolcini wrote:
> > > > > > > + Bryan, Anshul
> > > > > > > 
> > > > > > > On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > > > > > > > Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
> > > > > > > > everything was fine with b5213bbfdcb1.
> > > > > > > > 
> > > > > > > > Looking at the commits between the two revision, I would say that the
> > > > > > > > issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
> > > > > > > 
> > > > > > > We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
> > > > > > > nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
> > > > > > > 
> > > > > > 
> > > > > > Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
> > > > > > so I cannot reproduce this issue. This is also why I wasn't able to test
> > > > > > my series on my end and had requested board-specific maintainers do the
> > > > > > same.
> > > > > > 
> > > > > > Since I don't have the boards, could you run the following test to help
> > > > > > us ascertain which of the 2 suspected commits actually broke the boot?
> > > > > > 
> > > > > > * First drop my AM625 Verdin patch, and compile and copy the binaries,
> > > > > >   and boot.
> > > > > > * Then let my patch remain in the tree, and remove Anshul's refactor
> > > > > >   patch, and try the same thing again.
> > > > > > 
> > > > > > This could help us ascertain which commit broke boot, and we can try
> > > > > > fixing from that commit.
> > > > > 
> > > > > Sure, I can bisect it. 
> > > > > 
> > > > > Do this difference in the logs
> > > > > 
> > > > > Failed to set clock rates for '/a53@0': -22
> > > > > 
> > > > >   vs
> > > > > 
> > > > > Failed to set clock rates for '/a53@0': -61
> > > > > 
> > > > > ring any bell?
> > > > 
> > > > The boot failure start with commit 2ffab9da9142 ("Merge patch series
> > > > "Firewall ATF and OP-TEE memory regions in Sitara"").
> > > > 
> > > > With commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for
> > > > ATF/OPTEE addresses") the board still boots fine.
> > > > I have some concern that this commit is changing something, however
> > > > CONFIG_K3_ATF_LOAD_ADDR is 0x80000000, while before in the dtsi file it
> > > > was 0x70000000. I tried changing it back without any positive result,
> > > > I just got an EL3 exception.
> > > > 
> > > > Any more test I should do?
> > > 
> > > Should I revert that firewall series, at this point?
> > 
> > I did one more test.
> > 
> > It seems that the issue is some interaction between the firewall series
> > and commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for ATF/OPTEE
> > addresses").
> 
> That's the first part of the series, and to be clear I'd revert the
> whole series.

This series is confirmed to be working on TI boards. I just tested it
(again) on AM62 SK. See [0] for logs.
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.

We are working on figuring out why Verdin is seeing these issues, in the
meantime.

[0] https://gist.github.com/jsuhaas22/b4d153eedf25e2269ddefc992c6020be

Thanks
Suhaas

> 
> > If I keep the firewall series in, and revert 24338c81ec2f, it boots.
> > 
> > IMO, unless we understand what is going on exactly, we should revert
> > both.
> > 
> > Suhaas: is current master working for you on the am62 SK or beagle play?
> 
> These changes boot and some pytests run on am64x_evm_a53, am62x_evm_a53
> and am62x_beagleplay_a53
> 
> -- 
> Tom

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

[Wadim Egorov]

On 2/10/26 4:26 PM, Suhaas Joshi wrote:
> On 12:13-20260209, Tom Rini wrote:
>> On Mon, Feb 09, 2026 at 07:07:26PM +0100, Francesco Dolcini wrote:
>>> On Mon, Feb 09, 2026 at 11:43:08AM -0600, Tom Rini wrote:
>>>> On Mon, Feb 09, 2026 at 06:25:46PM +0100, Francesco Dolcini wrote:
>>>>> On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
>>>>>> On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
>>>>>>> On 09:45-20260209, Francesco Dolcini wrote:
>>>>>>>> + Bryan, Anshul
>>>>>>>>
>>>>>>>> On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
>>>>>>>>> Verdin AM62 and AM62P are not booting anymore with U-Boot 42b3ee7fa524,
>>>>>>>>> everything was fine with b5213bbfdcb1.
>>>>>>>>>
>>>>>>>>> Looking at the commits between the two revision, I would say that the
>>>>>>>>> issue is with this series https://lore.kernel.org/all/20260127081652.506357-1-s-joshi@ti.com/
>>>>>>>>
>>>>>>>> We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor common
>>>>>>>> nodes to k3-*-r5.dtsi") that might be the root cause for this issue.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Francesco. Unfortunately, I don't have Verdin line of boards with me,
>>>>>>> so I cannot reproduce this issue. This is also why I wasn't able to test
>>>>>>> my series on my end and had requested board-specific maintainers do the
>>>>>>> same.
>>>>>>>
>>>>>>> Since I don't have the boards, could you run the following test to help
>>>>>>> us ascertain which of the 2 suspected commits actually broke the boot?
>>>>>>>
>>>>>>> * First drop my AM625 Verdin patch, and compile and copy the binaries,
>>>>>>>    and boot.
>>>>>>> * Then let my patch remain in the tree, and remove Anshul's refactor
>>>>>>>    patch, and try the same thing again.
>>>>>>>
>>>>>>> This could help us ascertain which commit broke boot, and we can try
>>>>>>> fixing from that commit.
>>>>>>
>>>>>> Sure, I can bisect it.
>>>>>>
>>>>>> Do this difference in the logs
>>>>>>
>>>>>> Failed to set clock rates for '/a53@0': -22
>>>>>>
>>>>>>    vs
>>>>>>
>>>>>> Failed to set clock rates for '/a53@0': -61
>>>>>>
>>>>>> ring any bell?
>>>>>
>>>>> The boot failure start with commit 2ffab9da9142 ("Merge patch series
>>>>> "Firewall ATF and OP-TEE memory regions in Sitara"").
>>>>>
>>>>> With commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for
>>>>> ATF/OPTEE addresses") the board still boots fine.
>>>>> I have some concern that this commit is changing something, however
>>>>> CONFIG_K3_ATF_LOAD_ADDR is 0x80000000, while before in the dtsi file it
>>>>> was 0x70000000. I tried changing it back without any positive result,
>>>>> I just got an EL3 exception.
>>>>>
>>>>> Any more test I should do?
>>>>
>>>> Should I revert that firewall series, at this point?
>>>
>>> I did one more test.
>>>
>>> It seems that the issue is some interaction between the firewall series
>>> and commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for ATF/OPTEE
>>> addresses").
>>
>> That's the first part of the series, and to be clear I'd revert the
>> whole series.
> 
> This series is confirmed to be working on TI boards. I just tested it
> (again) on AM62 SK. See [0] for logs.
> 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.

I have not tested the patches on the phycore-soms yet.

> 
> We are working on figuring out why Verdin is seeing these issues, in the
> meantime.
> 
> [0] https://gist.github.com/jsuhaas22/b4d153eedf25e2269ddefc992c6020be
> 
> Thanks
> Suhaas
> 
>>
>>> If I keep the firewall series in, and revert 24338c81ec2f, it boots.
>>>
>>> IMO, unless we understand what is going on exactly, we should revert
>>> both.
>>>
>>> Suhaas: is current master working for you on the am62 SK or beagle play?
>>
>> These changes boot and some pytests run on am64x_evm_a53, am62x_evm_a53
>> and am62x_beagleplay_a53
>>
>> -- 
>> Tom
> 
> 

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

[Wadim Egorov]

On 2/10/26 5:02 PM, Wadim Egorov wrote:
> 
> 
> On 2/10/26 4:26 PM, Suhaas Joshi wrote:
>> On 12:13-20260209, Tom Rini wrote:
>>> On Mon, Feb 09, 2026 at 07:07:26PM +0100, Francesco Dolcini wrote:
>>>> On Mon, Feb 09, 2026 at 11:43:08AM -0600, Tom Rini wrote:
>>>>> On Mon, Feb 09, 2026 at 06:25:46PM +0100, Francesco Dolcini wrote:
>>>>>> On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
>>>>>>> On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
>>>>>>>> On 09:45-20260209, Francesco Dolcini wrote:
>>>>>>>>> + Bryan, Anshul
>>>>>>>>>
>>>>>>>>> On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
>>>>>>>>>> Verdin AM62 and AM62P are not booting anymore with U-Boot 
>>>>>>>>>> 42b3ee7fa524,
>>>>>>>>>> everything was fine with b5213bbfdcb1.
>>>>>>>>>>
>>>>>>>>>> Looking at the commits between the two revision, I would say 
>>>>>>>>>> that the
>>>>>>>>>> issue is with this series https://lore.kernel.org/ 
>>>>>>>>>> all/20260127081652.506357-1-s-joshi@ti.com/
>>>>>>>>>
>>>>>>>>> We have also commit 3382d75f7a6c ("arch: arm: dts: k3: refactor 
>>>>>>>>> common
>>>>>>>>> nodes to k3-*-r5.dtsi") that might be the root cause for this 
>>>>>>>>> issue.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Francesco. Unfortunately, I don't have Verdin line of boards 
>>>>>>>> with me,
>>>>>>>> so I cannot reproduce this issue. This is also why I wasn't able 
>>>>>>>> to test
>>>>>>>> my series on my end and had requested board-specific maintainers 
>>>>>>>> do the
>>>>>>>> same.
>>>>>>>>
>>>>>>>> Since I don't have the boards, could you run the following test 
>>>>>>>> to help
>>>>>>>> us ascertain which of the 2 suspected commits actually broke the 
>>>>>>>> boot?
>>>>>>>>
>>>>>>>> * First drop my AM625 Verdin patch, and compile and copy the 
>>>>>>>> binaries,
>>>>>>>>    and boot.
>>>>>>>> * Then let my patch remain in the tree, and remove Anshul's 
>>>>>>>> refactor
>>>>>>>>    patch, and try the same thing again.
>>>>>>>>
>>>>>>>> This could help us ascertain which commit broke boot, and we can 
>>>>>>>> try
>>>>>>>> fixing from that commit.
>>>>>>>
>>>>>>> Sure, I can bisect it.
>>>>>>>
>>>>>>> Do this difference in the logs
>>>>>>>
>>>>>>> Failed to set clock rates for '/a53@0': -22
>>>>>>>
>>>>>>>    vs
>>>>>>>
>>>>>>> Failed to set clock rates for '/a53@0': -61
>>>>>>>
>>>>>>> ring any bell?
>>>>>>
>>>>>> The boot failure start with commit 2ffab9da9142 ("Merge patch series
>>>>>> "Firewall ATF and OP-TEE memory regions in Sitara"").
>>>>>>
>>>>>> With commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for
>>>>>> ATF/OPTEE addresses") the board still boots fine.
>>>>>> I have some concern that this commit is changing something, however
>>>>>> CONFIG_K3_ATF_LOAD_ADDR is 0x80000000, while before in the dtsi 
>>>>>> file it
>>>>>> was 0x70000000. I tried changing it back without any positive result,
>>>>>> I just got an EL3 exception.
>>>>>>
>>>>>> Any more test I should do?
>>>>>
>>>>> Should I revert that firewall series, at this point?
>>>>
>>>> I did one more test.
>>>>
>>>> It seems that the issue is some interaction between the firewall series
>>>> and commit 24338c81ec2f ("arm: dts: k3-binman: Use configs for ATF/ 
>>>> OPTEE
>>>> addresses").
>>>
>>> That's the first part of the series, and to be clear I'd revert the
>>> whole series.
>>
>> This series is confirmed to be working on TI boards. I just tested it
>> (again) on AM62 SK. See [0] for logs.
>> 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.
> 
> I have not tested the patches on the phycore-soms yet.

The phycore-am62x boots, see the logs

https://pastebin.ubuntu.com/p/P3GHhZw8xc/plain/

But I can also see this new error

   Failed to set clock rates for '/a53@0': -61


> 
>>
>> We are working on figuring out why Verdin is seeing these issues, in the
>> meantime.
>>
>> [0] https://gist.github.com/jsuhaas22/b4d153eedf25e2269ddefc992c6020be
>>
>> Thanks
>> Suhaas
>>
>>>
>>>> If I keep the firewall series in, and revert 24338c81ec2f, it boots.
>>>>
>>>> IMO, unless we understand what is going on exactly, we should revert
>>>> both.
>>>>
>>>> Suhaas: is current master working for you on the am62 SK or beagle 
>>>> play?
>>>
>>> These changes boot and some pytests run on am64x_evm_a53, am62x_evm_a53
>>> and am62x_beagleplay_a53
>>>
>>> -- 
>>> Tom
>>
>>
> 

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

[Francesco Dolcini]

On Tue, Feb 10, 2026 at 05:22:13PM +0700, Wadim Egorov wrote:
> 
> 
> On 2/10/26 5:02 PM, Wadim Egorov wrote:
> > 
> > 
> > On 2/10/26 4:26 PM, Suhaas Joshi wrote:
> > > On 12:13-20260209, Tom Rini wrote:
> > > > On Mon, Feb 09, 2026 at 07:07:26PM +0100, Francesco Dolcini wrote:
> > > > > On Mon, Feb 09, 2026 at 11:43:08AM -0600, Tom Rini wrote:
> > > > > > On Mon, Feb 09, 2026 at 06:25:46PM +0100, Francesco Dolcini wrote:
> > > > > > > On Mon, Feb 09, 2026 at 11:16:35AM +0100, Francesco Dolcini wrote:
> > > > > > > > On Mon, Feb 09, 2026 at 03:38:51PM +0530, Suhaas Joshi wrote:
> > > > > > > > > On 09:45-20260209, Francesco Dolcini wrote:
> > > > > > > > > > + Bryan, Anshul
> > > > > > > > > > 
> > > > > > > > > > On Mon, Feb 09, 2026 at 09:38:55AM +0100, Francesco Dolcini wrote:
> > > > > > > > > > > Verdin AM62 and AM62P are not
> > > > > > > > > > > booting anymore with U-Boot
> > > > > > > > > > > 42b3ee7fa524,
> > > > > > > > > > > everything was fine with b5213bbfdcb1.
> > > > > > > > > > > 
> > > > > > > > > > > Looking at the commits between the
> > > > > > > > > > > two revision, I would say that the
> > > > > > > > > > > issue is with this series
> > > > > > > > > > > https://lore.kernel.org/
> > > > > > > > > > > all/20260127081652.506357-1-s-joshi@ti.com/
> > > > > > > > > > 
> > > > > > > > > > We have also commit 3382d75f7a6c ("arch:
> > > > > > > > > > arm: dts: k3: refactor common
> > > > > > > > > > nodes to k3-*-r5.dtsi") that might be
> > > > > > > > > > the root cause for this issue.
...

> > > This series is confirmed to be working on TI boards. I just tested it
> > > (again) on AM62 SK. See [0] for logs.
> > > 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.
> > 
> > I have not tested the patches on the phycore-soms yet.
> 
> The phycore-am62x boots, see the logs
> 
> https://pastebin.ubuntu.com/p/P3GHhZw8xc/plain/
> 
> But I can also see this new error
> 
>   Failed to set clock rates for '/a53@0': -61

Yes, this is also new on verdin am62. It seems unrelated, and it should
be also be fixed / investigated.

Francesco

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

[Francesco Dolcini]

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. 

Francesco

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

[Francesco Dolcini]

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?

Francesco

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

[Suhaas Joshi]

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?

Thanks
Suhaas

[0] https://lore.kernel.org/u-boot/20260211111328.1481562-1-s-joshi@ti.com/
> 
> Francesco
> 

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

[Francesco Dolcini]

Hello Suhaas, Bryan, all

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.

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


Logs of the booting device

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!
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-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)')
SPL initial stack usage: 2048 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
U-Boot 2026.04-rc2-0.0.0-devel+git.f9ffeec4bdcf (Feb 12 2026 - 14:12:09 +0000)
SoC:   AM62X SR1.0 HS-FS
Reset reason: POR
DRAM:  1 GiB
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 0073 Verdin AM62 Dual 1GB ET V1.2A
Serial#: 15412849
Carrier: Toradex Dahlia V1.1D, Serial# 11287113


Unfortunately I do not have a single core board to test readily
available now, and I will be out of office a couple of days, but
I decided to share this immediately so that we can try to understand
what's going on. Middle of next week I should be able to do more tests.

Thanks for the support,
Francesco

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

[Suhaas Joshi]

On 11:20-20260213, Francesco Dolcini wrote:
> Hello Suhaas, Bryan, all
> 
> 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?

Regards
Suhaas

> 
> Logs of the booting device
> 
> 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!
> 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-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)')
> SPL initial stack usage: 2048 bytes
> Trying to boot from MMC1
> Authentication passed
> Authentication passed
> U-Boot 2026.04-rc2-0.0.0-devel+git.f9ffeec4bdcf (Feb 12 2026 - 14:12:09 +0000)
> SoC:   AM62X SR1.0 HS-FS
> Reset reason: POR
> DRAM:  1 GiB
> 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 0073 Verdin AM62 Dual 1GB ET V1.2A
> Serial#: 15412849
> Carrier: Toradex Dahlia V1.1D, Serial# 11287113
> 
> 
> Unfortunately I do not have a single core board to test readily
> available now, and I will be out of office a couple of days, but
> I decided to share this immediately so that we can try to understand
> what's going on. Middle of next week I should be able to do more tests.
> 
> Thanks for the support,
> Francesco
> 

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

[Francesco Dolcini]

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

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

[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
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)')




Thanks,
Francesco

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

[Bryan Brattlof]

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. 

> 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

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

[Wadim Egorov]

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

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

[Suhaas Joshi]

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. 
> 
> > 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?

Thanks
Suhaas

> I wonder (complete guess right now) if we're passing the correct DRAM 
> density to the A53 SPL?
> 
> ~Bryan

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

[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

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

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

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

[Bryan Brattlof]

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
> 

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

[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 ...

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

It's quite a pain. I will review the complete memory map and check if I
missed something.

Bryan: I think TI should consider having both OP-TEE and TFA at the
beginning of the memory on any AM62* SOC by default, this would just be
the most robust way to have something working no matter the amount of
memory that is fitted.

Francesco

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

[Bryan Brattlof]

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.

I'll start bothering Andrei for some of your hardware :)

> 
> It's quite a pain. I will review the complete memory map and check if I
> missed something.
> 
> Bryan: I think TI should consider having both OP-TEE and TFA at the
> beginning of the memory on any AM62* SOC by default, this would just be
> the most robust way to have something working no matter the amount of
> memory that is fitted.
> 

Completely agree. 

The BeagleBoard people went through this pain a few weeks ago for the 
Pocketbeagle2 boards. It's a problem.

Originally we envisioned DRAM density would go up just like with flash 
densities as the SoC's matured. Obviously this isn't happening

It might be worth finding a way to move them (or change their default 
locations). I'll start pestering people in TI to get a plan in place.

~Bryan

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

[Francesco Dolcini]

+Devarsh

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 ...

Please verify this, because it is as well possible that I am completely
wrong.

Thanks
Francesco

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

[Francesco Dolcini]

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

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

[devarsh]

Hi Francesco,

On 24/02/26 15:51, Francesco Dolcini wrote:
<snip>
>>>> 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?
> 

Thanks for sharing this information, maybe I missed out handling the
board_get_usable_ram_top scenario in my original patch.

For this particular problem, could you please try with  "[PATCH] arm:
mach-k3: common: Clamp RAM end address to board-usable region in
spl_enable_cache()"

that I sent over the list/email and let us know if it helps solve above
problem ?

Regards
Devarsh

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

[Francesco Dolcini]

On Tue, Feb 24, 2026 at 11:21:23AM +0100, Francesco Dolcini wrote:
> 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:
> > 
> > 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 ...
> 
> 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.

Yes, I can confirm that this is another, but related issue :-/

There is a memory corruption, something not ok in get_ram_size(), cache
related, that is leading to a memory corruption and therefore these
random crashes.

For some reason the memory corruption is happening calling dram_init()
twice and with 512MB module and with commit cb41b7c83444 ("board:
toradex: Make A53 get RAM size from DT in K3 boards"), I did debug this
with plain v2026.01 + cb41b7c83444.

This https://lore.kernel.org/all/20250314100734.23777-1-eichest@gmail.com/
solves the issue, but it was not applied when it was first sent months
ago.

Tom: you were the one with some concern, from my point of view we
should just apply it, any concern?

On the other topic I am waiting for TI advise if they plan to fix
spl_enable_cache() or I would need to work on revising the memory map
for the various firmwares + U-Boot.

Francesco

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

[Francesco Dolcini]

Hello Tom,

On Tue, Feb 24, 2026 at 03:38:06PM +0100, Francesco Dolcini wrote:
> On Tue, Feb 24, 2026 at 11:21:23AM +0100, Francesco Dolcini wrote:
> > 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:
> > > 
> > > 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 ...
> > 
> > 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.
> 
> Yes, I can confirm that this is another, but related issue :-/

...

> On the other topic I am waiting for TI advise if they plan to fix
> spl_enable_cache() or I would need to work on revising the memory map
> for the various firmwares + U-Boot.

current master +

https://lore.kernel.org/all/20260224134557.2067046-1-devarsht@ti.com/
https://lore.kernel.org/all/20250314100734.23777-1-eichest@gmail.com/

fixes the boot failure on Verdin AM62 512MB variants.

Tom: does this looks ok to you? It should solve this regression,
finally.

Francesco