On Fri, Apr 21, 2017 at 3:11 PM, Robert Nelson <[email protected]> wrote:
> On Fri, Apr 21, 2017 at 3:44 PM, Robert Nelson <[email protected]> > wrote: > > On Fri, Apr 21, 2017 at 3:27 PM, Robert Nelson <[email protected]> > wrote: > >> On Fri, Apr 21, 2017 at 1:39 PM, Robert Nelson <[email protected]> > wrote: > >>> On Fri, Apr 21, 2017 at 12:36 PM, Mark A. Yoder < > [email protected]> 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 > > 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=="" > > 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. -- 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/CALHSORrp1xcLFO4HCJrApD0R08VVWp_yW2E06TcFaPr-N%3D-iVQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
