Closed CyrilBrulebois closed 1 year ago
Investigations led to the following discoveries:
RPi.GPIO
module relies on a /dev
node that's only available on Raspberry OS (module that has not been upstreamed into mainline, and therefore not available on Debian) by default, with a fallback on /dev/mem
which can't be accessed due to protections in place in the Debian kernel (CONFIG_STRICT_DEVMEM=y
and CONFIG_IO_STRICT_DEVMEM=y
).python3-spidev
to handle the two SPI ports, and python3-libgpiod
to handle the two GPIO ports.The latter is very good news, since the existing package is quite hacky, having bundled a bunch of pip-obtained modules into our package: we didn't pay too high a price to get everything available in Debian packages the last time around, and all the crap we put together at the time is about to just go away!
We can also clean up the top-level build.sh
(mainly comments, inside a case
statement).
We will drop all the current packaged-ish dependencies when we switch to spidev
and libgpiod
.
I think most of the clean-up should be fine now. I'll let you take ownership and port the code.
I just tested the new Python code relying on python3-libgpiod
and python3-spidev
(instead of Adafruit Blinka and other pasta soup) works just fine on RaspberryPi OS.
Great, closing then!
While investigating DTB/DTBO tweaks to have all components of the PiRogue Hat up and running on Debian 12 and its mainstream kernel (as opposed to the
rpi
one), I've tried installing the pirogue screen package, but its service unit didn't want to start:That persists even after installing packages that looked like might be relevant:
so we should probably check what we shipped in the package, and/or external dependencies that haven't been documented in a way a missing package would be spotted when deploying the package on a pristine Debian base.