Christos Posted October 29, 2016 Share Posted October 29, 2016 Hi Struggling here with Orange's GPIO so I would be glad to see any pointer to a working gpio example for 3.4.x kernel. Even a simple one pin state switching would be great. Christos Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 29, 2016 Share Posted October 29, 2016 WiringOP library uses C code as a backend, so you can take their implementation that uses /dev/mem for accessing registers directly: https://github.com/zhaolei/WiringOP/blob/h3/wiringPi/wiringPi.c or sysfs based access: https://github.com/zhaolei/WiringOP/blob/h3/gpio/gpio.c Can't help with the "simple" part, sorry Link to comment Share on other sites More sharing options...
snowbody Posted October 30, 2016 Share Posted October 30, 2016 Christos, Here's a link to an old post, which explains howto address the GPIO directly. There's an example for reading the onboard switch, but you can use it for any gpio port. http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=940&extra=page%3D3I found a usefull script on http://docs.cubieboard.org/tutorials/common/gpio_on_lubuntuI did consult the Allwinner H3 datasheet.On page 316 you'll find the exact offsets for each port : PL_DAT 0x24+0x10For example port A : PAxx the offset = 0x10*(unsigned int *)(ptr+0x10) = data; (adapt cubieboard example)This way you can read and write ports that are not listed in wiringOPPort L is something special because it starts at a different address (page 345) port L0x01F02C00In order to read to onboard switch PL03, you have to switch the bits in the controlregister for this port to 0 (=input)(script write_controller_register)Then you can read out the port using the script (read_test_switch)compile : gcc script.c -o readswitch Link to comment Share on other sites More sharing options...
Christos Posted October 30, 2016 Author Share Posted October 30, 2016 WiringOP library uses C code as a backend, so you can take their implementation that uses /dev/mem for accessing registers directly: https://github.com/zhaolei/WiringOP/blob/h3/wiringPi/wiringPi.c or sysfs based access: https://github.com/zhaolei/WiringOP/blob/h3/gpio/gpio.c Can't help with the "simple" part, sorry Is WiringOP the ONLY module that gives proper GPIO functionality on sunxi? Can we have sysfs GPIO without WiringOP or not? I'm asking this because I'm a bit puzzled with sunxi gpio and armbian. As I see in sunxi gpio docs -> http://linux-sunxi.org/GPIO the names of pins in the sysfs supposedly are "gpio1_pe0" but I get instead "gpio1" (and so far its not working..) (Got the script.bin gpio enabled ok) Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 30, 2016 Share Posted October 30, 2016 Is WiringOP the ONLY module that gives proper GPIO functionality on sunxi? No. It's just a good example of C code for GPIO access and it's a library mostly comparible with Python code designed for WiringPi Can we have sysfs GPIO without WiringOP or not? sysfs GPIO interface is provided by the kernel and it doesn't depend on any libraries like WiringOP. Link to comment Share on other sites More sharing options...
Christos Posted October 30, 2016 Author Share Posted October 30, 2016 Ok, Thanks zador, but you didnt replied on why I see different gpio names.. is it just a newer thing and sunxi gpio docs did not catch up? There has to be something that I miss entirely since I cannot do a single led turn on with plain sysfs gpio. (by using WiringOP and their somehow different gpio numbering, the leds do work ok though.. but I want to have plain sysfs gpio access without WiringOP) So, Got my OPi ONE, Armbian 5.24, jessie kernel 3.4.113 The script.fex compiled to .bin and rebooted with gpio_used = 1 gpio_num = 19 gpio_pin_1 = port:PA06<1><default><default><0> gpio_pin_2 = port:PA13<1><default><default><0> gpio_pin_3 = port:PA14<1><default><default><0> gpio_pin_4 = port:PA01<1><default><default><0> gpio_pin_5 = port:PD14<1><default><default><0> gpio_pin_6 = port:PA00<1><default><default><0> gpio_pin_7 = port:PA03<1><default><default><0> gpio_pin_8 = port:PC04<1><default><default><0> gpio_pin_9 = port:PC07<1><default><default><0> gpio_pin_10 = port:PA02<1><default><default><0> gpio_pin_11 = port:PA21<1><default><default><0> gpio_pin_12 = port:PA07<1><default><default><0> gpio_pin_13 = port:PA08<1><default><default><0> gpio_pin_14 = port:PG08<1><default><default><0> gpio_pin_15 = port:PA09<1><default><default><0> gpio_pin_16 = port:PA10<1><default><default><0> gpio_pin_17 = port:PG09<1><default><default><0> gpio_pin_18 = port:PG06<1><default><default><0> gpio_pin_19 = port:PG07<1><default><default><0> Also got the ONE's schematic from here -> http://linux-sunxi.org/File:ORANGE_PI-ONE-V1_1.pdf Now, lets say that I want to use the physical pin 29 of the 40pin connector. That is named PA07. In script.bin I see that PA07 is gpio_pin_12 so I guess I have to use and export pin 12. root@orangepione:~# root@orangepione:~# cd /sys/class/gpio root@orangepione:/sys/class/gpio# ls -l total 0 --w------- 1 root root 4096 Oct 30 14:16 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/sunxi-pinctrl/gpio/gpiochip0 --w------- 1 root root 4096 Oct 30 14:16 unexport root@orangepione:/sys/class/gpio# echo 12 > export root@orangepione:/sys/class/gpio# ls -l total 0 --w------- 1 root root 4096 Oct 30 14:17 export lrwxrwxrwx 1 root root 0 Oct 30 14:17 gpio12 -> ../../devices/platform/sunxi-pinctrl/gpio/gpio12 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/sunxi-pinctrl/gpio/gpiochip0 --w------- 1 root root 4096 Oct 30 14:16 unexport root@orangepione:/sys/class/gpio# cd gpio12 root@orangepione:/sys/class/gpio/gpio12# ls -l total 0 -rw-r--r-- 1 root root 4096 Oct 30 14:17 active_low lrwxrwxrwx 1 root root 0 Oct 30 14:17 device -> ../../../sunxi-pinctrl -rw-r--r-- 1 root root 4096 Oct 30 14:17 direction -rw-r--r-- 1 root root 4096 Oct 30 14:17 edge drwxr-xr-x 2 root root 0 Oct 30 14:17 power lrwxrwxrwx 1 root root 0 Oct 30 14:17 subsystem -> ../../../../../class/gpio -rw-r--r-- 1 root root 4096 Oct 30 14:17 uevent -rw-r--r-- 1 root root 4096 Oct 30 14:17 value root@orangepione:/sys/class/gpio/gpio12# echo out > direction root@orangepione:/sys/class/gpio/gpio12# echo 1 > value root@orangepione:/sys/class/gpio/gpio12# At this moment, I expected to have high on the pin, but.. nope!! When I do the WiringOP exercise for the same physical pin, it does work though.. So, please guys... is there something that I miss here? Is there some pin numbering or conversion that I have to take into account? Christos Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 30, 2016 Share Posted October 30, 2016 I'm asking this because I'm a bit puzzled with sunxi gpio and armbian. As I see in sunxi gpio docs -> http://linux-sunxi.org/GPIO the names of pins in the sysfs supposedly are "gpio1_pe0" but I get instead "gpio1" (and so far its not working..) (Got the script.bin gpio enabled ok) This depends on the kernel version/patches. Having non-standard sysfs names (gpio1_pe0 instead of gpio1) breaks many libraries that use GPIO sysfs interface, so in most (if not all) kernels used in Armbian there is no port/pin name after the number. So, please guys... is there something that I miss here? Is there some pin numbering or conversion that I have to take into account? Must be something with pin number/configuration, please try using different pins defined in FEX file. Link to comment Share on other sites More sharing options...
jernej Posted October 30, 2016 Share Posted October 30, 2016 Yes, you are calculating pin number wrong. I think that A means zero, B 1 and so on. Multiply this number by 32 and then add pin number. For example, PA9 -> 0 * 32 + 9 = 9. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 30, 2016 Share Posted October 30, 2016 Yes, you are calculating pin number wrong. I think that A means zero, B 1 and so on. Multiply this number by 32 and then add pin number. For example, PA9 -> 0 * 32 + 9 = 9. This is definitely the scheme for the mainline kernel, but I don't think it applies to 3.4.x which still uses FEX for configuring pin numbers. Link to comment Share on other sites More sharing options...
jernej Posted October 30, 2016 Share Posted October 30, 2016 It does. I just checked it. It is funny, but those pins definitions are not used, except if you load sunxi-gpio driver, which is not loaded by default. In later BSP versions (tinaos) this driver doesn't exist anymore. Link to comment Share on other sites More sharing options...
Christos Posted October 30, 2016 Author Share Posted October 30, 2016 This is definitely the scheme for the mainline kernel, but I don't think it applies to 3.4.x which still uses FEX for configuring pin numbers. Exactly @jernej Did the mainline arithmetic and got root@orangepione:/sys/class/gpio# ls -l total 0 --w------- 1 root root 4096 Oct 30 14:38 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/sunxi-pinctrl/gpio/gpiochip0 --w------- 1 root root 4096 Oct 30 14:25 unexport root@orangepione:/sys/class/gpio# echo 7 > export -bash: echo: write error: Device or resource busy root@orangepione:/sys/class/gpio# which is not correct as the gpio pin 7 according to FEX is used by UART2 (PA3) Will continue the tests here but it looks to me that there is something broken in sysfs gpio.. Link to comment Share on other sites More sharing options...
jernej Posted October 30, 2016 Share Posted October 30, 2016 I'm 100% sure that arithmetic is correct. Check https://github.com/igorpecovnik/linux/blob/sun8i/drivers/pinctrl/pinctrl-sunxi.h#L23and https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/include/mach/pinctrl.h#L19 You will get busy for sure if pins are claimed by some other driver, in this case uart, if fex has "uart_used = 1" for uart2. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 30, 2016 Share Posted October 30, 2016 I'm 100% sure that arithmetic is correct. Check https://github.com/igorpecovnik/linux/blob/sun8i/drivers/pinctrl/pinctrl-sunxi.h#L23and https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/include/mach/pinctrl.h#L19 Yes, you are right. Sorry. This is the right place to check: https://github.com/igorpecovnik/linux/blob/sun8i/drivers/gpio/gpio-sunxi.c compared to old linux-sunxi kernel which uses [gpio_para] data: https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/gpio/gpio-sunxi.c Link to comment Share on other sites More sharing options...
Christos Posted October 30, 2016 Author Share Posted October 30, 2016 I'm 100% sure that arithmetic is correct. Check https://github.com/igorpecovnik/linux/blob/sun8i/drivers/pinctrl/pinctrl-sunxi.h#L23and https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/include/mach/pinctrl.h#L19 You will get busy for sure if pins are claimed by some other driver, in this case uart, if fex has "uart_used = 1" for uart2. No, that is not the case. Not PA07, nor PA03 are reserved in anything else in FEX. And that is on the OPi ONE. For my NanoPi NEO though, (with Armbian 5.24, 3.4.113) everything works by using FriendlyArm's matrix example framework and the sysfs.. that is even without the FEX gpio parameters enabled!! Most likely the sysfs gpio is broken, please @jernej dont get me wrong but I firmly believe that someone should look into it in kernel 3.4.x unless of course nobody cares.. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 30, 2016 Share Posted October 30, 2016 I tested PC7 and PD14 on OPi+2E with a multimeter. Both work OK. root@orangepiplus2e:~# echo 110 > /sys/class/gpio/export root@orangepiplus2e:~# echo out > /sys/class/gpio/gpio110/direction root@orangepiplus2e:~# echo 0 /sys/class/gpio/gpio110/value root@orangepiplus2e:~# echo 1 > /sys/class/gpio/gpio110/value root@orangepiplus2e:~# echo 0 > /sys/class/gpio/gpio110/value root@orangepiplus2e:~# echo 71 > /sys/class/gpio/export root@orangepiplus2e:~# echo out > /sys/class/gpio/gpio71/direction root@orangepiplus2e:~# echo 0 > /sys/class/gpio/gpio71/value root@orangepiplus2e:~# echo 1 > /sys/class/gpio/gpio71/value root@orangepiplus2e:~# echo 0 > /sys/class/gpio/gpio71/value Link to comment Share on other sites More sharing options...
Christos Posted October 30, 2016 Author Share Posted October 30, 2016 Yes, you are right. Sorry. This is the right place to check: https://github.com/igorpecovnik/linux/blob/sun8i/drivers/gpio/gpio-sunxi.c compared to old linux-sunxi kernel which uses [gpio_para] data: https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/gpio/gpio-sunxi.c If you think this is right, then here it comes the legitimate question.. what sysfs commands should I put to set high the physical pin 29 of the 40 pin connector in OrangePi ONE? Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 30, 2016 Share Posted October 30, 2016 what sysfs commands should I put to set high the physical pin 29 of the 40 pin connector in OrangePi ONE? Please check what GPIOs are used with "cat /sys/kernel/debug/gpio" if PA7 is "busy" for you. Link to comment Share on other sites More sharing options...
Christos Posted October 30, 2016 Author Share Posted October 30, 2016 Ok, My OPi made me be and feel really embarrassed.. Dir a reboot and now the darn thing works.. since this morning it gives me hard time and lots of frustration and now it simply works.. It looks the busy came after I did a "modprobe gpio-sunxi" @jernej thank you very much, you are right, that mainline way of gpio arithmetic is also used in legacy. Guys I feel very sorry for the noise and wasted bandwidth.. The bottom line is that the sunxi gpio docs need update to reflect that the mainline arithmetic is also employed in the legacy too nowadays, at least at 3.4.113.. Someone put a [solved] on the title Thanks to all Christos Link to comment Share on other sites More sharing options...
jernej Posted October 30, 2016 Share Posted October 30, 2016 I guess there is no legitimate reason left to have sunxi-gpio driver. Does anyone feel any different? Allwinner already removed it. Link to comment Share on other sites More sharing options...
vr@m Posted October 21, 2017 Share Posted October 21, 2017 On 30/10/2016 at 9:32 AM, Christos said: No, that is not the case. Not PA07, nor PA03 are reserved in anything else in FEX. And that is on the OPi ONE. For my NanoPi NEO though, (with Armbian 5.24, 3.4.113) everything works by using FriendlyArm's matrix example framework and the sysfs.. that is even without the FEX gpio parameters enabled!! Most likely the sysfs gpio is broken, please @jernej dont get me wrong but I firmly believe that someone should look into it in kernel 3.4.x unless of course nobody cares.. Good morning, I'm new to GPIO in this kind of boards (I have a nanopi M1) so, do I need to change something in the SO to use friendlyarm's matrix in armbian?. Thank in advance for your answer. Link to comment Share on other sites More sharing options...
Guest Posted October 21, 2017 Share Posted October 21, 2017 I'm using this one. There's a reference here http://linux-sunxi.org/GPIO#C.2FC.2B.2B_program, but don't remember where I found it because it seems there's no such link in that page. The lib itself are only 2 files: a .h and a .c, and there's also a .c which is an example. I've been using it on a Vanilla Desktop image (legacy kernel) on an Orange Pi One, and I haven't found any troubles so far. I hope this helps gpio.zip Link to comment Share on other sites More sharing options...
Recommended Posts