Re: RK3399 TF-A hash verification failure for atf-3

[Vic B via U-Boot <u-boot@lists.u-boot-project.org>]

On Fri, Jul 24, 2026 at 02:55:20PM +0200, Quentin Schulz wrote:
> Hi Vic,

Hi Quentin,

> Since this is not really a U-Boot issue but rather TF-A as I understood it,
> maybe add (or switch to) the TF-A mailing list in Cc/To? c.f. https://lists.trustedfirmware.org/mailman3/lists/tf-a.lists.trustedfirmware.org/
> 
> The few times I wrote there I got first support in under a few days.

Yes, switching to TF-A mailing at this point is obviously the best way
to go now.

Although GCC 14.2 from Debian's stable which hits this issue is no longer
supported by TF-A (according to TF-A docs, minimal supported version GCC
version is 14.3), the same failure also happens on Debian testing with GCC
15.2, which is another reason to continue with TF-A folks rather than
let this go.

> > The Armbian's attempt to fix the issue by increasing PMUSRAM_RSIZE
> > in plat/rockchip/rk3399/include/shared/addressmap_shared.h from 8K
> > to 16K seems like more promising course to me - although the resulting
> > build with oversized pmusram isn't really usable, it produces much more
> 
> I don't think generating a broken binary over erroring out is a good thing
> (it seems however to be quite useful for your debugging session :) ). What I
> mean is that I don't think this is something we should get merged into TF-A.

I'm sure this one shouldn't get merged, although it is useful for
debugging, when the broken binary gets loaded by u-boot (which is
possible after disabling hash verification), it most probably results
in the M0 PMU running garbage after having the first half of its code
overwritten by the overflowing part.

But despite the M0 PMU running garbage and most probably not working at
all, the system appears stable even with this obviously broken binary.

And this is IMHO yet another reason to ask for help from TF-A folks, as I
have no idea how to determine whether the resulting PMUSRAM image works
as expected.

Cheers,

Vic

> I have neither the time nor knowledge to look at the rest unfortunately, but
> I really appreciate you giving lots of information and debugging output, I'm
> sure this will help someone help you eventually :)
> 
> Cheers,
> Quentin