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

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

On Mon, Jul 27, 2026 at 01:12:58PM +0100, Peter Robinson wrote:

Hi Pete,

> > 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 thing to note is it builds and works fine using the Fedora gcc
> toolchain so it might not be considered a TF-A problem by the upstream
> project. Now many that comes down the debian build options, or
> settings in TF-A code, or some random combination of pieces is what
> needs to be worked out.

I agree, finding the option that causes the difference is what needs to
be worked out in the first place (at least for those of us who use
GCC on Debian or Debian-based distros and need to compile TF-A for
RK3399; other people aren't affected, so they don't have to care).

After this gets clarified, that option may be either added to the long
list of compiler/linker options that TF-A already uses (and make it
support GCC regardless of its distribution-dependent default
configuration), or adjusted in Debian's GCC package (which works for
everything else except TF-A for RK3399, so the motivation for such
adjustment is probably quite low).

My findings so far indicate that the TF-A build system is complex enough
to make the first step (i.e., finding the option that differs between
GCC's default configuration of Fedora and Debian and causes this issue
to happen) a non-trivial task for someone who isn't familiar with the
internals of TF-A's build, and the size and alignment requirements add
another non-trivial part hidden inside the M0 code and its makefiles and
linkerscripts.

This makes me believe that the authors of TF-A's M0 code for RK3399 (who
already have full understanding of how the M0 code works with the HW
while providing all required APIs to other components and meeting the
size and alignment requirements, and also of how it gets built) are much
more qualified to help with this than Debian's GCC maintainers.

On the other hand, I fully understand that TF-A team, despite listing
GCC as one of the supported compilers, don't actively chase this issue
on their own; after all, the fact that TF-A can be compiled with GCC on
Fedora without problems confirms that GCC support in TF-A is fine.

So in the end, it's not surprising that this issue persists since 2018
and seems to be heading into Debian's upcoming release and future TF-A
versions as well :(

Vic