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

[Hans Kurscheidt]

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)

[schwar3kat]

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

[schwar3kat]

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).

[Hans Kurscheidt]

vor 14 Stunden schrieb schwar3kat:

Hans, It is a kernel deprecation issue. 

Yep, I thought about it. You won't make a lot of friends w/ this. 

[schwar3kat]

Hi Hans, 
I am currently looking at restoring the functionality for this build.
I will let you know when I have further information.

Kat

[Hans Kurscheidt]

vor 8 Stunden schrieb schwar3kat:

I am currently looking at restoring the functionality for this build.
 

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

[schwar3kat]

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

[MichaIng]

The Rockchip v5.15 kernel still has /sys/class/gpio, probably required configs can be taken from there.

 

Checking Armbian build commits, this looks promising: https://github.com/armbian/build/commit/cfc79c1

CONFIG_GPIO_SYSFS=y

[schwar3kat]

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

[Hans Kurscheidt]

vor 3 Stunden schrieb schwar3kat:

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

... if it would work. Please refer to

https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/

[schwar3kat]

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

[Hans Kurscheidt]

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

 

[schwar3kat]

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

 

 

 

[Hans Kurscheidt]

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

 

[going]

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

 

 

[going]

The first one in the search query displays a fairly detailed article:

https://blog.lxsang.me/post/id/33

[Hans Kurscheidt]

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

[going]

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?

[usual user]

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>;
<------><------>};
<------>};
};

 

[lanefu]

This functionality existed in our pervious stable kernel 5.10.y and should absolutely continue to be supported. It was a breaking change that should not have happened.

 

lane

[schwar3kat]

12 hours ago, Hans Kurscheidt said:

export: Permission denied

Hans, you are missing a / in front of bin.

[Hans Kurscheidt]

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.

[Hans Kurscheidt]

vor 13 Stunden schrieb usual user:

gpio-event-mon -n gpiochip0 -o 4 -r -f -b 10000 ; shutdown

@usual user

What & where is gpio-event-mon, and does it use the internal pull-up? And where is the documentation??

[Hans Kurscheidt]

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??

[Hans Kurscheidt]

vor 4 Stunden schrieb schwar3kat:

Hans, you are missing a / in front of bin.

Holy cow! sorry for this!! Its working now. Thanks!

[schwar3kat]

Happy that it works. 😀
 

[going]

28 минут назад, Hans Kurscheidt сказал:

What & where is gpio-event-mon

Linux kernel gpio tools

 

https://github.com/torvalds/linux/tree/master/tools/gpio

[Hans Kurscheidt]

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!

[lanefu]

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

[schwar3kat]

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.