Linking issue SAMA5D3 with GNU toolchain

[TechiePaul]

Hi,

I have downloaded the GNU toolchain "AArch32 bare metal target" and have then downloaded the source from the GitHub page... I have been able to compile certain examples (e.g. getting_started) and have got the load/debug working with J-Link... all good and thankyou very much for this code. However, the only way I could get this going was to change the compilation CFlags in makefile.sama5d3 like this:

#CFLAGS_CPU += -mcpu=cortex-a5 -mfpu=vfpv4-d16 -mfloat-abi=hard
#PRM altered, changed to soft FP
CFLAGS_CPU += -mcpu=cortex-a5 -mfpu=vfpv4-d16 -mfloat-abi=soft

i.e. not use the floating point unit.... This is not what I'd like to do really and I am wondering how I might be able to use

-mfloat-abi=hard

I have read a few articles and tried changing linker options a bit... make clean and make after each change... at the moment, if I use -mfloat-abi=hard I get:

 error: *.o uses VFP register arguments, *.elf does not
failed to merge target specific data of file ./build/sama5d3xplained/ddram/target/common/bootstrap.o

Can anyone help?

[TonyHan11]

Would you like to tell me the version of the compiler? On my side the make is OK with either "hard" or "soft", here's the version of the compiler I used:

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/lto-wrapper
Target: arm-none-eabi
Configured with: /tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/src/gcc/configure --target=arm-none-eabi --prefix=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/install-native --libexecdir=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/install-native/lib --infodir=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/install-native/arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/build-native/host-libs/usr --with-mpfr=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/build-native/host-libs/usr --with-mpc=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/build-native/host-libs/usr --with-isl=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/build-native/host-libs/usr --with-libelf=/tmp/jenkins/jenkins-GCC-8-build_toolchain_docker-519_20181216_1544945247/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for Arm Embedded Processors 8-2018-q4-major' --with-multilib-list=rmprofile
Thread model: single
gcc version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (GNU Tools for Arm Embedded Processors 8-2018-q4-major)

[TechiePaul]

Hi Tony,

Thanks for getting back to me so quickly.... The version I have is the latest from GNU running on Windows 10 through git bash:

$ arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=C:\Users\paul\Documents\SAMA5D3Compiler\bin\arm-none-eabi-gcc.exe COLLECT_LTO_WRAPPER=c:/users/paul/documents/sama5d3compiler/bin/../libexec/gcc/a rm-none-eabi/9.2.1/lto-wrapper.exe Target: arm-none-eabi Configured with: /tmp/lto_build/src/gcc/configure --target=arm-none-eabi --prefi x=/tmp/lto_build/build-mingw-arm-none-eabi/install// --with-gmp=/tmp/lto_build/b uild-mingw-arm-none-eabi/host-tools --with-mpfr=/tmp/lto_build/build-mingw-arm-n one-eabi/host-tools --with-mpc=/tmp/lto_build/build-mingw-arm-none-eabi/host-too ls --with-isl=/tmp/lto_build/build-mingw-arm-none-eabi/host-tools --disable-shar ed --disable-nls --disable-threads --disable-tls --enable-checking=release --ena ble-languages=c,c++,fortran --with-newlib --with-libiconv-prefix=/tmp/lto_build/ build-mingw-arm-none-eabi/host-tools --host=i686-w64-mingw32 --with-pkgversion=' GNU Toolchain for the A-profile Architecture 9.2-2020.02 (arm-9.10)' --with-bugu rl=https://bugs.linaro.org/ Thread model: single gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-202 0.02 (arm-9.10))

[TechiePaul]

I downloaded the GNU toolchain from here:

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads

[TonyHan11]

The Cortex-A5 processor implements the ARMv7 architecture, as it shows in A-Profile Architecture support in GNU toolchain GNU-A is supposed to be used for ARMv8 or later, would you like to try with the compiler under GNU-RM( targeting 32-bit Arm Cortex-A, Arm Cortex-M and Cortex-R family of processors)? Thanks.

[TechiePaul]

Aha, That might explain a few things... I will give this a go and report back... Again, many thanks,

Paul.

[TechiePaul]

Ok,

Thanks for the help Tony.... I have now fetched the latest ARM-RM GNU toolchain and tried again...... Still getting the same errors:

error: *.o uses VFP register arguments, *.elf does not failed to merge target specific data of file ./build/sama5d3xplained/ddram/target/common/bootstrap.o

However, I have managed to make it all build using the linker flag

-mfloat-abi=softfp

As I understand the documentation... This still makes use of the Floating Point Unit but does so with the calling conventions of the software equivalent libraries.... Good enough for me I think.

[TonyHan11]

Hi Paul, The toolchain documentation is improved by adding a suggested version and providing some tips to solve the compatibility issues of different toolchain versions.

[PaulMadle]

Thanks for the additional notes... We'll give those suggestions a go.