On Thu, Jun 04, 2026 at 05:24:47PM +0200, Diederik de Haas wrote:
> I recently did a fresh install of my system and doesn't have nearly as much
> programs/libraries installed as I had on my old system. And this may have led
> to an interesting new data point. Upstream recently released TF-A v2.15.0
> (although I don't think that's important).
>
> I built bl31.elf for RK3568 and RK3588 without problems.
> Then I tried to build bl31.elf for RK3399 and that failed 'interestingly':
>
> ```sh
> diederik@bagend:~/trusted-firmware-a$ make PLAT=rk3399 clean
> CLEAN
> diederik@bagend:~/trusted-firmware-a$ make PLAT=rk3399 bl31
> MD /home/diederik/trusted-firmware-a/build/rk3399/release/bl31
> CC bl31/bl31_context_mgmt.c
> CC bl31/bl31_main.c
> CC bl31/bl31_traps.c
> CC bl31/interrupt_mgmt.c
> ...
> AS plat/common/aarch64/platform_helpers.S
> AS plat/common/aarch64/platform_mp_stack.S
> AS plat/rockchip/common/aarch64/plat_helpers.S
> AS plat/rockchip/common/aarch64/pmu_sram_cpus_on.S
> MD /home/diederik/trusted-firmware-a/build/rk3399/release/m0
> make -C plat/rockchip/rk3399/drivers/m0
> BUILD=/home/diederik/trusted-firmware-a/build/rk3399/release/m0
> make[1]: Entering directory
> '/home/diederik/trusted-firmware-a/plat/rockchip/rk3399/drivers/m0'
> Makefile:31:
> Makefile:31: The configured RK3399 M0 C compiler could not be identified:
> Makefile:31:
> Makefile:31: 'arm-none-eabi-gcc' (default)
> Makefile:31:
> Makefile:31: The following tools are supported:
> Makefile:31:
> Makefile:31: - Arm® Compiler for Embedded `armclang`
> Makefile:31: - LLVM Clang (`clang`)
> Makefile:31: - GNU GCC (`gcc`)
> Makefile:31:
> Makefile:31: The build system will treat this C compiler as GNU GCC (`gcc`).
> Makefile:31:
> Makefile:34:
> Makefile:34: The configured RK3399 M0 linker could not be identified:
> Makefile:34:
> Makefile:34: 'arm-none-eabi-gcc' (default)
> Makefile:34:
> Makefile:34: The following tools are supported:
> Makefile:34:
> Makefile:34: - Arm® Compiler for Embedded `armclang`
> Makefile:34: - Arm® Compiler for Embedded `armlink`
> Makefile:34: - LLVM Clang (`clang`)
> Makefile:34: - LLVM LLD (`lld`)
> Makefile:34: - GNU GCC (`gcc`)
> Makefile:34: - GNU LD (`ld.bfd`)
> Makefile:34:
> Makefile:34: The build system will treat this linker as GNU GCC (`gcc`).
> Makefile:34:
> CC src/dram.c
> make[1]: arm-none-eabi-gcc: No such file or directory
> make[1]: *** [Makefile:112:
> /home/diederik/trusted-firmware-a/build/rk3399/release/m0/dram.o] Error 127
> make[1]: Leaving directory
> '/home/diederik/trusted-firmware-a/plat/rockchip/rk3399/drivers/m0'
> make: *** [plat/rockchip/rk3399/platform.mk:109:
> /home/diederik/dev/trustedfirmware.org/trusted-firmware-a/build/rk3399/release/m0/rk3399m0.bin]
> Error 2
> ```
>
> Apparently I did not have 'gcc-arm-none-eabi' installed AND it looks
> like RK3399 needs it, while RK3568 and RK3588 do not?!?
> Installing that resulted in these additional packages:
> ``binutils-arm-none-eabi{a} gcc-arm-none-eabi picolibc-arm-none-eabi{a}``
>
> When I then tried to built it, it showed the following error:
>
> ```sh
> AS plat/rockchip/common/aarch64/plat_helpers.S
> AS plat/rockchip/common/aarch64/pmu_sram_cpus_on.S
> MD /home/diederik/trusted-firmware-a/build/rk3399/release/m0
> make -C plat/rockchip/rk3399/drivers/m0
> BUILD=/home/diederik/trusted-firmware-a/build/rk3399/release/m0
> make[1]: Entering directory
> '/home/diederik/trusted-firmware-a/plat/rockchip/rk3399/drivers/m0'
> CC src/dram.c
> CC src/stopwatch.c
> CC src/startup.c
> LD
> /home/diederik/trusted-firmware-a/build/rk3399/release/m0/rk3399m0.elf
> /usr/bin/arm-none-eabi-ld: section .m0_bin LMA [00000000,000001e7] overlaps
> section .text LMA [00000000,0000011f]
> /usr/bin/arm-none-eabi-ld: warning: cannot find entry symbol _start;
> defaulting to 00000000
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:100:
> /home/diederik/trusted-firmware-a/build/rk3399/release/m0/rk3399m0.elf] Error
> 1
> make[1]: Leaving directory
> '/home/diederik/trusted-firmware-a/plat/rockchip/rk3399/drivers/m0'
> make: *** [plat/rockchip/rk3399/platform.mk:109:
> /home/diederik/trusted-firmware-a/build/rk3399/release/m0/rk3399m0.bin] Error
> 2
> ```
>
> Realizing I previously reported failures with RK3328, I uninstalled the above
> packages again and tried to build bl31.elf for RK3328.
>
> ```sh
> diederik@bagend:~/trusted-firmware-a$ make PLAT=rk3328 clean
> CLEAN
> diederik@bagend:~/trusted-firmware-a$ make PLAT=rk3328 bl31
> MD /home/diederik/trusted-firmware-a/build/rk3328/release/bl31
> CC bl31/bl31_context_mgmt.c
> CC bl31/bl31_main.c
> CC bl31/bl31_traps.c
> CC bl31/interrupt_mgmt.c
> ...
> CC lib/libc/strtol.c
> CC lib/libc/memset.c
> AS lib/libc/aarch64/setjmp.S
> AR /home/diederik/trusted-firmware-a/build/rk3328/release/lib/libc.a
> LD /home/diederik/trusted-firmware-a/build/rk3328/release/bl31/bl31.elf
> /usr/bin/aarch64-linux-gnu-ld.bfd:
> /home/diederik/trusted-firmware-a/build/rk3328/release/bl31/bl31.elf section
> `.text_pmusram' will not fit in region `PMUSRAM'
> /usr/bin/aarch64-linux-gnu-ld.bfd: region `PMUSRAM' overflowed by 8 bytes
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:1035:
> /home/diederik/trusted-firmware-a/build/rk3328/release/bl31/bl31.elf] Error 1
> ```
>
> Which is very similar to the earlier reported issue, but the linker used is
> different? (Or is this just a change in the packaging?
>
> ```sh
> diederik@bagend:~$ dpkg -S /usr/bin/aarch64-linux-gnu-ld.bfd
> binutils-aarch64-linux-gnu: /usr/bin/aarch64-linux-gnu-ld.bfd
> diederik@bagend:~$ aptitude versions binutils-aarch64-linux-gnu
> i A 2.46-3 testing,unstable 500
> p A 2.46.50.20260519-1 experimental 101
> ```
>
> But it looks like RK3328 doesn't need gcc-arm-none-eabi either?
> So it's only RK3399 that needs that? For DRAM training code?
>
> On Sat Nov 22, 2025 at 10:47 AM CET, Matthias Klose wrote:
> > please could you provide a self-contained test case, without any
> > references to a repo?
>
> Can you explain what you mean by 'self-contained test case'?
> Why is the reference to a repo a problem? The repo is not big and
> after cloning it, this is all that's needed to reproduce the problem:
>
> ```
> export CROSS_COMPILE=aarch64-linux-gnu-
> make PLAT=rk3328 clean
> make PLAT=rk3328 bl31
> ```
>
> On a(ny) amd64 system, so you don't need an arm64 device or any other
> special or extensive setup procedure.
This fixes the 3328. The commit you pointed at messed up that errata
option. It is a gcc option NOT a linker option. As far as I can tell the
case where ERRATA_A53_843419 is enabled was almost certainly broken before
given the gcc documentation says that has to be -mfix-cortex-a53-843419
not --fix-cortex-a53-843419 (which appears to be what llvm/clang wants)
diff --git a/make_helpers/cflags.mk b/make_helpers/cflags.mk
index 680567396..b0972204a 100644
--- a/make_helpers/cflags.mk
+++ b/make_helpers/cflags.mk
@@ -201,11 +201,11 @@ endif
# Errata build flags
ifneq ($(call bool,$(ERRATA_A53_843419)),)
-ldflags-aarch64 += $(call ld_option,--fix-cortex-a53-843419)
+ldflags-aarch64 += $(call cc_option,-mfix-cortex-a53-843419)
else
# GCC automatically adds fix-cortex-a53-843419 flag when used to link
# which breaks some builds, so disable if errata fix is not explicitly enabled
-ldflags-aarch64 += $(call ld_option,--no-fix-cortex-a53-843419)
+ldflags-aarch64 += $(call cc_option,-mno-fix-cortex-a53-843419)
endif
ifneq ($(call bool,$(ERRATA_A53_835769)),)A
This broke it:
-ifeq ($($(ARCH)-ld-id),gnu-gcc)
-TF_LDFLAGS_aarch64 += -mno-fix-cortex-a53-843419
-endif
+# GCC automatically adds fix-cortex-a53-843419 flag when used to link
+# which breaks some builds, so disable if errata fix is not explicitly enabled
+ldflags-aarch64 += $(call ld_option,--no-fix-cortex-a53-843419)
The 3399 is a different problem that I didn't spot yet.
--
Len Sorensen
