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

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

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