User avatar
panik
Posts: 369
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands

/sys/class/gpio behaviour changed in newer Raspbian?

Sat Feb 07, 2015 9:29 pm

Interfacing /sys/class/gpio on the new firmware (Raspbian 2015-01-31) seems different than older firmware.

On older firmware, the following script leaves an LED connected to GPIO 4 on after the script finishes (and keeps the pin an output). In the new firmware, the LED turns off after 1 second (and the pin returns to an input) even though the script never explicitly told it to.

Code: Select all

#!/bin/bash

echo "4" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio4/direction
echo "1" > /sys/class/gpio/gpio4/value

sleep 1

echo "4" > /sys/class/gpio/unexport
This happens on both the Model B+ and the new Pi 2 with the 2015-01-31 Raspbian with 'apt-get upgrade' (no rpi-update).

Is there a way around it and get the old behaviour back?
Microcontroller addon boards and software for Raspberry Pi A+/B+/Pi2:
- ARMinARM: ARM Cortex-M3 (STM32)
- AVRPi: ATmega32U4 & ATmega328 ("Arduino")
http://www.onandoffables.com

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: /sys/class/gpio behaviour changed in newer Raspbian?

Sun Feb 08, 2015 1:01 am

With Device Tree a new gpio driver is used: pinctrl-bcm2835.
When you unexport, the pin is set back as input. If you want to keep it, don't unexport it.
Unexporting tells Linux that you don't use the pin anymore.

Call cain:
unexport_store() => gpiod_free() => __gpiod_free() => chip->free():bcm2835_gpio_free() => pinctrl_free_gpio() => pinmux_free_gpio() => pin_free() => ops->gpio_disable_free():bcm2835_pmx_gpio_disable_free()

Code: Select all

static void bcm2835_pmx_gpio_disable_free(struct pinctrl_dev *pctldev,
                struct pinctrl_gpio_range *range,
                unsigned offset)
{
        struct bcm2835_pinctrl *pc = pinctrl_dev_get_drvdata(pctldev);

        /* disable by setting to GPIO_IN */
        bcm2835_pinctrl_fsel_set(pc, offset, BCM2835_FSEL_GPIO_IN);
}
Refs:
- http://lxr.free-electrons.com/ident?i=unexport_store
- http://lxr.free-electrons.com/ident?i=b ... sable_free

User avatar
panik
Posts: 369
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands

Re: /sys/class/gpio behaviour changed in newer Raspbian?

Sun Feb 08, 2015 12:22 pm

Ah yes, that explains it. After disabling it by adding 'device_tree=' in /boot/config.txt, the old behaviour is back.

I'll look into cleaner ways of handling this new 'device tree' thing, but at least everything is working again for now.

Thanks for the in-depth answer!
Microcontroller addon boards and software for Raspberry Pi A+/B+/Pi2:
- ARMinARM: ARM Cortex-M3 (STM32)
- AVRPi: ATmega32U4 & ATmega328 ("Arduino")
http://www.onandoffables.com

User avatar
FTrevorGowen
Forum Moderator
Forum Moderator
Posts: 5348
Joined: Mon Mar 04, 2013 6:12 pm
Location: Bristol, U.K.
Contact: Website

Re: /sys/class/gpio behaviour changed in newer Raspbian?

Sun Feb 08, 2015 7:18 pm

notro wrote:With Device Tree a new gpio driver is used: pinctrl-bcm2835.
When you unexport, the pin is set back as input. If you want to keep it, don't unexport it.
Unexporting tells Linux that you don't use the pin anymore.
...
To some extent this behaviour is what I thought "ought to happen" but didn't (and thus now "breaks" some of my 'C' demo. (G)LCD display programs which used wiringPi's variant of the export process, unexporting all used pins on closure - ie. backlights turned on via an exported pin now turn off shortly after exit). So that leads to two questions:
1) Is it O.K. to re-request a pin to be exported that hasn't been unexported previously (as opposed to one that's never been exported)?
2) If not, is there a "robust" or "preferred" way of testing whether a pin has previously been exported (and still is)?
Trev.
Still running Raspbian Jessie or Stretch on some older Pi's (an A, B1, B2, B+, P2B, 3xP0, P0W, 2xP3A+, P3B+, P3B, B+, A+ and a B2) but Buster on the P4B's. See: https://www.cpmspectrepi.uk/raspberry_pi/raspiidx.htm

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: /sys/class/gpio behaviour changed in newer Raspbian?

Sun Feb 08, 2015 8:27 pm

FTrevorGowen wrote: 1) Is it O.K. to re-request a pin to be exported that hasn't been unexported previously (as opposed to one that's never been exported)?
2) If not, is there a "robust" or "preferred" way of testing whether a pin has previously been exported (and still is)?
Re-requesting returns an error, because the pin is in use.
Check for the /sys/class/gpio/gpioNN directory to see if the pin has been exported to userspace.

Code: Select all

$ sudo -i
# cd /sys/class/gpio/
# echo 4 > export
# ls -l gpio4
lrwxrwxrwx 1 root gpio 0 Feb  8 20:14 gpio4 -> ../../devices/soc/3f200000.gpio/gpio/gpio4
# echo 4 > export
bash: echo: write error: Device or resource busy
#
# echo 4 > unexport
# ls -l gpio4
ls: cannot access gpio4: No such file or directory
#

User avatar
FTrevorGowen
Forum Moderator
Forum Moderator
Posts: 5348
Joined: Mon Mar 04, 2013 6:12 pm
Location: Bristol, U.K.
Contact: Website

Re: /sys/class/gpio behaviour changed in newer Raspbian?

Sun Feb 08, 2015 10:03 pm

notro wrote:
FTrevorGowen wrote: 1) Is it O.K. to re-request a pin to be exported that hasn't been unexported previously (as opposed to one that's never been exported)?
2) If not, is there a "robust" or "preferred" way of testing whether a pin has previously been exported (and still is)?
Re-requesting returns an error, because the pin is in use.
Check for the /sys/class/gpio/gpioNN directory to see if the pin has been exported to userspace.

Code: Select all

$ sudo -i
# cd /sys/class/gpio/
# echo 4 > export
# ls -l gpio4
lrwxrwxrwx 1 root gpio 0 Feb  8 20:14 gpio4 -> ../../devices/soc/3f200000.gpio/gpio/gpio4
# echo 4 > export
bash: echo: write error: Device or resource busy
#
# echo 4 > unexport
# ls -l gpio4
ls: cannot access gpio4: No such file or directory
#
Hmmm... I had a "nasty suspicion" that it'd be something like that. I'll have to check exactly how gordon (drogon) does the export etc. in his wiringPi 'C' library, since, in practice, I currently perform a 'C' system call to his gpio program from that.
Trev.
Still running Raspbian Jessie or Stretch on some older Pi's (an A, B1, B2, B+, P2B, 3xP0, P0W, 2xP3A+, P3B+, P3B, B+, A+ and a B2) but Buster on the P4B's. See: https://www.cpmspectrepi.uk/raspberry_pi/raspiidx.htm

Return to “Interfacing (DSI, CSI, I2C, etc.)”