Re: Bug#1118651: cpp-15-aarch64-linux-gnu: Build failure of TF-A for rk3328/rk3399 since TF-A commit 6c2e5bf68955

"Diederik de Haas" <[email protected]> Thu, 04 Jun 2026 17:24:47 +0200
Newsgroups gmane.linux.debian.ports.arm
Message-ID <[email protected]>
--5d8d0facdd731188628d4e70692a6e366516dbe46a71d448644cb51777ae
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Thu Oct 23, 2025 at 4:33 PM CEST, Diederik de Haas wrote:
> On Thu Oct 23, 2025 at 4:18 PM CEST, Diederik de Haas wrote:
>> 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")
>
> ... maybe useful to show the actual error as well ...
>
> ```
> diederik@bagend:~/dev/trustedfirmware.org/trusted-firmware-a$ make distcl=
ean
>   REALCLEAN
> diederik@bagend:~/dev/trustedfirmware.org/trusted-firmware-a$ make PLAT=
=3Drk3328 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 `PMUS=
RAM'
> /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
> ```

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 l=
ed
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=3Drk3399 clean
  CLEAN
diederik@bagend:~/trusted-firmware-a$ make PLAT=3Drk3399 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=3D/home/diederik/trusted-firm=
ware-a/build/rk3399/release/m0
make[1]: Entering directory '/home/diederik/trusted-firmware-a/plat/rockchi=
p/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=C2=AE 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=C2=AE Compiler for Embedded `armclang`
Makefile:34:   - Arm=C2=AE 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/trusted=
firmware.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=3D/home/diederik/trusted-firm=
ware-a/build/rk3399/release/m0
make[1]: Entering directory '/home/diederik/trusted-firmware-a/plat/rockchi=
p/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/rk3399m=
0.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; defaul=
ting 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-fir=
mware-a/build/rk3399/release/m0/rk3399m0.bin] Error 2
```

Realizing I previously reported failures with RK3328, I uninstalled the abo=
ve
packages again and tried to build bl31.elf for RK3328.

```sh
diederik@bagend:~/trusted-firmware-a$ make PLAT=3Drk3328 clean
  CLEAN
diederik@bagend:~/trusted-firmware-a$ make PLAT=3Drk3328 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/re=
lease/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=3Daarch64-linux-gnu-
make PLAT=3Drk3328 clean
make PLAT=3Drk3328 bl31
```

On a(ny) amd64 system, so you don't need an arm64 device or any other
special or extensive setup procedure.

--5d8d0facdd731188628d4e70692a6e366516dbe46a71d448644cb51777ae
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCaiGYwQAKCRDXblvOeH7b
bqMaAQDUwkgN1S/Jl1Ms20EnRiVZYPLrfZK0oSgFFmFlEVbiCQD8DbAq7h9oBg2t
4zpIIjYj5q3nvpVlei8OTwJXsDUkrQ4=
=AX7B
-----END PGP SIGNATURE-----

--5d8d0facdd731188628d4e70692a6e366516dbe46a71d448644cb51777ae--