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