When trying to build 'master' of TF-A [1,2,3] for the rk3328 and rk3399
platforms the build started to fail, but succeeded for rk3568/rk3588,
since upstream commit
6c2e5bf68955 ("feat(build): use clang as a linker")

So I went to the review/discussion of that commit here:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/36981

They were not able to reproduce the problem.
I then asked someone (on #linux-rockchip) to try to built it on a
non-Debian platform and someone confirmed it build fine on Fedora 42.

I've also tried to build it on a Rock64 (which is rk3328), but mostly
because that runs Stable, thus GCC-14, and that build failed as well.

So the most logical explanation is that the build failure is introduced
via a Debian specific patch?

I've attached the 'patch' from commit 6c2e5bf68955 which may help
identify why that commit introduced breakage of the build.

Cheers,
  Diederik

[1] https://www.trustedfirmware.org/projects/tf-a
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git or
[3] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a

... maybe useful to show the actual error as well ...

```
diederik@bagend:~/dev/trustedfirmware.org/trusted-firmware-a$ make distclean
  REALCLEAN
diederik@bagend:~/dev/trustedfirmware.org/trusted-firmware-a$ make PLAT=rk3328 all
  MD      /home/diederik/dev/trustedfirmware.org/trusted-firmware-a/build/rk3328/release/libfdt
  CC      lib/libfdt/fdt.c
  CC      lib/libfdt/fdt_addresses.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/dev/trustedfirmware.org/trusted-firmware-a/build/rk3328/release/bl31/bl31
  CPP     bl31/bl31.ld.S
  LD      /home/diederik/dev/trustedfirmware.org/trusted-firmware-a/build/rk3328/release/bl31/bl31.elf
/usr/lib/gcc-cross/aarch64-linux-gnu/15/../../../../aarch64-linux-gnu/bin/ld: /home/diederik/dev/trustedfirmware.org/trusted-firmware-a/build/rk3328/release/bl31/bl31.elf section `.text_pmusram' will not fit in region `PMUSRAM'
/usr/lib/gcc-cross/aarch64-linux-gnu/15/../../../../aarch64-linux-gnu/bin/ld: region `PMUSRAM' overflowed by 8 bytes
collect2: error: ld returned 1 exit status
make: *** [Makefile:1010: /home/diederik/dev/trustedfirmware.org/trusted-firmware-a/build/rk3328/release/bl31/bl31.elf] Error 1
```

And let's add the reproducer too:

```sh
git clone https://review.trustedfirmware.org/TF-A/trusted-firmware-a
cd trusted-firmware-a
export CROSS_COMPILE=aarch64-linux-gnu-
make distclean
make PLAT=rk3328 all
```

please could you provide a self-contained test case, without any
references to a repo?

also the error message more likely points to a linker error.

does it still build without lto enabled?

please could you provide a self-contained test case, without any
references to a repo?

also the error message more likely points to a linker error.

does it still build without lto enabled?

I have no idea *why* it fails with rk3328 and rk3399, while it succeeds
with rk3568 and rk3588. I'm not aware of that (same) issue happening
elsewhere. I do know I can easily and consistently reproduce it.

I (git) bisected the problem to this commit:
https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/6c2e5bf68955
6c2e5bf68955 ("feat(build): use clang as a linker")

But that's (pretty much) the extend to which I can narrow down the
problem space. I don't understand what the changes in that commit would
or could have as effect on gcc or ld.
My knowledge wrt Makefiles is also limited.

I agree.

I build it as follows, which IIUC disables LTO:

```
export ENABLE_LTO=0
export CROSS_COMPILE=aarch64-linux-gnu-
make distclean
make PLAT=rk3328 all
```

And it still fails with the same error.

It's unfortunate that the above referenced commit also contains unrelated
(AFAIK) changes, but I did learn that LTO is disabled by default.

So I did another build with ``export ENABLE_LTO=1`` but that failed with
the same error as well. So it appears LTO has no effect on this issue.

While this does not affect the current arm-trusted-firmware packages in
Debian, updating to the new version woudl be blocked by this, so marking
that it affects arm-trusted-firmware.

live well,
  vagrant

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?

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.

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.

Hi,

Thanks a lot for your input :-)

It is VERY likely my bisect operation was done only wrt RK3328.

I haven't found any commit (by trying some random ones for the past couple
of years) that built.  Of course I suspect it is the linker not aggreeing
with something in the ld.S script, but I have no experience with those.
It looks like it isn't placing .text in the location the ld.S has
*(.text*), but rather defaults to putting it at 0 which is where the
reserved area is placed too for the isr_vectors.

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/53010
"fix(build): fix misapplication of errata A53 843419"

I have confirmed this fixes the build issue wrt RK3328.
The issue I mentioned in #46 with RK3399 is still present though.