GPIO sysfs changes between Debian 7 (wheezy) and Debian 11 (bullseye)

[kimfaint]

We have some software using GPIO running on an old A20 image based on Debian 7 (wheezy) 3.4.90+ kernel.

It is reading GPIO-1 Pin 40 PC23. At the shell you can do the following:

Code Select Expand

root@a20-olimex:/usr/local/bin# ls -la /sys/class/gpio/
total 0
drwxr-xr-x  2 root root    0 Jun  2 04:30 .
drwxr-xr-x 52 root root    0 Jun  2 04:30 ..
--w-------  1 root root 4096 Jun  2 04:30 export
lrwxrwxrwx  1 root root    0 Jun  2 04:30 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1
--w-------  1 root root 4096 Jun  2 04:30 unexport
root@a20-olimex:/usr/local/bin# echo 13 > /sys/class/gpio/export
root@a20-olimex:/usr/local/bin# ls -la /sys/class/gpio/
total 0
drwxr-xr-x  2 root root    0 Jun  2 04:30 .
drwxr-xr-x 52 root root    0 Jun  2 04:30 ..
--w-------  1 root root 4096 Jun  2 04:33 export
lrwxrwxrwx  1 root root    0 Jun  2 04:33 gpio13_pc23 -> ../../devices/platform/gpio-sunxi/gpio/gpio13_pc23
lrwxrwxrwx  1 root root    0 Jun  2 04:30 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1
--w-------  1 root root 4096 Jun  2 04:30 unexport

Our software relies on reading /sys/class/gpio/gpio13_pc23

We are upgrading to use the latest Debian 11 (bullseye) Olinuxino image, where that same process gives:

Code Select Expand

root@dss:~# ls -la /sys/class/gpio/
total 0
drwxr-xr-x  2 root root    0 Jan  1  1970 .
drwxr-xr-x 57 root root    0 Jan  1  1970 ..
--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 Jun  1 11:09 gpiochip413 -> ../../devices/platform/soc/1c2ac00.i2c/i2c-0/0-0034/axp20x-gpio/gpio/gpiochip413
--w-------  1 root root 4096 Jan  1  1970 unexport
root@dss:~# echo 13 > /sys/class/gpio/export
root@dss:~# ls -la /sys/class/gpio/
total 0
drwxr-xr-x  2 root root    0 Jan  1  1970 .
drwxr-xr-x 57 root root    0 Jan  1  1970 ..
--w-------  1 root root 4096 Jun  1 11:10 export
lrwxrwxrwx  1 root root    0 Jun  1 11:10 gpio13 -> ../../devices/platform/soc/1c20800.pinctrl/gpiochip0/gpio/gpio13
lrwxrwxrwx  1 root root    0 Jan  1  1970 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0
lrwxrwxrwx  1 root root    0 Jun  1 11:09 gpiochip413 -> ../../devices/platform/soc/1c2ac00.i2c/i2c-0/0-0034/axp20x-gpio/gpio/gpiochip413
--w-------  1 root root 4096 Jan  1  1970 unexport

And the software crashes because it cannot find /sys/class/gpio/gpio13_pc23 because it has been exported as /sys/class/gpio/gpio13

After RTFM (Olimage Linux guide) in a bit more detail, the formula it gives to calculate the gpio number is

gpioNumberLinux = (portLetterChip position in the alphabet - 1) * 32 + pinNumberChip
 = (3-1)*32+23
 = 87

So if I run:

Code Select Expand

root@dss:~# echo 87 > /sys/class/gpio/export

I get /sys/class/gpio/gpio87 and when then run

Code Select Expand

root@dss30008:~# watch -n 1 cat /sys/class/gpio/gpio87/value

I can see the value change between 1 and 0 when I hold down the button :-)

So we can change our app to export 87 instead of 13.

Has anyone else hit this issue and can explain why this seems to have changed?

[adamor]

Hi kimfaint,
I think the difference is mainly that since Debian9 (if I remember well) Olimex switched from AllWinner custom kernel (3.x based) to mainline Debian based ones.
Hence all the I/O changed relatively and are managed quite differently.

We are facing similar issue on using uart2_rts and uart2_cts signals which could be enabled previously by mean of script.fex/script.bin files in the /boot but with Debian11 I wasn't able to use.

The solution I've found (albeit only in C/C++), which looks to works in both kernel case (Debian8 and Debian11) is to use the following sunxi gpio lib:
https://github.com/rubitwa/sunxi_gpio_lib

Even if you don't use C/C++ for you project you will find very easy to understand the concept.
The lib basically uses /dev/mem and base address to directly access the

This way only one file descriptor needs to be open and the access is very very fast.

I hope this will help your case.

Cheers,
Adamo