Does Anyone Know Where to Define The Hardware, Revision and Serial No. Fields of /Proc/Cpuinfo

Does anyone know where to define the hardware, revision and serial no. fields of /proc/cpuinfo?

It depends on the version of Linux and processor architecture. Since this is a TI ARM, you can start with: arch/arm/kernel/setup.c.

Look for static int c_show().

The Revision and Serial values are set with ATAG_REVISION and ATAG_SERIAL, so an appropriate boot loader can pass them to Linux. Typically you do not set these in the code but use them as conditionals to handle hardware variations that can not be detected at run time in a machine file or driver.

Is `Serial` field in `/proc/cpuinfo` unique for each Android device?

Serial is some number optionally passed by the bootloader and has nothing to do with the CPU. If set, the kernel treats it as unique for the device.

I have several devices with unset serial number (0000000000000000) and ARM64 and non-ARM devices do not have Serial at all.

What is the difference between CPU Revision and Revision fields for arm processors?

CPU revision: It Indicates patch release or "minor revision". In your case it is 1. So this value is specific to your CPU. You can see that CPU revision is matching to Processor : ARMv7 Processor rev 1 (v7l)

You can refer to attached image for the details of other filled as well.

Revision: It is related to your hardware (board) configuration. In your case your are using the Qualcomm hardware so revision number depends upon on it. It is independent of the CPU revision number.

I have a cpu cache coherency-looking problem that I can't figure out how to fix. Two cpus see different contents of the same memory

So miracle of miracles I came across the answer totally by accident.
I'd like to share in case anybody else comes across this and similarly bangs their heads for months.

In a totally unrelated change for another system I'm working on using this block driver, I made a change today and tried it on the pi4 and like magic it's all working.

What was the change? Not at all where I was looking....

So I register a callback with blk_queue_make_request not blk_init_queue.
I don't handle the request queue, I handle the bios in the block request directly.

In so doing, you are told:
https://www.kernel.org/doc/htmldocs/kernel-api/API-blk-queue-make-request.html

"The driver that does this must be able to deal appropriately with buffers in “highmemory”. This can be accomplished by either calling __bio_kmap_atomic to get a temporary kernel mapping, or by calling blk_queue_bounce to create a buffer in normal memory. "

Well, I had been achieving that with calls to kmap_atomic when I wanted to get the buffer. Today I read that there's a limited number of slots for those memory mappings and you should only call that if you're in an interrupt context and can't go to sleep, because the kmap_atomic call pulls from the reserved pile so it doesn't have to allocate on the call and possibly be put to sleep.

But my kernel module can sleep, so I changed the call to kmap() and... like magic... it's working.

So I'm thinking the failure cases were where kmap_atomic was failing and I wasn't catching or noticing, or possibly, something is wrong with kmap_atomic on the pi4 or on the interaction between the kernel in that case or something.
I'll play more and see if I can tease out what's going on, but the trick is something's wrong with the way I was calling kmap_atomic.

After a little playing around...

Feb 25 21:12:46 pi205 kernel: [86149.193899][13905] kernel:    buffer after kmap_atomic ffefd000
Feb 25 21:12:46 pi205 kernel: [86149.193912][13905] kernel:    buffer after kmap        bfe84000

so when kmap_atomic returns a different value than kmap, is when the other thread doesn't see the memory correctly. I read something saying there's a per-cpu cache of these kmap_atomic mappings, which would explain that behaviour, if that's what it is.

What is the equivalent of /proc/cpuinfo on FreeBSD v8.1?

Use dmidecode command:

# dmidecode -t processor -t cache
# dmidecode 3.0
Scanning /dev/mem for entry point.
SMBIOS 2.4 present.

Handle 0x0004, DMI type 4, 35 bytes
Processor Information
        Socket Designation: LGA 775
        Type: Central Processor
        Family: Pentium 4
        Manufacturer: Intel
        ID: F6 06 00 00 FF FB EB BF
        Signature: Type 0, Family 6, Model 15, Stepping 6
        Flags:
                FPU (Floating-point unit on-chip)
                VME (Virtual mode extension)
                DE (Debugging extension)
                PSE (Page size extension)
                TSC (Time stamp counter)
                MSR (Model specific registers)
                PAE (Physical address extension)
                MCE (Machine check exception)
                CX8 (CMPXCHG8 instruction supported)
                APIC (On-chip APIC hardware supported)
                SEP (Fast system call)
                MTRR (Memory type range registers)
                PGE (Page global enable)
                MCA (Machine check architecture)
                CMOV (Conditional move instruction supported)
                PAT (Page attribute table)
                PSE-36 (36-bit page size extension)
                CLFSH (CLFLUSH instruction supported)
                DS (Debug store)
                ACPI (ACPI supported)
                MMX (MMX technology supported)
                FXSR (FXSAVE and FXSTOR instructions supported)
                SSE (Streaming SIMD extensions)
                SSE2 (Streaming SIMD extensions 2)
                SS (Self-snoop)
                HTT (Multi-threading)
                TM (Thermal monitor supported)
                PBE (Pending break enabled)
        Version: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
        Voltage: 1.4 V
        External Clock: 266 MHz
        Max Speed: 3800 MHz
        Current Speed: 2394 MHz
        Status: Populated, Enabled
        Upgrade: Other
        L1 Cache Handle: 0x0005
        L2 Cache Handle: 0x0006
        L3 Cache Handle: 0x0007
        Serial Number: To Be Filled By O.E.M.
        Asset Tag: To Be Filled By O.E.M.
        Part Number: To Be Filled By O.E.M.

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
        Socket Designation: L1-Cache
        Configuration: Enabled, Not Socketed, Level 1
        Operational Mode: Write Back
        Location: Internal
......

How to determinal optimal GCC arm options from /proc/cpuinfo?

With the Android NDK comes several samples, just look at the one named hello-neon and its Android.mk .

All you need to know is there, if you are only interested about the compiler options you probably only want to take into account the C flag.

cpuid: reported micro-architecture seems ambiguous

This is the http://www.etallen.com/cpuid.html version of the cpuid command, rather than the one that's part of the msr-tools package.

---

According to Intel's web site, "Intel(R) Xeon(R) E-2278G" is a Coffee Lake, as your cpuid shell command figured out from other CPUID info, perhaps including the brand string.

Specifically, according to wikichip, it's a Coffee Lake Refresh iteration of Coffee Lake E (the Xeon-badged versions of "client" cores), so Coffee Lake ER.

Being Coffee Lake means the IA cores are microarchitecturally identical to Skylake (and Kaby Lake), although it has a newer GPU and has memory controllers rated for higher speeds.

For the CPU cores, the improvement is just a refinement of the silicon process (14nm++).

Except maybe for some hardware fix for vulnerabilities like Meltdown, and L1TF or other related things. And maybe refinement of the Spectre mitigations. But not yet fixing the bug that required disabling the LSD (loop buffer) in microcode, or the JCC erratum, so both those performance problems are still self-inflicted by its microcode to ensure correctness even in corner cases.

The PMU hardware is AFAIK identical in SKL, KBL, and CFL, except perhaps(?) some errata being fixed. The event IDs are all the same, I assume.

---

Understanding command-line cpuid output:

 version information (1/eax):
 ... family/model/stepping/...
 (simple synth)  = Intel Core (unknown type) (Kaby Lake / Coffee Lake) {Skylake}, 14nm

I'm guessing that this is saying that the family/model/stepping and extended-model/family fields don't distinguish between KBL and CFL (thus unknown type), but do imply one or the other. And {Skylake} is reminding you that KBL and CFL are both iterations of Skylake.

The "(unknown type)" is probably saying it doesn't know whether it's an i3/5/7/9 or Pentium or Celeron.

On my i7-6700k Skylake desktop, I get this. From cpuid version 20170122 from an old Arch Linux AUR install, which is still over a year after the CPU itself was released, which may be an older version than you have.

   version information (1/eax):
      processor type  = primary processor (0)
      family          = Intel Pentium Pro/II/III/Celeron/Core/Core 2/Atom, AMD Athlon/Duron, Cyrix M2, VIA C3 (6)
      model           = 0xe (14)
      stepping id     = 0x3 (3)
      extended family = 0x0 (0)
      extended model  = 0x5 (5)
      (simple synth)  = Intel Core i3-6000 / i5-6000 / i7-6000 / Pentium G4000 / Celeron G3900 / Xeon E3-1200 (Skylake), 14nm

So yeah, (simple synth) is probably what it was able to divine from just the things in that leaf, not the brand string.

From the latest version of the tool, version 20220224,

   version information (1/eax):
      processor type  = primary processor (0)
      family          = 0x6 (6)
      model           = 0xe (14)
...
      (family synth)  = 0x6 (6)
      (model synth)   = 0x5e (94)
      (simple synth)  = Intel Core (unknown type) (Skylake-H R0) {Skylake}, 14nm
    ...
   (uarch synth) = Intel Skylake {Skylake}, 14nm
   (synth) = Intel Core i*-6000 (Skylake-H R0) {Skylake}, 14nm

So the (unknown type) seems perfectly normal, just a consequence of Intel not varying the family, model, stepping numbers across i3/5/7.

The version of cpuid in your Ubuntu 20.04 LTS does seem to know about Coffee Lake, though. Perhaps not new enough to know about Coffee Lake Refresh, since yours said "R0" for yours, same as "R0" for my Skylake (which is not a "refresh"; there weren't new iterations of CPUs released as Skylake. They moved straight on to Kaby Lake after SKL.)

Anyway, your version of cpuid does eventually get to a correct and fully accurate description of your CPU, synthesized from various pieces of information.

   (synth) = Intel Xeon E-2200 (Coffee Lake R0) {Skylake}, 14nm

I'm not sure exactly what cpuid means by R0. Perhaps "revision 0", which would make sense if it didn't know about "Coffee Lake Refresh". I wonder if a newer cpuid would report R1 or spell out "Refresh"?

It is indeed an E-22xx series Xeon of the Coffee Lake family. The CPU cores are basically identical to Skylake, and it's built in a 14nm(++) process. IDK if Intel tweaked anything at all inside the cores between CFL and CFL-refresh, so for programming it you have all the info you need.

Other instances of "R" show up in CPUID output that mean "registered trademark" like in "Intel(R) Xeon(R)" in the brand string Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz that Linux pulls directly out of the CPU via the EAX=0017h leaf of the CPUID machine instruction with different ECX inputs. But I think the R0 is probably being used to mean "first iteration" (0th refresh?), since it's not just copying strings like "Xeon(R)".

---

Related Topics