Robert:
I just edited /etc/default/cloud9 and changed HOME to
HOME=/home/debian
and now the default home for cloud9 is /home/debian.
I don’t know if I’ve broken anything.
–Mark
The last URL should be:
I’m not getting the gpio permissions to work. I think there are two methods posted here.
Could you repost the one the works?
–Mark
As long as it doesn't ask you to install a bunch of stuff under '.c9'
Regards,
Just:
sudo apt update ; sudo apt upgrade
and
cd /opt/scripts/
git pull
sudo reboot
Regards,
I fired up a fresh copy of the 4-18 image and noticed:
debian@Bone:/var/lib/cloud9$ ls -ls
total 24
4 drwxr-xr-x 2 root root 4096 Apr 18 20:34 autorun
4 drwxrwxr-x 6 root cloud9ide 4096 Apr 18 20:30 examples
12 -rw-rw-r-- 1 root cloud9ide 8808 Jun 27 2016 LICENSE
4 -rw-rw-r-- 1 root cloud9ide 1291 Jun 27 2016 README.md
autorun is in the wrong group. And some of the things in /opt/cloud9 aren’t in cloud9ide.
debian@Bone:/var/lib/cloud9$ cd /opt/
debian@Bone:/opt$ ls -ls
total 16
4 drwxr-xr-x 3 root root 4096 Apr 18 2017 backup
4 drwxr-xr-x 5 root root 4096 Apr 18 20:31 cloud9
4 drwxr-xr-x 11 debian debian 4096 Apr 18 20:34 scripts
4 drwxr-xr-x 13 debian debian 4096 Apr 18 20:37 source
debian@Bone:/opt$ cd cloud9/
debian@Bone:/opt/cloud9$ ls -las
total 20
4 drwxr-xr-x 5 root root 4096 Apr 18 20:31 .
4 drwxr-xr-x 6 root root 4096 Apr 18 2017 …
4 drwxr-xr-x 3 debian debian 4096 Apr 18 20:31 build
4 drwxrwxr-x 4 root cloud9ide 4096 Apr 18 20:36 .c9
4 drwxrwxr-x 2 root cloud9ide 4096 Apr 18 20:31 .cache
debian@Bone:/opt/cloud9$ cd .c9/
debian@Bone:/opt/cloud9/.c9$ ls -ls
total 16
4 drwxr-xr-x 2 root root 4096 Apr 18 20:36 bin
4 -rw-rw-r-- 1 root cloud9ide 2 Apr 13 17:47 installed
4 drwxrwxr-x 3 root cloud9ide 4096 Apr 18 20:31 node
4 -rw-r–r-- 1 root root 3414 Apr 21 2017 user.settings
–Mark
user.settings is created by cloud9 when it's run
But i think i got the rest:
#2017-04-18
debian@beaglebone:/var/lib/cloud9$ ls -lh
total 24K
drwxr-xr-x 2 root root 4.0K Apr 21 17:03 autorun
drwxrwxr-x 6 root cloud9ide 4.0K Apr 19 00:30 examples
-rw-rw-r-- 1 root cloud9ide 8.7K Jun 27 2016 LICENSE
-rw-rw-r-- 1 root cloud9ide 1.3K Jun 27 2016 README.md
debian@beaglebone:/opt/cloud9$ ls -las
total 20
4 drwxr-xr-x 5 root root 4096 Apr 19 00:31 .
4 drwxr-xr-x 6 root root 4096 Apr 19 01:10 ..
4 drwxr-xr-x 3 debian debian 4096 Apr 19 00:31 build
4 drwxrwxr-x 3 root cloud9ide 4096 Apr 19 00:31 .c9
4 drwxrwxr-x 2 root cloud9ide 4096 Apr 19 00:31 .cache
debian@beaglebone:/opt/cloud9/.c9$ ls -lha
total 16K
drwxrwxr-x 3 root cloud9ide 4.0K Apr 19 00:31 .
drwxr-xr-x 5 root root 4.0K Apr 19 00:31 ..
-rw-rw-r-- 1 root cloud9ide 2 Apr 13 21:47 installed
drwxrwxr-x 3 root cloud9ide 4.0K Apr 19 00:31 node
Get:1 http://repos.rcn-ee.com/debian stretch/main armhf bone101 armhf
1.1.6-0rcnee30~stretch+20170419 [53.7 MB]
Get:2 http://repos.rcn-ee.com/debian stretch/main armhf
c9-core-installer armhf 3.1.3543+git20170407-0rcnee9~stretch+20170421
[10.9 MB]
Get:3 http://repos.rcn-ee.com/debian stretch/main armhf
bb-cape-overlays armhf 4.4.20170418-0rcnee2~stretch+20170421 [52.9 kB]
debian@beaglebone:/var/lib/cloud9$ ls -lh
total 28K
drwxrwxr-x 2 root cloud9ide 4.0K Apr 21 17:03 autorun
drwxrwxr-x 7 root cloud9ide 4.0K Apr 21 17:07 examples
drwxrwxr-x 6 root cloud9ide 4.0K Apr 19 00:30 examples_old
-rwxrwxr-x 1 root cloud9ide 8.7K Jun 27 2016 LICENSE
-rwxrwxr-x 1 root cloud9ide 1.3K Jun 27 2016 README.md
debian@beaglebone:/opt/cloud9$ ls -lha
total 20K
drwxr-xr-x 5 root root 4.0K Apr 19 00:31 .
drwxr-xr-x 6 root root 4.0K Apr 19 01:10 ..
drwxr-xr-x 3 debian debian 4.0K Apr 19 00:31 build
drwxrwxr-x 3 root cloud9ide 4.0K Apr 21 17:08 .c9
drwxrwxr-x 2 root cloud9ide 4.0K Apr 19 00:31 .cache
debian@beaglebone:/opt/cloud9/.c9$ ls -lha
total 16K
drwxrwxr-x 3 root cloud9ide 4.0K Apr 21 17:08 .
drwxr-xr-x 5 root root 4.0K Apr 19 00:31 ..
-rw-rw-r-- 1 root cloud9ide 2 Apr 21 16:42 installed
drwxrwxr-x 3 root cloud9ide 4.0K Apr 19 00:31 node
#sudo reboot
debian@beaglebone:/var/lib/cloud9$ ls -lh
total 28K
drwxrwxr-x 2 root cloud9ide 4.0K Apr 21 17:03 autorun
drwxrwxr-x 7 root cloud9ide 4.0K Apr 21 17:07 examples
drwxrwxr-x 6 root cloud9ide 4.0K Apr 19 00:30 examples_old
-rwxrwxr-x 1 root cloud9ide 8.7K Jun 27 2016 LICENSE
-rwxrwxr-x 1 root cloud9ide 1.3K Jun 27 2016 README.md
debian@beaglebone:/opt/cloud9$ ls -lha
total 20K
drwxr-xr-x 5 root root 4.0K Apr 19 00:31 .
drwxr-xr-x 6 root root 4.0K Apr 19 01:10 ..
drwxr-xr-x 3 debian debian 4.0K Apr 19 00:31 build
drwxrwxr-x 3 root cloud9ide 4.0K Apr 21 17:08 .c9
drwxrwxr-x 2 root cloud9ide 4.0K Apr 19 00:31 .cache
debian@beaglebone:/opt/cloud9/.c9$ ls -lha
total 16K
drwxrwxr-x 3 root cloud9ide 4.0K Apr 21 17:08 .
drwxr-xr-x 5 root root 4.0K Apr 19 00:31 ..
-rw-rw-r-- 1 root cloud9ide 2 Apr 21 16:42 installed
drwxrwxr-x 3 root cloud9ide 4.0K Apr 19 00:31 node
Fire up cloud9 by hitting port 3000:
debian@beaglebone:/opt/cloud9/.c9$ ls -lha
total 24K
drwxrwxr-x 4 root cloud9ide 4.0K Apr 21 17:12 .
drwxr-xr-x 5 root root 4.0K Apr 19 00:31 ..
drwxr-xr-x 2 debian debian 4.0K Apr 21 17:12 bin
-rw-rw-r-- 1 root cloud9ide 2 Apr 21 16:42 installed
drwxrwxr-x 3 root cloud9ide 4.0K Apr 19 00:31 node
-rw-r--r-- 1 debian debian 3.4K Apr 21 17:12 user.settings
PS, i will have a new "stretch-iot" image up this afternoon, with the
debian user set by default. 
Regards,
I’ll grab the new image when I see it. Does debian by default mean the bash window has /home/debian as its home?
–Mark
Nope, need to figure out how to hide this:
https://i.imgur.com/CSchvbR.png
When, home is /opt/cloud9/
it find's
/opt/cloud9/.c9/installed & /opt/cloud9/.c9/node/bin/node
But i don't want to stick ".c9" under /home/debian/ as a user may
remove it. (it's more apart of cloud9 then user editable)
Regards,
cd /opt/scripts/
git pull
fixes: blinkled.js
https://github.com/RobertCNelson/boot-scripts/commit/e71f9f8f0104f47d3836458f90f8001738f5e835
Regards,
analog.js is currently broken, this might need a udev expert.. I've
fixed one of the side cases but that pwm0 enable eludes me:
#Works:
SUBSYSTEM=="pwm", ACTION=="add", PROGRAM="/bin/sh -c '/bin/chown -R
root:pwm /sys/class/pwm/"
SUBSYSTEM=="pwm", ACTION=="add", PROGRAM="/bin/sh -c '/bin/chmod -R
ug+rw /sys/class/pwm/"
#Works:
SUBSYSTEM=="pwm", ACTION=="add", PROGRAM="/bin/sh -c '/bin/chown -R
root:pwm /sys/devices/platform/ocp/*.epwmss/*.*/pwm/pwmchip*/'"
SUBSYSTEM=="pwm", ACTION=="add", PROGRAM="/bin/sh -c '/bin/chmod -R
ug+rw /sys/devices/platform/ocp/*.epwmss/*.*/pwm/pwmchip*/'"
#not working yet...
SUBSYSTEM=="pwm", ACTION=="add", PROGRAM="/bin/sh -c '/bin/chown -R
root:pwm /sys/devices/platform/ocp/*.epwmss/*.*/pwm/pwmchip*/pwm*/'"
SUBSYSTEM=="pwm", ACTION=="add", PROGRAM="/bin/sh -c '/bin/chmod -R
ug+rw /sys/devices/platform/ocp/*.epwmss/*.*/pwm/pwmchip*/pwm*/'"
#original
debian@beaglebone:/sys/class/pwm/pwmchip2$ ls -lha
total 0
drwxrwxr-x 3 root pwm 0 Apr 21 22:02 .
drwxr-xr-x 3 root root 0 Apr 21 22:02 ..
lrwxrwxrwx 1 root pwm 0 Apr 21 22:02 device -> ../../../48302200.pwm
-rw-rw---- 1 root pwm 4.0K Apr 21 22:02 export
-rw-rw-r-- 1 root pwm 4.0K Apr 21 22:02 npwm
drwxrwxr-x 2 root pwm 0 Apr 21 22:02 power
lrwxrwxrwx 1 root pwm 0 Apr 21 22:02 subsystem ->
../../../../../../../class/pwm
-rw-rw-r-- 1 root pwm 4.0K Apr 21 22:02 uevent
-rw-rw---- 1 root pwm 4.0K Apr 21 22:02 unexport
#run analog.js, pwm0 pop's up, but stays root:root
debian@beaglebone:/sys/class/pwm/pwmchip2$ ls -lha
total 0
drwxrwxr-x 4 root pwm 0 Apr 21 22:04 .
drwxr-xr-x 3 root root 0 Apr 21 22:04 ..
lrwxrwxrwx 1 root pwm 0 Apr 21 22:02 device -> ../../../48302200.pwm
-rw-rw---- 1 root pwm 4.0K Apr 21 22:02 export
-rw-rw-r-- 1 root pwm 4.0K Apr 21 22:02 npwm
drwxrwxr-x 2 root pwm 0 Apr 21 22:02 power
drwxr-xr-x 3 root root 0 Apr 21 22:04 pwm0
lrwxrwxrwx 1 root pwm 0 Apr 21 22:02 subsystem ->
../../../../../../../class/pwm
-rw-rw-r-- 1 root pwm 4.0K Apr 21 22:02 uevent
-rw-rw---- 1 root pwm 4.0K Apr 21 22:02 unexport
udevadm info -a -p /sys/class/pwm/pwmchip2/pwm0
calling: info
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2/pwm0':
KERNEL=="pwm0"
SUBSYSTEM==""
DRIVER==""
ATTR{duty_cycle}=="0"
ATTR{enable}=="0"
ATTR{period}=="0"
ATTR{polarity}=="normal"
looking at parent device
'/devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2':
KERNELS=="pwmchip2"
SUBSYSTEMS=="pwm"
DRIVERS==""
ATTRS{npwm}=="2"
looking at parent device '/devices/platform/ocp/48302000.epwmss/48302200.pwm':
KERNELS=="48302200.pwm"
SUBSYSTEMS=="platform"
DRIVERS=="ehrpwm"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/ocp/48302000.epwmss':
KERNELS=="48302000.epwmss"
SUBSYSTEMS=="platform"
DRIVERS=="pwmss"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/ocp':
KERNELS=="ocp"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
Regards,
That's odd, because chown -R should work for all child directories off the
first udev rule. One thing you might try that I have not tested, and can
not test at this moment. Would be to just have the last non working rule in
place, but instead of changing the ownership of that subdirectory. Walk all
the way out to the main parent and chown -R. If that does not what, what
I'm fairly sure will work would be running a systemd timer off one of the
rules to change ownership of the pwm main parent. To me, it kind of seems
that these rules are being fired as each part of the directory structure is
added, and I mean _right_when_ they're added.
You could also try tightening up your wild card matching, as perhaps there
is something that's being created, that is cause the rule to fail right
off. So maybe if you replace pwm* with pwm? or pwm[0-2] it may work? Or in
the case of each pwm module where the children would be 0, and 1 npwm[0-1].
I need to go look at my bonejs repo and see how I managed all that.
Another thing that come to mind right off is that some files can only be read, while others still can only be written to. If you’re attempting to change permissions to these files in a way that it’s not meant to be used. It could potentially cause the whole rule to fail.
Yeah, this one is really stumping me:
With only the first part:
SUBSYSTEM=="pwm", ACTION=="add", PROGRAM="/bin/sh -c '/bin/chown -R
root:pwm /sys/class/pwm/"
SUBSYSTEM=="pwm", ACTION=="add", PROGRAM="/bin/sh -c '/bin/chmod -R
ug+rw /sys/class/pwm/"
/sys/class/pwm/ looks like:
lrwxrwxrwx 1 root pwm 0 Apr 22 01:22 pwmchip0 ->
../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip0
lrwxrwxrwx 1 root pwm 0 Apr 22 01:22 pwmchip1 ->
../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip1
lrwxrwxrwx 1 root pwm 0 Apr 22 01:22 pwmchip2 ->
../../devices/platform/ocp/48300000.epwmss/48300200.pwm/pwm/pwmchip2
lrwxrwxrwx 1 root pwm 0 Apr 22 01:22 pwmchip4 ->
../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip4
lrwxrwxrwx 1 root pwm 0 Apr 22 01:22 pwmchip6 ->
../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip6
All the pwmchipX dir's look like:
lrwxrwxrwx 1 root root 0 Apr 22 01:24 device -> ../../../48300100.ecap
--w------- 1 root root 4.0K Apr 22 01:24 export
-r--r--r-- 1 root root 4.0K Apr 22 01:24 npwm
drwxr-xr-x 2 root root 0 Apr 22 01:24 power
lrwxrwxrwx 1 root root 0 Apr 22 01:24 subsystem ->
../../../../../../../class/pwm
-rw-r--r-- 1 root root 4.0K Apr 22 01:22 uevent
--w------- 1 root root 4.0K Apr 22 01:24 unexport
with teh 2nd rule
debian@test-bbb-2:/sys/class/pwm/pwmchip0$ ls -lha
total 0
drwxrwxr-x 3 root pwm 0 Apr 22 01:32 .
drwxr-xr-x 3 root root 0 Apr 22 01:32 ..
lrwxrwxrwx 1 root pwm 0 Apr 22 01:32 device -> ../../../48300200.pwm
-rw-rw---- 1 root pwm 4.0K Apr 22 01:32 export
-rw-rw-r-- 1 root pwm 4.0K Apr 22 01:32 npwm
drwxrwxr-x 2 root pwm 0 Apr 22 01:32 power
lrwxrwxrwx 1 root pwm 0 Apr 22 01:32 subsystem ->
../../../../../../../class/pwm
-rw-rw-r-- 1 root pwm 4.0K Apr 22 01:32 uevent
-rw-rw---- 1 root pwm 4.0K Apr 22 01:32 unexport
Regards,
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,
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.
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
Here's my latest gpio udev rule that i'm pushing thru apt
(bb-customizations) package:
Regards,
Wow, the Pine64 community is actually active ? hehe. . .