1 2 Previous Next 16 Replies Latest reply on Mar 13, 2017 4:29 PM by rdrdrd

    MRAA and Ubuntu 16.04.1 LTS



      I was able to update my BIOS, install Ubuntu 16.04.1 LTS, and install MRAA from (github.com/intel-iot-devkit/mraa).  However, I am unable to initialize the GPIOs and PWM signals on the Intel Joule 570X Development Board.  Below are my system details and troubleshooting notes.  Can someone help guide me with resolving this IO issue?


      I am unable to get MRAA to work on Ubuntu 16.04.1 LTS

      System Setup

      - Intel Joule 570X Development Kit

      - Operating System:

      $ uname -a

      Linux JOULE 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

      $ lsb_release -a

      No LSB modules are available.

      Distributor ID: Ubuntu

      Description: Ubuntu 16.04.1 LTS

      Release: 16.04

      Codename: xenial

      - MRAA:

      $ mraa-gpio version
      Version v1.5.1 on Intel GT Tuchuck

      - List of GPIO Pin Mapping can be found at



      Reproducing the Issue

      1) Attempt to Update LED via Terminal, MRAA:

      $ mraa-gpio set 100 1

      Could not initialize gpio 100


      2) Attempt to Update LED via Terminal, GPIO direct:

      $ ls /sys/class/gpio/

      export gpiochip284 gpiochip357 unexport

      gpiochip264 gpiochip315 gpiochip429

      $ sudo echo "100" > /sys/class/gpio/export

      bash: /sys/class/gpio/export: Permission denied


      3) Compile and Run C++ Example:


      Arguments: Pin 100

      Program Response:

      terminate called after throwing an instance of 'std::invalid_argument'

      what(): Invalid GPIO pin specified

        • 1. Re: MRAA and Ubuntu 16.04.1 LTS
          Intel Corporation
          This message was posted on behalf of Intel Corporation

          Hello Romanator,

          Thanks for reaching out!

          Ubuntu on Joule is still on beta phase, therefore, there hasn't been much tests with mraa+Ubuntu. 

          My best suggestion is that you contact Ubuntu directly (https://developer.ubuntu.com/en/snappy/start/intel-joule/), they might be able to provide you a more accurate response.

          I hope this helps.

          • 2. Re: MRAA and Ubuntu 16.04.1 LTS


            Regarding issue #1 above:


            I have the same Ubuntu setup as you listed above, and the following works on my board:


            sudo mraa-gpio set 101 1                turn led on

            sudo mraa-gpio set 101 0           turn led off



            Note: LED pin 100 also works on my board


            Regarding issue #2:


            My output is different then your output for the command "ls /sys/class/gpio/"



            Joule:~$ ls /sys/class/gpio/

            export   gpio393  gpio415  gpio486      gpiochip315  unexport

            gpio337  gpio397  gpio421  gpiochip264  gpiochip357

            gpio338  gpio411  gpio446  gpiochip284  gpiochip429


            Regarding Issue #3:

            This code appears to work:


            "for testing pin - 100, or any pin"


               if(mraa_pin_mode_test(100, MRAA_PIN_VALID  ) == 0)
                    qDebug() << "MRAA_PIN_VALID Error.\n";
                    isValidPin = false;


                if(mraa_pin_mode_test(100, MRAA_PIN_GPIO ) == 0)
                    qDebug() << "MRAA_PIN_GPIO Error.\n";
                    isGpio = false;


                if(mraa_pin_mode_test(100, MRAA_PIN_GPIO ) == 0)
                    qDebug() << "MRAA_PIN_GPIO - slow.\n";
                    isFast = false;


            For Controlling output pin:

            mraa::Gpio* myGpioPtr;


            myGpioPtr = new mraa::Gpio(100);




            delete myGpioPtr;



            I would have also appreciated/expected a little more insight and help from Intel, with all of their support and expertise, and I am a little surprised at the simple response. They should have Ubuntu running on one of their systems by now. Linux Ostro is limited compared to Ubuntu. And Ubuntu Core Snappy sounds like it has some great potential.


            I do appreciate the majority of the integration of the Intel Joule and associated technology.

            1 of 1 people found this helpful
            • 3. Re: MRAA and Ubuntu 16.04.1 LTS

              Thanks floydg,

              Your response was really helpful because it verifies that MRAA is compatible on the Joule using the Ubuntu OS.  I'm wondering how different our installation processes were and why your "ls /sys/class/gpio/" is different.  Could you possibly help me by answering these questions or providing additional insight?


              1. What formal process did you take to install MRAA?

              Did you perform the install like described in (https://github.com/intel-iot-devkit/mraa)?

              sudo add-apt-repository ppa:mraa/mraa

              sudo apt-get update

              sudo apt-get install libmraa1 libmraa-dev mraa-tools python-mraa python3-mraa


              2. Did you do a special recompile of the Ubuntu kernel during your system installation/setup?


              3. What formal process did you take to install Ubuntu 16.04.1 LTS?

              Did you perform the install like described in (https://communities.intel.com/thread/106120)?

              • 4. Re: MRAA and Ubuntu 16.04.1 LTS

                Regarding 3 questions above (Nov 28, 2016 4:34 PM )

                1) yes

                2) no

                3) yes

                1 of 1 people found this helpful
                • 5. Re: MRAA and Ubuntu 16.04.1 LTS

                  There are now several procedures to install Ubuntu on the referenced thread (Installing Ubuntu on Intel Joule 570x ), including the beta from Canonical.   You also made some posts there on your process, which was more or less a regular install but with a workaround for creating the installable media manually, so I assume that is what you are doing?

                  1 of 1 people found this helpful
                  • 6. Re: MRAA and Ubuntu 16.04.1 LTS

                    Hi guys,


                    I have similar setup of Joule with Ubuntu Xenial and mraa. As floydg reported, sudo mraa-gpio works while mraa-gpio does not. I can reproduce it with python, where "sudo python" does not give any error while "python" gives me the following;


                    $ python

                    >>>import mraa

                    >>> x = mraa.Gpio(103)

                    Traceback (most recent call last):

                      File "<stdin>", line 1, in <module>

                      File "/usr/lib/python2.7/dis-packages/mraa.py", line 995, in __init__

                        this = _mraa.new_Gpio(pin, owner, raw)

                    ValueError: Invalid GPIO pin specified


                    However, this error message is misleading since journalctl -f suggests it is a matter of writing permission;


                    .... libmraa[4034]: imraa: gpio340: init: Failed to open'export' for writing: Permission denied


                    This does not happen if you start python by sudo.


                    mraa gpio 100 to 103 appear to correspond to gpio337 to 340 for ubuntu. Changing ownership of these pins might solve this problem, but I am not sure if that is a right approach. Besides, permission is a general cause of problem with mraa and I had similar experience with node.js.

                    1 of 1 people found this helpful
                    • 7. Re: MRAA and Ubuntu 16.04.1 LTS

                      It looks like the GPIOs get exported as root and then you need root permissions to access them.

                      What needs to be done here is set up "groups" to access certain pins and then add the user to that group so they have permissions.

                      This however can't be done statically since the files in question get created at runtime when the GPIOs are exported.


                      (removed previous comments about pinctrl... may not be what we want)


                      Might be fixable using an approach like the following, which basically monitors the GPIOs and puts them in the right group when they get exported:

                      Fixing GPIO user permission errors


                      Alternatively you could write a script (that you run using sudo) to export the pins you want and put them in a suitable group.   Then later a user in that group will be able to access them.   You could set things up as well so this script runs at boot.

                      1 of 1 people found this helpful
                      • 8. Re: MRAA and Ubuntu 16.04.1 LTS

                        I've been googling around and this (non-root access to GPIOs) seems to be a general issue with embedded Linux devices.

                        The problem is not specific to the Joule, and there does not seem to be a solution that satisfies everyone (eg people building prototypes will not be as sensitive to security as people building products).


                        That said, if someone can come up with a good udev rule that assigns a group to GPIOs as they are exported, I think that would be a reasonable solution for people doing prototyping, although not for the most security or safety conscious.   An alternative and arguably "better" approach would be to write scripts or programs that do specific actions with GPIOs and can only access specific GPIOs in certain ways, and then setuid them.  Then you protect not only the specific GPIOs, but how they are used, and it still beats writing a driver.

                        1 of 1 people found this helpful
                        • 9. Re: MRAA and Ubuntu 16.04.1 LTS

                          I found a partial solution using udev.   You basically follow the instructions on the following page:

                          Fixing GPIO user permission errors

                          except when you set up the udev rule, use the path "/sys/devices/platform/INT34D1:*/gpio" rather than "/sys/devices/soc.0/*pinctrl/gpio".

                          This works, but has one issue: the first time you export a GPIO, you won't get permissions to actually use it until udev runs and updates the perms.

                          So you have to wait a bit after exporting your GPIOs.

                          What this means with mraa-gpio is that the first "mraa-gpio set" will not work (since it exports the GPIO and then immediately tries to use it) but a second one a second later will, as well as any later uses of that GPIO.


                          Not perfect, but perfectly fine IMO if you structure your programs to export all your GPIOs first, sleep for a second, and then proceed.

                          I'm also not totally sure about the path above, the "INT34D1" device was the one that showed up when I tried to access the on-board LEDs for testing.

                          Other GPIOs may have different paths.   If it fails, take a look at where the exported GPIOs in /sys/class/gpio point and update the rule as necessary.


                          You can also easily modify this rule to set different groups for different GPIOs.


                          If you really don't like the "wait until udev runs" then instead of using a udev rule, you could create a setuid script that does the same thing (fixing up the permissions under devices/platform).

                          However, mraa-gpio still won't work quite right unless you update it to invoke that script after it first exports a GPIO.

                          1 of 1 people found this helpful
                          • 10. Re: MRAA and Ubuntu 16.04.1 LTS

                            I thought I would document the procedure in more detail here rather than relying on the external link.  A similar procedure is also documented here.  Note that this is ONLY for GPIOs.  Something similar could probably be done for I2C (and mraa-i2c) and SPI but I haven't gotten that far.


                            First, create a group and add the user that needs access to the GPIOs to it (this is for the current user; replace $USER with an explicit username if you want).

                            sudo groupadd gpio 
                            sudo usermod -a -G gpio $USER

                            Second, add the following lines to /etc/rc.local (you will have to edit it as root, using sudo vi or whatever).

                            chown -R root:gpio /sys/class/gpio 
                            chmod -R ug+rw /sys/class/gpio

                            Third, create a new udev rule in a file, say /etc/udev/rules.d/80-gpio-noroot.rules (you will have to edit it as root again):

                            # /etc/udev/rules.d/80-gpio-noroot.rules 
                            # Corrects sys GPIO permissions on the Joule so non-root users in the gpio group can manipulate bits
                            # Change group to gpio
                            SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chown -R root:gpio /sys/devices/platform/INT34D1:*/gpio'"
                            # Change user permissions to ensure user and group have read/write permissions
                            SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chmod -R ug+rw /sys/devices/platform/INT34D1:*/gpio'"

                            Fourth, reboot or restart udev using

                            sudo udevadm trigger --subsystem-match=gpio

                            And finally test:

                            mraa-gpio set 100 0 
                            mraa-gpio set 100 1
                            mraa-gpio set 100 0

                            As already noted, the first call will not do anything but set up the GPIO, but following calls should work.  This turns on the first LED, the other ones are 101, 102, and 103.

                            2 of 2 people found this helpful
                            • 11. Re: MRAA and Ubuntu 16.04.1 LTS

                              I can confirm that the above sequence works via copy-pasta.


                              The only thing which did not completely work is sudo udevadm trigger --subsystem-match=gpio. I would not get permissions errors when running mraa-gpio set 100 0 and mraa-gpio set 100 1, but the LEDs themselves would not toggle until after a reboot.

                              1 of 1 people found this helpful
                              • 12. Re: MRAA and Ubuntu 16.04.1 LTS

                                Huh, let me see if I can figure that out.   Can you double-check the command you entered?   But yes, you can reboot instead and that also starts the udev rule.

                                After you add the rc.local rule you don't get perms errors anymore with "mraa-gpio set", it just doesn't work, but fails silently --- unless the udev rule is also running.

                                • 13. Re: MRAA and Ubuntu 16.04.1 LTS

                                  I copy-pasted the commands, double-checking the order and the content. Honestly, it's so easy and well documented it would be hard to have missed one!


                                  I had tried running the `udevadm` command a second time, but no joy. I tried each command several times, as per the limitation outlined in the instructions, but no joy there either. I confirm that I could still set/unset the bits with `sudo`, so it seems to be isolated to `udevadm` not performing what we think it should have.

                                  • 14. Re: MRAA and Ubuntu 16.04.1 LTS

                                    kubark42, I was not able to reproduce your issue.   I turned off my udev rule (by commenting out lines in the rules file and rebooting) and confirmed the problem was back (so mraa-gpio set only worked with sudo).  However, by uncommenting the appropriate lines in the rules file then using the udevadm command noted above, mraa-gpio started working without sudo, as expected.


                                    So... I don't know what's going on with your system (or was; I assume that after a reboot it is working for you).   But if someone else can reproduce the issue that would be good.  I may have installed something or upgraded a package or set some permissions on a directory somewhere so my system is in not quite the same state as yours.

                                    1 2 Previous Next