Hi Francesco,
On 24/02/26 15:51, Francesco Dolcini wrote:
<snip>
>>>> U-Boot SPL 2026.04-rc2-00038-g2d83c0fbbfed-dirty (Feb 20 2026 - 11:23:36
>>>> +0100)
>>>> SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
>>>> Set clock rates for '/a53@0', CPU: 800MHz at Speed Grade 'K'
>>>> SPL initial stack usage: 13464 bytes
>>>> Trying to boot from MMC1
>>>> Authentication passed
>>>> Authentication passed
>>>> Authentication passed
>>>> Loading Environment from nowhere... OK
>>>> init_env from device 9 not supported!
>>>> Warning: Did not detect image signing certificate. Skipping authentication
>>>> to prevent boot failure. This will fail on Security Enforcing
>>>> (HS-SE) devices
>>>
>>> How strange. It's odd U-Boot on some boots finds a certificate with the
>>> binaries and on others attempts it does not. If the image inside the
>>> tispl.bin was corrupted I would expect the SPL to reject the image.
>>
>> Some more updates ...
>>
>> I was not able to verify this yet, but it seems that since commit
>> ba20b2443c29 ("arm: mach-k3: common: Reserve video memory from end of
>> the RAM") the ram top is overwritten and our
>> verdin-am62.c:board_get_usable_ram_top() is ignored :-(
>>
>> So, the change from devarsh broke it, but before the addition of the
>> memory firewall the memory corruption was not leading to a crash ...
>
> Some small progress.
>
> I can confirm that the issue is around the board_init_f() that is
> overridden on the k3 architecture and spl_enable_cache(). It messes up
> with gd->*ram* variables ignoring various config options, including
> verdin-am62.c:board_get_usable_ram_top(). Any comment on this?
>
Thanks for sharing this information, maybe I missed out handling the
board_get_usable_ram_top scenario in my original patch.
For this particular problem, could you please try with "[PATCH] arm:
mach-k3: common: Clamp RAM end address to board-usable region in
spl_enable_cache()"
that I sent over the list/email and let us know if it helps solve above
problem ?
Regards
Devarsh
