pins/local: Add fallback device-tree method for hardware revision detection

[theyoyojo]

This patch adds support for gpiozero in Fedora Linux via RPi.GPIO2

See https://github.com/underground-software/python3-libgpiod-rpi and https://pypi.org/project/RPi.GPIO2/

Currently, only the Raspberry Pi 3 Model B is supported as this PR is just a proof-of-concept for now.

Signed-off-by: Joel Savitz joelsavitz@gmail.com

[bennuttall]

Is there a way you can get the actual revision code? It's useful to know the exact specs of the Pi at runtime, e.g. RAM. Not vital but useful for the pinout command line tool, which with a patch like this would "lie" to the user.

@lurch

[lurch]

A few lines above the code being added in this PR, it does:

io.open('/proc/device-tree/system/linux,revision', 'rb')

Does that not work on Fedora Linux? @theyoyojo

the exact specs of the Pi at runtime, e.g. RAM.

I think it's only the Pi4 which has different amounts of RAM for the same "model" string?

P.S. @bennuttall Any idea why this file is using io.open() rather than the regular open()?

[theyoyojo]

@lurch Yes, unfortunately that file is not present on the official Fedora Linux images.

[waveform80]

Hmmm, I would suggest Fedora would be better served by figuring out how to add that chunk of the d-t.

The model name is not a terribly reliable mechanism under certain circumstances. For instance, booting a Pi400 or CM4 is possible with firmware that pre-dates their release (consider the case of someone booting an SD card they've been using on a Pi4 but haven't upgraded after the release of a new Pi). However, when doing so, the model name in the d-t (which is patched by the start.elf bootloader to match the board it thinks it's on) becomes "Raspberry Pi Model ? Rev 1.0". By contrast, in these circumstances, the linux,revision node is still correct (as is the revision code in /proc/cpuinfo, when that's present).

My other objection is that this would introduce yet another lookup table that'd need maintaining (got quite enough of those already in pins/data :). As it stands, I'll have to reject this; if you could revise this to pull the revision code from some other location on Fedora I'd be happy to merge that?

I'll leave this open for now in case that's a possibility.

[theyoyojo]

My other objection is that this would introduce yet another lookup table that'd need maintaining (got quite enough of those already in pins/data :). As it stands, I'll have to reject this; if you could revise this to pull the revision code from some other location on Fedora I'd be happy to merge that?

Ok, I'll look into it, thanks for the review 👍