# cat /etc/debian_version
10.13
# uname -a
Linux bb-pres 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux
I’m trying to use several pins as pull-up inputs. I’ve started with a single pin, from header P8, namely P8_11, which is GPIO1_13 as per the reference manual.
Applying the formula from the reference manual, that pin line should be: 32*1 + 13 → 45.
Now, if I go and read the pseudo-file /sys/class/gpio/gpio45/value I never get the correct signal. After hunting a bit in the /sys/class/gpio directory, I’ve discovered that my pin is actually #30 (!). That is, /sys/class/gpio/gpio30/value has the correct values.
Considering I need to add a dozen more pins to my program, I’d really like to know what I’m getting wrong in respect to mapping the header pins GPIO names to the `/sys/class/gpio’ pseudo-files.
This subsystem has been tagged for removal for awhile, while it has not been removed yet. The developers would rather you use libgpiod due to these exact issues you are seeing.
If you have pins that are pure output, use gpio-leds, for input we usually hackup gpio-keys, but /sys/class/gpio will still work fine, just be aware between major kernel versions these pin values can change…
Here are a couple of things I’ve noticed, as I am also getting a grip on that gpio line as well as its neighbors.
You may want to watch what mode the pin is in.
Checking /sys/devices/platform/ocp/ocp:P8_11_pinmux/state will let you know if it is in “default” mode, which I’m seeing behave like gpio_pu.
One potential pitfall that’s been getting me is the apparent race condition related to which interface goes to what port. I’m bouncing between the shipped kernel (4.19.94) and 5.15.49-bone-rt45 and the physical ports shifted from their abstraction in /dev and /sys. You can verify that gpio_45 will go to gpio1[13] by running the following command and seeing it respond with “gpiochip1”
The command is:
ls find /sys/devices/platform/ocp -name 4804c000.gpio | grep gpiochip