Hello,
have anyone tried here to get the gpio ports working?
I'm using the linux image and have tried it with:
echo "0" > /sys/class/gpio/export
etc.
But I don't get the correct mapping.
Which are the correct gpio numbers for the port on the board?
Or did I miss something?
Any ideas?
Thanks in advantage.
Best regards,
David
What 'correct mapping' were you expecting ?
The SoC itself has many more gpios than are presented on the expansion port. So there's a physical pin on expansion port to physical pin on SoC mapping which you can work out by looking at the schematics. There's then a 'logical block' to physical pin mapping which may be alterable using something normally described within the kernel as pinmux.
For example, when I look at the contents of /sys/class/gpio on my Sabre-Lite (uses the quad-core version of the SoC on the RIoT) I see the following
# ls /sys/class/gpio export gpiochip128@ gpiochip192@ gpiochip64@ unexport gpiochip0@ gpiochip160@ gpiochip32@ gpiochip96@
Each of these gpiochip<n> directories comprises 32 gpios in their respective 'logical block' for a total of 224 gpios.. While the Sabre-Lite only has perhaps 10 to 20 on several different headers, the RIoT having just 35 on J13. So you need to use the schematics and the SoC datasheet to create the mapping.
There's nothing unusual in this, all of the SoC's on the many SBC's do something very similar as they have more functions than available pins. This idea allows you to chose what to use
Anyway, as a simplistic example, if you look at the table on p31 of the user manual, J13 pin 5 maps to a signal called GPIO4_16. You can see the same on p19 of the schematics. Follow the schematics back to page 7 and you'll see the signal labeled GPIO4_16 goes to DIO_DISP_CLK on ball N19.
Look in the IMX6DQRM.pdf (find it here http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp=1&tab=Documentation_Tab ) on page 233 you'll find this:
ALT0, ALT1, ALT5 are the 'pinmux' settings. In other words, that physical pin can be configured for three totally different functions. Meaning that if the physical pin is configured as IPU1_DIO_PIN03 then it won't matter what you do in /sys/class/gpio - you won't see it reflected in the state of the physical pin.
Dig a bit deeper in the datasheet and you'll see there are 'logical blocks' of gpios - starting at the bottom half of the table on p316 and that they're described as GPIO1 to GPIO7, all apart from 7 having _IO00 to _IO31.
So looking at the contents of /sys/class/gpio, the logical assumption is that gpiochip0 maps to GPIO1, gpiochip32 to GPIO2, etc. Take careful note that the datasheet starts at 1 with GPIO1_ but the kernel numbering starts at zero with gpiochip0. This off-by-one thing is apt to cause confusion, some boards like the BeagleBone black have used one convention for a certain kernel release then changed to the opposite for a later kernel - meaning that when you export gpio 23 on the later kernel you get a totally different pin.
So, the example of gpio4_16 means we look at the 17th pin in gpiochip96 (why 17? numbering starts at zero remember), i.e. gpio4_0 is 96, gpio4_1 is 97 and gpio4_16 is 112 so you'd need to write 112 to /sys/class/gpio/export.
Now while that's the logical way to map things, it may not be how it's been done. You'd have to look at the kernel source code to be sure and to know if the pinmux has been configured to put gpio4_16 onto that physical pin or not.
Apologies if the explanation seems a bit long, however understanding how it works will be useful for other boards you might buy and it'll be useful for others reading this too.
@david
there are two user defined leds in riotboard (D45 and D46) as mentioned in pg39 of rioboard manual.
the gpio leds are exported to /sys/class/leds
to control leds use below:
ON/OFF D45:
echo 1 > /sys/class/leds/user_led/brightness
echo 0 > /sys/class/leds/user_led/brightness
ON/OFF D46:
echo 1 > /sys/class/leds/sys_led/brightness
echo 0 > /sys/class/leds/sys_led/brightness
Regards
Tushar
Which kernel you're using probably has a large influence. The steps I followed generally works ok on later kernels - I'm using 3.12 or 3.13 on sabre-lite and wandboard, but the older 3.0.35 kernels do things differently as they don't use devicetree.
This might be a starting point https://github.com/embest-tech/linux-imx/blob/embest_imx_3.0.35_4.1.0/arch/arm/mach-mx6/devices.c which makes it look like it works as I described. However, it may be that the default pinmux mode for that physical pin is something other than the gpio.
I'm not 100% sure, but I don't see anywhere that sets the pinmux modes for that particular pin in linux, so either it's left at the power-on reset default, or perhaps u-boot configures it.
Later kernels make finding this stuff much easier as it all tends to be in the devicetree file rather than hunting for a needle in a haystack 
Some ideas on how to dig deeper. Lets continue using GPIO4_16 as the example.
If you don't already have it, download devmem2 from here http://www.lartmaker.nl/lartware/port/devmem2.c
build it:
gcc -o devmem2 devmem2.c
From the ref manual p233
<html><head><title>Jive SBS</title></head>
<body><font face="arial,helvetica,sans-serif">
<b>Error</b><br><font size="-1">
An general error occurred while processing your request.
</font></font></body></html>
p319
<html><head><title>Jive SBS</title></head>
<body><font face="arial,helvetica,sans-serif">
<b>Error</b><br><font size="-1">
An general error occurred while processing your request.
</font></font></body></html>
the last column of the above two tables gives us the registers that control that physical pin.
Following through the docs, we get the base address and reset value:
make sure you are logged in as root, or use su or sudo. and do the following
root@sl3:~# ./devmem2 0x20e0470 w
/dev/mem opened.
Memory mapped at address 0xb6f40000.
Value at address 0x20E0470 (0xb6f40470): 0x10
root@sl3:~# ./devmem2 0x20e015c w
/dev/mem opened.
Memory mapped at address 0xb6f22000.
Value at address 0x20E015C (0xb6f2215c): 0x0
My results on a Sabre-Lite show the pin isn't at defaults, it's configured as ALT0 instead of the reset default of ALT5
we can then look at the gpio registers themselves: (section 28.4 p1378)
root@sl3:~# ./devmem2 0x20a8004 w
/dev/mem opened.
Memory mapped at address 0xb6fd6000.
Value at address 0x20A8004 (0xb6fd6004): 0x0
or all inputs for me:
finally read any data:
root@sl3:~# ./devmem2 0x20a8008 w
/dev/mem opened.
Memory mapped at address 0xb6f8b000.
Value at address 0x20A8008 (0xb6f8b008): 0x107FE0
If you're somewhat careful you can use devmem2 to circumvent the kernels gpio driver and examine how the hardware is configured, and possibly even change the state of various pins.
While doing that, remember that there's a kernel driver that owns these resources and it may well change the values behind your back.
A good example of this is where you're looking at one of the LED pins that tusharp mentioned - if that led is configured for heartbeat then the driver will be accessing the same registers to make the led flash and coud easily overwrite whatever you're trying to do in the same set of registers..
Ideally you'd want to either disable the gpio driver altogether or at least exclude one block of 32 pins from what the driver knows about. Unfortunately due to the extensive use of gpios and the grouping into 32 bit blocks, excluding a block will probably mean some other peripherals stop functioning as well.
