HWBOT Prime Benchmark Script 2.0
Table of contents
The Update
This week I changed the process of identification inside my little HWBOT Prime1 benchmark script, about which I wrote an article some time ago.
The main purpose is to collect as much and correct information in order to provide this data for uploading the benchmark score, so the part to identify the used Raspberry Pi is very important.
I rewrote the whole part and used the unique revision code of each RPi, which is stored inside /proc/cpuinfo
.
Revision Codes
Every Raspberry Pi model has its own revision code which is unique.
On the official website2 you can find a table which model has which revision code. I used this table and added some more information about SoC, CPU etc.
Now, you get these information:
- Type of RPi-model
- Revision
- Type of SoC
- Type of CPU
- Architecture of ARM-CPU
- Size & type of memory
- Manufacturer
While comparing the revision codes from my different RPi-models with the ones provided by the official documentation, I found a flaw inside the current OS and an outdated documentation.
The documentation says there are two code styles, an old 4-digit hex-code for the Raspberry Pi 1 and a new 6-digit one for Raspberry Pi 2 and above.
Unfortunatelly none of my old RPi1s have an old-style revision code, but an odd 7-digit one. You get a 100000e instead of a 000e. My RPi2B and 3B (but not 3B+) also have this 7-digit code, but with a 2 as prefix to its normal new-style revision code.
Here you can see the different patterns of revision codes:
Model | Rev Code (documentation) | Rev Code (read out) |
---|---|---|
Raspberry Pi Model B Rev 2 / 512 MB | 000e | 100000e |
Raspberry Pi Model B+ Rev 1.2 / 512 MB | 900032 | 1900032 |
Raspberry Pi 2 Model B Rev 1.1 / 1 GB | a01041 | 2a01041 |
Raspberry Pi 3 Model B Rev 1.2 / 1 GB | a02082 | 2a02082 |
Raspberry Pi 3 Model B+ Rev 1.3 / 1 GB | a020d3 | a020d3 |
Raspberry Pi 4 Model B Rev 1.1 / 1 GB | a03111 | a03111 |
Raspberry Pi Compute Module 4 Rev 1.0 / 1 GB | a03140 | a03140 |
I filed issue #1888 at the official GitHub repository.
Maybe the behaviour is right, but the documentation is simply outdated, maybe it’s a bug.
Update: 29.04.2021
Issue #1888 was closed and now I’m wiser than before.
I misunderstand the way the revision code is generated…and there is a little flaw the RPi does it.
The new-style revision code is a result of a 32 bit value, (almost) each bit represents a piece of hardware-information: NOQuuuWuFMMMCCCCPPPPTTTTTTTTRRRR
N | O | Q | uuu | W | u | F | MMM | CCCC | PPPP | TTTTTTTT | RRRR |
---|---|---|---|---|---|---|---|---|---|---|---|
Overvoltage | OTP Program | OTP Read | Unused | Warranty bit | Unused | New flag | Memory size | Manufacturer | Processor | Type | Revision |
The prefixed 1 for the Raspberry Pi 1s a result of the warranty bit set to 1, due to overclocking. But the wrong bit in the pattern is used to indicate that the warranty is void.
Raspberry Pi Model B Rev. 2
100000e in hex means 1000000000000000000001110 in bin.
Raspberry Pi Model B+ Rev 1.2
1900032 in hex means 1100100000000000000110010 in bin.
Overvoltage | OTP Program | OTP Read | Unused | Warranty bit | Unused | New flag | Memory size | Manufacturer | Processor | Type | Revision |
---|---|---|---|---|---|---|---|---|---|---|---|
0 | 0 | 0 | 000 | 0 | 1 | 0 | 000 | 0000 | 0000 | 00000000 | 1110 |
0 | 0 | 0 | 000 | 0 | 1 | 1 | 001 | 0000 | 0000 | 00000011 | 0010 |
As you can see, the warranty bit isn’t set to 1, but the unused bit between the warranty and the new flag bit. This is the flaw.
The correct revision code should be 200000e and 2900032.
For the Raspberry Pi 2 and 3 the 2 as a prefix indicates a voided warranty. Everything is normal.
Since the Raspberry Pi 3 B+ no warranty bit is set any more, because the Raspberry Pi Foundation saw no correlation with a set warranty bit and increased chip failures.
I’m currenty working on a new version of my script, to improve the collection of information across all RPi generations.
As always, I’ll keep you updated.
The script in action
The script checks the revision code stored in /proc/cpuinfo
and compares it to the table.
Since I’m no programmer the task of comparing the read out code to the one stored in the table, was quite difficult. A good friend of mine introduced me to associative arrays.
I also tuned the look a little bit, so the information is displayed in a more satisfyingly order.
You can download the script at my GitHub repository.3