GPIO / WiringPi mit neuer Version 3.75.7.20240420 unter RPI5 nicht vorhanden!?

[GithubuserSRL]

Describe the issue you are experiencing

Mit der neuen Version 3.75.6.20240316 und der Hardwareplattform Raspberry Pi 5 lassen sich die GPIO´s nicht mehr ansprechen.

Describe the behavior you expected

Ich nutze zur Zeit einen RPI 3b+ mit 3.75.6.20240316 und kann die GPIO´s ansteuern. Mein Ziel war ein Hardwarewechsel von RPI 3b+ auf 5. Bis auf das ansprechen der GPIO´s scheint alles zu funktionieren. Da die Ansteuerung der GPIO´s für mich sehr wichtig ist, bin ich wieder auf die alte Hardewarekonfiguration zurück gewechselt. Auch mit dem aktuellen Firmwarerelease 3.75.7.20240420 hat sich das noch nicht geändert. Eine GPIO Readall Abfrage über Putty bringt beim RPI 3b+ das übliche Ergebnis mit der Konfiguration der GPIO-Pins. Beim der gleichen Abfrage unter dem RPI5 erscheint folgende Meldung :
WiringPiSetup: Unable to open /dev/mem or /dev/gpiomem: No such file or directory.
Aborting your program because if it can not access the GPIO
hardware then it most certianly won't work

Steps to reproduce the issue

1. Firmware 3.75.6.20240316 auf RPI5 installiert
2. Backup auf die neue Plattform aufgespielt.
3. Verbindung mit Putty zur Plattform
4. GPIO Readall Abfrage

What is the version this bug report is based on?

3.75.6.20240316 und 3.75.7.20240420

Which base platform are you running?

rpi5 (RaspberryPi5, ARM64/aarch64)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

X

Additional information

X

[jens-maus]

This "problem" is more or less known. The point is, that using wiringpi on modern linux platforms is more or less obsolete and users are suggested to move over to the official new GPIO tools which directly interact with newer kernels. Therefore wiringPi is also more or less flagged obsolete and the original author does not release newer versions anymore (cf. https://hackaday.com/2019/09/18/wiringpi-library-to-be-deprecated/). Thought, there are third party developer which try to keep up for some more time. Nevertheless it would be IMHO a better option to move over your use-cases to use the new official gpio tools (cf. https://github.com/brgl/libgpiod) which are part of RaspberryMatic already. Thus, use commands like gpiodetect, gpioset, etc. to interact with GPIOs in future.

Nevertheless, I will try to see if I can integrate a newer version of these wiringpi forks which try to keep up. But in long term you should better switch over IMHO.

[mwallner]

FWIW: WiringPi is back since Feb 2024 in version 3 and going strong on all current kernels and supported through all Raspberry Boards from V1 to 5 😉

See the current Releases

[jens-maus]

Already integrated wiringpi 3.2 for the next release, see bc1e1ec

However, I am still not sure if it would not be better to use the native libgpiod tools since wiringpi still performs direct kernel access and therefore does not allow to lockdown a kernel. That's why I had to loosen the kernel security a bit to get it working again (see 16850f7)

[mstroh76]

"third party developer"? - I prefer the term open source developer.
The interface of libgpiod is already included into wiringpi library and will be released very soon .

[jens-maus]

The interface of libgpiod is already included into wiringpi library and will released very soon .

That would be great of course if wiringpi could even be used on a locked down kernel like the native libgpiod tools. Looking forwarding so that I can enable kernel lockdown per default again...

[mstroh76]

Version 3.4 was release https://github.com/WiringPi/WiringPi/releases/tag/3.4
When wiringPiSetupGpioDevice(WPIPinType) is executed, the new Kernel GPIO Device is used.
(examples 1-4: https://github.com/WiringPi/WiringPi/tree/master/wiringPi/test )
No need to change anything else.
pinMode(PM_OFF) can release the line, if needed after using it.

gpio -v is testing kernel/system for access possibility's. But I'm not sure if it's accurate, shows strange behavior on Ubuntu 24.04.