On Tue, Feb 24, 2026 at 11:21:23AM +0100, Francesco Dolcini wrote:
> On Mon, Feb 23, 2026 at 04:58:21PM +0100, Francesco Dolcini wrote:
> > On Fri, Feb 20, 2026 at 07:23:42AM -0600, Bryan Brattlof wrote:
> > > On February 20, 2026 thus sayeth Francesco Dolcini:
> >
> > 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 ...
>
> 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?
>
> Trying to get out of this regression, one solution would be to move the
> whole memory map as it was done on the pocket beagle2, as it was
> suggested a few email ago.
>
> Or fix the spl_enable_cache() implementation.
>
> Bryan, and TI folks, what's your suggestion on the next steps here?
>
> In addition to that, no matter if I do a quick and dirty hack on
> spl_enable_cache(), or if I move the optee at the beginning of the ram,
> I get this error once every few resets
>
> ```
> ...
> 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
> ```
>
> and after that a freeze. I am starting to think that this is another,
> unrelated issue.
Yes, I can confirm that this is another, but related issue :-/
There is a memory corruption, something not ok in get_ram_size(), cache
related, that is leading to a memory corruption and therefore these
random crashes.
For some reason the memory corruption is happening calling dram_init()
twice and with 512MB module and with commit cb41b7c83444 ("board:
toradex: Make A53 get RAM size from DT in K3 boards"), I did debug this
with plain v2026.01 + cb41b7c83444.
This https://lore.kernel.org/all/[email protected]/
solves the issue, but it was not applied when it was first sent months
ago.
Tom: you were the one with some concern, from my point of view we
should just apply it, any concern?
On the other topic I am waiting for TI advise if they plan to fix
spl_enable_cache() or I would need to work on revising the memory map
for the various firmwares + U-Boot.
Francesco
