Anthias
Anthias copied to clipboard
Update Raspberry Pi revision codes.
General
- The dictionary can be updated based on what's included in Raspberry Pi's revision codes.
- Currently, some of the revision codes on RPi's official page are not included in the
database
dictionary.
Other Concerns
- Could be better if we can look for officially provided by Raspberry Pi, like an API, a JSON file, a Python module, or similar (so that we don't have to manually update the
database
dict more frequently).
Code Snippet
From lib/raspberry_pi_helper.py
:
def lookup_raspberry_pi_revision(revision):
"""
Takes the revision number and returns the
manufacturer, ram and human readable hardware revision.
Dataset is available here:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
"""
database = {
'900021': {'manufacturer': 'Sony UK',
'model': 'Model A+',
'ram': '512MB',
'revision': '1.1'},
'900032': {'manufacturer': 'Sony UK',
'model': 'Model B+',
'ram': '512MB',
'revision': '1.2'},
'900061': {'manufacturer': 'Sony UK',
'model': 'Model CM',
'ram': '512MB',
'revision': '1.1'},
# ...
'd03115': {'manufacturer': 'Sony UK',
'model': 'Model 4B',
'ram': '8GB',
'revision': '1.5'},
'c03115': {'manufacturer': 'Sony UK',
'model': 'Model 4B',
'ram': '4GB',
'revision': '1.5'}
}
return database.get(revision, 'Unknown Raspberry Pi version.')
@nicomiguelino Instead of trying to maintain a database of revision codes, I would decode the revision itself. I have some code that does this already, but it was a bit more of change than I wanted to put up for an initial PR. I'll work on a PR.
Sounds great... Awesome, thanks!
Actually, an even easier way is to just look in /proc/device-tree/model
like we do in upgrade_containers.sh
. That way we don't need to maintain any revisions at all.
@vpetersson Given that information was already in /proc/cpuinfo
as well, I assume there was reason to maintain specific details. If it is just for informational purposes, then using /proc/cpuinfo
or /proc/device-tree/model
would seem to suffice.
Good question. I am fairly certain that this code predates the metadata in /proc
. I can't see any reason to maintain two separate ways of looking up the same thing. Using /proc
seems a lot more robust too.
The only possible value that I can see in using the revision would be for debugging (in case it's a revision specific version), but I doubt that is something we'll run across frequently.
👍🏻 I like the direction this is going, not relying on backend database for revision info just to display on interface page..
The only possible value that I can see in using the revision would be for debugging (in case it's a revision specific version), but I doubt that is something we'll run across frequently.
The revision information is already on the outcome of /proc/cpuinfo
so I think simply exporting this info by grepping it into a variable for the containers should suffice.
@nicomiguelino
This can be closed since we use the direct /proc/cpuinfo
now.