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

Peter Robinson <[email protected]>
Newsgroups gmane.comp.boot-loaders.u-boot
Message-ID <CALeDE9N1GUu7z2vL4SG+JNyA32Ro207P1QQCPUuxz6QycJ-dGA@mail.gmail.com>
On Wed, 22 Jul 2026 at 18:13, Quentin Schulz via U-Boot
<[email protected]> wrote:
>
> Hi Vic,
>
> On 7/18/26 6:03 PM, Vic B wrote:
> > [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi,
> >
> > while trying to compile u-boot v2026.07 (or v2026.04) for RK3399-based
> > NanoPi R4S, I run into issues with current mainline TF-A (using 2.14, more
> > precisely the lts-v2.14.4 tag). I'm cross-compiling both TF-A and u-boot
> > using GCC version 14.2.0 (Debian 14.2.0-19) from Debian Trixie.
> >
> > First, I encountered TF-A build failure with the
> >
> >   region `PMUSRAM' overflowed by 3928 bytes
> >
> > error message, which seems to be a long-term issue know since 2018:
> >
> >   https://github.com/ARM-software/tf-issues/issues/650
> >
> > and recently also mentioned in this mailing list:
> >
> >   https://lists.denx.de/pipermail/u-boot/2026-April/613754.html
> >
> > Although some discussions suggest that this issue may be compiler or
> > toolchain dependent, I've eventually found a solution in Armbian
>
> Debian toolchain issue, reported to TF-A last year, see
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/36981/comments/877be809_5abf10d8.
> We wanted to rely on Debian upgrading at some point their TF-A, hitting
> the same issue and working on it but it seems they are stuck on
> lts-v2.12.1 (which is slightly concerning considering we're at
> lts-v2.12.12 already) so this hasn't happened yet. I'm building on
> Fedora and my company's CI has lts-v2.12 pinned to avoid this issue, so
> I'm not going to be chasing this myself. Can you try to work this out
> with Debian maybe? You're not the first, not the last I suspect either.

The distro team got to the bottom of the problem, it's an issue with
the TF-A linker [1] not getting that CPU errata may well be enabled by
default in a compiler options. The patch I think should apply to most
branches of TF-A.

[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/53010
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.