Jump to content

[Solved] Difficulty accessing gpio via the sunxi-gpio export interface


David Van Cleef

Recommended Posts

I've started playing around with gpio, and thus far I don't have problems with any of the following:

  • Access via the WiringOP C or Python bindings
  • Access via /sys/class/gpio_sw

However I can't seem to get the access via /sys/class/gpio to work.

 

According to http://linux-sunxi.org/GPIOI need to write the pin number as defined in the fex file to /sys/class/gpio/export for 3.4 kernel (mainline kernel codes the pin number).

 

For WiringOP pin #1 (physical pin #12 on the header), this is PD14, which is gpio_pin_5 according to the fex file, however the following does not light an LED connected to the pin:

# echo "5" >/sys/class/gpio/export
# echo "out" >/sys/class/gpio/gpio5/direction
# echo "1" > /sys/class/gpio/gpio5/value
Link to comment
Share on other sites

I'm usually running Mainline, but in this case, I've rebooted with a Legacy, the "orangepilite 3.4.112-sun8i" and gave it a try.

 

It didn't worked with gpio5, but was working perfectly with gpio110.

 

So, since you got "Device or resource busy" using gpio110, we need more details :

 

Did you tried gpio110 right after reboot (because it could be "busy" by some other apps) ?

What kind is your board exactly ?

Is your 3.4 coming from Armbian ? (which subversion ?)

 

EDIT : what "cat /sys/kernel/debug/gpio" is showing ?

Link to comment
Share on other sites

 

I had already tried that. 

# echo "110" >/sys/class/gpio/export
bash: echo: write error: Device or resource busy

My device is orange pi one. And uname -r display 3.4.112-sun8i.

My symptom is same to you.

And I tried "cat /sys/kernel/debug/gpio". 

================

root@orangepione:~# cat /sys/kernel/debug/gpio
GPIOs 0-383, platform/sunxi-pinctrl, sunxi-pinctrl:
 gpio-0   (?                   ) out lo
 gpio-1   (?                   ) out lo
 gpio-2   (?                   ) out lo
 gpio-3   (?                   ) out lo
 gpio-6   (?                   ) out lo
 gpio-7   (?                   ) out lo
 gpio-8   (?                   ) out lo
 gpio-9   (?                   ) out lo
 gpio-10  (?                   ) out lo
 gpio-13  (?                   ) out lo
 gpio-14  (?                   ) out lo
 gpio-15  (red_led             ) out hi
 gpio-16  (?                   ) out lo
 gpio-21  (?                   ) out lo
 gpio-68  (?                   ) out lo
 gpio-71  (?                   ) out lo
 gpio-110 (?                   ) out lo
 gpio-198 (?                   ) out lo
 gpio-199 (?                   ) out lo
 gpio-200 (?                   ) out lo
 gpio-201 (?                   ) out lo
 gpio-354 (?                   ) out hi
 gpio-362 (green_led           ) out hi
==============
Command [# echo "4" >/sys/class/gpio/export] works.(That is omitted in the above list)
But that is meaningless. I don't know which pin is gpio4 ?
 
Instead using mainline export method, now I use gpio_sw.(/sys/class/gpio_sw/PG6/cfg... etc)
There is no problem in Freepascal programming.
 
Btw, ls -l /sys/class/gpio_sw list is same to FEX file gpio no & name.(All is 19)
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA0 -> ../../devices/platform/gpio_sw.5/gpio_sw/PA0
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA1 -> ../../devices/platform/gpio_sw.3/gpio_sw/PA1
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA10 -> ../../devices/platform/gpio_sw.15/gpio_sw/PA10
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA13 -> ../../devices/platform/gpio_sw.1/gpio_sw/PA13
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA14 -> ../../devices/platform/gpio_sw.2/gpio_sw/PA14
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA2 -> ../../devices/platform/gpio_sw.9/gpio_sw/PA2
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA21 -> ../../devices/platform/gpio_sw.10/gpio_sw/PA21
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA3 -> ../../devices/platform/gpio_sw.6/gpio_sw/PA3
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA6 -> ../../devices/platform/gpio_sw.0/gpio_sw/PA6
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA7 -> ../../devices/platform/gpio_sw.11/gpio_sw/PA7
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA8 -> ../../devices/platform/gpio_sw.12/gpio_sw/PA8
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PA9 -> ../../devices/platform/gpio_sw.14/gpio_sw/PA9
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PC4 -> ../../devices/platform/gpio_sw.7/gpio_sw/PC4
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PC7 -> ../../devices/platform/gpio_sw.8/gpio_sw/PC7
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PD14 -> ../../devices/platform/gpio_sw.4/gpio_sw/PD14
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PG6 -> ../../devices/platform/gpio_sw.17/gpio_sw/PG6
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PG7 -> ../../devices/platform/gpio_sw.18/gpio_sw/PG7
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PG8 -> ../../devices/platform/gpio_sw.13/gpio_sw/PG8
lrwxrwxrwx 1 root root 0 Jun 27 04:17 PG9 -> ../../devices/platform/gpio_sw.16/gpio_sw/PG9
 
Link to comment
Share on other sites

Worked it out, the gpio_sunxi module had control of things. After rmmod-ing it everything started working exporting pin 110.

 

The information on the sunxi-linux wiki about what number is passed to the export is incorrect for the armbian legacy kernel.

Link to comment
Share on other sites

Worked it out, the gpio_sunxi module had control of things. After rmmod-ing it everything started working exporting pin 110.

 

The information on the sunxi-linux wiki about what number is passed to the export is incorrect for the armbian legacy kernel.

 

But isn't this module disabled by default?

 

Regarding different legacy kernel behaviour please keep in mind that we exchanged the whole kernel tree with a newer variant back in March (post #2 here) so maybe it worked before differently. Now that we know that info in linux-sunxi wiki is wrong the logical next step would be to provide correct information. As a double check trying out one of the loboris images would be cool too since otherwise information in the wiki still might be wrong (if it's true and these different BSP kernel variants expose the GPIO pins differently)

Link to comment
Share on other sites

But isn't this module disabled by default?

 

Regarding different legacy kernel behaviour please keep in mind that we exchanged the whole kernel tree with a newer variant back in March (post #2 here) so maybe it worked before differently. Now that we know that info in linux-sunxi wiki is wrong the logical next step would be to provide correct information. As a double check trying out one of the loboris images would be cool too since otherwise information in the wiki still might be wrong (if it's true and these different BSP kernel variants expose the GPIO pins differently)

 

Well, it was disabled by default, but when I found the gpio class not working according to the documents I went looking for alternate access methods and then returned to revisit the export interface after I was sure that I didn't have a wiring or hardware problem.

 

I have some more sd cards arriving soon, once they're here I'll check if loboris kernels exhibit the same behavior.

Link to comment
Share on other sites

Why should you revert to loboris kernel ? it is simply junk to throw away...

You should continue in the Armbian path, even if you are facing pitfalls (those will be easier to fix than loboris ones) ... ;)

 

Just to confirm the behaviour in previous 3.4 kernels and properly correct the sunxi wiki. Incorrect/incomplete documentation is very frustrating and we should attempt to fix it if at all possible.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines