Permissions

Peter ScargillC Code29 Comments on Permissions

I’m sure Linux life would be a LOT easier for beginners if it were not for the pesky permissions..

You’ll see in previous blogs that with help from readers, I discovered that the WIRINGOP library will work with H3 chips – and allow access to the pins on for example the FriendlyArm NanoPi M1 boards.

A compiled C program such as this…

#include <stdio.h> // Used for printf() statements
#include <wiringPi.h> // Include WiringPi library!   const int pwmPin = 7;
int DELAY_MS = 30;
const int pwmValue = 75;   int main(void)
{
    // Setup stuff:
    wiringPiSetup();
    softPwmCreate(pwmPin, 0, 100);
    printf("PWD is running! Press CTRL+C to quit.\n");
    int up;
    int down;
    while(1)
    {     {
      for(up = 11; up <= 21; up++)
          {
            //pwmWrite(pwmPin, up);
            softPwmWrite (pwmPin, up);
            delay(DELAY_MS);
          }
      for(down = up; down >= 11; down--)
          {
            //pwmWrite(pwmPin, down);
            softPwmWrite (pwmPin, down);
            delay(DELAY_MS * 2);
          }
    }   }
    return 0;
}

can be compiled as such…

gcc -o pwm pwm.c -l wiringPi

and lo and behold you can control pins on the M1…. but only as ROOT user – which is utterly useless for many situations.

I then discovered elsewhere that THIS

sudo chown root:root pwm
sudo chmod 4755 pwm

makes the program work for normal users – in my case on new boards I always create a user PI with similar permission to the PI user on the Raspberry Pi.

Wheeeeeee.

And so it was that I got all excited when I realised, after discovering that WiringPi has some hardwired limits – (hardwarePWM for example does not work unless you use a REAL Raspberry Pi) that THIS exists for the M1 –

https://github.com/friendlyarm/matrix

So this is a whole lot of code and demos… one of them is called MATRIX-GPIO_OUT

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include “libfahw.h”

#define STATUS_CHANGE_TIMES (5)

int main(int argc, char ** argv)

{

int pin = GPIO_PIN(7);

int i, value, board;

int ret = -1;

if ((board = boardInit()) < 0) {

printf(“Fail to init board\n”);

return -1;

}

if (board == BOARD_NANOPI_T2)

pin = GPIO_PIN(15);

if (argc == 2)

pin = GPIO_PIN(atoi(argv[1]));

if ((ret = exportGPIOPin(pin)) == -1) {

printf(“exportGPIOPin(%d) failed\n”, pin);

}

if ((ret = setGPIODirection(pin, GPIO_OUT)) == -1) {

printf(“setGPIODirection(%d) failed\n”, pin);

}

for (i = 0; i < STATUS_CHANGE_TIMES; i++) {

if (i % 2) {

value = GPIO_HIGH;

} else {

value = GPIO_LOW;

}

if ((ret = setGPIOValue(pin, value)) > 0) {

printf(“%d: GPIO_PIN(%d) value is %d\n”, i+1, pin, value);

} else {

printf(“setGPIOValue(%d) failed\n”, pin);

}

sleep(1);

}

unexportGPIOPin(pin);

return 0;

}

and so here is a C program that lets you control the actual pins of the M1 – it was the first example I came across – REALLY simple – compile it and sure enough like that previous program – it works – but only as ROOT user.

Thinking I was being clever I tried…

sudo chown root:root matrix-gpio_out
sudo chmod 4755 matrix-gpio_out

SADLY – it would not work as a non-root user even with this – no access.  Is anyone clever enough to know WHY and how to get around it – there are lots of example programs in this MATRIX library but Node-Red does not run as ROOT – cannot access root programs using SUDO and therefore the whole lot are useless to me (and others using similar software) as it stands. The Matrix manual is only available in Chinese so it is looking like WiringPI (or WiringOP) is the only way forward for non-root users of these boards – and that’s a shame. I hope I’m wrong.

Why does the WiringPi C code example work after user is changed to root – but THIS example does not?

Ideas anyone?

29 thoughts on “Permissions”

  1. You wrote: “but only as ROOT user”
    The trick is not to be scared of root. We are only talking about a titchy little $10 embedded board – what’s the worst that could happen?
    It’s not as if one slip of the finger will bring the world’s commerce grinding to a halt.

    I use root all the time for everything – always! It makes everything so much simpler.

    When you get a new board, from whatever you log in as, do the following:
    sudo bash ## get’s you a root shell
    passwd whateverpasswordyouwant ## sets a password for root

    and then when you want to do some real work, unencumbered my messy permissions, log in as usual (or permit root logins) and type:
    su –
    followed by your password when prompted.

    1. Hi

      No not scared of root at all 🙂 – however on the subject of root – the titchy board is in charge of a very expensive to run electric heating system 🙂 But generally I agree for many uses this whole Linux permissions thing can be a pain in the bum

  2. mrshark: You say you are on an M1 with Armbian – well having realised I was not using Armbian – I’m on it now – what EXACTLY did you do to get the WIFI working (apart from plugging in the WIFI of course).

      1. Groan -that’s what I get for rushing – Armbian WIFI isn’t working – only locally… I may start again from scratch later today…

    2. Sorry, I’ve no wifi adapter to test, nor I’ve an ethernet switch to go wired ad the moment… The only test I can do is permissions, if you send me a compiled binary… I’m on vacation site fighting with connectivity issues…

  3. If I understand, you’ve changed the permissions of the program.
    If you are only planning to run it as one specific user, e.g. pete.
    sudo chown pete:pete matrix-gpio_out
    sudo chmod +x matrix-gpio_out

    The program should run, but it’s possible it does not work as expect if there are permissions issues. As mentioned above using strace would help.
    strace ./matrix-gpio_out

    This will show what files / devices are accessed, and possibly show other permissions issues. You may have to change the GPIO permissions or/and ownwership.

    1. Hi there – you’re right – it didn’t work..

      Hardware:sun8i
      Revision:0000
      BoardType:68330
      FAHW-Lib: Unable to open file /sys/class/gpio/export
      exportGPIOPin(7) failed
      FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/direction
      setGPIODirection(7) failed
      FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value
      setGPIOValue(7) failed
      FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value
      setGPIOValue(7) failed
      FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value
      setGPIOValue(7) failed
      FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value
      setGPIOValue(7) failed
      FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value
      setGPIOValue(7) failed
      FAHW-Lib: Unable to open file /sys/class/gpio/unexport

      Not entirely sure how to use that strace program.

    3. Ah, installed Strace – I can honestly say I am absolutely no further forward after running the command.

      execve(“./matrix-gpio_out”, [“./matrix-gpio_out”], [/* 20 vars */]) = 0
      brk(0) = 0x21000
      uname({sys=”Linux”, node=”nanopim1a”, …}) = 0
      access(“/etc/ld.so.nohwcap”, F_OK) = -1 ENOENT (No such file or directory)
      mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ff0000
      access(“/etc/ld.so.preload”, R_OK) = -1 ENOENT (No such file or directory)
      open(“/etc/ld.so.cache”, O_RDONLY|O_CLOEXEC) = 3
      fstat64(3, {st_mode=S_IFREG|0644, st_size=61098, …}) = 0
      mmap2(NULL, 61098, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6fbc000
      close(3) = 0
      access(“/etc/ld.so.nohwcap”, F_OK) = -1 ENOENT (No such file or directory)
      open(“/usr/local/lib/libfahw.so”, O_RDONLY|O_CLOEXEC) = 3
      read(3, “\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0p\35\0\0004\0\0\0″…, 512) = 512
      lseek(3, 36472, SEEK_SET) = 36472
      read(3, “\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0″…, 1080) = 1080
      lseek(3, 25217, SEEK_SET) = 25217
      read(3, “A2\0\0\0aeabi\0\1(\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22″…, 51) = 51
      fstat64(3, {st_mode=S_IFREG|0644, st_size=37552, …}) = 0
      mmap2(NULL, 91192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6fa5000
      mprotect(0xb6fab000, 65536, PROT_NONE) = 0
      mmap2(0xb6fbb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0xb6fbb000
      close(3) = 0
      access(“/etc/ld.so.nohwcap”, F_OK) = -1 ENOENT (No such file or directory)
      open(“/lib/arm-linux-gnueabihf/libm.so.6”, O_RDONLY|O_CLOEXEC) = 3
      read(3, “\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0h<\0\0004\0\0\0"..., 512) = 512 lseek(3, 405976, SEEK_SET) = 405976 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1160) = 1160 lseek(3, 405640, SEEK_SET) = 405640 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0644, st_size=407136, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fef000 mmap2(NULL, 471184, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f31000 mprotect(0xb6f94000, 61440, PROT_NONE) = 0 mmap2(0xb6fa3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x62000) = 0xb6fa3000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0Mw\1\0004\0\0\0"..., 512) = 512 lseek(3, 908188, SEEK_SET) = 908188 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2880) = 2880 lseek(3, 904740, SEEK_SET) = 904740 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\3\f"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=911068, ...}) = 0 mmap2(NULL, 980392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e41000 mprotect(0xb6f1c000, 61440, PROT_NONE) = 0 mmap2(0xb6f2b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xda000) = 0xb6f2b000 mmap2(0xb6f2e000, 9640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f2e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0EQ\0\0004\0\0\0"..., 512) = 512 lseek(3, 100684, SEEK_SET) = 100684 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1520) = 1520 lseek(3, 65940, SEEK_SET) = 65940 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=102204, ...}) = 0 mmap2(NULL, 139836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e1e000 mprotect(0xb6e2e000, 61440, PROT_NONE) = 0 mmap2(0xb6e3d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0xb6e3d000 mmap2(0xb6e3f000, 4668, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6e3f000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fee000 set_tls(0xb6fee4c0, 0xb6ff3050, 0xb6feeba8, 0xb6fee4c0, 0xb6ff3050) = 0 mprotect(0xb6f2b000, 8192, PROT_READ) = 0 mprotect(0xb6e3d000, 4096, PROT_READ) = 0 mprotect(0xb6fa3000, 4096, PROT_READ) = 0 mprotect(0xb6ff2000, 4096, PROT_READ) = 0 munmap(0xb6fbc000, 61098) = 0 set_tid_address(0xb6fee068) = 3112 set_robust_list(0xb6fee070, 12) = 0 rt_sigaction(SIGRTMIN, {0xb6e22d9d, [], SA_RESTORER|SA_SIGINFO, 0xb6e67b01}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb6e22cbd, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0xb6e67b01}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x21000 brk(0x42000) = 0x42000 open("/proc/cpuinfo", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fed000 read(3, "Processor\t: ARMv7 Processor rev "..., 1024) = 422 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fec000 write(1, "Hardware:sun8i\n", 15Hardware:sun8i ) = 15 write(1, "Revision:0000\n", 14Revision:0000 ) = 14 read(3, "", 1024) = 0 write(1, "BoardType:68330\n", 16BoardType:68330 ) = 16 open("/sys/class/gpio/export", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied) write(1, "FAHW-Lib: Unable to open file /s"..., 53FAHW-Lib: Unable to open file /sys/class/gpio/export ) = 53 write(1, "exportGPIOPin(7) failed\n", 24exportGPIOPin(7) failed ) = 24 open("/sys/class/gpio/gpio203/direction", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) write(1, "FAHW-Lib: Unable to open file /s"..., 64FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/direction ) = 64 write(1, "setGPIODirection(7) failed\n", 27setGPIODirection(7) failed ) = 27 open("/sys/class/gpio/gpio203/value", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) write(1, "FAHW-Lib: Unable to open file /s"..., 60FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value ) = 60 write(1, "setGPIOValue(7) failed\n", 23setGPIOValue(7) failed ) = 23 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0xbeaf441c) = 0 open("/sys/class/gpio/gpio203/value", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) write(1, "FAHW-Lib: Unable to open file /s"..., 60FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value ) = 60 write(1, "setGPIOValue(7) failed\n", 23setGPIOValue(7) failed ) = 23 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0xbeaf441c) = 0 open("/sys/class/gpio/gpio203/value", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) write(1, "FAHW-Lib: Unable to open file /s"..., 60FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value ) = 60 write(1, "setGPIOValue(7) failed\n", 23setGPIOValue(7) failed ) = 23 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0xbeaf441c) = 0 open("/sys/class/gpio/gpio203/value", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) write(1, "FAHW-Lib: Unable to open file /s"..., 60FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value ) = 60 write(1, "setGPIOValue(7) failed\n", 23setGPIOValue(7) failed ) = 23 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0xbeaf441c) = 0 open("/sys/class/gpio/gpio203/value", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) write(1, "FAHW-Lib: Unable to open file /s"..., 60FAHW-Lib: Unable to open file /sys/class/gpio/gpio203/value ) = 60 write(1, "setGPIOValue(7) failed\n", 23setGPIOValue(7) failed ) = 23 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0xbeaf441c) = 0 open("/sys/class/gpio/unexport", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied) write(1, "FAHW-Lib: Unable to open file /s"..., 55FAHW-Lib: Unable to open file /sys/class/gpio/unexport ) = 55 exit_group(0) = ? +++ exited with 0 +++

      1. Are you sure this is a permission issue at all? The problem seems to be that there are two sysfs node trees available and that you need gpio_sunxi being unloaded to make use of WiringOP? http://www.cnx-software.com/2015/09/26/status-of-orange-pi-boards-gpio-support/#comment-523049

        (Disclaimer: Did GPIO stuff on H3 boards a while ago relying on Armbian defaults where gpio_sunxi is commented out by default. With the help of a few guys in Armbian forum I succeeded with everything I was interested in — basic GPIO stuff and accessing RFID readers — and since this worked I never looked into again. Please note: when combining Armbian with FA’s Matrix code snippets things might go wrong. At least it’s untested)

        1. Hi tkaiser, of Wiringop works no problem – but as it is not set up for the M1 specifically, attempts to use hardware PWM say sorry – can’t use that port… I assume I2c will be the same.

          Incidentally at this point I realised I was using plain Debian not Armbian on the M1 so I’ve done a re-install.. two things – by default in the command line server version of Armbian (Jessie) the overscan on both my monitors is such that I can’t see the bottom line – ok once I get onto WinSCP of course – but actually using the video output is difficult. Secondly, with a standard WIFI usb I am getting no-where – checked the instructions on the Armbian site… it’s no clear whether I needed to load the drivers or they were already in – either way I SEEM to have WLAN0 but it won’t scan for WIFI and won’t connect…. might be me but it seems that WIFI setup is not as simple as it would be in the graphical environment… connecting with hardwired ethernet no problem.

          2. First regarding HDMI and WiFi: Display driver is known to cause issues and we can’t do much against (libhdmi is a blob in H3 legacy kernel, hdmi source code available is licenseless but the only real ‘documentation’ available so this mess prevents writing a sane HDMI driver from scratch for H3 boards). Armbian does only support a few WiFi dongles, please have a look through ‘OPI ONE wireless success’ thread in forum (we can’t do more here other than perfectly supporting the onboard WiFi of all the boards we support, it’s just a matter of man-power).

            Regarding pin mapping I just today realized that NanoPi M1 uses also different ones than Oranges and M2+ 🙁
            http://forum.armbian.com/index.php/topic/1745-different-gpio-pin-mappings-on-bpi-m2-compared-to-orange-pis/?view=getlastpost

            Regarding PWM: On H3 devices it’s available but shares the pin mapping with uart0 (serial boot console, RX pin –> on M1 the outer pin on the small header): http://forum.armbian.com/index.php/topic/1324-opipc-pwm-on-gpio/

            Without disabling uart0, enabling pwm0 in fex file and loading the driver it can’t work.

            1. More very useful information tkaiser – thanks for that…. yes, M1 is very different as my blog shows – I’ve mapped a good number of pins for general GPIO access but it really would be good to be able to do I2c as well, sadly I contacted FriendlyArm on the subject of the Neo and Debian and their response was pretty straightforward – the only support Ubuntucore and that was the end of the discussion. I think people should be banned from calling something “Pi” unless it is compatible – but there you are.

              So You are saying that on the M1 we just ignore hardware PWM – because it is not going to work – fair enough – software PWM seems to work – I don’t think it is worth losing UART0 for – of course- you have to leave the program running for software PWM to work which is a pain… it really would be nice to get I2c working.

              HDMI I can live with but I really want to get the WIFI working – I’m using a standard one of those little WIFI dongles with 802.11n in white on the end – the drivers are commonplace – and I got WIFI working locally – no problem but no matter what I did on first attempt – I could not get it to talk to the outside world – so clearly either I’m missing the point of the instructions or they’re not quite right. I’m reading the thread you suggested right now….

          3. I2C is confirmed to work with Armbian/H3 since March (just a few weeks after we started supporting H3 boards). Should also work with M1 since pin mappings are the same. Please see post #269 in this lengthy thread: http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/page-9

            Regarding WiFi (I almost never use it on Linux): If you’re not using a desktop environment where network manager, wicd or the like set up things accordingly you have to play with settings files (outlined in the aforementioned thread). That means manually fiddling around with /etc/network/interfaces and wpa_supplicant stuff and checking dmesg/lsmod/lsusb output whether dongle is recognized or not. At least loading the required driver module is mandatory. I would ask in the aforementioned thread if the troubleshooting steps there aren’t already sufficient to solve the problem.

            But in general: the best way to use WiFi with Armbian is to choose one of the boards with onboard WiFi since at least for these combinations we provide full support (approx. 10 of the 40 boards we support have WiFi).

            1. Here’s a thing – having realised I was using Debian and not Armbian on the M1 – I made new SDs of both today. The Debian connects to my WIFI no problem at all first time – the Armbian has to have several attempts to connect and then the likes of apt-get update fails to resolve names – plug a hard network in and it works no problem….

              Same board, same WICD graphical control panel – why the difference?

  4. You’re running Debian on the NanoPi right? Is it Debian 8 (the newest major release)? They switched to using Udev ( https://wiki.archlinux.org/index.php/udev ) to manage pluggable hardware. Maybe you need to set the permissions with udevadm instead? I know that’s what I use on my desktop to set permissions for serial ports and such and on my RasPi’s to set the permissions on the GPIOs.

    I thought the old way of directly setting permissions was supposed to still work, but maybe there’s some complication going on behind the scenes. This thread has some helpful stuff, they’re talking about the RasPi but the commands should be similar
    https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=9667

    1. Hi there Jason – isn’t that link you sent about Arch Linux? I’m afraid not being that familiar with Linux it didn’t really mean a lot to me. That Pi link looks promising but refers to 99-gpio.rules – there is no such file on the M1.

      Ta.

      1. Yeah, that link is what we need, or the equivalent on this H3 boards, but eventually without udev we can put the right command in /etc/rc.local once found it: it will be executed on every boot

      2. The first link is for Arch, yes, but udev is pretty standardized across distributions so the information there should apply.

        So the way udev works is that you can define various rules files in /etc/udev/rules.d; all files ending with .rules are parsed in, with the convention being that they also start with a number if you want to control the order they are applied in (they are read in dictionary order). These rules specify a device to match and an action to apply.

        The 99-gpio.rules file probably doesn’t exist, you’re right. You have to make it yourself and figure out what rules need to be applied. The info in the Raspberry Pi forum thread should provide a lot of the commands needed to query current permissions and figure out what they need to be, then you can add them. Querying stuff with udevadm in particular should be quite helpful.

        Unfortunately this stuff is kind of complicated and really the Armbian / FriendlyARM people should have instructions on this somewhere. I can’t really help much without having one of the boards in front of me.

    2. Another one of those links that looks when you read it like… “yup that makes sense” – made the change to the dialup group – made sure my pi user was part of that group – rebooted… absolutely no difference at all

      1. I don’t know if dialout is the correct group, you have to use strace the check what is accessed by your program… Anyway, as you already posted other comments and I’ve seen other stuff you already tried and seen your strace, try this (not permanent, let’s try for now):

        (assign gpio tree to the dialout group you are already in):
        sudo chgrp -r dialout /sys/class/gpio

        Or even, if it doesn’t work (open full legs of that tree 🙂 ):
        sudo chmod -r 777 /sys/class/gpio

        That’s the stuff your program can’t access, there we have to act…

        2. Thank you Mr Shark – that was an upper case R needed there 🙂 and no – neither of those made any difference… worth trying though.

          1. I’ve a Pi m1 with armbian, maybe I can try there… Tell me how to test this stuff, I’ll do what I can asap

Comments are closed.