37 Replies Latest reply on Oct 4, 2014 3:45 AM by medosoft

    GPIO Ports on RIoT Board

    1337
    1337 Mar 21, 2014 2:17 AM

      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

        • Re: GPIO Ports on RIoT Board
          agrahambell Mar 21, 2014 4:43 AM (in response to 1337)

          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.

          1 of 1 people found this helpful
            • Re: GPIO Ports on RIoT Board
              1337
              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
                      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): 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.

                    • Re: GPIO Ports on RIoT Board
                      tushar panda
                      tushar panda Mar 21, 2014 5:51 AM (in response to 1337)

                      @david

                       

                      there are two user defined leds in riotboard (D45 and D46) as mentioned in pg39 of rioboard manual.

                      riot_leds.png

                      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

                      1 of 1 people found this helpful