Jump to content

GPIO depreciation sysfs on O-PI; No /sys/class/gpio/... anymore?


Hans Kurscheidt
Go to solution Solved by schwar3kat,

Recommended Posts

Linux orangepizeroplus 5.15.25-sunxi64 #22.02.1 SMP Sun Feb 27 09:24:04 UTC 2022 aarch64 GNU/Linux.

I don't see anymore the /sys/class/gpio... directory. Has this been suppressed or is my filesystem corrupted? The /sys/class/ dir exists w/ a lot of stuff, just gpio is missing!

This is duplicated in Discord, but I'm not sure, if it is right there (1st use)

Link to comment
Share on other sites

On 3/22/2022 at 1:21 AM, Hans Kurscheidt said:

I don't see anymore the /sys/class/gpio... directory.

Hi Hans,
Please could you report this as a bug.  Perhaps something might have been missed
https://www.armbian.com/bugs/

Edit: Actually hold off on the bug report.  I suspect that this might be a kernel deprecation issue.  I will investigate and report back.
 

Kat

Link to comment
Share on other sites

On 3/22/2022 at 1:21 AM, Hans Kurscheidt said:

/sys/class/gpio

Hans, It is a kernel deprecation issue.  There is a possibility that it can be added back dependent on effort required.  I will look into this.

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
https://www.kernel.org/doc/Documentation/ABI/obsolete/sysfs-gpio
https://www.kernel.org/doc/Documentation/driver-api/gpio/drivers-on-gpio.rst

In the mean time, you may want to look into whether libgpiod can do what you need. ( apt install gpiod).
A reasonable explanation and some instructions for using libgpiod.
https://www.thegoodpenguin.co.uk/blog/stop-using-sys-class-gpio-its-deprecated/

Update: The pull request has been merged and functionality restored (in nightly builds until next release).

Link to comment
Share on other sites

9 hours ago, Hans Kurscheidt said:

WiringPi for the OrangePi family has no prominent promoter and gpiod is still in its crude infancy.

It may take me some time to work this out, and no there are no guarantees.
In the mean time, the legacy build on linux-5.10y still appears to generate this directory at least it did when I built it last night. 
If you hover your mouse over the links in the archive, you can see the kernel versions.
https://armbian.hosthatch.com/archive/orangepizeroplus/archive/
 

Kat

Link to comment
Share on other sites

4 hours ago, MichaIng said:

probably required configs can be taken from there

Thanks MichaIng,  that's what I thought too.    Seems the linux kernel people are trying purposely to make it difficult.

I eventually found it :)
I compared the compile artifacts from legacy and current /drivers/gpio (before the build cleaned them) and found that .gpiolib-legacy.o.cmd and .gpiolib-sysfs.o.cmd were missing.  They were not compiling. This was in spite of kernel config containing CONFIG_GPIO_SYSFS=y and Makefile containing obj-$(CONFIG_GPIOLIB) += gpiolib-legacy.o and obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o

I then compared Kconfig, hoping to find a hint in the comments. There was a hint in the comments "select GPIO_CDEV # We need to encourage the new ABI"

but also... bool "/sys/class/gpio/... (sysfs interface)" if EXPERT  (this I did not expect).

I patched Kconfig to remove the if EXPERT, built it and it worked.  I tested the GPIO and was able to toggle a pin.  I will prep a PR for current and edge.

Kat

Link to comment
Share on other sites

17 minutes ago, Hans Kurscheidt said:

"select GPIO_CDEV # We need to encourage the new ABI"

.

Hi Hans,
That quote is what the upstream linux mainline kernel developers put in the comments where they disabled gpio sysfs for sunxi.
Armbian has no input into the upstream kernel build.

I have found how they disabled the gpio sysfs stuff and am in the process of crafting a pull request to restore it to Armbian build

When it is restored, I will ask you to please test.

Regards Kat

Link to comment
Share on other sites

vor 1 Stunde schrieb schwar3kat:

Armbian has no input into the upstream kernel build.

Hi Kat,

your effort is highly appreciated! But you can tell'em in my name the following:

Depreciating a widely used i/f is BAU, but replacing it w/ something not backwards compatible is already doubtful! Even if it was announced before, just switching it off and forcing a bazillion number of users rewriting their code is NOT AKZEPTABLE! It not just hits the sysfs users, it affects as well the large community of WiringPi users. It is not akzeptable, especially because

  1. the new i/f is not widely accepted; most users are not even aware of it. What RPI users think about it, one can read here: https://raspberrypi.stackexchange.com/questions/136479/confusion-with-libgpiod-and-the-gpiod-user-tools  
  2. there is no alternative to gpiod and no documentation for different levels of expertise
  3. the current Debian distributes gpiod 1.3, which is for all practical purposes useless, if you want to do more than just blinking an LED. The current stable version is at 1.6.5.
  4. Even the gpiod V 2.0 nightly cannot work, due to kernel-driver issues in the driver for the Allwinner CPUs, as I have stated here: https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/

Hence, most users are left in Limbo! I would at least expect that they create a switch so that old/new can be selectable at user level. That behavior wasn't #Expert, more #Amateur

RGDS

hk

I just powered up my RPI and found that they are still on kernel 5.10; there might ba reason for this!

$ uname -a
Linux raspberrypi 5.10.103-v7+ #1530 SMP Tue Mar 8 13:02:44 GMT 2022 armv7l GNU/Linux
hk@raspberrypi:~ $ ls -l /sys/class/g*
/sys/class/gpio:
insgesamt 0
--w--w---- 1 root gpio 4096 29. Mär 17:45 export
lrwxrwxrwx 1 root gpio    0 29. Mär 17:45 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio    0 29. Mär 17:45 gpiochip100 -> ../../devices/gpiochip1/gpio/gpiochip100
lrwxrwxrwx 1 root gpio    0 29. Mär 17:45 gpiochip504 -> ../../devices/platform/soc/soc:firmware/soc:firmware:expgpio/gpio/gpiochip504
--w--w---- 1 root gpio 4096 29. Mär 17:45 unexport

More over, compared to OPI/Armbian, pse take note that there is a Group gpio (not root) which solves quite some ACL problems w/ gpio

uname -a
Linux orangepizeroplus 5.10.60-sunxi64 #21.08.1 SMP Wed Aug 25 18:29:57 UTC 2021 aarch64 GNU/Linux
hk@orangepizeroplus:~$ ll /sys/class/gpio
total 0
--w------- 1 root root 4096 Jan  1  1970 export
lrwxrwxrwx 1 root root    0 Jan  1  1970 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0
lrwxrwxrwx 1 root root    0 Jan  1  1970 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352
--w------- 1 root root 4096 Jan  1  1970 unexport

 

Link to comment
Share on other sites

On 4/3/2022 at 9:36 PM, Hans Kurscheidt said:

Group gpio (not root)

Update: For others with non-root gpio sysfs ACL issues with this SBC, Hans has now confirmed that the method below works.

For ACL's
You probably already know this, but if not then you could try this:
If you try it then let us know if it works for your purposes.  PS I don't know if gpio10 is a pin, I just used it to check ACL's
 

As root (sudo su) create a gpio group:
$ groupadd gpio

add your user (replace "youruser" with your username):
$ usermod -a -G gpio youruser

create a file /etc/udev/rules.d/99-gpio-group.rules containing:
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc && chmod -R 770 /sys/devices/platform/soc'"


$ reboot

Log in as youruser

$ cd /sys/class/gpio
$ echo 10 > export

$ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Apr  5 09:24 export
lrwxrwxrwx 1 root gpio    0 Apr  5 09:24 gpio10 -> ../../devices/platform/soc/1c20800.pinctrl/gpiochip1/gpio/gpio10
lrwxrwxrwx 1 root gpio    0 Apr  5 09:23 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0
lrwxrwxrwx 1 root gpio    0 Apr  5 09:23 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352
-rwxrwx--- 1 root gpio 4096 Apr  5 09:23 unexport


$ echo out >/sys/class/gpio/gpio10/direction

$ ls -Ll /sys/class/gpio/gpio10/
total 0
-rwxrwx--- 1 root gpio 4096 Apr  5 09:24 active_low
drwxrwx--- 4 root gpio    0 Apr  5 09:24 device
-rwxrwx--- 1 root gpio 4096 Apr  5 09:25 direction
-rwxrwx--- 1 root gpio 4096 Apr  5 09:24 edge
drwxrwx--- 2 root gpio    0 Apr  5 09:24 power
drwxrwx--- 2 root gpio    0 Apr  5 09:24 subsystem
-rwxrwx--- 1 root gpio 4096 Apr  5 09:24 uevent
-rwxrwx--- 1 root gpio 4096 Apr  5 09:24 value

 

 


 

Link to comment
Share on other sites

Sorry, doesn't work for me. Tried to make it executable, but no cure.

Welcome to Armbian 22.02.1  with Linux 5.10.60-sunxi64

System load:   18%              Up time:       0 min
Memory usage:  26% of 474M      IP:            192.168.1.37 192.168.100.1
CPU temp:      57°C             Usage of /:    24% of 29G
RX today:      111.6 MiB

[ 0 security updates available, 37 updates total: apt upgrade ]
Last check: 2022-04-05 17:24

Last login: Tue Apr  5 17:24:18 2022 from 192.168.1.31
hk@orangepizeroplus:~$ ll /sys/class/gpio
total 0
--w------- 1 root root 4096 Apr  5 17:28 export
lrwxrwxrwx 1 root root    0 Apr  5 17:28 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0
lrwxrwxrwx 1 root root    0 Apr  5 17:28 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352
--w------- 1 root root 4096 Apr  5 17:28 unexport

hk@orangepizeroplus:~$ cd /sys/class/gpio
hk@orangepizeroplus:/sys/class/gpio$ echo 6 >export
-bash: export: Permission denied

hk@orangepizeroplus:/sys/class/gpio$ cat /etc/udev/rules.d/99-gpio-group.rules
SUBSYSTEM=="gpio*", PROGRAM="bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc && chmod -R 770 /sys/devices/platform/soc'"
hk@orangepizeroplus:/sys/class/gpio$ ll /etc/udev/rules.d/
total 12
-rw-r--r-- 1 root root   70 Oct 12 17:33 10-wifi-disable-powermanagement.rules
-rw-r--r-- 1 root root 3449 Oct 12 17:33 50-usb-realtek-net.rules
-rwxr-xr-x 1 root root  285 Apr  5 17:23 99-gpio-group.rules
hk@orangepizeroplus:/sys/class/gpio$groups
hk tty disk dialout sudo audio video plugdev games users systemd-journal input netdev ssh i2c gpio

 

Link to comment
Share on other sites

vor einer Stunde schrieb going:

please explain to me why the existence of the /sys/class/gpio interface is so important

Hi,

just go and write in your preferred method a shell script, for a GPIO Pin w/ pull-up and a button, to initiate shutdown, when the button is pressed. 

In sysfs & WiringPi its about 10 lines of bash; hence I hope I'm asking you not too much.

RGDS

Link to comment
Share on other sites

3 часа назад, Hans Kurscheidt сказал:
orangepizeroplus

 

Did I understand correctly? Do you need the power off button on this board to work? Is that all?

I looked at the arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus.dts file.

It really doesn't have this capability. Maybe we'll add it?

Link to comment
Share on other sites

2 hours ago, Hans Kurscheidt said:

just go and write in your preferred method a shell script, for a GPIO Pin w/ pull-up and a button, to initiate shutdown, when the button is pressed. 

#!/bin/bash
gpio-event-mon -n gpiochip0 -o 4 -r -f -b 10000 ; shutdown

Sorry, tried hard, but can't reach the requested 10 LOC in the bash script.

And as device tree overlay:

/dts-v1/;
/plugin/;

/ {
<------>compatible = "solidrun,cubox-i/q";
};

&{/} {
<------>gpio-keys {
<------><------>compatible = "gpio-keys";
<------><------>pinctrl-0 = <&pinctrl_gpio_key>;
<------><------>pinctrl-names = "default";

<------><------>button_0 {
<------><------><------>gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
<------><------><------>label = "Power-Key";
<------><------><------>linux,code = <KEY_POWER>;
<------><------>};
<------>};
};

 

Link to comment
Share on other sites

vor 13 Stunden schrieb going:

Did I understand correctly? Do you need the power off button on this board to work? Is that all?

@going

No! I use the OPi0+ on a PCB as MoBo as an EFIS w/ an Arduino Nano as analogue concentrator and GPIO extender w/ RS232, I2C, SPI, GPIO and a handful of sensors. Shutdown was just 1 function of it, I picked it as example, because its easy. The important issues for me to switch to the new i/f are the ability to use the internal pull-ups, because I don't want to make a new PCB revision w/ external pull-ups and a working event monitoring, which is not the case for gpiod on the OPi0+, as I stated before. The shutdown is initiated electronically w/ a MOSFET and an R/C combination & Optocoupler, where the MOSFET keeps the power 30 secs alive when the avionic switch is pulled off to enable a proper shutdown.

Link to comment
Share on other sites

WRT dtb editing. May be I am old fashioned, but an APP for me is supposed to run on the designed HW "as is" i.e. it has to bring its own capability to configure the necessary i/f at user space, making eventually use of middleware. In my case, I achieve this by using sysfs and WiringPi. Apart from the fact that armbian-config has a bug and edits the wrong dtb, disasembling, editing & recompiling a dtb file is not for the average user and would my App put into the situation, where its not runnable on OPi0+ boards from the shelve, anymore. Or do you think that M$ Office would be so successful, if the users had to go into the BIOS of their MoBo to fiddle around w/ something??

Link to comment
Share on other sites

Cannot set internal pull-ups!

Moreover I don't want to go on "somebodies" git page to look for solutions, which may be abandoned, tomorrow. If the Debian Kernel makers decide to stop and remove  a widely used i/f by surprise, they have the obligation to provide a widely working and well documented new solution for USERS ! 

I don't see anything like this. Forcing users to search git up&down, retro-engineer code and .h files is no documentation. And distributing a version of e.g. gpiod of 3-4 versions behind is no solution as well!

Link to comment
Share on other sites

8 hours ago, Hans Kurscheidt said:

Cannot set internal pull-ups!

Moreover I don't want to go on "somebodies" git page to look for solutions, which may be abandoned, tomorrow. If the Debian Kernel makers decide to stop and remove  a widely used i/f by surprise, they have the obligation to provide a widely working and well documented new solution for USERS ! 

I don't see anything like this. Forcing users to search git up&down, retro-engineer code and .h files is no documentation. And distributing a version of e.g. gpiod of 3-4 versions behind is no solution as well!

 

Yeah that was my experience with libgpiod a year or 2 ago.  No pull-ups etc.     It's not ready for prime use.     

 

Sysfs gpio access is the most consistent method to deal with gpio accross different devices.  And I'll gladly take it over 20 forks of wiring pi (which truly is deprecated in a much more literal sense) 

 

 

for background Even Adafruit jumped on the bandwagon libgpiod when it was announced but they quickly backed off quietly once the reality hit that it wasn't ready for their core customer base.

 

Deprecated in Kernel land doesn't meant stop using immediately, it means don't extend and start preparing/be aware for the (long-term) future

Link to comment
Share on other sites

On 3/22/2022 at 1:21 AM, Hans Kurscheidt said:

I don't see anymore the /sys/class/gpio... directory.

Hi Hans,
The pull request has been merged.   The changes should be available in the nightly builds now.
You can switch to nightly builds using armbian-config system settings.
If you get a chance please test and report back.
 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines