Hi all,
I'm currently trying to get GCC to auto-detect what CPU to optimize for by finding out what CPU it's actually running on (the user would only have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
The problem is finding what magic numbers correspond to what CPU. I've found the numbers for A8 and A9 empirically, but I'd like a longer list than that!
Does anybody have a list of such numbers?
Or else, perhaps people could just post any number they happen to know?
I do have a few devices other than A8 and A9 lying around I can look at, but the problem there is I don't actually know for certain what exact CPU model those numbers map to, so confirmed numbers only please.
Thanks
Andrew
Does anybody have a list of such numbers?
If you search the specs on http://infocenter.arm.com for "Main ID register" you should get all the numbers you wish for :-)
Or else, perhaps people could just post any number they happen to know?
For v6 and v7 processors, the /proc/cpuinfo's "CPU part" (I guess that's the one you are after?) is the "Part number" in the "Main ID register". For Cortex-A family these are going to be 0xc00 + number, ie. 0xc09 = A9, 0xc08 = A8, 0xc0f = A15 etc. ARM11 family is (surprise, what's hex value for 11? ;-) 0xb0_ etc.
So for what I know:
Cortex A5 - 0xc05 Cortex A8 - 0xc08 Cortex A9 - 0xc09 Cortex A15 - 0xc0f
Cortex R4 - 0xc14 Cortex R5 - 0xc15
ARM1136 - 0xb36 ARM1156 - 0xb56 ARM1176 - 0xb76 ARM11 MPCore - 0xb02
Cheers!
Paweł
If you search the specs on http://infocenter.arm.com for "Main ID register" you should get all the numbers you wish for :-)
Apparently it's called "ID Code Register" for ARM9 and the expected (not tested ;-) values would be:
ARM926 - 0x926 ARM946 - 0x946 ARM966 - 0x966
etc., you get the picture :-)
Paweł
PS. The number I quoted are valid when "CPU implementer" == 0x41 (ARM Ltd.)
PPS. I think older (and MMU-less) parts were using other scheme...
On 01/09/11 12:02, Pawel Moll wrote:
If you search the specs on http://infocenter.arm.com for "Main ID register" you should get all the numbers you wish for :-)
Apparently it's called "ID Code Register" for ARM9 and the expected (not tested ;-) values would be:
Thanks Paweł, this is exactly the sort of thing I was looking for.
Andrew
On 1 September 2011 12:02, Pawel Moll pawel.moll@arm.com wrote:
If you search the specs on http://infocenter.arm.com for "Main ID register" you should get all the numbers you wish for :-)
Apparently it's called "ID Code Register" for ARM9 and the expected (not tested ;-) values would be:
ARM926 - 0x926 ARM946 - 0x946 ARM966 - 0x966
etc., you get the picture :-)
Paweł
PS. The number I quoted are valid when "CPU implementer" == 0x41 (ARM Ltd.)
What about non-ARM implementations from e.g. Qualcomm and Marvell? A Marvell I have on hand reports this:
Processor : Feroceon 88FR131 rev 1 (v5l) BogoMIPS : 1192.75 Features : swp half fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part : 0x131 CPU revision : 1
Here the Processor line contains the exact name of the CPU, which can presumably derived from the ID register somehow.
I don't have a Qualcomm processor handy at the moment.
PPS. I think older (and MMU-less) parts were using other scheme...
They do, but I wouldn't worry about that since they're not likely to be running gcc anyway.
PS. The number I quoted are valid when "CPU implementer" == 0x41 (ARM Ltd.)
What about non-ARM implementations from e.g. Qualcomm and Marvell?
Sorry, I have no access to theirs specs and the ARM ARM (Architecture Reference Manual) does not enforce any particular numbering scheme.
Some SA and PXA processors are enumerated in the qemu's list mentioned by Dave Gilbert, but that's probably less interesting as well.
Paweł
On Thu, Sep 01, 2011 at 11:20:21AM +0100, Pawel Moll wrote:
Does anybody have a list of such numbers?
If you search the specs on http://infocenter.arm.com for "Main ID register" you should get all the numbers you wish for :-)
I actually did look for a bit and never found a definitive list. I've found descriptions of the bitfield and some sample values, but I haven't seen an actual official list.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Bgbidde...
For the M Series:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0395b/CIHCAGHH.html
I actually did look for a bit and never found a definitive list. I've found descriptions of the bitfield and some sample values, but I haven't seen an actual official list.
That's correct, I don't think such a list exists (at least within official ARM specs). What I meant is searching for the register name and getting the number out the relevant TRM).
Cheers!
Paweł
On 1 September 2011 10:40, Andrew Stubbs ams@codesourcery.com wrote:
Hi all,
I'm currently trying to get GCC to auto-detect what CPU to optimize for by finding out what CPU it's actually running on (the user would only have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
The problem is finding what magic numbers correspond to what CPU. I've found the numbers for A8 and A9 empirically, but I'd like a longer list than that!
Does anybody have a list of such numbers?
Or else, perhaps people could just post any number they happen to know?
I do have a few devices other than A8 and A9 lying around I can look at, but the problem there is I don't actually know for certain what exact CPU model those numbers map to, so confirmed numbers only please.
The QEMU tree appears to have a list in target-arm/cpu.h (LGPL):
#define ARM_CPUID_ARM1026 0x4106a262 #define ARM_CPUID_ARM926 0x41069265 #define ARM_CPUID_ARM946 0x41059461 #define ARM_CPUID_TI915T 0x54029152 #define ARM_CPUID_TI925T 0x54029252 #define ARM_CPUID_SA1100 0x4401A11B #define ARM_CPUID_SA1110 0x6901B119 #define ARM_CPUID_PXA250 0x69052100 #define ARM_CPUID_PXA255 0x69052d00 #define ARM_CPUID_PXA260 0x69052903 #define ARM_CPUID_PXA261 0x69052d05 #define ARM_CPUID_PXA262 0x69052d06 #define ARM_CPUID_PXA270 0x69054110 #define ARM_CPUID_PXA270_A0 0x69054110 #define ARM_CPUID_PXA270_A1 0x69054111 #define ARM_CPUID_PXA270_B0 0x69054112 #define ARM_CPUID_PXA270_B1 0x69054113 #define ARM_CPUID_PXA270_C0 0x69054114 #define ARM_CPUID_PXA270_C5 0x69054117 #define ARM_CPUID_ARM1136 0x4117b363 #define ARM_CPUID_ARM1136_R2 0x4107b362 #define ARM_CPUID_ARM1176 0x410fb767 #define ARM_CPUID_ARM11MPCORE 0x410fb022 #define ARM_CPUID_CORTEXA8 0x410fc080 #define ARM_CPUID_CORTEXA8_R2 0x412fc083 #define ARM_CPUID_CORTEXA9 0x410fc090 #define ARM_CPUID_CORTEXM3 0x410fc231
With the field you were looking at being nybbles 3..1
Dave
On Thursday 01 September 2011, Andrew Stubbs wrote:
Hi all,
I'm currently trying to get GCC to auto-detect what CPU to optimize for by finding out what CPU it's actually running on (the user would only have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
The problem is finding what magic numbers correspond to what CPU. I've found the numbers for A8 and A9 empirically, but I'd like a longer list than that!
Does anybody have a list of such numbers?
Or else, perhaps people could just post any number they happen to know?
I do have a few devices other than A8 and A9 lying around I can look at, but the problem there is I don't actually know for certain what exact CPU model those numbers map to, so confirmed numbers only please.
This is what we use in the kernel: to find out the architecture level:
#define CPU_ARCH_UNKNOWN 0 #define CPU_ARCH_ARMv3 1 #define CPU_ARCH_ARMv4 2 #define CPU_ARCH_ARMv4T 3 #define CPU_ARCH_ARMv5 4 #define CPU_ARCH_ARMv5T 5 #define CPU_ARCH_ARMv5TE 6 #define CPU_ARCH_ARMv5TEJ 7 #define CPU_ARCH_ARMv6 8 #define CPU_ARCH_ARMv7 9
int cpu_architecture(void) { int cpu_arch;
if ((read_cpuid_id() & 0x0008f000) == 0) { cpu_arch = CPU_ARCH_UNKNOWN; } else if ((read_cpuid_id() & 0x0008f000) == 0x00007000) { cpu_arch = (read_cpuid_id() & (1 << 23)) ? CPU_ARCH_ARMv4T : CPU_ARCH_ARMv3; } else if ((read_cpuid_id() & 0x00080000) == 0x00000000) { cpu_arch = (read_cpuid_id() >> 16) & 7; if (cpu_arch) cpu_arch += CPU_ARCH_ARMv3; } else if ((read_cpuid_id() & 0x000f0000) == 0x000f0000) { unsigned int mmfr0;
/* Revised CPUID format. Read the Memory Model Feature * Register 0 and check for VMSAv7 or PMSAv7 */ asm("mrc p15, 0, %0, c0, c1, 4" : "=r" (mmfr0)); if ((mmfr0 & 0x0000000f) >= 0x00000003 || (mmfr0 & 0x000000f0) >= 0x00000030) cpu_arch = CPU_ARCH_ARMv7; else if ((mmfr0 & 0x0000000f) == 0x00000002 || (mmfr0 & 0x000000f0) == 0x00000020) cpu_arch = CPU_ARCH_ARMv6; else cpu_arch = CPU_ARCH_UNKNOWN; } else cpu_arch = CPU_ARCH_UNKNOWN;
return cpu_arch; }
[ within the /proc/cpuinfo code: ] ... seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24); seq_printf(m, "CPU architecture: %s\n", proc_arch[cpu_architecture()]);
if ((read_cpuid_id() & 0x0008f000) == 0x00000000) { /* pre-ARM7 */ seq_printf(m, "CPU part\t: %07x\n", read_cpuid_id() >> 4); } else { if ((read_cpuid_id() & 0x0008f000) == 0x00007000) { /* ARM7 */ seq_printf(m, "CPU variant\t: 0x%02x\n", (read_cpuid_id() >> 16) & 127); } else { /* post-ARM7 */ seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15); } seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff); } seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15); ...
Arnd
On Thu, Sep 01, 2011 at 10:40:27AM +0100, Andrew Stubbs wrote:
I'm currently trying to get GCC to auto-detect what CPU to optimize for by finding out what CPU it's actually running on (the user would only have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
The problem is finding what magic numbers correspond to what CPU. I've found the numbers for A8 and A9 empirically, but I'd like a longer list than that!
Does anybody have a list of such numbers?
Or else, perhaps people could just post any number they happen to know?
/proc/cpuinfo on the three Qualcomm MSM platforms I have convenient gives:
The Hardware string on the last one is my device tree work, it's on an MSM8660 FLUID (http://www.bsquare.com/snapdragon-mobile-development-platform.aspx)
---------------------------------------------------------------------- Processor : ARMv7 Processor rev 1 (v7l) processor : 0 BogoMIPS : 13.53
processor : 1 BogoMIPS : 13.53
Features : swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x51 CPU architecture: 7 CPU variant : 0x0 CPU part : 0x04d CPU revision : 1
Hardware : QCT MSM8960 CDP Revision : 0000 Serial : 0000000000000000 ---------------------------------------------------------------------- Processor : ARMv7 Processor rev 1 (v7l) BogoMIPS : 191.69 Features : swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc05 CPU revision : 1
Hardware : QCT MSM9615 CDP Revision : 0000 Serial : 0000000000000000 ---------------------------------------------------------------------- Processor : ARMv7 Processor rev 2 (v7l) processor : 0 BogoMIPS : 501.35
processor : 1 BogoMIPS : 209.30
Features : swp half thumb fastmult vfp edsp neon tls CPU implementer : 0x51 CPU architecture: 7 CPU variant : 0x0 CPU part : 0x02d CPU revision : 2
Hardware : Qualcomm MSM (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000 ----------------------------------------------------------------------
W dniu 02.09.2011 06:40, David Brown pisze:
Processor : ARMv7 Processor rev 1 (v7l) BogoMIPS : 191.69 Features : swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc05 CPU revision : 1
Hardware : QCT MSM9615 CDP Revision : 0000 Serial : 0000000000000000
wow - finally A5 in other form then ARM FPGA :)
On 01/09/11 10:40, Andrew Stubbs wrote:
I'm currently trying to get GCC to auto-detect what CPU to optimize for by finding out what CPU it's actually running on (the user would only have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
Thanks to everybody who answered my previous questions. I now have sufficient numbers to be going on with. :)
Next question ... is /proc/cpuinfo really the best way to detect this?
I mean, is auxv a better approach? Or something else? What's the most efficient, and most stable API to read the CPU architecture, CPU model, and FPU/NEON availability?
There's some worry among the toolchain team that /proc/cpuinfo is a somewhat fragile and inefficient way to achieve this goal. Some insight from the kernel experts would be helpful!
Thanks
Andrew
W dniu 05.09.2011 11:28, Andrew Stubbs pisze:
Next question ... is /proc/cpuinfo really the best way to detect this?
I mean, is auxv a better approach? Or something else? What's the most efficient, and most stable API to read the CPU architecture, CPU model, and FPU/NEON availability?
There's some worry among the toolchain team that /proc/cpuinfo is a somewhat fragile and inefficient way to achieve this goal. Some insight from the kernel experts would be helpful!
Remember that there are cpus like imx51 to2 which have broken neon and this is shown in /proc/cpuinfo (no neon flag for them). So using own tests should also check what kernel has to say.
On 5 September 2011 10:52, Marcin Juszkiewicz marcin.juszkiewicz@linaro.org wrote:
W dniu 05.09.2011 11:28, Andrew Stubbs pisze:
Next question ... is /proc/cpuinfo really the best way to detect this?
I mean, is auxv a better approach? Or something else? What's the most efficient, and most stable API to read the CPU architecture, CPU model, and FPU/NEON availability?
There's some worry among the toolchain team that /proc/cpuinfo is a somewhat fragile and inefficient way to achieve this goal. Some insight from the kernel experts would be helpful!
Remember that there are cpus like imx51 to2 which have broken neon and this is shown in /proc/cpuinfo (no neon flag for them). So using own tests should also check what kernel has to say.
Yes, but that is indicated both in /proc/cpuinfo and in the auxv vector, so it doesn't make any difference to the "is parsing cpuinfo a good/bad idea" question.
-- PMM
On Mon, Sep 05, 2011 at 11:10:10AM +0100, Peter Maydell wrote:
On 5 September 2011 10:52, Marcin Juszkiewicz marcin.juszkiewicz@linaro.org wrote:
W dniu 05.09.2011 11:28, Andrew Stubbs pisze:
Next question ... is /proc/cpuinfo really the best way to detect this?
I mean, is auxv a better approach? Or something else? What's the most efficient, and most stable API to read the CPU architecture, CPU model, and FPU/NEON availability?
There's some worry among the toolchain team that /proc/cpuinfo is a somewhat fragile and inefficient way to achieve this goal. Some insight from the kernel experts would be helpful!
Remember that there are cpus like imx51 to2 which have broken neon and this is shown in /proc/cpuinfo (no neon flag for them). So using own tests should also check what kernel has to say.
Yes, but that is indicated both in /proc/cpuinfo and in the auxv vector, so it doesn't make any difference to the "is parsing cpuinfo a good/bad idea" question.
Note that the hwcaps info in /proc/cpuinfo is generated from the same hwcaps word exposed via auxv so, for now, the information is identical.
I would normally rate parsing /proc/cpuinfo as being a bad idea, but /proc/cpuinfo is probably the only source of the part ID information, for now. This is a bit unfortunate, especially since the format of /proc/cpuinfo could change at some point in the future, but in practice it seems to have been pretty stable with respect to this particular piece of information.
---Dave
On Wednesday 07 September 2011 10:32:27 Dave Martin wrote:
Note that the hwcaps info in /proc/cpuinfo is generated from the same hwcaps word exposed via auxv so, for now, the information is identical.
I would normally rate parsing /proc/cpuinfo as being a bad idea, but /proc/cpuinfo is probably the only source of the part ID information, for now. This is a bit unfortunate, especially since the format of /proc/cpuinfo could change at some point in the future, but in practice it seems to have been pretty stable with respect to this particular piece of information.
We do try to keep any ABI stable, including /proc/cpuinfo. I would generally consider it a bug when it breaks.
Arnd
On Wed, Sep 07, 2011 at 11:37:12AM +0200, Arnd Bergmann wrote:
On Wednesday 07 September 2011 10:32:27 Dave Martin wrote:
Note that the hwcaps info in /proc/cpuinfo is generated from the same hwcaps word exposed via auxv so, for now, the information is identical.
I would normally rate parsing /proc/cpuinfo as being a bad idea, but /proc/cpuinfo is probably the only source of the part ID information, for now. This is a bit unfortunate, especially since the format of /proc/cpuinfo could change at some point in the future, but in practice it seems to have been pretty stable with respect to this particular piece of information.
We do try to keep any ABI stable, including /proc/cpuinfo. I would generally consider it a bug when it breaks.
Agreed, but there are occasional changes, such is rmk pulling out the cache configuration information when he considered it had become too unsustainable.
As a general rule, the more generic a piece of information in /proc/cpuinfo is, the less likely it is to break. The CPU part number seems pretty generic, so it should be fairly safe to refer to it.
Cheers ---Dave
-
Andrew Stubbs -
Arnd Bergmann -
Christian Robottom Reis -
Dave Martin -
David Brown -
David Gilbert -
Mans Rullgard -
Marcin Juszkiewicz -
Pawel Moll -
Peter Maydell -
Stubbs, Andrew