Update Raspberry Pi revision codes.

[nicomiguelino]

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.')

[tmeiczin]

@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.

[nicomiguelino]

Sounds great... Awesome, thanks!

[vpetersson]

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.

[tmeiczin]

@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.

[vpetersson]

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.

[ealmonte32]

👍🏻 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.

[ealmonte32]

@nicomiguelino This can be closed since we use the direct /proc/cpuinfo now.