• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 613 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

66AK2G12: How to verify the linux kernel version in processor-sdk-linux[-rt] ?

PROCESSOR-SDK-AM64X: 32bit ELF support in kernel and related PSDK documentation

William Coulter
Prodigy 214 points

Part Number: PROCESSOR-SDK-AM64X

Hi,

I'm having issues running 32bit ELF files compiled for linux-gnueabihf using an older, legacy toolchain. Particularly, the latest PSDK (07_03_00_02) doesn't include /lib/ld-linux-armhf.so.3

The documentation online is confusing about how the kernel is compiled and is missing documentation.

The SDK documentation at https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/07_03_00_02/exports/docs/devices/AM64X/Linux_Release_Notes.html says that the kernel is compiled for armhf:

The git link doesn't work (none of them on this page to TI Git work). Could these be updated?

However, when I look at the running kernel, 'uname -a' gives me aarch64 ... "Linux am64xx-evm 5.4.106-rt54-g519667b0d8 #1 SMP PREEMPT_RT Tue Apr 13 04:03:24 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux"

Any help clarifying whether I should be able to run 32-bit ELFs and what I would need to do to get the missing shared object would be appreciated.

Thanks,

-- Will

  • 0
    TI__Guru**** 177101 points

    Hi Will,

    William Coulter said:
    I'm having issues running 32bit ELF files compiled for linux-gnueabihf using an older, legacy toolchain. Particularly, the latest PSDK (07_03_00_02) doesn't include /lib/ld-linux-armhf.so.3

    AM64x runs Linux on A53 which is 64-bit processor, and the root filesystem and kernel provided in Processor SDK are built with 64-bit ARM toolchain, so it doesn't provide an environment to directly run 32-bit ELF.

    William Coulter said:
    The git link doesn't work (none of them on this page to TI Git work). Could these be updated?

    Sorry, the link should be git.ti.com/.../ti-linux-kernel (without .git at the end). We will update the documentation.

    William Coulter said:
    However, when I look at the running kernel, 'uname -a' gives me aarch64 ... "Linux am64xx-evm 5.4.106-rt54-g519667b0d8 #1 SMP PREEMPT_RT Tue Apr 13 04:03:24 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux"

    This is also a documentation error. The kernel (and the root filesystem) is compiled with aarch64-none-linux-gnu-gcc. We will update the documentation.

    William Coulter said:
    Any help clarifying whether I should be able to run 32-bit ELFs and what I would need to do to get the missing shared object would be appreciated.

    Is it possible to rebuilt your application with the aarch64 toolchain provided in the Processor SDK?

  • 0 in reply to Bin Liu
    Prodigy 214 points

    Hi Ben,

    Thanks for the detailed reply.

    I'm sure we will get to a new toolchain eventually, but at this time, there's friction involved in doing so because of some upstream frameworks we are trying to use.

    The kernel supports the EL0 option and I've since had some success with static linking the 32-bit libraries, but this is far from ideal. And, who knows when/how this will break.

    Do you know if anyone has experience running a 32-bit ti/Yocto OS on this A53 core? Do you know what steps one might take to do so? If you look at other packages like Raspberry Pi (3B+) that are on A53, they are still on a 32-bit OS. 

    We *want* to make the transition to 64-bit, but trying to balance existing vs new for prototyping.

    Thanks for any insights,

    -- Will

  • 0 in reply to William Coulter
    TI__Guru**** 177101 points

    Hi Will,

    Understood your situation.

    I am routing your query to our Yocto expert to see if there is a short term solution to run 32bit applications on am64x.

  • +1 in reply to Bin Liu
    TI__Mastermind 27050 points
    William Coulter said:
    The kernel supports the EL0 option and I've since had some success with static linking the 32-bit libraries, but this is far from ideal. And, who knows when/how this will break.

    This is probably the option to look at. Or the same approach but with aarch64 and -mabi=ilp32 for the application and linked libraries. ilp32 will get you the double register count that ARMv8 introduced. aarch32 is the ARMv7 backwards compatibility mode. Neither approach is in practice popular, just going for 64-bit is by far the most common approach.

    Maybe depending on where the concern with 64-bit is coming from maybe even a Docker container for the 32-bit libraries could be an alternative.

      Pekka

  • 0 in reply to Pekka Varis
    Prodigy 214 points

    Thanks, Pekka, for the detailed answer. Looks like static linking is probably indeed the best choice for us until we can make the switch to aarch64.