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/[email protected]/ > > > > > > > > > > > > > > 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
