Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Recent kernels no longer support sysfs interface for GPIO (raspberry pi) #250

Open
jbalonso opened this issue Sep 1, 2023 · 4 comments · Fixed by jbalonso/opensprinkler-firmware#2
Open

Recent kernels no longer support sysfs interface for GPIO (raspberry pi) #250

jbalonso opened this issue Sep 1, 2023 · 4 comments · Fixed by jbalonso/opensprinkler-firmware#2

Comments

@jbalonso
Copy link

jbalonso commented Sep 1, 2023

See https://forums.raspberrypi.com/viewtopic.php?t=343514.

On my recent system, running Linux sprinkler 6.3.9-1-default #1 SMP PREEMPT_DYNAMIC Thu Jun 22 03:53:43 UTC 2023 (0df701d) aarch64 aarch64 aarch64 GNU/Linux, the sysfs interface no longer works. This breaks raspi-gpio, and I think this critically impacts the workings of https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/gpio.cpp, beyond even just the system() call to raspi-gpio.

A potential remedy is written up here: https://www.ics.com/blog/gpio-programming-exploring-libgpiod-library. There exists packages for gpiod (CLI tools), libgpiod2 (runtime libraries), and libgpiod-dev (runtime libraries and development headers). I notice three choices:

  1. Replace raspi-gpio and the sysfs interface with the use of libgpiod.
  2. Replace rapsi-gpio and the sysfs interface with system() calls to gpioset.
  3. Continue supporting older kernels by conditionalizing the use of raspi-gpio and the sysfs interface vs. gpioset.

I might be able to do a little empirical testing to see if raspi-gpio and gpioset both work on older kernels.
@jbalonso jbalonso mentioned this issue Sep 4, 2023
Merged
@jbalonso
Copy link
Author

jbalonso commented Sep 5, 2023

I did not intend to close this issue when working on it in my fork... sorry.

@jbalonso jbalonso reopened this Sep 5, 2023
@jbalonso
Copy link
Author

jbalonso commented Sep 5, 2023

I worked on this over in my fork (please see the PR in my fork that accidentally closed this issue). I'd have offered it as a PR here, but:

  1. My fork builds off of @developer79433's Containerize2 #225 PR, so the dependencies are corrected in Dockerfile but not build.sh.
  2. Rather than porting the preliminary work on interrupts to libgpiod (which is possible), I just deleted it. Even then, I did not remove the pthreads includes/linking, though I think I determined they were only present for the interrupt handlers.
  3. I didn't address the possibility of needing to run this firmware on an older kernel that supports the sysfs interface (as well as raspi-gpio 's peculiar manipulations of /dev/gpiomem or /dev/mem).

I did, however, determine the code went from not-working to working by actually watering my lawn.

@lnxsrt
Copy link

lnxsrt commented Jan 20, 2024

Your code tweaks worked for me. However libgpiod in ArchLinuxARM is now at version 2.0.1 which completely breaks the older API. Downgrading to libgpiod 1.6.4 allowed your code to compile. Just lovely how GPIO handling in the kernel and libraries seem to change every few months. Figured by now those APIs would be fairly stable, but change for change sake I guess. Thanks again!

@jbalonso
Copy link
Author

Thanks for the heads-up!

Looking at distros, it seems Ubuntu (the base image I used for the docker image), Alpine (what I probably should have used), and even openSUSE Tumbleweed (what my k8s cluster running opensprinkler for me uses natively) are all still at 1.6.x.

I confirm, though, that Arch Linux is at 2.0.1.

It looks like I should bring my fork up-to-date with this repo anyway, and I should see if I can support both old and new libgpiod with good-old preprocessor directives. Unfortunately, it's the dead of winter here, so this will likely wait until spring is closer. (Also: a quick investigation shows that ArchLinuxARM is going to be tricky to test against).

Separately: you could try running opensprinkler as a container using docker or containerd (nerdctl) and side-step downgrading your system libgpiod.

@jbalonso jbalonso mentioned this issue Jan 22, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Rewrite gpio.cpp routines to use gpiod for OSPI/OSBO jbalonso/opensprinkler-firmware
2 participants
@jbalonso @lnxsrt