cpu/native: Support native64 Board on ARM

[carl-tud]

Contribution Description.

This PR adds support for the native64 board on arm64/aarch64¹

• ISR functionality has been extended to work on 64-bit ARMv8²
• Since gcc cannot be compiled to support the -m32 and -m64 flags on ARM (?) (hence gcc-multilib is unavailable on ARM), -mXX flags are omitted when they would match getconf LONG_BIT

Testing procedure (GNU/Linux)

Compile and run on an ARM 64-bit CPU.

Footnotes

1. Why? E.g., with 64-bit ARM support, you can use the native board on Apple Silicon Macs in a Linux-based virtualized environment (i.e., multipass (or qemu directly), Docker, Virtualization.framework or Hypervisor.framework), without having to resort to emulating a 32-bit ARM or x86 CPU. ↩

2. For anyone else also wondering how the PC can be set on ARM 64-bit, v8, while preserving all general-purpose registers: You don't. On ARMv8, PC cannot be written to anymore, and branch instructions (and friends) either require a static address (which isn't available to us (stored in _native_saved_eip) or a register containing the destination address. If you look at the glibc implementation of setcontext (which lets you set the instruction pointer) in glibc's setcontext.S, you'll notice x16 is used as the register for the br instruction. This PR adopts the same technique. ↩

[Teufelchen1]

Cool! Let me know when you need a review. I can also aid in testing as I have an Apple Silicon ARM PC at hand.

[carl-tud]

@Teufelchen1 PR is ready for review :)

[Teufelchen1]

Thanks for waiting.

I noticed a few things, maybe I have an invalid setup for testing or this PR need more work.
My setup:

• MacOS Ventura 13.2.1
• ARM64 / Apple M2
• Docker
  • Ubuntu (latest) for --platform linux/arm64
• Within docker, running BOARD=native64 make all term

Does that sound reasonable to you? Would you expect everything to work with the given setup?

Following things did not work as expected:

• The ipc_pingpong example, indefinitely hangs after both threads are created.
• The default example, crashes immediately after hitting an assertion within gnrc.
• Building for 32 bit native does not work (the issue marked in your PR description). I think we should handle that case more gracefully.

If needed, I can also arrange a plain linux on ARM64 environment.

[carl-tud]

Thank‘s for testing. These issues definitely need to be resolved first, I’m going to try and figure out what’s going on there with these non-functional examples..

On ARM 64 bit, building for 32 bit platforms with gcc seems to be inherently impossible due to lacking gcc multilib support, at least to my knowledge.. Your setup seems fine and similar to mine.
(edit: haven’t tried compiling with clang)

What is it exactly you had in mind when you said »we should handle that case more gracefully«? A pretty error message with a reference to RIOT‘s doc perhaps..

carl

[chrysn]

This branch also works for the Raspberry Pi devices used by for the exercises. Skimming the discussion I'm afraid we won't get this merged by tomorrow so it could go into this summit's tutorials :-)

Could you add a branch to cpu/native/Makefile.include already in this PR so that on matching platforms, the RUST_TARGET can be aarch64-unknown-linux-gnu? (You can verify that by building and running examples/rust-gcoap or any other Rust example).