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

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

Open
jbalonso opened this issue Sep 1, 2023 · 15 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
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.

@wommy
Copy link

wommy commented Apr 18, 2024

i got it working on bookworm by running the following commands

wget https://raw.githubusercontent.com/jbalonso/opensprinkler-firmware/main/gpio.cpp \
-O gpiod.cpp # pulls @jbalonso's edited gpio.cpp renaming it gpiod.cpp

cp build.sh build_bw.sh # perserve executable
sed -i '26s/-dev/-dev libgpiod-dev/' build_bw.sh # avoid a second query by appending
sed -i '/raspi-gpio/,+5d' build_bw.sh # delete raspi-gpio and its command check
sed -i '/-DOSPI/s/gpio/gpiod/' build_bw.sh # in the `-DOSPI` line, change gpio to gpiod
sed -i '/-DOSPI/s/$/ -lgpiod/' build_bw.sh # append ` -lgpiod` 

sudo ./build_bw.sh ospi # and finally run the build script

diff between build.sh and build_bw.sh for visibility

26,32c26
<       apt-get install -y libmosquitto-dev
<       apt-get install -y raspi-gpio
<       if ! command -v raspi-gpio &> /dev/null
<       then
<               echo "Command raspi-gpio is required and is not installed"
<               exit 0
<       fi
---
>       apt-get install -y libmosquitto-dev libgpiod-dev


34c28
<       g++ -o OpenSprinkler -DOSPI -std=c++14 main.cpp OpenSprinkler.cpp program.cpp opensprinkler_server.cpp utils.cpp weather.cpp gpio.cpp etherport.cpp mqtt.cpp -lpthread -lmosquitto
---
>       g++ -o OpenSprinkler -DOSPI -std=c++14 main.cpp OpenSprinkler.cpp program.cpp opensprinkler_server.cpp utils.cpp weather.cpp gpiod.cpp etherport.cpp mqtt.cpp -lpthread -lmosquitto -lgpiod

@mrave
Copy link

mrave commented Apr 26, 2024

@wommy followed your instructions, still not working, any tips, or things to check?
Does it make sense to clone the jbalonso repo entirely and run it instead, is that recommended?

@jbalonso
Copy link
Author

jbalonso commented Apr 26, 2024

I suspect we'll all be happier if we added a github action to my repo to build the binary as well as the docker image. I wonder if we can assure that the libgpiod2 library can be statically linked...

@rayshobby
Copy link
Member

Sorry about the delay. I will take a look at this soon. We are still in the middle of the semester and I don't have time to check all the details. The semester will be over in a few weeks by which time I will have more time. To be honest I don't understand why every couple of years Raspberry Pi decides to change the way gpios are operated. Instead of providing a backward compatible method, they just get rid of the old method. It's like not understanding what software abstraction means -- it should provide a high level interface that remain unchanged over decades.

@mrave
Copy link

mrave commented Apr 26, 2024

I suspect we'll all be happier if we added a github action to my repo to build the binary as well as the docker image. I wonder if we can assure that the libgpiod2 library can be statically linked...

That would be great indeed... but I still wonder whats not working, since I can't see any logs or anything. Any idea?

Sorry about the delay. I will take a look at this soon. We are still in the middle of the semester and I don't have time to check all the details. The semester will be over in a few weeks by which time I will have more time. To be honest I don't understand why every couple of years Raspberry Pi decides to change the way gpios are operated. Instead of providing a backward compatible method, they just get rid of the old method. It's like not understanding what software abstraction means -- it should provide a high level interface that remain unchanged over decades.

@rayshobby thanks for the prompt reply. The real problem here is that the irrigation is not working for a week (since I upgraded raspibian) and i did not even know, until I noticed the plants getting sick...
Anything I can do to help? Is there any was I can run the taps from command line, i.e. until this gets fixed? If there's an easy tool to talk to the electric taps I can just cron job it for now.

@wommy
Copy link

wommy commented Apr 26, 2024

@mrave

Does it make sense to clone the jbalonso repo entirely and run it instead, is that recommended?

not at all, unless youre fluent in docker.

@wommy followed your instructions, still not working, any tips, or things to check?

did you run those commands on the repo after a pull?

your else block should look like this

else
	echo "Installing required libraries..."
	apt-get update
	apt-get install -y libmosquitto-dev libgpiod-dev
	echo "Compiling firmware..."
	g++ -o OpenSprinkler -DOSPI -std=c++14 main.cpp OpenSprinkler.cpp program.cpp opensprinkler_server.cpp utils.cpp weather.cpp gpiod.cpp etherport.cpp mqtt.cpp -lpthread -lmosquitto -lgpiod
fi

@wommy
Copy link

wommy commented Apr 26, 2024

tomorrow, im going to reinstall raspian bookworm to test this, as i might be missing a dependency

wommy@981b215

@mrave
Copy link

mrave commented Apr 27, 2024

@mrave

Does it make sense to clone the jbalonso repo entirely and run it instead, is that recommended?

not at all, unless youre fluent in docker.

@wommy followed your instructions, still not working, any tips, or things to check?

did you run those commands on the repo after a pull?

your else block should look like this

else
	echo "Installing required libraries..."
	apt-get update
	apt-get install -y libmosquitto-dev libgpiod-dev
	echo "Compiling firmware..."
	g++ -o OpenSprinkler -DOSPI -std=c++14 main.cpp OpenSprinkler.cpp program.cpp opensprinkler_server.cpp utils.cpp weather.cpp gpiod.cpp etherport.cpp mqtt.cpp -lpthread -lmosquitto -lgpiod
fi

Thanks @wommy. I ended up cloing your repo, fixing the missing libgpiod, std arguments, rebuilding and using the OpenSprinkler binary for now. So I am ok for now, until @rayshobby will incorporate this into the master. Appreciate your help man!

@rayshobby
Copy link
Member

I suspect we'll all be happier if we added a github action to my repo to build the binary as well as the docker image. I wonder if we can assure that the libgpiod2 library can be statically linked...

That would be great indeed... but I still wonder whats not working, since I can't see any logs or anything. Any idea?

Sorry about the delay. I will take a look at this soon. We are still in the middle of the semester and I don't have time to check all the details. The semester will be over in a few weeks by which time I will have more time. To be honest I don't understand why every couple of years Raspberry Pi decides to change the way gpios are operated. Instead of providing a backward compatible method, they just get rid of the old method. It's like not understanding what software abstraction means -- it should provide a high level interface that remain unchanged over decades.

@rayshobby thanks for the prompt reply. The real problem here is that the irrigation is not working for a week (since I upgraded raspibian) and i did not even know, until I noticed the plants getting sick... Anything I can do to help? Is there any was I can run the taps from command line, i.e. until this gets fixed? If there's an easy tool to talk to the electric taps I can just cron job it for now.

Why not downgrade Raspbian to Bullseye? Not sure if you noticed, but we've put a note on the instructions page:
https://openthings.freshdesk.com/support/solutions/articles/5000631599-installing-and-updating-the-unified-firmware-on-ospi
that says specifically the firmware currently does not work with Bookworm. Unfortunately OSPi does not have current sensing ability so it doesn't show you the current draw from solenoids. If you have OpenSprinkler 3.x, they will show the actual current draw, which would allow you to see that the solenoids are not open. On the other hand, you can install a flow/water meter and use it to monitor the flow rate. This would allow you to notice that no water is flowing.

@wommy
Copy link

wommy commented Apr 28, 2024

that notice was put up long after I upgraded
https://wiki.debian.org/SystemDowngrade

@mrave
Copy link

mrave commented Apr 28, 2024

Yeah, downgrading debian is, hmmm, not recommended anyway :)
I am running currently with @wommy code and it seems to work. I'll wait till you have some time to upgrade formally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants