I used the following udev rule (similar to William Hermans, without the
pinmux/state changes using a new 'gpio' group).
udev rule:
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/ocp/4????000.gpio/gpio/; chmod -R 770
/sys/devices/platform/ocp/4????000.gpio/gpio/'"
This worked successfully for an image that had the following setup (uname):
Linux bbb-3ed2 4.4.12-ti-rt-r30 #1 SMP PREEMPT RT Thu Jun 9 07:50:04 UTC
2016 armv7l armv7l armv7l GNU/Linux
I am now moving to a newer image (uname): Linux bbb-f652 4.9.24-ti-rt-r31
#1 SMP PREEMPT RT Wed Apr 26 23:38:10 UTC 2017 armv7l armv7l armv7l
GNU/Linux. I see the /sys/class/gpio directory setup with the 'gpio' group
name. But when I export a pin and look at that directory, the ownership of
all the files are root:root. This will not allow me to control the GPIO
from a non-root account. Any idea on what might have changed that would
effect this would be greatly appreciated.
/sys/class/gpio$ ls -al
total 0
drwxrwx--- 2 root gpio 0 Apr 27 20:54 .
drwxr-xr-x 59 root root 0 Apr 27 20:46 ..
-rwxrwx--- 1 root gpio 4096 Apr 27 20:54 export
lrwxrwxrwx 1 root gpio 0 Apr 27 20:54 gpio10 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio10
lrwxrwxrwx 1 root gpio 0 Apr 27 20:38 gpiochip0 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio 0 Apr 27 20:38 gpiochip32 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpiochip32
lrwxrwxrwx 1 root gpio 0 Apr 27 20:38 gpiochip64 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpiochip64
lrwxrwxrwx 1 root gpio 0 Apr 27 20:38 gpiochip96 ->
../../devices/platform/ocp/481ae000.gpio/gpio/gpiochip96
-rwxrwx--- 1 root gpio 4096 Apr 27 20:54 unexport
/sys/class/gpio/gpio10$ ls -al
total 0
drwxr-xr-x 3 root root 0 Apr 27 20:54 .
drwxr-xr-x 3 root root 0 Apr 27 20:54 ..
-rw-r--r-- 1 root root 4096 Apr 27 20:54 active_low
lrwxrwxrwx 1 root root 0 Apr 27 20:54 device -> ../../../gpiochip0
-rw-r--r-- 1 root root 4096 Apr 27 20:54 direction
-rw-r--r-- 1 root root 4096 Apr 27 20:54 edge
-r--r--r-- 1 root root 4096 Apr 27 20:54 label
drwxr-xr-x 2 root root 0 Apr 27 20:54 power
lrwxrwxrwx 1 root root 0 Apr 27 20:54 subsystem ->
../../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Apr 27 20:54 uevent
-rw-r--r-- 1 root root 4096 Apr 27 20:54 value
On Friday, April 21, 2017 at 11:20:58 PM UTC-5, William Hermans wrote:
>
> This is what I had to do with the gpio pins, note the last two parts of
> the rules.
>
> 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/ocp/4????000.gpio/gpio/; chmod -R
> 770 /sys/devices/platform/ocp/4????000.gpio/gpio/;
> chown root:gpio /sys/devices/platform/ocp/ocp:??_??_pinmux/state; chmod 770
> /sys/devices/platform/ocp/ocp:??_??_pinmux/state'"
>
> So in my own mind, mode 770 is a really bad idea. But I seem to recall having
> issues unless I gave myself executable permissions as well. Why, I'm not
> sure.
> I'm definitely not a udev expert. I also recall, some paths gave me issues,
> which is why above I had to place additional rules on the "state" file. Also
> note my SUBSYSTEM "define"
> which is "gpio*". Other obvious differences is the order in which I used
> chown, and chmod, but I'm not positive that would make any difference. Since
> the system udev is running
> these rules when the sysfs file / directory structure is created. As such, it
> should be root, or better, if possible.
>
> Anyway, you could create a systemd one-shot timer at boot, that waits a
> certain amount of time ( maybe 5-10 seconds ), then does this "manually". I'm
> pretty sure that would work.
> But that would feel like a "hack" to me. e.g. not really the proper way to go
> about things. But short term, it would work. Which is what really is
> important.
>
>
> On Fri, Apr 21, 2017 at 7:35 PM, Robert Nelson <[email protected]
> <javascript:>> wrote:
>
>> This is what the analog.js application shows:
>>
>> https://i.imgur.com/4ifEFBQ.png
>>
>> if i manually do:
>>
>> debian@test-bbb-2:/sys/class/pwm/pwmchip4$ sudo /bin/chown -R root:pwm
>> ./pwm0/
>> debian@test-bbb-2:/sys/class/pwm/pwmchip4$ sudo /bin/chmod -R ug+rw
>> ./pwm0/
>>
>> debian@test-bbb-2:/sys/class/pwm/pwmchip4$ ls -lha
>> total 0
>> drwxrwxr-x 4 root pwm 0 Apr 22 02:30 .
>> drwxr-xr-x 3 root root 0 Apr 22 02:31 ..
>> lrwxrwxrwx 1 root pwm 0 Apr 22 02:26 device -> ../../../48302200.pwm
>> -rw-rw---- 1 root pwm 4.0K Apr 22 02:26 export
>> -rw-rw-r-- 1 root pwm 4.0K Apr 22 02:26 npwm
>> drwxrwxr-x 2 root pwm 0 Apr 22 02:26 power
>> drwxrwxr-x 3 root pwm 0 Apr 22 02:30 pwm0
>> lrwxrwxrwx 1 root pwm 0 Apr 22 02:26 subsystem ->
>> ../../../../../../../class/pwm
>> -rw-rw-r-- 1 root pwm 4.0K Apr 22 02:26 uevent
>> -rw-rw---- 1 root pwm 4.0K Apr 22 02:26 unexport
>> debian@test-bbb-2:/sys/class/pwm/pwmchip4$ cd pwm0/
>> debian@test-bbb-2:/sys/class/pwm/pwmchip4/pwm0$ ls -lha
>> total 0
>> drwxrwxr-x 3 root pwm 0 Apr 22 02:30 .
>> drwxrwxr-x 4 root pwm 0 Apr 22 02:30 ..
>> -rw-rw-r-- 1 root pwm 4.0K Apr 22 02:32 duty_cycle
>> -rw-rw-r-- 1 root pwm 4.0K Apr 22 02:32 enable
>> -rw-rw-r-- 1 root pwm 4.0K Apr 22 02:32 period
>> -rw-rw-r-- 1 root pwm 4.0K Apr 22 02:32 polarity
>> drwxrwxr-x 2 root pwm 0 Apr 22 02:32 power
>> -rw-rw-r-- 1 root pwm 4.0K Apr 22 02:32 uevent
>>
>> it looks like it works:
>>
>> https://i.imgur.com/z4AztWJ.png
>>
>> (board's in a box in the basement, so i'm assuming P9_14 has a pwm output
>> ;)
>>
>> debian@test-bbb-2:/sys/class/pwm/pwmchip4/pwm0$ cat ./*
>> 259585
>> 1
>> 500000
>> normal
>> cat: ./power: Is a directory
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/d2999d81-2bfd-47f1-ac2d-7b85defd3ba7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
