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

[Wadim Egorov <w.egorov@phytec.de>]

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