I'm attempting to access the ARM CPU ID register via inline assembly
in my C code (ARM mode). I can compile, but the call crashes. Is this
not supported by the NDK?
Example (pseudo code):
unsigned int getArmCpuId()
{
unsigned int id = 0;
asm volatile("mrc p15 0, %0, c0, c0, 0" : "=r" (id)); // <--- this
crashes
return id;
}
I'd like to avoid reading /proc/cpuinfo if at all possible.
Thanks for any tips!
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Currently I'm working in the emulator -- The physical device I have on
hand right now is a G1, but I've yet to try it.
As for the crash, from logcat:
I/DEBUG ( 28): signal 4 (SIGILL), fault addr 821821e0
--
Although, none of these are accessible in user-mode - and therefore
not accessible from the NDK. You need to be
running in privileged mode to be able to access them:
Main ID - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/Bgbiddeb.html
CPU ID - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/Babgbeed.html
MPIDR - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/CIHEBGFG.html
On the emulator I suspect it is being (correctly) treated as an
UNDEFINED instruction (the emulator is running as an ARM926 I
believe), under user-mode on an ARM1176 or an ARMv7-a processor it
will still be treated as an UNDEFINED
while in user mode. The SIGILL is what I would expect in either case.
In theory, the OS is supposed to be the source of information about
what features are available - this is because
the OS is also responsible for setting up and supporting some of
them. If you can describe what it is you want to
do I (and by 'I' I mean people I know who I can ask) might be able to
suggest something.
--
On 5 Apr, 23:40, David Turner <di...@android.com> wrote:
> Ah, I wonder if this is an emulation bug, or comes from the fact that CPUID
> is not supported before ARMv6. Will look into it.
>
>
>
> On Mon, Apr 5, 2010 at 3:22 PM, Bryan Ashby <nuskoo...@gmail.com> wrote:
> > On Apr 5, 4:16 pm, David Turner <di...@android.com> wrote:
> > > What is the crash exactly ? on which device ?
>
> > Currently I'm working in the emulator -- The physical device I have on
> > hand right now is a G1, but I've yet to try it.
>
> > As for the crash, from logcat:
> > I/DEBUG ( 28): signal 4 (SIGILL), fault addr 821821e0
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>
I'm after the main ID register. It appears I somehow missed the part
about privileged only -- which explains my issues.
> In theory, the OS is supposed to be the source of information about
> what features are available - this is because
> the OS is also responsible for setting up and supporting some of
> them. If you can describe what it is you want to
> do I (and by 'I' I mean people I know who I can ask) might be able to
> suggest something.
Our seat management uses CPU information as part of it's identifier --
on x86 for example this is from the CPUID instruction; I was hoping to
carry some of that over. /proc/cpuinfo has a lot of the information,
which should do.
In some ways /proc/cpuinfo is better, at least for feature detection.
For example, if the hardware supports VFP but the feature isn't
enabled in the kernel, you won't actually have floating point support
available.
Is there something missing from /proc/cpuinfo that you would find
useful?
Everything the cp15 c0 gives back appears to be there, so it looks
fine. My only gripe is that /proc/cpuinfo itself is quite non-standard
in it's formatting and contents. This is a Linux gripe though, not a
Android one :)
The NDK is now including an API function that parses /proc/cpuinfo and
turns it into feature flags:
(If the URL gets broken up, it's in ndk/sources/cpufeatures/cpu-
features.c)
This should help smooth over Linux-version-dependent differences. I
don't know if what you want is there though -- it's currently just
interested in CPU family (ARM vs x86) and yes/no on "is ARMv7", "has
VFPv3", "has NEON".
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+unsubscribe@googlegroups.com.