UP Board 4.4 Linux Kernel for Ubuntu 16.04 and 14.04 is now available
DCleri
Administrator, AAEON Posts: 1,213 admin
New Ubuntu 14.04 and Ubuntu 16.04 4.4 Kernel packages for the UP...
[article]52[/article]
[article]52[/article]
Comments
-
Thanks,
So I installed on 16.04 following the instructions. Was wondering if there is something else I need to do to access the GPIO pins from Ubuntu.kurt@kurt-UP-CHT01:~$ uname -a Linux kurt-UP-CHT01 4.4.0-1-upboard #10-Ubuntu SMP Fri Sep 23 12:26:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux kurt@kurt-UP-CHT01:~$ echo 26 > /sys/class/gpio/export -bash: /sys/class/gpio/export: Permission denied kurt@kurt-UP-CHT01:~$ sudo echo 26 > /sys/class/gpio/export -bash: /sys/class/gpio/export: Permission denied kurt@kurt-UP-CHT01:~$ ls /sys/class/gpio export gpiochip0 gpiochip318 gpiochip373 gpiochip397 gpiochip456 unexp
Thanks -
Hi Kurt
You can access the 28 GPIO pins on the 40-pin HAT I/O header via gpiochip0.
You'll find the corresponding Linux GPIO numbers for each of the pins in a column in the table on this page:
https://up-community.org/wiki/Pinout
If you want to use a Python library to access the GPIO/I2C/SPI/UART/PWM functions on those pins, I recommend libMRAA. There are instructions for installing it for Ubuntu on this page: https://github.com/intel-iot-devkit/mraa
And some examples for using it on UP here: https://up-community.org/wiki/MRAA/UPM
Enjoy! :-) -
Thanks Dan,
Note: from the wiki pinout page, I was following the first example:echo 26 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio26/direction echo 1 > /sys/class/gpio/gpio26/value
Which fails as Permission Denied on the first echo which should have made the pin available. So I think something is wrong.
I am a C/C++ type guy but will try MRAA again. I used it when I was playing with the Edison and I have downloaded my fork which I synced up to the main one of it and have now built it. Will take a look to see maybe it is maybe using memory mapped access instead of file system access?
Maybe I need to see if I can plug in one of my Edisons and see if there is differences, like maybe the owner of the file system. As far as I can tell with UP it looked like root, but sudo did not help.
Edit: pulled out Edison, took awhile to remember that on here was logged in as Root also does not have access control, so things might be different
Will keep trying.
Thanks -
As I mentioned I built my version of MRAA which is in sync with https://github.com/intel-iot-devkit/mraa
I tried running the example: blink-io
And it failed, at least on the default pin 8 as well as pin 26.Are you sure that pin8 you requested is valid on your platform?kurt@kurt-UP-CHT01:~/mraa/build/examples$ ./blink-io 26 MRAA Version: v0.5.1-941-g92fdb8a Starting Blinking on IO26 Are you sure that pin26 you requested is valid on your platform?kurt@kurt-UP-CHT01:~/mraa/build/examples$ cd ../..
Looking at the source of example:mraa_gpio_context gpio; gpio = mraa_gpio_init(iopin); if (gpio == NULL) { fprintf(stderr, "Are you sure that pin%d you requested is valid on your platform?", iopin); exit(1); } printf("Initialised pin%d\n", iopin);So mraa_gpio_init is failing, my guess is for the same reasons I am seeing at command line.
Edit: Here is messages from system log: ( /var/log/syslog)Sep 25 07:10:45 kurt-UP-CHT01 libmraa[1874]: libmraa version v0.5.1-941-g92fdb8a initialised by user 'kurt' with EUID 1000 Sep 25 07:10:45 kurt-UP-CHT01 libmraa[1874]: libmraa initialised for platform 'UP' of type 12 Sep 25 07:10:45 kurt-UP-CHT01 libmraa[1874]: gpio14: init: Failed to open 'export' for writing: Permission denied Sep 25 07:11:22 kurt-UP-CHT01 libmraa[1875]: libmraa version v0.5.1-941-g92fdb8a initialised by user 'kurt' with EUID 1000 Sep 25 07:11:22 kurt-UP-CHT01 libmraa[1875]: libmraa initialised for platform 'UP' of type 12 Sep 25 07:11:22 kurt-UP-CHT01 libmraa[1875]: gpio7: init: Failed to open 'export' for writing: Permission denied
I did a little more playing around as I noticed:kurt@kurt-UP-CHT01:/sys/class/gpio$ ls -l total 0 --w--w--w- 1 root root 4096 Sep 25 08:10 export lrwxrwxrwx 1 root root 0 Sep 25 08:10 gpio26 -> ../../devices/platform/up-pinctrl/gpio/gpio26 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip0 -> ../../devices/platform/up-pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip318 -> ../../devices/platform/INT33FF:03/gpio/gpiochip318 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip373 -> ../../devices/platform/INT33FF:02/gpio/gpiochip373 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip397 -> ../../devices/platform/INT33FF:01/gpio/gpiochip397 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip456 -> ../../devices/platform/INT33FF:00/gpio/gpiochip456 --w------- 1 root root 4096 Sep 25 08:07 unexport
So I tried: chmod 222 export
Then tried echo 26 > export
Which worked
But then tried the next line in the first example which then failed as you can see:
kurt@kurt-UP-CHT01:/sys/class/gpio$ echo 26 > export kurt@kurt-UP-CHT01:/sys/class/gpio$ ls export gpio26 gpiochip0 gpiochip318 gpiochip373 gpiochip397 gpiochip456 unexport kurt@kurt-UP-CHT01:/sys/class/gpio$ echo out > /sys/class/gpio/gpio26/direction -bash: /sys/class/gpio/gpio26/direction: Permission denied kurt@kurt-UP-CHT01:/sys/class/gpio$ ls -l total 0 --w--w--w- 1 root root 4096 Sep 25 08:10 export lrwxrwxrwx 1 root root 0 Sep 25 08:10 gpio26 -> ../../devices/platform/up-pinctrl/gpio/gpio26 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip0 -> ../../devices/platform/up-pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip318 -> ../../devices/platform/INT33FF:03/gpio/gpiochip318 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip373 -> ../../devices/platform/INT33FF:02/gpio/gpiochip373 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip397 -> ../../devices/platform/INT33FF:01/gpio/gpiochip397 lrwxrwxrwx 1 root root 0 Sep 25 08:07 gpiochip456 -> ../../devices/platform/INT33FF:00/gpio/gpiochip456 --w------- 1 root root 4096 Sep 25 08:07 unexport kurt@kurt-UP-CHT01:/sys/class/gpio$ ls -l gpio26/ total 0 -rw-r--r-- 1 root root 4096 Sep 25 08:12 active_low lrwxrwxrwx 1 root root 0 Sep 25 08:12 device -> ../../../up-pinctrl -rw-r--r-- 1 root root 4096 Sep 25 08:11 direction -rw-r--r-- 1 root root 4096 Sep 25 08:12 edge drwxr-xr-x 2 root root 0 Sep 25 08:12 power lrwxrwxrwx 1 root root 0 Sep 25 08:12 subsystem -> ../../../../../class/gpio -rw-r--r-- 1 root root 4096 Sep 25 08:10 uevent -rw-r--r-- 1 root root 4096 Sep 25 08:12 value
Again if I do something like: chmod 666 direction
I can then echo out> direrection
likewise issue with value...
My guess is gpiochip0 is not setting up proper permissions. Or not sure if there is some form of /etc/udev/rules.d (or /lib/udev...) file that can be created for this? -
Quick update: I believe that the setting for only root can export GPIO pins appears to be consistent with at least a few other processors on 16.04 including my Odroid XU4. I am curious to look to see if it was this way on earlier versions like 14.04.
Also appears to be true with at least some version of RPI.
I was able to run the blink c example of MRAA using Sudo.
Would be nice to be able to create some form of udev rules or the like that maybe creates it in a new group like GPIO and then add write access for the group, in much the same way as the UARTS are under DIALUP... But will probably continue this later under a new thead. -
Hi Kurt
Yes, you will need to have root privileges (or use 'sudo') to access the GPIO pins via sysfs.
For ubilinux, we did look at using udev rules to change the permissions of these files in /sys/class/gpio/..., in a similar way to how RPi does it. It can work, but these files get created dynamically after the "export" and there's a small delay before the udev rules get triggered. If you have a script that tries to access the GPIO immediately after the export (and before the udev rule fires), then it still hits this error and we found that this was causing confusion for end users. So, to keep things simple, we left out those udev rules.
No memory-mapped GPIO access available at this point. Everything needs to go through sysfs. See this post for details: https://up-community.org/forum/general-discussion/852-native-c-libraries-to-gpio-pins#2235
-Dan -
Hi Kurt
Yes, you will need to have root privileges (or use 'sudo') to access the GPIO pins via sysfs.
For ubilinux, we did look at using udev rules to change the permissions of these files in /sys/class/gpio/..., in a similar way to how RPi does it. It can work, but these files get created dynamically after the "export" and there's a small delay before the udev rules get triggered. If you have a script that tries to access the GPIO immediately after the export (and before the udev rule fires), then it still hits this error and we found that this was causing confusion for end users. So, to keep things simple, we left out those udev rules.
No memory-mapped GPIO access available at this point. Everything needs to go through sysfs. See this post for details: https://up-community.org/forum/general-discussion/852-native-c-libraries-to-gpio-pins#2235
-Dan -
Thanks Dan,
I took a look through and will do some more experimenting .
I noticed it was stated that the UP is maybe 10 times slower than RPI with GPIO. I wonder how it compares with the Edison...
Will start new thread later. -
Need help here as I'm struggling with UPBOARD! my GPIO especially UART1 is not working still. I cannot install RPI.GPIO also. anything I missed here to get the UART1 (dev/ttyS1) work?
-
Hi
Are you using Ubuntu with the upboard kernel, or ubilinux? Can you run the 'dmesg' command and attach the output? This might give us some clues.
Also, the RPi.GPIO module for UP is only included with ubilinux at this time.
Regards,
-Dan -
hey dan,
I'm having issues with the UART as well I am using Ubuntu with the upboard kernel and i can't get mraa to work. everytime i run my program it gives me the following error:
File "motorController.py", line 8, in <module>
transmitter = mraa.Uart(1)
File "/usr/local/lib/python2.7/dist-packages/mraa.py", line 1181, in __init__
this = _mraa.new_Uart(*args)
ValueError: Error initialising UART
i've tried multiple numbers in mraa.Uart and none work. The Up-board wiki says to use ttyS1 for UART but when i run
dmesg | grep tty i get the following:
[ 0.000000] console [tty0] enabled
[ 1.123350] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 3.555733] 8086228A:00: ttyS4 at MMIO 0xa171b000 (irq = 39, base_baud = 2764800) is a 16550A
ttyS1 isn't showing on here and I don't know if that's the issue or not. and if it is i'm not sure how to enable the port.
also, not sure if this is any help but when i run sudo cat /proc/tty/driver/serial i get the following.
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
1: uart:unknown port:000002F8 irq:3
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:16550A mmio:0xA171B000 irq:39 tx:0 rx:0
5: uart:unknown port:00000000 irq:0
6: uart:unknown port:00000000 irq:0
7: uart:unknown port:00000000 irq:0
8: uart:unknown port:00000000 irq:0
9: uart:unknown port:00000000 irq:0
10: uart:unknown port:00000000 irq:0
11: uart:unknown port:00000000 irq:0
12: uart:unknown port:00000000 irq:0
13: uart:unknown port:00000000 irq:0
14: uart:unknown port:00000000 irq:0
15: uart:unknown port:00000000 irq:0
16: uart:unknown port:00000000 irq:0
17: uart:unknown port:00000000 irq:0
18: uart:unknown port:00000000 irq:0
19: uart:unknown port:00000000 irq:0
20: uart:unknown port:00000000 irq:0
21: uart:unknown port:00000000 irq:0
22: uart:unknown port:00000000 irq:0
23: uart:unknown port:00000000 irq:0
24: uart:unknown port:00000000 irq:0
25: uart:unknown port:00000000 irq:0
26: uart:unknown port:00000000 irq:0
27: uart:unknown port:00000000 irq:0
28: uart:unknown port:00000000 irq:0
29: uart:unknown port:00000000 irq:0
30: uart:unknown port:00000000 irq:0
31: uart:unknown port:00000000 irq:0
I want to be able to communicate to my motor controller through serial but can't find out how it works. Any help will do. Thanks in advance. -
Which OS are you using? I am using, I am using 16.04.
What do you see if you type ls /dev/ttyS*
When I login in to a KiTTy (Putty) window I see:login as: kurt kurt@192.168.2.112's password: Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-1-upboard x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage 0 packages can be updated. 0 updates are security updates. Last login: Fri Oct 14 14:42:08 2016 from 192.168.2.102 kurt@kurt-UP-CHT01:~$ uname -s Linux kurt@kurt-UP-CHT01:~$ uname -a Linux kurt-UP-CHT01 4.4.0-1-upboard #10-Ubuntu SMP Fri Sep 23 12:26:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux kurt@kurt-UP-CHT01:~$ ls /dev/ttyS* /dev/ttyS0 /dev/ttyS1 /dev/ttyS2 /dev/ttyS3 kurt@kurt-UP-CHT01:~$
Note the kernel showing 4.4.0-2-upboard. Does yours say upboard or generic?
Is your user a member of the dialout group? Example from my machine:kurt@kurt-UP-CHT01:~$ ls -l /dev/ttyS1 crw-rw---- 1 root dialout 4, 65 Oct 16 14:34 /dev/ttyS1 kurt@kurt-UP-CHT01:~$ groups kurt adm dialout cdrom sudo dip plugdev lpadmin sambashare kurt@kurt-UP-CHT01:~$
Note: I don't do Python, but have used MRAA in C. Also I have not use mraa for Uarts as when I started using MRAA on edison, the Uart code did not do anything
Is there anything interesting in the /var/log/syslog file after you run your app? When I get a failure I do something like:tail -40 /var/log/syslog
Note: I installed MRAA on my UP from sources.
Not sure if any of this helps, but... -
I am using 14.04
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
My output for ls /dev/ttyS* is:
/dev/ttyS0 /dev/ttyS11 /dev/ttyS14 /dev/ttyS17 /dev/ttyS2 /dev/ttyS22 /dev/ttyS25 /dev/ttyS28 /dev/ttyS30 /dev/ttyS5 /dev/ttyS8
/dev/ttyS1 /dev/ttyS12 /dev/ttyS15 /dev/ttyS18 /dev/ttyS20 /dev/ttyS23 /dev/ttyS26 /dev/ttyS29 /dev/ttyS31 /dev/ttyS6 /dev/ttyS9
/dev/ttyS10 /dev/ttyS13 /dev/ttyS16 /dev/ttyS19 /dev/ttyS21 /dev/ttyS24 /dev/ttyS27 /dev/ttyS3 /dev/ttyS4 /dev/ttyS7
maverick@maverick-UP-CHT01:~$ uname -s
Linux
maverick@maverick-UP-CHT01:~$ uname -a
Linux maverick-UP-CHT01 4.4.0-42-generic #62~14.04.1-Ubuntu SMP Fri Oct 7 23:15:48 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
how do i change it to cupboard as apposed to generic? can that be the issue?
I've checked the group and my user is in the dialout group.
I've used the libmraa with python on the edison on the same motor controller i'm trying to use now and it works.
my syslog output:
i tried to run the program again with 8 as the Uart constructor field and got the same error. However, when i did syslog again i got the following:
Oct 16 17:03:38 maverick-UP-CHT01 libmraa[1862]: libmraa version v1.3.0-7-g8ec4fcb initialised by user 'maverick' with EUID 1000
Oct 16 17:03:38 maverick-UP-CHT01 libmraa[1862]: libmraa initialised for platform 'UP' of type 12
Oct 16 17:03:38 maverick-UP-CHT01 libmraa[1862]: uart8: init: platform has only 2 uarts
Then i ran again with 0 as the Uart constructor field (i saw this in an example python program in this repository) and got the following.
Oct 16 17:06:06 maverick-UP-CHT01 libmraa[1875]: libmraa version v1.3.0-7-g8ec4fcb initialised by user 'maverick' with EUID 1000
Oct 16 17:06:06 maverick-UP-CHT01 libmraa[1875]: libmraa initialised for platform 'UP' of type 12
Oct 16 17:06:06 maverick-UP-CHT01 libmraa[1875]: uart: tcgetattr(/dev/ttyS1) failed: Input/output error -
My guess is yes, that is the issue.chrispolanco wrote:maverick@maverick-UP-CHT01:~$ uname -a
Linux maverick-UP-CHT01 4.4.0-42-generic #62~14.04.1-Ubuntu SMP Fri Oct 7 23:15:48 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
how do i change it to cupboard as apposed to generic? can that be the issue?
I followed the steps in the wiki: https://up-community.org/wiki/Ubuntu
I did option 1, which did: sudo apt-get autoremove --purge 'linux-.*generic' -
i followed the instructions to remove the generic however my up kernel is out of date and i can't seem to update it. i have 4.2 and it's at 4.4. i followed the instructions given here https://up-community.org/wiki/Ubuntu however it just keeps the current.
-
if the upgrade doesn't work, please install manually the 4.4 kernel on Trusty with the command:
sudo apt-get isntall linux-upboard-lts-xenial
Then you can proceed and remove the generic kernel as suggested here: https://up-community.org/wiki/Ubuntu -
I saw that but wasn't sure i could install that one since i'm using Trusty. I'll try it now and let you know how it goes.
-
The kernel update fixed the problem thank you.
-
dcleri wrote:New Ubuntu 14.04 and Ubuntu 16.04 4.4 Kernel packages for the UP...
Hi dcleri, any plans for an upgraded kernel at some point? This is 4.4.0-1 and has some issues in detecting devices. For example it randomly detects my webcam microphone. 4.4.0-38/43 don't have this issue...
let us know... thanks. -
Hello Dan
The udev rules you mentioned for ubilinux. Is there a way to implement them into the upboard linux kernel. The problem in my case is that I don't only need to sudo execute the code I want to run, but also export some environmental variables as super user (This includes some paths to shared libraries). My code (ROS node) is also part of a larger launch chain which complicates things even more by requiring password. I'm currently doing this with a shell script, but I believe this is a very inelegant solution. It would be nice as KurtE mentioned to have some rules for GPIO and to simply add a user to a group to access it.
