Quanta Posted November 17, 2019 Share Posted November 17, 2019 Armbianmonitor: https://drive.google.com/open?id=1Xfu8YhRqs1OCbWmSoMbsP4VvBEhGgbyv Greetings all. I am having no success getting access to gpio pins in NR using opi-gpio. I am trying to re-build a system that I messed up due to an update. The update broke access to the 1-wire host adapter I had running on I2C. I have searched and read a lot trying to find a solution but I am not making enough sense of the solutions I read to even know if they apply or if I am applying them correctly. Very frustrating because I had this working once but that was a number of versions ago for both armbian and NR. Also, the gpio pins were working even after the I2c update. In the process of 'fixing' that I started over with current armbian: millheim@Millheim:~$ Linux Millheim 4.19.63-sunxi64 #5.92 SMP Fri Aug 2 00:18:27 CEST 2019 aarch64 GNU/Linux and node red 1.0.2. Once running, I copied the backup I made of the flow and have most things working as I had them before. The main thing that I cannot get working is GPIO. I decided to try to use an approach that duplicates as closely as possible another system I have running which is a Nanopi Neo Core 2 LTS. The board I am trying to get working is a Nanopi Neo 2. I flashed the corresponding image, selected docker and hassio (hassio was false start and am not using it). I then pulled official current NR and now have NR flow working except for access to gpio. It looks to me like the docker container isn't getting access to the gpio. I cannot figure out what I need to do here. When it comes to giving the correct permissions, I want to use good practice but don't think I need to be retentive and only give access to the 3 pins I am using at the moment. I am looking for a solution that will allow me to access the pins, interrupts, etc. shown in gpio readall without having to fiddle with this issue repeatedly. This iteration: docker run -it -p 1880:1880 --device=/dev/gpiochip0 --device=/dev/gpiochip1 -v /home/millheim/.node-red/data:/data --name nodered nodered/node-red Gives this error: 17 Nov 03:39:24 - [info] Starting flows 17 Nov 03:39:24 - [info] [opi_out:Pin 24 - PC3] Pin: 67 17 Nov 03:39:24 - [error] [opi_out:9f074a4f.c5db88] Error: EACCES: permission denied, open '/sys/class/gpio/export' 17 Nov 03:39:24 - [info] [opi_out:Pin 23 - PC2] Pin: 66 17 Nov 03:39:24 - [error] [opi_out:526f3769.6171f8] Error: EACCES: permission denied, open '/sys/class/gpio/export' 17 Nov 03:39:24 - [info] [opi_out:Pin 21 - PC1] Pin: 65 17 Nov 03:39:24 - [error] [opi_out:acccfc03.277b9] Error: EACCES: permission denied, open '/sys/class/gpio/export' 17 Nov 03:39:24 - [info] Started flows My user is member of group gpio. It is probably clear to others (barely to me) NR does run this way and does communicate with owserver. There are errors thrown but only because only one sensor is present. Others aren't connected. /etc/rc.local has this: sudo chown root:gpio /sys/class/gpio/unexport /sys/class/gpio/export sudo chmod 220 /sys/class/gpio/unexport /sys/class/gpio/export exit 0 /etc/udev/rules.d/99-com.rules has this: # KERNEL=="gpio*", RUN="/bin/sh -c 'chgrp -R gpio /sys/%p /sys/class/gpio && chmod -R g+w /sys/%p /sys/class/gpio'" # SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio'" SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'find -L /sys/class/gpio/ -maxdepth 2 -exec chown root:gpio {} \; -exec chmod 770 {} \; || true'" Output of armbianmonitor -u: https://drive.google.com/open?id=1Xfu8YhRqs1OCbWmSoMbsP4VvBEhGgbyv I doubt this will be terribly helpful but just in case millheim@Millheim:~$ gpio readall +-----+-----+----------+------+---+-NanoPi-NEO2--+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | 3.3V | | | 1 || 2 | | | 5V | | | | 12 | 8 | GPIOA12 | ALT5 | 0 | 3 || 4 | | | 5V | | | | 11 | 9 | GPIOA11 | ALT5 | 0 | 5 || 6 | | | 0v | | | | 203 | 7 | GPIOG11 | OFF | 0 | 7 || 8 | 0 | OFF | GPIOG6 | 15 | 198 | | | | 0v | | | 9 || 10 | 0 | OFF | GPIOG7 | 16 | 199 | | 0 | 0 | GPIOA0 | OFF | 0 | 11 || 12 | 0 | OFF | GPIOA6 | 1 | 6 | | 2 | 2 | GPIOA2 | OFF | 0 | 13 || 14 | | | 0v | | | | 3 | 3 | GPIOA3 | OFF | 0 | 15 || 16 | 0 | OFF | GPIOG8 | 4 | 200 | | | | 3.3v | | | 17 || 18 | 0 | OFF | GPIOG9 | 5 | 201 | | 64 | 12 | GPIOC0 | OFF | 0 | 19 || 20 | | | 0v | | | | 65 | 13 | GPIOC1 | OFF | 0 | 21 || 22 | 0 | OFF | GPIOA1 | 6 | 1 | | 66 | 14 | GPIOC2 | OFF | 0 | 23 || 24 | 0 | OFF | GPIOC3 | 10 | 67 | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+-NanoPi-NEO2--+------+----------+-----+-----+ +-----+----NanoPi-NEO2 USB/Audio-+----+ | BCM | wPi | Name | Mode | V | Ph | +-----+-----+----------+------+---+----+ | | | 5V | | | 25 | | | | USB-DP1 | | | 26 | | | | USB-DM1 | | | 27 | | | | USB-DP2 | | | 28 | | | | USB-DM2 | | | 29 | | | | IR-RX | | | 30 | | 17 | 19 | GPIOA17 | OFF | 0 | 31 | | | | PCM/I2C | | | 32 | | | | PCM/I2C | | | 33 | | | | PCM/I2C | | | 34 | | | | PCM/I2C | | | 35 | | | | 0V | | | 36 | +-----+-----+----------+------+---+----+ +-----+----NanoPi-NEO2 Debug UART-+----+ | BCM | wPi | Name | Mode | V | Ph | +-----+-----+----------+------+---+----+ | 4 | 17 | GPIOA4 | ALT5 | 0 | 37 | | 5 | 18 | GPIOA5 | ALT5 | 0 | 38 | +-----+-----+----------+------+---+----+ Thanks for taking the time to look through this. Hope you can help. Q Link to comment Share on other sites More sharing options...
Quanta Posted November 17, 2019 Author Share Posted November 17, 2019 One other thing. The local group gpio has a group ID of 1002. I created the group because it was (apparently) needed but did not specify GID on creation. When I have seen GIDs for gpio elsewhere they are sub 1000 numbers (101 I think)- presumably reserved for system functions. I assume these sub 1000 numbers are assigned by the os and by convention the range below 1000 is used. It does not follow (in my mind anyway) that there is any necessity for that convention except easier system admin, config, etc. It would not surprise me however, to learn that some core code can't handle system GIDs above 1000. That said, if GID should be changed, to what? Use same method as usual? 100 is not currently assigned but 101 is ( systemd-journal) is 100 ok to use or is there another? In any case, after such a change I assume a reboot would be at a minimum wise - if not required. Q Link to comment Share on other sites More sharing options...
Recommended Posts