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
