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

[Tom Rini <trini@konsulko.com>]

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