-
Notifications
You must be signed in to change notification settings - Fork 2.1k
cpu/native: Support native CPU on arm64 Linux #20739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
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. |
native64
Board on ARMnative64
Board on ARM
native64
Board on ARMnative64
Board on ARM
@Teufelchen1 PR is ready for review :) |
Thanks for waiting. I noticed a few things, maybe I have an invalid setup for testing or this PR need more work.
Does that sound reasonable to you? Would you expect everything to work with the given setup? Following things did not work as expected:
If needed, I can also arrange a plain linux on ARM64 environment. |
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. 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 |
0419f5e
to
8beb57c
Compare
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 |
Any update on this? I think it would be super cool to have native support on a RPi. |
There‘s still some investigating needed to find out why some of the examples fail.. also, networking with gnrc does not work for me (maybe a threading issue?). Perhaps the ISR logic can‘t be that naively ported to arm from x86? I still want to get arm64 support working eventually, but I don’t have the time at the moment. If somebody wants to dig into this or has some insights to share as to why this isn’t working as it should, your help would be greatly appreciated 🚀. |
native64
Board on ARM
Figured it out last week: Also, when setting @Teufelchen1 can you check, please? |
If Murdock looks at this PR, the result will actually just indicate nothing has been broken but won't tell us if native on arm64 works, right? Because the CI currently does not know about arm64, does it? |
@chrysn why does RIOT/cpu/native/Makefile.include Line 19 in 26ca217
use arch_32bit and FEATURES_USED instead of NATIVE_ARCH_BIT (which is either 32 or 64 )?
That's the part that sets the Rust target triple |
Looks super promising! Overall review is very cluttered, I will go through it by commits then. When do you need my review? Are you blocked or can I take my time? |
Ah no, 21283 has been merged, if you rebase, the PR should shrink and look rather clean! Neat! |
Rebased. #21289 builds on this, but does not block me. |
I have successfully tested this on a Raspberry Pi Zero 2 W (with few examples & driver tests, |
Update 10 April 2025:
#21283 is merged.
Update 10 March 2025:
This PR now builds upon #21283. The next PR will revive macOS support which this PR is the basis for.
You may look at the first approach here:
native64-arm-old
Contribution Description.
This PR adds support for the
native64
board on arm64/aarch641 Linux platforms (e.g., Raspberry Pi, Mac)-m32
and-m64
flags on ARM (?) (hencegcc-multilib
is unavailable on ARM),-mXX
flags are omitted when they would matchgetconf LONG_BIT
Testing procedure (GNU/Linux)
Compile and run on an ARM 64-bit CPU on Linux.
Footnotes
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. ↩
For anyone else also wondering how the PC can be set on ARM 64-bit, v8, while preserving all general-purpose registers: You simply can’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 ofsetcontext
(which lets you set the instruction pointer) in glibc'ssetcontext.S
, you'll noticex16
is used as the register for thebr
instruction. This PR adopts the same technique. Edit 10 March 2025: You can set LR andret
there, so actually don't even needx16
. This is also consistent with _setcontext.s in libplatform. ↩