-
Re: GPIO Ports on RIoT Board
agrahambell Mar 21, 2014 4:43 AM (in response to 1337)1 of 1 people found this helpfulWhat '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.
-
Re: GPIO Ports on RIoT Board
1337 Mar 21, 2014 7:33 AM (in response to agrahambell)Thanks for the information.
112 is not working so I have to check the linux kernel...
-
Re: GPIO Ports on RIoT Board
agrahambell Mar 21, 2014 8:10 AM (in response to 1337)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
-
Re: GPIO Ports on RIoT Board
1337 Mar 21, 2014 8:18 AM (in response to agrahambell)I'm using the linux image from the riotboard team:
Linux linaro-ubuntu-desktop 3.0.35-02871-ga35ffe3 #1 SMP PREEMPT Wed Oct 30 15:27:47 CST 2013 armv7l armv7l armv7l GNU/Linux
So you think it would be a good idea to upgrade to kernel 3.12+?
And try again?
-
Re: GPIO Ports on RIoT Board
agrahambell Mar 21, 2014 9:21 AM (in response to 1337)It's not currently clear that going to 3.12+ is a good idea.
e14 are only supporting your 3.0.35 kernel for now and there's no signs of that changing yet. Freescale, who manufacture the SoC, have finally moved on from 3.0.35 to 3.10.x, so perhaps e14 will follow, perhaps not. e14 seem to be targetting RIoT exclusively at Android, so exactly how high Linux is on the list of priorities for them we can only guess.
There's curently no support for RIoT in the mainstream linux kernels, although there is good support for other i.MX6 based boards which means most on-chip stuff will work.
Pablo posted a devicetree and kernel config needed to run 3.13.5 in this thread http://www.element14.com/community/thread/31675?start=15&tstart=0
For now, using anything more recent than 3.0.35 is something you need to do yourself. Keep in mind that the usual caveat with Arm SBCs and mainline linux is that support for their GPUs tends to be mostly non-existent. It's looking like the i.MX6 may be one of the first to reach useability in this area though. You'll want to look at etna_viv drivers here https://github.com/laanwj/etna_viv
-
-
-
Re: GPIO Ports on RIoT Board
agrahambell Mar 21, 2014 11:51 AM (in response to 1337)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
p319
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): 0x0My 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): 0x0or 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): 0x107FE0If 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.
-
Re: GPIO Ports on RIoT Board
1337 Mar 24, 2014 5:22 AM (in response to agrahambell)Thanks again.
Ich have done what you have written. Can you help me please interpret the results?
root@linaro-ubuntu-desktop:~/tmp# ./devmem2 0x20e0470 w /dev/mem opened. Memory mapped at address 0x2abdb000. Value at address 0x20E0470 (0x2abdb470): 0x8028 root@linaro-ubuntu-desktop:~/tmp# ./devmem2 0x20e015c w /dev/mem opened. Memory mapped at address 0x2ad18000. Value at address 0x20E015C (0x2ad1815c): 0x5 root@linaro-ubuntu-desktop:~/tmp# ./devmem2 0x20a8004 w /dev/mem opened. Memory mapped at address 0x2ac64000. Value at address 0x20A8004 (0x2ac64004): 0x200 root@linaro-ubuntu-desktop:~/tmp# ./devmem2 0x20a8008 w /dev/mem opened. Memory mapped at address 0x2ab9a000. Value at address 0x20A8008 (0x2ab9a008): 0x7C20
-
Re: GPIO Ports on RIoT Board
bbe@heise.de Mar 24, 2014 6:07 AM (in response to 1337)Hi,
I get the same values here. I would read them as:
0x20e0470 = 0x8028:
Drive Strength is 48 Ohm (Bit 5:3 = 101)
100 K Pullup is enabled (Bit 15:14 = 10)
0x20E015C = 0x5
GPIO4_16 the MUX-MODE is correct (ALT5) (Bit 2:0 = 101)
So everything seems correct until here.
0x20a8004= 0x200
GPIO4_16 is configured as an input (Bit 15 = 0)
0x20a8008= 0x7C20
Input value is read as 0 (Bit 15 = 0)
I can even set the Pin as output by writing to /sys/class/export, /sys/class/gpio112/direction and /sys/class/gpio112/value but I don't the LED connected between PIN 4 and 5 of J13 to blink
Regards Benjamin
-
Re: GPIO Ports on RIoT Board
agrahambell Mar 25, 2014 10:21 AM (in response to bbe@heise.de)Benjamin Benz wrote:
0x20a8004= 0x200
GPIO4_16 is configured as an input (Bit 15 = 0)
I suspect that gpio4_16 will actually be bit 16 since the gpio's are generally numbered 0-31, but even so that doesn't really change anything.
-
Re: GPIO Ports on RIoT Board
phrateus Mar 27, 2014 4:53 AM (in response to bbe@heise.de)Hi !
In fact, Riot board have an IMX6S and not Q (single core and not quad core).
Get the IMX6SDLRM here : i.MX6S: i.MX 6Solo Family of Applications Processors (click on "Reference Manuals")
If you search "IOMUXC_SW_MUX_CTL_PAD_DI0_DISP_CLK", you get the correct address : 20E009C. I've tried it, it works on my riot board
I found this mistake this morning, IMX6 address are not intercompatible.
Hope it can help you,
Benjamin.
-
Re: GPIO Ports on RIoT Board
1337 Mar 27, 2014 6:02 AM (in response to phrateus)Which gpio do you now use for the /sys/class/export ??
-
Re: GPIO Ports on RIoT Board
phrateus Mar 27, 2014 6:15 AM (in response to 1337)Sorry, I was a little hurry this morning.
I use GPIO4_IO16 (the 5th pin on the schematic, the one down GND on the card).
Firtly, I put 0x5 (or 0x15, both works for me, I don't now what exactly do the SION param) at 0x20E009C instead of 0x0. Puting 5 make the mux on ALT5 mode, so selected signal is GPIO4_IO16 and not display clock signal.
Then, I configure this GPIO by :
cd /sys/class/gpio
echo 112 > export
cd gpio112
echo out > direction
And now, you can control state with :
echo 1 > value (high state, more or less 3.3V)
echo 0 > value (low state, more or less 0V)
Next step for me is using serial port
-
Re: GPIO Ports on RIoT Board
1337 Mar 27, 2014 6:44 AM (in response to phrateus)Thanks ! :-)
It is working
-
Re: GPIO Ports on RIoT Board
agrahambell Mar 27, 2014 9:00 AM (in response to 1337)Good to see you've got it working..
I think however that we shouldn't need to mess around with devmem2 to get this to work, if the kernel exposes these via /sys/class/gpio then they should be setup to work correctly. If not then I feel that's a bug in the kernel - either what's exposed should work, or it shouldn't be exposed at all.
Unfortunately it ends up being a side effect of Linux being a low priority for the manufacturer and the board essentially being un-supported in the mainline versions of kernel and/or u-boot - bugs stick.
I'd be interested to know if you ever do decide to try a recent 3.12/13 kernel do these same issues exist there ?
-
Re: GPIO Ports on RIoT Board
1337 Mar 27, 2014 9:27 AM (in response to agrahambell)Hi, maybe in the next week I try a newer kernel. Is there any preconfigured linux image? Or did I make it on my own?
-
Re: GPIO Ports on RIoT Board
agrahambell Mar 27, 2014 9:46 AM (in response to 1337)I haven't seen any images with newer kernels. Probably you need to make your own
-
-
-
Re: GPIO Ports on RIoT Board
agrahambell Apr 1, 2014 4:09 AM (in response to 1337)I just wanted to add that I've got the 3.14 kernel running on a RIoTboard and the gpios just work as expected. No messing with devmem2 required, simply export pin 112 and away you go.
I'll leave to your imagination what I think of ancient vendor kernels
-
Re: GPIO Ports on RIoT Board
1337 Apr 1, 2014 4:27 AM (in response to agrahambell)Hi,
thanks for sharing this information.
How have you created the image with the newer kernel?
-
Re: GPIO Ports on RIoT Board
agrahambell Apr 1, 2014 5:22 AM (in response to 1337)http://www.element14.com/community/message/107809/l/re-how-can-i-flash-using-linux#107809
add to that a generic armhf filesystem that I use on Sabre-Lite, Wandboard, BeagleBone Black, A20-OLinuXino, that I built using http://www.linuxfromscratch.org/ although there's no particular reason you can't use something like Robert Nelsons minimal Debian image from http://eewiki.net/display/linuxonarm/A10-OLinuXino-LIME#A10-OLinuXino-LIME-RootFileSystem
You should be aware that with a mainline kernel you're probably not getting HDMI at this time and there are still some things to work out - for example I'm having trouble getting the sgtl5000 audio driver to load at the moment and I need to work out how to configure the PMIC properly. This stuff is expected at this stage though as there's no proper support for the board in either mainline u-Boot or the kernel as yet
-
-
-
-
-
-
Re: GPIO Ports on RIoT Board
bbe@heise.de Mar 27, 2014 6:15 AM (in response to phrateus)My Riotboard reads
0x20E009C = 0x0
which would according to IMX6SDLRM.pdf translate to Muxmode = Alt0 , which would mean, that we have to change Muxmode to Alt5 (0x5) in order to get gpio4_16 to work.
The following worked for me:
devmem2 0x20E009C w 0x5
echo 112 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio112/direction
echo 1 > /sys/class/gpio/gpio112/value
echo 0 > /sys/class/gpio/gpio112/value
Best regards Benjamin
-
Re: GPIO Ports on RIoT Board
florisvd Sep 16, 2014 8:55 AM (in response to bbe@heise.de)Hello,
How to get devmem2 working?
It is not standard in an Android image, is it?
I tried to build it in ubuntu, and get the object file to android.
But it doesn't work.
-
Re: GPIO Ports on RIoT Board
tushar panda Sep 16, 2014 4:57 PM (in response to florisvd)How to get devmem2 working?
the source code here: www.lartmaker.nl/lartware/port/devmem2.c
cc devmem2.c -o devmem2
it works in linux.
-
Re: GPIO Ports on RIoT Board
florisvd Sep 17, 2014 1:01 AM (in response to tushar panda)I am using android on the Riotboard.
And at first I compiled it on Ubuntu in this way:
Gcc -Wall devmem2.c -o devmem2
And after that, I exported it to the android environment and tried to write some data at an address via the command line (serial port) of the riot board.
Should it work with cc?
-
Re: GPIO Ports on RIoT Board
florisvd Sep 19, 2014 8:53 AM (in response to tushar panda)Hello,
Do you know a solution for me?
I keep getting that error message.
I compiled it with the gcc compiler, and exported it as .o file to android and try to run is from the folder /sdcard
Best regards
-
Re: GPIO Ports on RIoT Board
radiatortwo Sep 19, 2014 9:23 AM (in response to florisvd)Which gcc compiler do you use?
As far as I know you have to compile with an arm cross compiler like "
arm-linux-gnueabi-gcc".
And then compile like this:arm-linux-gnueabi-gcc -static -march=armv7 devmem2.c -o devmem2
If you only use gcc I think you compiled for x86 not for arm.
-
Re: GPIO Ports on RIoT Board
tushar panda Sep 20, 2014 6:53 AM (in response to florisvd)as mentioned above, you might be using gcc build for PC not the cross compiler one.
can you show the output for below ??
# file devmem2
-
Re: GPIO Ports on RIoT Board
florisvd Sep 22, 2014 2:56 AM (in response to tushar panda)I tried compiling the devmem2.c with ubuntu gcc, androideabi 4.7 gcc and gnueabi gcc.
But with every output file, I get the same result; the error of above.
Any other recommendation to try?
-
Re: GPIO Ports on RIoT Board
tushar panda Sep 23, 2014 11:14 AM (in response to florisvd)I have used devmem in linux only.
check if you can use this https://github.com/kylemanna/pydevmem/blob/master/devmem.py to customise for imx6 platform.
-
-
Re: GPIO Ports on RIoT Board
florisvd Sep 22, 2014 9:27 AM (in response to tushar panda)Could you perhaps post the output file devmem2 when it works on your riotboard in Android?
-
Re: GPIO Ports on RIoT Board
tushar panda Sep 23, 2014 11:18 AM (in response to florisvd)i have not used devmem on android but will try
with the above python code in near future .
above script possible with qpython, no idea if qpython permits such core level access.
-
-
-
-
-
Re: GPIO Ports on RIoT Board
tushar panda Sep 16, 2014 5:04 PM (in response to florisvd)I tried to build it in ubuntu, and get the object file to android.
But it doesn't work.
can you show what you have tried.
have you checked on android NDK support, it helps to bind c library to apk.
-
Re: GPIO Ports on RIoT Board
florisvd Sep 17, 2014 7:52 AM (in response to tushar panda)See my last post.
-
screenshot.jpg 61.2 KB
-
-
Re: GPIO Ports on RIoT Board
florisvd Sep 17, 2014 7:51 AM (in response to tushar panda)When I try to use devmem2 in this way:
su ./devmem2 0x480033f0 b 0x2
I get the error:
su:exec failed for 0x480033f0 Error:No such file or directory
But this should be an adress and no file or directory, so why is that error?
-
screenshot.jpg 61.2 KB
-
-
-
-
Re: GPIO Ports on RIoT Board
medosoft Oct 4, 2014 3:45 AM (in response to bbe@heise.de)I tried your solution and it works perfectly.
Now I am trying to use the same port as an input port instead of output.
My first instinct was to change the direction to in instead of out, I dont know whether this is correct or not.
echo in > /sys/class/gpio/gpio112/direction but then I do not know how to read the values from that port.
Could you tell me how to modify the code in order to do this?
Thanks
-
-
Re: GPIO Ports on RIoT Board
agrahambell Mar 27, 2014 9:06 AM (in response to phrateus)Benjamin ADAM wrote:
In fact, Riot board have an IMX6S and not Q (single core and not quad core).
Get the IMX6SDLRM here : i.MX6S: i.MX 6Solo Family of Applications Processors (click on "Reference Manuals")
If you search "IOMUXC_SW_MUX_CTL_PAD_DI0_DISP_CLK", you get the correct address : 20E009C. I've tried it, it works on my riot board
I found this mistake this morning, IMX6 address are not intercompatible.
That's somewhat unfortunate, and I apologise for the mistake - entirely my fault. As I only have boards with quad core i.MX6, that's the only way I can test. Not an excuse, but the reason why I was using the doc for the quad.
I still hope that the method for tracing things through the docs is helpful though, just use the correct doc
-
-
-
-
-
-
-
Re: GPIO Ports on RIoT Board
tushar panda Mar 21, 2014 5:51 AM (in response to 1337)1 of 1 people found this helpful@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
-
Re: GPIO Ports on RIoT Board
1337 Mar 21, 2014 7:33 AM (in response to tushar panda)This is also working for me.
Have you tried the gpio ports on your board?
-
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