This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/PROCESSOR-SDK-AM65X: Linker bug in GNU aarch64 compiler included in SDK 7.0

Part Number: PROCESSOR-SDK-AM65X
Other Parts Discussed in Thread: AM6548

Tool/software: Code Composer Studio

Dear TI team,

we are migrating our application from processor SDK 6.03 to processor SDK 7.00 and encountered a linker error:

gcc-arm-9.2-2019.12-mingw-w64-i686-aarch64-none-elf/bin/../lib/gcc/aarch64-none-elf/9.2.1/../../../../aarch64-none-elf/bin/ld.exe: can not size stub section: invalid operation
gcc-arm-9.2-2019.12-mingw-w64-i686-aarch64-none-elf/bin/../lib/gcc/aarch64-none-elf/9.2.1/../../../../aarch64-none-elf/bin/ld.exe: linker stubs: file class ELFCLASSNONE incompatible with ELFCLASS64
gcc-arm-9.2-2019.12-mingw-w64-i686-aarch64-none-elf/bin/../lib/gcc/aarch64-none-elf/9.2.1/../../../../aarch64-none-elf/bin/ld.exe: final link failed: file in wrong format

After some investigation we found the following bug report in the sourceware bugtracker for the GNU bintuils: sourceware.org/.../show_bug.cgi

It's apparently a linker bug, that triggers when the following two command line options are used, and a problematic code sequence is found that actually requires a fix to be applied:

-mfix-cortex-a53-835769
-mfix-cortex-a53-843419

This bug was fixed on 2020-01-16: sourceware.org/.../

Unfortunately the "GNU Toolchain for the A-profile Architecture Version 9.2-2019.12" from arm.com (assuming that's the compiler included with the processor SDK) includes the binutils 2.33.1 on commit da3b036b57c0d409fc1fc3e25597fa13dc71baf5 from 2019-12-09 that still contains the bug.

According to chapter 2.2.5. of the "ARM ProcessorCortex®-A53 MPCore - Product Revision r0 - Software Developers Errata Notice" (developer.arm.com/.../latest) the A53 core r0p4 used in the AM6548 should NOT be affected by the two errata, since the REVIDR_EL1 reads 0x00000380. Accroding to the errata document both 835769 and 843419 should be fixed in this implementation.

The template applications that we used to create our application used to include these two command line switches, and the BIOS 6.82.01.19 bundled with the processor SDK 7.00 includes the two options -mfix-cortex-a53-835769 and -mfix-cortex-a53-843419 in several XDC configuration files (not sure how and when these are used).

Is the A53 core used in the AM6548 affected by ARM errata 835769 and 843419, or can we safely remove these two switches when linking our own application?

Does TI use cores affected by these errata on other processors, and is it therefore necessary to keep the fixes enabled for compatibility reasons?

Regards,

Dominic

 

  • Dominic,

    This thread was in a incorrect state and hence didn't get our attention, bringing it back to focus and will come back to you on this next week.

    Regards

    Karthik

  • Hello Karthik,

    it would be great if you could provide some feedback on this issue.

    We've dropped these two command line switches from our configuration, and haven't encountered any misbehavior for several months, but the errata seems to describe some rather rare error conditions, that are apparently not often encountered, or otherwise more users would have complained about the linker error message. Since this is a huge project we would like to be sure of what we're doing.

    Even the latest files from SDK 07.01 still contain these two command line switches all over the tree, and since SDK 07.01 still uses the same GCC toolchain version it would still be affected by the linker bug.

    Regards,

    Dominic

  • Hello Dominic,

    Reviewing your comments and the specifications (design, TRM, & Errata), I agree that ARM errata 835769 and 843419 should not impact this A53 given the r0p4's REVIDR bits have been set to indicate the fixes are in place. Your removal of the work around appears safe.

    I have sent a mail to the designers who integrated the ARM RTL to confirm.  I fully expect he will confirm this as this should have been as delivered from ARM.

    Regards,

    Richard W.

  • The design owner did concur the fix state does follow the REVIDR bits as expected.