A20 GPIO map

[Ruler]

I've  been expirimenting with GPIO and this is what I've come up with so far. Thought it might be usefull for
sharing.




Best regards,

Roel P

[olimex]

nice!
you can have look at uboot pio tool we use it to test the board GPIOs at production as Linux still have no GPIO support

[viseng]

hi Ruler,

Thanks very much for providing some light on the GPIO for the A20.
As a newbie to Android and Linux, recently purchased the A20 Android card. Attempting to understand how to access GPIO but have had little success so far. Have tried the "toogle led" example by TsvetanUsunov but there appear to be major differences in file structure between the A20 and A10S, for instance -
PE3 is LED1 = PH2 on A20. Thats should be easy enough to sort out, but the file organisation is different!
A10S : #echo 1 > /sys/class/gpio_sw/PE3/mul_sel does not correspond in any way with
A20 = sys/class/gpio/gpiochip0  to gpiochip229 but excluding gpiochip169 which is for LED1 on the A20 . Does this indicate that you address a specific pin by selecting the gpiochip167 then adding a 2 bit offset? -seems an odd way to do it.

According to linux literature, there should be a way of writing to gpiochipxx with binary values for direction and value, but have not been able to achieve this so far. I would assume that something at a system level needs to be setup first in a config file of some kind but need help to get this underway.

Can anyone provide an example of driving pins on the A20 under andoid?

Many thanks

[Ruler]

Hi viseng,

I think you are missing the point with reading the map. The four matrixes actually represent the four 40 pin headers on the board.  The bold nr's represent the GPIO nr and the 1 to 40 the pin nr. I uploaded a new picture to clarify. GPIO169 doesn't have to be excluded the signal appears on pin 7 of header GPIO 3.

According to the map:

If you want pin 8 of header GPIO 3 to go high, use GPIO28
If you want pin 9 of header GPIO 3 to go high, use GPIO174

From a terminal do it like this:


Open a terminal(I used a serial port connection to UART0 when I was using Android)

Enter sh

Export the particular GPIO pin. We'll take GPIO169 as an example.

echo 169 > /sys/class/gpio/export

Change the GPIO pin direction to out

echo "out" > /sys/class/gpio/gpio169/direction   # we use this GPIO as an output  "in"  is used to configure as input

Change the value

echo 1 > /sys/class/gpio/gpio169/value  # switch it on

(led1 will light and pin 7 of GPIO3 will go high - 3.3volt)


echo 0 > /sys/class/gpio/gpio169/value  # and off

Unexport the GPIO pin when done

echo 169 > /sys/class/gpio/unexport

You can read the schematics for function assignments of the pins. All the bold nr's in the map
are usable as output but it's always good to check what functions the 'GP'IO has.








BTW I made a little python GUI program to set the GPIO's, so if anyone is interested let me know.

Good luck

[Lurch]

I made a little python GUI program to set the GPIO's

I'm interested. Please post.
Thank you for the table.  It helps a lot.

[Ruler]

I will post it soon.  Lurch.

Still needs some improvement but getting there. The aim is to create a configuration and save that to
disk so that you can re-upload it to the board. Also the option to set and read IO.
Also made some corrections to the map, turns out 178 and 188 are not usable. Also there's quite some
GPIO that can be exported but isn't yet found on the headers. Once my software fully works it will be simpler
to find out.

Best regards,

Roel
 

[XFer]

Anyone knows of any news regarding Linux GPIO support for this A20 Olimex board?
Currently published kernel does not support GPIO (no driver).
Had a look on Sunxi but looks like they are not working on the issue...?

Thanks

[olimex]

second revision of A20-Debian is uploaded and linked to Wiki with sysfs GPIO support

[Mouchon]

Hi many thanks for this second image. Can you provide kernel source and config you used ?

Regards

[XFer]

Thanks Olimex for the new image! 

I agree with Mouchon, a .config for the kernel source would be great: so we could recompile a custom kernel without having to guess at the zillion options.

Fernando

[sanzoghenzo]

Thanks ruler for sharing this, and thanks olimex for the debian image.
I'm interest at the linux source and config file, too. Is it from linux-sunxi? because I cannot read any "SUN7I" in the gpio-sunxi driver.
I would like to use (many) gpio pins as buttons, is gpio_keys supported (or will it be) by the gpio driver?

[olimex]

linux-sunxi have no working kernel yet
the Debian image we make is based on Allwinner's kernel which is in A20-SDK you can load it from the wiki link

[XFer]

Thanks Ruler for the excellent work!

A question to everyone who played with GPIO on the A20: are GPIO pins connected to some irq line?

I mean: it would be great if, instead of continuosly checking the status of a given GPIO Input pin (say to read the position of a on/off switch), that pin could trigger an irq that could start a routine.
IRQ-driven instead of polling, that is: like in Arduino. :-)

With Debian image Release2 and kernel 3.3, it looks like we can only use GPIOs via the sysfs; right, or am I missing something?

Thanks!

Fernando

[sanzoghenzo]

Thanks Ruler for the excellent work!

A question to everyone who played with GPIO on the A20: are GPIO pins connected to some irq line?

that's the reason why I bought this board! I'm not good at kernel driver development, so my board sits in my closet until something magic happens
I saw that GPIO driver at linux-sunxi, also used in cubieboardhas irq map for a10 and a13. just a matter of adding irq enabled pins in there? If only we could have a good documentation of A20...

It seems to me like an open hardware driven by a black box! Hope it will change soon!

[XFer]

No replies?
Nobody thinks that switches, buttons etc. should raise an IRQ to get attention?
Should we stick to polling only?

On a related argument: what is the actual meaning of the [GPIO_xxx] sections of the script.fex?

I mean: on the GPIO Map kindly posted by Ruler, we see that, for example, GPIO26 corresponds to Pin36 of LCD connector (aka GPIO_1 connector).

But in the [gpio_para] section of the script.fex, we have:

gpio_pin_26 = port:PC23<0><default><default><default>

which looks like completely unrelated to the said map.

Moreover, in the script.fex only GPIO1 to GPIO76 are included; despite that, I'm currently using GPIO 167 and 169 to drive LEDs, and they work (at least with kernel 3.3-CB2).

Can anyone shed some light upon the matter? 

Thanks!

Fernando