Cloud9 IDE Update (c9-core-installer_3.1.3543)

[Robert Nelson]

Hey Everyone,

I just pushed out a new Cloud9 IDE update. This fixes one of the
long-standing problems between github.com/c9/core and our version..

"hints" & "autocomplete" things now show up as you start typing stuff..

do i know why it now works, not really... i had tweaked the build
setup, and while testing I just noticed hints are working..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Mark Yoder]

Robert:

  Presently Cloud 9 runs as root.  Would it be possible for it to run as debian instead?  That would mean the examples would have to run with sudo.

Seems like this would be much more secure.

--Mark

[Robert Nelson]

On Thu, Apr 13, 2017 at 9:13 AM, Mark Yoder <mark.a...@gmail.com> wrote:
> Robert:
> Presently Cloud 9 runs as root. Would it be possible for it to run as
> debian instead? That would mean the examples would have to run with sudo.
>
> Seems like this would be much more secure.

With yesterday's build It's actually really really easy:

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#

User=debian

cat /lib/systemd/system/cloud9.service
[Unit]
Description=Cloud9 IDE
ConditionPathExists=|/var/lib/cloud9

[Service]
WorkingDirectory=/opt/cloud9/build/standalonebuild
EnvironmentFile=/etc/default/cloud9
ExecStart=/usr/bin/nodejs server.js --packed -w /var/lib/cloud9
SyslogIdentifier=cloud9ide
User=debian

Still a few issues:

https://i.imgur.com/amVHbaE.png

Apr 13 14:34:29 beaglebone cloud9ide[528]: LISTEN_FDS = 1
Apr 13 14:34:29 beaglebone cloud9ide[528]: Connect server listening at
http://127.0.0.1:3000
Apr 13 14:34:30 beaglebone cloud9ide[528]: CDN: version standalone
initialized /opt/cloud9/build/standalonebuild/build
Apr 13 14:34:30 beaglebone systemd-timesyncd[273]: Synchronized to
time server 154.16.245.246:123 (2.debian.pool.ntp.org).
Apr 13 14:34:32 beaglebone cloud9ide[528]: Started
'/opt/cloud9/build/standalonebuild/configs/standalone' with config
'standalone'!
Apr 13 14:34:32 beaglebone cloud9ide[528]: Cloud9 is up and running
Apr 13 14:34:35 beaglebone cloud9ide[528]: cache
/opt/cloud9/build/standalonebuild/build/standalone/config/default.js
Apr 13 14:34:35 beaglebone cloud9ide[528]: cache hit
/opt/cloud9/build/standalonebuild/build/standalone/config/default.js
Apr 13 14:34:36 beaglebone bonescript-autorun[348]: 4:4:60-ti-r97
Apr 13 14:34:36 beaglebone cloud9ide[528]: cache
/opt/cloud9/build/standalonebuild/build/standalone/skin/default/dark.css
Apr 13 14:34:36 beaglebone cloud9ide[528]: cache hit
/opt/cloud9/build/standalonebuild/build/standalone/skin/default/dark.css
Apr 13 14:34:36 beaglebone bonescript-autorun[348]: info: Starting
bonescript autorun service
Apr 13 14:34:36 beaglebone cloud9ide[528]: cache
/opt/cloud9/build/standalonebuild/build/standalone/modules/ace/theme/cloud9_night_low_color.js
Apr 13 14:34:36 beaglebone cloud9ide[528]: cache hit
/opt/cloud9/build/standalonebuild/build/standalone/modules/ace/theme/cloud9_night_low_color.js
Apr 13 14:34:37 beaglebone cloud9ide[528]: cache
/opt/cloud9/build/standalonebuild/build/standalone/worker/plugins/c9.ide.language.core/worker.js
Apr 13 14:34:37 beaglebone cloud9ide[528]: cache
/opt/cloud9/build/standalonebuild/build/standalone/modules/ace/theme/idle_fingers.js
Apr 13 14:34:37 beaglebone cloud9ide[528]: cache hit
/opt/cloud9/build/standalonebuild/build/standalone/worker/plugins/c9.ide.language.core/worker.js
Apr 13 14:34:37 beaglebone cloud9ide[528]: cache hit
/opt/cloud9/build/standalonebuild/build/standalone/modules/ace/theme/idle_fingers.js
Apr 13 14:34:42 beaglebone cloud9ide[528]: 768: Error: EACCES:
permission denied, open '/opt/cloud9/.c9/user.settings'
Apr 13 14:34:42 beaglebone cloud9ide[528]: at Error (native)
Apr 13 14:34:42 beaglebone cloud9ide[528]: 768: Error: EACCES:
permission denied, open '/var/lib/cloud9/.c9/project.settings'
Apr 13 14:34:42 beaglebone cloud9ide[528]: at Error (native)
Apr 13 14:34:42 beaglebone cloud9ide[528]: 768: Error: EACCES:
permission denied, open '/var/lib/cloud9/.c9/state.settings'
Apr 13 14:34:42 beaglebone cloud9ide[528]: at Error (native)
Apr 13 14:34:42 beaglebone cloud9ide[528]: 768: Error: ENOENT: no such
file or directory, open '/var/lib/cloud9/.c9/metadata/tab2'
Apr 13 14:34:42 beaglebone cloud9ide[528]: at Error (native)
Apr 13 14:34:47 beaglebone cloud9ide[528]: 768: Error: EACCES:
permission denied, open '/var/lib/cloud9/.c9/state.settings'
Apr 13 14:34:47 beaglebone cloud9ide[528]: at Error (native)
Apr 13 14:34:47 beaglebone cloud9ide[528]: 768: Error: EACCES:
permission denied, open '/var/lib/cloud9/.c9/state.settings'
Apr 13 14:34:47 beaglebone cloud9ide[528]: at Error (native)
Apr 13 14:34:59 beaglebone cloud9ide[528]: 768: Error: EACCES:
permission denied, open '/var/lib/cloud9/.c9/state.settings'
Apr 13 14:34:59 beaglebone cloud9ide[528]: at Error (native)

(i'm going to create "cloud9" group and tie /var/lib/cloud9/ and
debian to that group..

and all the examples are broken: (aka |> Run button)

https://i.imgur.com/rNt0TPR.png

So other then all bonescript examples broken, it works. ;)

@Drew, in the python adafruit library you have a gpio/etc debian
permission script, wonder if we should enable that by default, then
the bonescript examples would work as debian user.

[Robert Nelson]

Okay, the permissions are now taken care of:

https://github.com/RobertCNelson/omap-image-builder/commit/7f47e1f6fbbd23835ae14dce0face69c44171378

https://github.com/rcn-ee/repos/commit/be34382757f990d6d6b21de745cd338dbafec0b7

> and all the examples are broken: (aka |> Run button)
>
> https://i.imgur.com/rNt0TPR.png
>
> So other then all bonescript examples broken, it works. ;)
>
> @Drew, in the python adafruit library you have a gpio/etc debian
> permission script, wonder if we should enable that by default, then
> the bonescript examples would work as debian user.

Here's the udev rules:

https://github.com/adafruit/adafruit-beaglebone-io-python/tree/master/udev

[Mark Yoder]

Robert:

  Wow, that was quick.  So then Cloud 9 runs a debian now and the udev script sets all the gpio /sys/ files to be owned by debian.

So do I need to grab next week's build to test it?

--Mark

[Robert Nelson]

On Thu, Apr 13, 2017 at 11:26 AM, Mark Yoder <mark.a...@gmail.com> wrote:
> Robert:

> Wow, that was quick. So then Cloud 9 runs a debian now and the udev
> script sets all the gpio /sys/ files to be owned by debian.

No, it's still root by default.. It's a one line change to get Cloud9
running as debian user via the service file (with a reboot). and i
think that udev rule should make it work without being root. We just
need someone to test it. ;)

> So do I need to grab next week's build to test it?

I just fired up a build, while you could tweak last Sunday's image,
you'd have to manually add the new cloud9ide group and run apt
update/apt upgrade.. or just wait for a test build in about an hour.
;)

[Mark Yoder]

I'll wait for the new image.  It hasn't popped up yet.

--Mark

[Robert Nelson]

On Thu, Apr 13, 2017 at 12:44 PM, Mark Yoder <mark.a...@gmail.com> wrote:
> I'll wait for the new image. It hasn't popped up yet.

yeah, ran into a small problem of install order:

https://github.com/rcn-ee/repos/commit/2b52ed42fa6a33c2e25e42fe68dce582113ced4b

It's almost done. ;)

[Jason Kridner]

> On Apr 12, 2017, at 3:32 PM, Robert Nelson <robert...@gmail.com> wrote:
>
> Hey Everyone,
>
> I just pushed out a new Cloud9 IDE update. This fixes one of the
> long-standing problems between github.com/c9/core and our version..
>
> "hints" & "autocomplete" things now show up as you start typing stuff..
>
> do i know why it now works, not really... i had tweaked the build
> setup, and while testing I just noticed hints are working..

Can a student run all the demos in the Cookbook? How do we make that an every 6 weeks task for students? ;-)

>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>

> --
> You received this message because you are subscribed to the Google Groups "Beagle Alpha" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagle-alpha...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Thu, Apr 13, 2017 at 12:44 PM, Mark Yoder <mark.a...@gmail.com> wrote:

> I'll wait for the new image. It hasn't popped up yet.

Okay give this a shot:

https://rcn-ee.net/rootfs/bb.org/testing/2017-04-13/stretch-iot/

add 'User=debian' to the end of /lib/systemd/system/cloud9.service

and also run:

sudo chown -R :cloud9ide /var/lib/cloud9/ || true
sudo chmod -R g+w /var/lib/cloud9/ || true
sudo chown -R :cloud9ide /opt/cloud9/.c9/ || true
sudo chmod -R g+w /opt/cloud9/.c9/ || true

as for some reason the package still didn't fix those...

[Mark Yoder]

I'm flashing it now.  Wow, things really download fast when you aren't competing with 2000 students.

--Mark

[Mark Yoder]

Well, it's running. Here's a couple of things I notice:

1.  The message "Failed to write to 'state.settings'. Access denied acccessing this file or folder."  Keeps flashing in red above the edit window.

2.  The terminal window starts in /var/lib/cloud9.  (A good place to start.)  Typing cd changes you to /opt/cloud9 which is owned by root. I think it should be /home/debian. 

I'll keep playing around with it.

--Mark

[Robert Nelson]

On Thu, Apr 13, 2017 at 2:31 PM, Mark Yoder <mark.a...@gmail.com> wrote:
> Well, it's running. Here's a couple of things I notice:
>
> 1. The message "Failed to write to 'state.settings'. Access denied
> acccessing this file or folder." Keeps flashing in red above the edit
> window.

That's what this would fix..

sudo chown -R :cloud9ide /var/lib/cloud9/ || true
sudo chmod -R g+w /var/lib/cloud9/ || true
sudo chown -R :cloud9ide /opt/cloud9/.c9/ || true
sudo chmod -R g+w /opt/cloud9/.c9/ || true

but you can try:

sudo apt update ; sudo apt upgrade

as i pushed another new bone101/c9-core-installer update which should do above ^

>
> 2. The terminal window starts in /var/lib/cloud9. (A good place to start.)
> Typing cd changes you to /opt/cloud9 which is owned by root. I think it
> should be /home/debian.

/opt/cloud9/ is the home directory for cloud9 application. ;)

otherwise i haven't found where that is spawn'ed yet..

[Robert Nelson]

On Thu, Apr 13, 2017 at 2:35 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Thu, Apr 13, 2017 at 2:31 PM, Mark Yoder <mark.a...@gmail.com> wrote:
>> Well, it's running. Here's a couple of things I notice:
>>
>> 1. The message "Failed to write to 'state.settings'. Access denied
>> acccessing this file or folder." Keeps flashing in red above the edit
>> window.
>
> That's what this would fix..
>
> sudo chown -R :cloud9ide /var/lib/cloud9/ || true
> sudo chmod -R g+w /var/lib/cloud9/ || true
> sudo chown -R :cloud9ide /opt/cloud9/.c9/ || true
> sudo chmod -R g+w /opt/cloud9/.c9/ || true
>
> but you can try:
>
> sudo apt update ; sudo apt upgrade
>
> as i pushed another new bone101/c9-core-installer update which should do above ^

finally, those directories have the correct permissions on a clean build. ;)

Have you had any luck with Drew's udev rule?

[Mark Yoder]

Yup, the chown/chmod fixed it, and the apt upgrade appears to have worked too.

As for the udev rules, no.  I still need to sudo to access the gpio pins.  Looks like everything is still root:root.

dmesg[1] doesn't seem to show anything.

--Mark

[1] http://paste.debian.net/927517/ 

[Mark Yoder]

Hmmm....  nothing in /etc/udev/rules.d.  Looks like it didn't install.

--Mark

[Robert Nelson]

On Thu, Apr 13, 2017 at 2:57 PM, Mark Yoder <mark.a...@gmail.com> wrote:
> Yup, the chown/chmod fixed it, and the apt upgrade appears to have worked
> too.
>
> As for the udev rules, no. I still need to sudo to access the gpio pins.
> Looks like everything is still root:root.
>
> dmesg[1] doesn't seem to show anything.
>
> --Mark
>
> [1] http://paste.debian.net/927517/

Did you add the udev rule? It's not packaged.. and i just tried it,
maybe Drew knows what's going on:

installed via:

wget https://github.com/adafruit/adafruit-beaglebone-io-python/raw/master/udev/80-non-root-gpio-permissions.rules
wget https://github.com/adafruit/adafruit-beaglebone-io-python/raw/master/udev/udev-non-root-gpio-permissions.sh
sudo mv udev-non-root-gpio-permissions.sh /usr/local/bin/
sudo chmod +x /usr/local/bin/udev-non-root-gpio-permissions.sh
sudo mv 80-non-root-gpio-permissions.rules /etc/udev/rules.d/
sudo reboot


BUT serial login is toast:

[ OK ] Reached target Host and Network Name Lookups.
[ TIME ] Timed out waiting for device dev-ttyS0.device.
[DEPEND] Dependency failed for Serial Getty on ttyS0.
[ TIME ] Timed out waiting for device dev-ttyGS0.device.
[DEPEND] Dependency failed for Serial Getty on ttyGS0.
[ OK ] Reached target Login Prompts.
[ OK ] Started Generic Board Startup.
Starting BB WL18xx Bluetooth Service...
[ OK ] Started BB WL18xx Bluetooth Service.
[ OK ] Reached target Multi-User System.
[ OK ] Reached target Graphical Interface.
Starting Update UTMP about System Runlevel Changes...
[ OK ] Started Update UTMP about System Runlevel Changes.

<aka no login prompt>

ssh over eth0 works..

debian@beaglebone:~$ ls -lh /sys/class/gpio/
total 0
--w--w---- 1 debian debian 4.0K Apr 13 19:57 export
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio112 ->
../../devices/platform/ocp/481ae000.gpio/gpio/gpio112
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio114 ->
../../devices/platform/ocp/481ae000.gpio/gpio/gpio114
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio115 ->
../../devices/platform/ocp/481ae000.gpio/gpio/gpio115
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio116 ->
../../devices/platform/ocp/481ae000.gpio/gpio/gpio116
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio14 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio14
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio15 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio15
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio2 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio2
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio20 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio20
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio22 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio22
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio23 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio23
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio26 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio26
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio27 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio27
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio3 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio3
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio30 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio30
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio31 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio31
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio4 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio4
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio44 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio44
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio45 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio45
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio46 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio46
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio47 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio47
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio48 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio48
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio49 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio49
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio5 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio5
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio50 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio50
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio51 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio51
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio60 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio60
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio61 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpio61
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio65 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpio65
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio66 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpio66
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio67 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpio67
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio68 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpio68
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio69 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpio69
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpio7 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio7
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpiochip0 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpiochip32 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpiochip32
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpiochip64 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpiochip64
lrwxrwxrwx 1 debian debian 0 Apr 13 19:57 gpiochip96 ->
../../devices/platform/ocp/481ae000.gpio/gpio/gpiochip96
--w--w---- 1 debian debian 4.0K Apr 13 19:57 unexport

blinkled.js still fails...

[Mark Yoder]

That was it.  gpio seems to be working now as debian.  I'll keep playing...

--Mark

[Mark Yoder]

I'll ask about student support.  If the student is directly supporting the class, I think it can be done.  However if the student is supporting an outside project it get trickier.

Could we pay a student?  

--Mark

[Robert Nelson]

On Thu, Apr 13, 2017 at 3:07 PM, Mark Yoder <mark.a...@gmail.com> wrote:
> That was it. gpio seems to be working now as debian. I'll keep playing...

Okay got gpio working and it's not locking up the serial port:

chown -R root:gpio /sys/class/gpio
chmod -R ug+rw /sys/class/gpio

https://github.com/RobertCNelson/boot-scripts/commit/dfd4241c909000837a1ebb7fb6c3d474def8e52f

and this udev rule:

https://github.com/rcn-ee/repos/blob/master/bb-bb-customizations/suite/jessie/debian/80-gpio-noroot.rules

[Mark Yoder]

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

[Mark Yoder]

The last URL should be:

https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/jessie/debian/80-gpio-noroot.rules

[Mark Yoder]

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

[Robert Nelson]

On Tue, Apr 18, 2017 at 4:31 PM, Mark Yoder <mark.a...@gmail.com> wrote:
> 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.

As long as it doesn't ask you to install a bunch of stuff under '.c9'

[Robert Nelson]

On Tue, Apr 18, 2017 at 4:40 PM, Mark Yoder <mark.a...@gmail.com> wrote:
> I'm not getting the gpio permissions to work. I think there are two methods
> posted here.
>
> Could you repost the one the works?

Just:

sudo apt update ; sudo apt upgrade

and

cd /opt/scripts/
git pull

sudo reboot

[Mark Yoder]

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

[Robert Nelson]

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. ;)

[Mark A. Yoder]

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

[Robert Nelson]

On Fri, Apr 21, 2017 at 12:36 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:
> I'll grab the new image when I see it. Does debian by default mean the bash
> window has /home/debian as its home?

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)

[Robert Nelson]

On Fri, Apr 21, 2017 at 1:39 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Fri, Apr 21, 2017 at 12:36 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:
>> I'll grab the new image when I see it. Does debian by default mean the bash
>> window has /home/debian as its home?

Okay it's up:

https://rcn-ee.net/rootfs/bb.org/testing/2017-04-21/stretch-iot/

[Robert Nelson]

On Fri, Apr 21, 2017 at 3:27 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Fri, Apr 21, 2017 at 1:39 PM, Robert Nelson <robert...@gmail.com> wrote:
>> On Fri, Apr 21, 2017 at 12:36 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:
>>> I'll grab the new image when I see it. Does debian by default mean the bash
>>> window has /home/debian as its home?
>
> Okay it's up:
>
> https://rcn-ee.net/rootfs/bb.org/testing/2017-04-21/stretch-iot/

cd /opt/scripts/
git pull

fixes: blinkled.js

https://github.com/RobertCNelson/boot-scripts/commit/e71f9f8f0104f47d3836458f90f8001738f5e835

[Robert Nelson]

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==""

[William Hermans]

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.

[William Hermans]

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.

[Robert Nelson]

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

[Robert Nelson]

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

[William Hermans]

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. 

[Robert Nelson]

On Thu, Apr 27, 2017 at 4:27 PM, Metelko <mary....@gmail.com> wrote:
> 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.

Here's my latest gpio udev rule that i'm pushing thru apt
(bb-customizations) package:

https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/jessie/debian/80-gpio-noroot.rules

[William Hermans]

Wow, the Pine64 community is actually active ? hehe. . .

--
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 beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYiBjbmZgZ4BdPc%2BYX1r7jvR2KmGcX%2BpeBiHGhtRDYT%3Duw%40mail.gmail.com.

[Robert Nelson]

On Thu, Apr 27, 2017 at 4:39 PM, William Hermans <yyr...@gmail.com> wrote:
> Wow, the Pine64 community is actually active ? hehe. . .

Yeah i stole that from them..

with cape-universal/u0boot overlays/4.9.25-ti-r31.2

all came up root:gpio

debian@beaglebone:/sys/class/gpio$ ls -lha
total 0
drwxrwxr-x 2 root gpio 0 Apr 27 21:38 .
drwxr-xr-x 61 root root 0 Apr 27 21:38 ..
-rw-rw---- 1 root gpio 4.0K Apr 27 21:38 export
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio112 ->
../../devices/platform/ocp/481ae000.gpio/gpiochip3/gpio/gpio112
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio114 ->
../../devices/platform/ocp/481ae000.gpio/gpiochip3/gpio/gpio114
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio115 ->
../../devices/platform/ocp/481ae000.gpio/gpiochip3/gpio/gpio115
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio116 ->
../../devices/platform/ocp/481ae000.gpio/gpiochip3/gpio/gpio116
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio14 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio14
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio15 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio15
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio2 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio2
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio20 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio20
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio22 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio22
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio23 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio26 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio26
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio27 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio27
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio3 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio3
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio30 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio30
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio31 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio31
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio4 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio4
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio44 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio44
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio45 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio45
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio46 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio46
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio47 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio47
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio48 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio48
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio49 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio49
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio5 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio5
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio50 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio50
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio51 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio51
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio60 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio60
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio61 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio61
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio65 ->
../../devices/platform/ocp/481ac000.gpio/gpiochip2/gpio/gpio65
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio66 ->
../../devices/platform/ocp/481ac000.gpio/gpiochip2/gpio/gpio66
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio67 ->
../../devices/platform/ocp/481ac000.gpio/gpiochip2/gpio/gpio67
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio68 ->
../../devices/platform/ocp/481ac000.gpio/gpiochip2/gpio/gpio68
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio69 ->
../../devices/platform/ocp/481ac000.gpio/gpiochip2/gpio/gpio69
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpio7 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio7
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpiochip0 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpiochip32 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpiochip32
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpiochip64 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpiochip64
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 gpiochip96 ->
../../devices/platform/ocp/481ae000.gpio/gpio/gpiochip96
-rw-rw---- 1 root gpio 4.0K Apr 27 21:38 unexport

[Robert Nelson]

and inside one:

debian@beaglebone:/sys/class/gpio/gpio2$ ls -lha
total 0
drwxrwxr-x 3 root gpio 0 Apr 27 21:38 .
drwxrwxr-x 16 root gpio 0 Apr 27 21:38 ..
-rw-rw-r-- 1 root gpio 4.0K Apr 27 21:38 active_low
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 device -> ../../../gpiochip0
-rw-rw-r-- 1 root gpio 4.0K Apr 27 21:38 direction
-rw-rw-r-- 1 root gpio 4.0K Apr 27 21:38 edge
-rw-rw-r-- 1 root gpio 4.0K Apr 27 21:38 label
drwxrwxr-x 2 root gpio 0 Apr 27 21:38 power
lrwxrwxrwx 1 root gpio 0 Apr 27 21:38 subsystem ->
../../../../../../../class/gpio
-rw-rw-r-- 1 root gpio 4.0K Apr 27 21:38 uevent
-rw-rw-r-- 1 root gpio 4.0K Apr 27 21:38 value

[William Hermans]

Still having issues with PWM ?

--
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 beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjVk5McHfV2pE8mWN1EbY3tO%2B316SgAa878mPExhAvcSQ%40mail.gmail.com.

[William Hermans]

By the way, I think the small amount I talked about udev, and permissions on my git for bonejs. I pretty much got most of that information from rPI content all over the web. I did have to make several modifications though . ..

[Robert Nelson]

On Thu, Apr 27, 2017 at 4:43 PM, William Hermans <yyr...@gmail.com> wrote:
> Still having issues with PWM ?

Yeah i took a break from that, PWM was too painful..

Fixed an LCD and the v4.4.x-bone/v4.4.x-rt-bone u-boot overlay problem
some users where having..

So let's try the pwm with v4.9.x ;)

[William Hermans]

On Thu, Apr 27, 2017 at 2:46 PM, Robert Nelson <robert...@gmail.com> wrote:

On Thu, Apr 27, 2017 at 4:43 PM, William Hermans <yyr...@gmail.com> wrote:
> Still having issues with PWM ?

Yeah i took a break from that, PWM was too painful..

Fixed an LCD and the v4.4.x-bone/v4.4.x-rt-bone u-boot overlay problem
some users where having..

So let's try the pwm with v4.9.x ;)

At this very moment I'm in the process of re-writing an overlay for an *ahem* undisclosed cape that just so happens to enable 6 channel PWM on the board. After that, I have to write hardware test software for that same board( test jig ). So maybe I'll be able to document all the udev rules I have to make for that board. Maybe, because now I'm thinking I may not be able to pull that off in a short amount of time. If I do though, I'll relay that information to you.

[Robert Nelson]

On Thu, Apr 27, 2017 at 4:46 PM, William Hermans <yyr...@gmail.com> wrote:
> By the way, I think the small amount I talked about udev, and permissions on
> my git for bonejs. I pretty much got most of that information from rPI
> content all over the web. I did have to make several modifications though .

if only they had a pwm udev rule. ;)

still no go with v4.9.x-ti

debian@beaglebone:/sys/class/pwm$ ls -lha
total 0
drwxrwxr-x 2 root pwm 0 Apr 27 21:39 .
drwxr-xr-x 61 root root 0 Apr 27 21:39 ..
lrwxrwxrwx 1 root pwm 0 Apr 27 21:39 pwmchip0 ->
../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip0
lrwxrwxrwx 1 root pwm 0 Apr 27 21:39 pwmchip1 ->
../../devices/platform/ocp/48300000.epwmss/48300200.pwm/pwm/pwmchip1
lrwxrwxrwx 1 root pwm 0 Apr 27 21:39 pwmchip3 ->
../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip3
lrwxrwxrwx 1 root pwm 0 Apr 27 21:39 pwmchip5 ->
../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5
lrwxrwxrwx 1 root pwm 0 Apr 27 21:39 pwmchip6 ->
../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip6

debian@beaglebone:/sys/class/pwm/pwmchip3$ ls -lha
total 0
drwxrwxr-x 4 root pwm 0 Apr 27 21:48 .
drwxr-xr-x 3 root root 0 Apr 27 21:38 ..
lrwxrwxrwx 1 root pwm 0 Apr 27 21:39 device -> ../../../48302200.pwm
-rw-rw---- 1 root pwm 4.0K Apr 27 21:39 export
-rw-rw-r-- 1 root pwm 4.0K Apr 27 21:39 npwm
drwxrwxr-x 2 root pwm 0 Apr 27 21:39 power
drwxr-xr-x 3 root root 0 Apr 27 21:48 pwm0
lrwxrwxrwx 1 root pwm 0 Apr 27 21:39 subsystem ->
../../../../../../../class/pwm
-rw-rw-r-- 1 root pwm 4.0K Apr 27 21:39 uevent
-rw-rw---- 1 root pwm 4.0K Apr 27 21:39 unexport

debian@beaglebone:/sys/class/pwm/pwmchip3/pwm0$ ls -lha
total 0
drwxr-xr-x 3 root root 0 Apr 27 21:49 .
drwxrwxr-x 4 root pwm 0 Apr 27 21:48 ..
-r--r--r-- 1 root root 4.0K Apr 27 21:50 capture
-rw-r--r-- 1 root root 4.0K Apr 27 21:50 duty_cycle
-rw-r--r-- 1 root root 4.0K Apr 27 21:48 enable
-rw-r--r-- 1 root root 4.0K Apr 27 21:50 period
-rw-r--r-- 1 root root 4.0K Apr 27 21:50 polarity
drwxr-xr-x 2 root root 0 Apr 27 21:50 power
-rw-r--r-- 1 root root 4.0K Apr 27 21:50 uevent

the "pwm0" node always comes up root:root..

[William Hermans]

@Robert,

I'm thinking at  this point in time, that we may have to fall off the last creation of files in that path, and do single file permission changes, would would be tedious, and painful. So whatever the last path to be created, you run the udev rule off that, and just traverse down into the exact files you need. Maybe some sort of wild card sorting could be used ? I'm not sure, but I'm thinking we'd need to do something like enable pwmchip0, enable both channels on that, then enable each file seperately for period, and duty cycle. Then whatever other files needs to be changed for access.

[Robert Nelson]

yeah take the first two blocks:

https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/jessie/debian/81-pwm-noroot.rules

it's enough to let you do:

debian@beaglebone:/sys/class/pwm/pwmchip3$ echo 0 > export

debian@beaglebone:/sys/class/pwm/pwmchip3$ echo 0 > unexport

but you have to be root to change pwm0/* after..

[Robert Nelson]

it works for gpio... so i wonder if we need to patch the pwm's kernel
permissions....

[William Hermans]

On Thu, Apr 27, 2017 at 2:59 PM, William Hermans <yyr...@gmail.com> wrote:

On Thu, Apr 27, 2017 at 2:56 PM, Robert Nelson <robert...@gmail.com> wrote:

On Thu, Apr 27, 2017 at 4:55 PM, William Hermans <yyr...@gmail.com> wrote:
> @Robert,

it works for gpio... so i wonder if we need to patch the pwm's kernel
permissions....

Maybe, but if you have other things that are more important right now, I can look into this today / tonight, and give you a short term answer if no, then long term if yes.

Opps, didn't mean that to go directly to you only. Hate gmail sometimes . .. Anyway, schematics to sift through, overlay to write . . . Not often I get the chance to do work for the boss, and the community at the same time so . . .

[Robert Nelson]

so pwm (pwmchip_sysfs_export), uses: device_create

Whereas gpio (gpiod_export) uses: device_create_with_groups

[Robert Nelson]

https://lkml.org/lkml/2016/6/14/967

[William Hermans]

On Thu, Apr 27, 2017 at 3:15 PM, William Hermans <yyr...@gmail.com> wrote:

On Thu, Apr 27, 2017 at 3:12 PM, Robert Nelson <robert...@gmail.com> wrote:

https://lkml.org/lkml/2016/6/14/967

Ouch, so sounds like a boot script hack is the only way right now ?

Sorry, did it again, twice.

[Robert Nelson]

On Thu, Apr 27, 2017 at 5:15 PM, William Hermans <yyr...@gmail.com> wrote:

>
>
> On Thu, Apr 27, 2017 at 3:12 PM, Robert Nelson <robert...@gmail.com>
> wrote:
>>
>>
>> https://lkml.org/lkml/2016/6/14/967
>>
>
> Ouch, so sounds like a boot script hack is the only way right now ?

Yay! That patch did it. now to figure out where it is in the patchqueue..

Sorry Jason/Drew/Mark, looks like i'm breaking pwm in
bonescript/adafruit/etc.. "pwm0" -> "pwm-0:0"


debian@beaglebone:/sys/class/pwm/pwmchip0$ ls -lha
total 0
drwxrwxr-x 3 root pwm 0 Apr 27 22:16 .
drwxr-xr-x 3 root root 0 Apr 27 22:12 ..
lrwxrwxrwx 1 root pwm 0 Apr 27 22:16 device -> ../../../48300100.ecap
-rw-rw---- 1 root pwm 4.0K Apr 27 22:16 export
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 npwm
drwxrwxr-x 2 root pwm 0 Apr 27 22:16 power
lrwxrwxrwx 1 root pwm 0 Apr 27 22:16 subsystem ->
../../../../../../../class/pwm
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 uevent
-rw-rw---- 1 root pwm 4.0K Apr 27 22:16 unexport
debian@beaglebone:/sys/class/pwm/pwmchip0$ echo 0 > export

debian@beaglebone:/sys/class/pwm/pwmchip0$ ls -lha
total 0
drwxrwxr-x 4 root pwm 0 Apr 27 22:16 .
drwxr-xr-x 3 root root 0 Apr 27 22:16 ..
lrwxrwxrwx 1 root pwm 0 Apr 27 22:16 device -> ../../../48300100.ecap
-rw-rw---- 1 root pwm 4.0K Apr 27 22:16 export
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 npwm
drwxrwxr-x 2 root pwm 0 Apr 27 22:16 power
drwxrwxr-x 3 root pwm 0 Apr 27 22:16 pwm-0:0
lrwxrwxrwx 1 root pwm 0 Apr 27 22:16 subsystem ->
../../../../../../../class/pwm
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 uevent
-rw-rw---- 1 root pwm 4.0K Apr 27 22:16 unexport
debian@beaglebone:/sys/class/pwm/pwmchip0$ cd pwm-0\:0/

debian@beaglebone:/sys/class/pwm/pwmchip0/pwm-0:0$ ls -lha
total 0
drwxrwxr-x 3 root pwm 0 Apr 27 22:16 .
drwxrwxr-x 4 root pwm 0 Apr 27 22:16 ..
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 capture
lrwxrwxrwx 1 root pwm 0 Apr 27 22:16 device -> ../../pwmchip0
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 duty_cycle
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 enable
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 period
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 polarity
drwxrwxr-x 2 root pwm 0 Apr 27 22:16 power
lrwxrwxrwx 1 root pwm 0 Apr 27 22:16 subsystem ->
../../../../../../../../class/pwm
-rw-rw-r-- 1 root pwm 4.0K Apr 27 22:16 uevent

[William Hermans]

It'll break bonejs too, but I can live with that. Just an additional two characters in a string somewhere in my code. A few times . . .hehe

[William Hermans]

On Thu, Apr 27, 2017 at 3:22 PM, William Hermans <yyr...@gmail.com> wrote:

It'll break bonejs too, but I can live with that. Just an additional two characters in a string somewhere in my code. A few times . . .hehe

Actually, it won't break my implementation at all. Just need to change how the implementation is used. pwm(0, 0.0 ) instead of pwm(0, 0).  Short term fix, long term, maybe I should stick with pwm(0, 0) and change the implementation parsing. *shrug*

[Robert Nelson]

It's a little more then that, the first 0 comes from parent:

/sys/class/pwm/pwmchip0/pwm-0:0

/sys/class/pwm/pwmchipA/pwm-A:B

[William Hermans]

On Thu, Apr 27, 2017 at 5:06 PM, Robert Nelson <robert...@gmail.com> wrote:

It's a little more then that, the first 0 comes from parent:

/sys/class/pwm/pwmchip0/pwm-0:0

/sys/class/pwm/pwmchipA/pwm-A:B

Right, with my implementation as it sits. pwm(x, y) where pwmchipx, -> pwmy. x being the pwmchip numerical number, y being the actual pwm channel( 0 or 1 ) in relation to that pwmchip. So if I passed in something like pwm(0, 0), I could use the first zero as the pwmchipx number, and then use both numbers to build the channel y number . . .javascript makes this really easy, almost too easy.

It's pretty awesome this will be fixed though. So when all said and done, this could be fixed by installing a new kernel, without contaminating the rest of the system. right ? I'm kind of cringing at the idea of a kernel change right now, I have everything exactly how I want it :/

[Robert Nelson]

it's a pretty small patch:

https://patchwork.kernel.org/patch/9177249/raw/

Documentation/pwm.txt | 6 ++++--
drivers/pwm/sysfs.c | 15 ++++++++++++---
2 files changed, 16 insertions(+), 5 deletions(-)

I tried pinging the author David Hsu, but his email address is disabled.

[William Hermans]

On Thu, Apr 27, 2017 at 7:07 PM, Robert Nelson <robert...@gmail.com> wrote:

it's a pretty small patch:

https://patchwork.kernel.org/patch/9177249/raw/

 Documentation/pwm.txt |    6 ++++--
 drivers/pwm/sysfs.c   |   15 ++++++++++++---
 2 files changed, 16 insertions(+), 5 deletions(-)

I tried pinging the author David Hsu, but his email address is disabled.

Right now, or at least last I checked( a few months ago ) the naming in DT's was as thus:

"ehrpwm0A",
"ehrpwm0B",
"ehrpwm1A",
"ehrpwm1B",
"ehrpwm2A",
"ehrpwm2B";

This wont change will it ? Only in sysfs, right ?

[Robert Nelson]

Correct just the sysfs names.. of course that's what every user space application uses..

Regards,

[Metelko]

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

[Metelko]

Thanks Robert!  That seemed to have worked.  I can control it from my user account.  I do believe we will be working with PWM devices soon, so I will watch for any updates on that.

/sys/class/gpio/gpio43$ ls -al

total 0

drwxrwxr-x 3 root gpio    0 Apr 27 21:48 .

drwxrwxr-x 3 root gpio    0 Apr 27 21:48 ..

-rw-rw-r-- 1 root gpio 4096 Apr 27 21:48 active_low

lrwxrwxrwx 1 root gpio    0 Apr 27 21:48 device -> ../../../gpiochip1

-rw-rw-r-- 1 root gpio 4096 Apr 27 21:48 direction

-rw-rw-r-- 1 root gpio 4096 Apr 27 21:48 edge

-rw-rw-r-- 1 root gpio 4096 Apr 27 21:48 label

drwxrwxr-x 2 root gpio    0 Apr 27 21:48 power

lrwxrwxrwx 1 root gpio    0 Apr 27 21:48 subsystem -> ../../../../../../../class/gpio

-rw-rw-r-- 1 root gpio 4096 Apr 27 21:48 uevent

-rw-rw-r-- 1 root gpio 4096 Apr 27 21:48 value

[Metelko]

I have updated my system starting with a base image from:  https://rcn-ee.com/rootfs/2017-04-07/elinux/ubuntu-16.04.2-console-armhf-2017-04-07.tar.xz

Then updating the kernel:  Linux bbb-266a 4.9.30-ti-rt-r37 #1 SMP PREEMPT RT Sun May 28 15:55:20 UTC 2017 armv7l armv7l armv7l GNU/Linux

I am using the udev rule previously suggested: 80-gpio-no-root.rules

    # /etc/udev/rules.d/80-gpio-noroot.rules

    #

    # From: https://forum.pine64.org/showthread.php?tid=2233

    #

    # Corrects sys GPIO permissions on the Pine64 so non-root users in the gpio group can manipulate bits

    #

    # Change group to gpio

    SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chown -R root:gpio /sys/devices/platform/ocp/*.gpio'"

    # Change user permissions to ensure user and group have read/write permissions

    SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chmod -R ug+rw /sys/devices/platform/ocp/*.gpio'"

I am still able to manually export gpio pins from the non-root user account and control the GPIO (echo 50 >> export in /sys/class/gpio directory).  But I am using Adafruit_BBIO to do it in software.  When we discussed this last (April 27, 2017), I was able to control it from a user account using Adafruit_BBIO in a python application.  Now I am getting a permission error.  Did something change in the last month that would effect this?  I do not see any changes to Adafruit_BBIO that would impact this.

    Python 3.5.2 (default, Nov 17 2016, 17:05:23)

    [GCC 5.4.0 20160609] on linux

    Type "help", "copyright", "credits" or "license" for more information.

    >>> import Adafruit_BBIO.GPIO as GPIO

    >>> GPIO.setup("P8_15", GPIO.OUT)

    Traceback (most recent call last):

      File "<stdin>", line 1, in <module>

    ValueError: Set gpio direction failed, missing file or invalid permissions.

Kindest regards,
Mary

[William Hermans]

You could see if that is in fact a permissions error by running the python script as root. If it runs without error, then something in the BBIO library is not quite ready for prime time yet. My guess is that it would be a simple pathing issue. e.g. the pathing in the update BBIO library is not quite up to date.

[Mary Metelko]

The Adafruit_BBIO code usage does work when the user is root.  

Kindest regards,

Mary

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/kKLf8zWAfoM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrREBLNGPY14436sGgaXKMH9wzSrwK1ce6e%2Bg6ieNoKMQ%40mail.gmail.com.

[William Hermans]

On Thu, Jun 1, 2017 at 5:13 PM, Mary Metelko <mary.m...@gmail.com> wrote:

The Adafruit_BBIO code usage does work when the user is root.  

Then it's a matter of permissions. Which means you need to adjust permission forr the user using those applications. Make udev rules for the hardware you're using to allow a group to use that hardware, then add that user to that group. Or just run the application as root.

FYI, startup scripts run in the traditional manner all run as root anyhow. So perhaps running as root is the optimal fix ?

[Robert Nelson]

On Thu, Jun 1, 2017 at 7:13 PM, Mary Metelko <mary.m...@gmail.com> wrote:
> The Adafruit_BBIO code usage does work when the user is root.

The goal with the Stretch images is to fix that..

Right now the gpio's can be exported/etc by "debian or any user in
"gpio" group" pwm is close, but i need to break userspace, so waiting
for all the nodejs libraies to get fixed, before i break that..

So, let us "know" which calls don't work in Stretch:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_testing

Side note, these "rootless" changes are happening in stretch "first"..

[Mary Metelko]

Thank you for your input.  Upon further testing, my application is working using Adafruit_BBIO.  I must have forgotten a step when I was doing it manually using python3.  

--

Kindest regards,

Mary

“The more you know, the more you know you don’t know.”  — Aristotle