Jump to content

GPIO not working for non root


skematic

Recommended Posts

I want to use my GPIO pins on my OPi lite. After much research and testing, I have done the following

- Add user pi to group gpio

-  Changed /etc/udev/rules.d/99-gpio.rules to

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/platform/soc/1c20800.pinctrl/gpiochip0/gpio && chmod -R 770 /sys/devices/platform/soc/1c20800.pinctrl/gpiochip0/gpio;?\
    '"????

Now, accessing GPIO pins is working fine via bash:

(env) pi@orangepilite:~$ echo 65 > /sys/class/gpio/export
(env) pi@orangepilite:~$ echo out > /sys/class/gpio/gpio65/direction
(env) pi@orangepilite:~$ echo 1 > /sys/class/gpio/gpio65/value

The LED connected to the corresponding pin lights up nicely.

 

The problem is using Python to control the pin. I'm using the python module OrangePi.GPIO

(env) pi@orangepilite:~$ python
>>> import OPi.GPIO as GPIO
>>> GPIO.setboard (GPIO.PCPCPLUS)
>>> GPIO.setmode (GPIO.BOARD)
>>> GPIO.setup (21, GPIO.OUT)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: No access to /dev/mem.  Try running as root!

This error is only there when trying to run the script from user pi. On root it's working fine.

 

How do I access gpio pins on a non root user in python?

 

Edited by skematic
Linked to the wrong python module
Link to comment
Share on other sites

1 hour ago, martinayotte said:

Change permissions of /dev/mem ...

I have changed the permission for group and others to rw (so same permissions as user root)

@orangepilite:~$ ls -l /dev/mem
crw-rw-rw- 1 root kmem 1, 1 Nov  8 14:01 /dev/mem

However I'm stil getting No access to /dev/mem. Also, by opening access to /dev/mem, could there be any safety issues?

Link to comment
Share on other sites

47 minutes ago, skematic said:

Also, by opening access to /dev/mem, could there be any safety issues?

Right ! I digged the issue by trying out myself, and figured out by searching the web that it would requires to compile kernel with "CONFIG_STRICT_DEVMEM=n"

Maybe using setuid() method inside the python library should fix that ... I will try it this afternoon ...

Link to comment
Share on other sites

4 hours ago, skematic said:

No access to /dev/mem.

Ok ! I've found the recipe :

chmod 4775 /usr/bin/python

If you wish to restrict the security, you should probably copy /usr/bin/python into /usr/bin/python-as-root and doing "chmod 4775 /usr/bin/python-as-root" and running your GPIO python code with this one.

Link to comment
Share on other sites

  "Permission denied : /sys/class/gpio/gpio10/direction"  

 

i tried all the online solution given in forum and Opi.GPIO Documentation but the error remains the same . 

 

OPi.GPIO Documentation (https://opi-gpio.readthedocs.io/en/latest/install.html)  for non root access the error remains the same

 

 

how could  i able to give permission to "sys/class/gpio/"  location in non root access

Please anyone reply 

 

 

Link to comment
Share on other sites

5 hours ago, Anurag Alone said:

i tried all the online solution given in forum

 

Most of the existing documentation is valid only for legacy 3.4.y kernel. Also on the one you are reffering to.

 

On modern kernel, fundaments are changed (most likely to align with some standards). Kernel 3.4.y had Allwinner "standards".

Link to comment
Share on other sites

18 hours ago, Igor said:

 

Most of the existing documentation is valid only for legacy 3.4.y kernel. Also on the one you are reffering to.

 

On modern kernel, fundaments are changed (most likely to align with some standards). Kernel 3.4.y had Allwinner "standards".

what  would  you suggest me to follow documents regarding the solution for this error.  if you correct me in right direction  . Thanks in advance . 

Link to comment
Share on other sites

24 minutes ago, Anurag Alone said:

if you correct me in right direction

 

I did. Once again:
 

19 hours ago, Igor said:

Most of the existing documentation is valid only for legacy 3.4.y kernel.

 

You are referring to a wrong documentation and asking why it doesn't work. It is expected to fail and I told you that. (now the 3rd time and last time)


Read this to understand background:

https://linux-sunxi.org/GPIO

 

Step by step documentation? I don't know if it exists. I will not search it nor make it for you - you have to invest your own time with the essential information which you got here.

Link to comment
Share on other sites

On 9/14/2019 at 9:01 AM, Anurag Alone said:

if you correct me in right direction


I assume you now understand the fundamental change between legacy and mainline.

Perhaps asking authors of this document @sgjava @5kft @Adrian Cuzman ... if they know how to solve https://opi-gpio.readthedocs.io/en/latest/install.html#non-root-access under mainline kernel?

Link to comment
Share on other sites

For what it's worth, I gave up on OPi.GPIO some time back, and switched to the standard libgpiod instead (e.g., see https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/).  Use of libgpiod eliminates almost all pain in terms of permissions to manage GPIOs for non-root users.  If you don't want to build your own copy, libgpiod is available in Debian buster; see package libgpiod2 (https://packages.debian.org/buster/libgpiod2).  Python bindings are available via the python3-libgpiod package (see https://packages.debian.org/buster/python3-libgpiod).

 

All that is needed for user access to GPIOs is to set the group of /dev/gpiochip* to a group that the user is a member of - e.g., I use a "gpio" group, and then "chgrp gpio /dev/gpiochip*"), and set the permissions of /dev/gpiochip* to group read/write (e.g., "chmod g+rw /dev/gpiochip*") so that the "gpio" group can read/write to it.  After doing this the user has full access to the GPIOs (in C, in Python, at the command line, etc.) without having to run as root.

 

Here's a simple Python example that illustrates controlling a LED that wired to H5 GPIO PA12:

import gpiod

PA12 = 12               # LED is wired to GPIO PA12

# configure GPIOs
chip = gpiod.Chip('1', gpiod.Chip.OPEN_BY_NUMBER)

led_line = chip.get_line(PA12)
led_line.request(consumer="test", type=gpiod.LINE_REQ_DIR_OUT)

led_line.set_value(1)	# turn on LED
led_line.set_value(0)	# turn off LED

libgpiod also comes with some handy utilities to track GPIO pin usage as well (e.g., "gpioinfo").

 

I hope this helps...!

Link to comment
Share on other sites

I am trying to host an web application (Python Django based) and i am using GPIO pins (library: OPi.GPIO==0.6.3). I got the permission error in "sys/class/gpio/* " and when i give manually permission to several files (location=sys/class/gpio/*) but the issue  remains the same .

 

Device :OrangePi Zero
OS : Ubuntu Bionic with Armbian Linux 4.19.62-sunxi


 

Link to comment
Share on other sites

Hi,

 

Two things come to my mind, reading your post

  1. armbianmonitor -u   tells the reader all the details about your Installation, like Kernel-Version and much more
  2. Did you already use the search function in the right hand topcorner?

 

Link to comment
Share on other sites

4 hours ago, martinayotte said:

Try this :


@Anurag Alone and his company colleagues are keep spamming forum and email with the same question and so far they have done nothing to understand hints we already gave to them. I am one click away  ...

 

Mr. Anurag, please read:
https://forum.armbian.com/guidelines

https://www.armbian.com/get-involved/

If you don't have an option to understand tips, hire someone: https://www.debian.org/consultants/ and remember that support on this forum is 100% our good will.

Link to comment
Share on other sites

On 9/15/2019 at 11:48 PM, 5kft said:

For what it's worth, I gave up on OPi.GPIO some time back, and switched to the standard libgpiod instead (e.g., see https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/).  Use of libgpiod eliminates almost all pain in terms of permissions to manage GPIOs for non-root users.

 

I still use OPi.GPIO and it works fine for non root users with the proper udev rules. When I started using it I had to patch it to delay opening the files (the udev rules take some time to apply), but now it does it itself (it checks that the file is accessible before giving up).

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines