David Van Cleef Posted June 23, 2016 Posted June 23, 2016 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
The_Loko Posted June 25, 2016 Posted June 25, 2016 I had this working some time ago, but I don't know why it doens't work anymore, maybe it is a bug on newer Armbian versions.
martinayotte Posted June 25, 2016 Posted June 25, 2016 Maybe you can check if it is follow the method used in Mainline ... (position of letter in alphabet - 1) * 32 + pin number So, PD14 will be 3 * 32 +14 = 110
David Van Cleef Posted June 26, 2016 Author Posted June 26, 2016 Maybe you can check if it is follow the method used in Mainline ... So, PD14 will be 3 * 32 +14 = 110 I had already tried that. # echo "110" >/sys/class/gpio/export bash: echo: write error: Device or resource busy
martinayotte Posted June 26, 2016 Posted June 26, 2016 Try the python library that I'm using since awhile from https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 If it is working for you, we can try to figure out why /sys/class/gpio doesn't. (BTW, which kernel are you using ?)
David Van Cleef Posted June 26, 2016 Author Posted June 26, 2016 The Python and the WiringOP C libraries work fine, as does the gpio_sw sys class. I'm using the 3.4 kernel.
martinayotte Posted June 26, 2016 Posted June 26, 2016 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 ? 1
psbkkim Posted June 27, 2016 Posted June 27, 2016 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
David Van Cleef Posted June 27, 2016 Author Posted June 27, 2016 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.
tkaiser Posted June 27, 2016 Posted June 27, 2016 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)
David Van Cleef Posted June 27, 2016 Author Posted June 27, 2016 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.
martinayotte Posted June 28, 2016 Posted June 28, 2016 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) ...
David Van Cleef Posted June 28, 2016 Author Posted June 28, 2016 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. 1
Recommended Posts