Skip to content
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

ARM support #49

Open
der-imp opened this issue May 29, 2021 · 7 comments
Open

ARM support #49

der-imp opened this issue May 29, 2021 · 7 comments

Comments

@der-imp
Copy link

der-imp commented May 29, 2021

I currently try to compile infoware on aarch64. But on all tried distribution the <cpuid.h> is missing. (debain for arm, raspberry OS)
In this source the header is referenced. Is there a possibility to add support for aarch64?

@der-imp der-imp changed the title Support Arm (Aarch64) Compilation Support Arm (Aarch64) Plattform May 29, 2021
@nabijaczleweli nabijaczleweli changed the title Support Arm (Aarch64) Plattform ARM support May 29, 2021
@ThePhD
Copy link
Owner

ThePhD commented May 29, 2021

I think at that point we'd have to drop down strictly to some assembly to query this information...

@nabijaczleweli
Copy link
Collaborator

nabijaczleweli commented May 29, 2021

Sure, you'll need to:

  • ifdef away most of cpuid[_non]_windows.cpp on __x86_64/__x86_64__/__i386/__i386__ – possibly supplying a different set of functions relevant to ARM
  • same for iware::cpu::vendor_id() in vendor_id.cpp and iware::cpu::supported_instruction_sets() in instruction_set.cpp and provide a new implementation
  • rename iware::cpu::architecture_t::arm{=>64} and return that instead of ::arm in architecture_windows.cpp, then add a different ::arm
  • NEON/&c. detection would be a bonus

@ThePhD
Copy link
Owner

ThePhD commented May 29, 2021

ARM manual says we need to poke at some funny registers to get some of this information:

ARM manual for MIDR_EL1

I guess at some point poking directly into Registers was going to have to be necessary. Some inline assembly can probably work, unless we're on MSVC, in which case they've banned inline assembly. But I can't imagine VC++ works on anything outside of a Windows-like environment.

@eleszet
Copy link

eleszet commented Dec 25, 2021

Hello together,

I came across the same problem when I build on my Raspberry. Are there plans to fix this any soon?

Didn't find a suitable solution myself yet.

BR

@nabijaczleweli
Copy link
Collaborator

The suitable solution is but two posts up: #49 (comment). You have relevant hardware: write a port; IIRC there's nothing Very Surprising that will bite you in the arse in this. Or give me (access to) an aarch64 computer. I hear Ampere has a good offering. Or a fiver for a cable to unfuck a Pi 0W I have (disclaimers apply: it's a 0W, so BCM2835, so armhf). Ports to any hardware, exotic or otherwise, don't happen because you want them to, but because you spend an hour or three with said hardware. There are no "plans" to "fix" anything: there's nothing to fix, save mayhap for your RHEL licensee attitude.

@eleszet
Copy link

eleszet commented Dec 29, 2021

Thanks for your reply. You are right, I am not deep in this topic. I just wanted to check if there are any plans to fix this - if not I will dig into it and find a way to solve it for my particular situation.

@tkchia
Copy link

tkchia commented Jun 26, 2022

Hello @ThePhD, hello @nabijaczleweli,

I am not sure the proposed solution will work — as far as I know, the MIDR_EL1 register and all the other ..._EL1 registers are only accessible from Exception Level 1 (EL1) or above, which means they cannot be read from userland code. I guess this is quite unlike the cpuid instruction on the x86.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants