Oh, right so just two ways of configure-ring, and using the same pin ? Yeah, no big deal to me, I'd just never use P9_92, and haven't to date.
On Tue, Jul 26, 2016 at 10:33 PM, William Hermans <[email protected]> wrote: > Charles, > > Is there a way through modifying your overlay files to put an output pin > in a specific state as the overlay file is loaded ? I noticed one can > change input to output as needed in fragment@2. But do not see a way to > change pin state. unless if it'll work if i replace "input" with hi, or low > ? I've replaced with "output" and that works . . . e.g. > > P8_07 { > gpio-name = "P8_07"; > gpio = <&gpio2 2 0>; > *input;* > dir-changeable; > }; > > On Wed, Jul 20, 2016 at 11:33 AM, William Hermans <[email protected]> > wrote: > >> You can replace cape_universal by the libpruio universal overlay. That >>> doesn't enable drivers/subsystems (= saves power and resources >>> consumptions), but has the same pinmuxing capability. It's even more safe, >>> since it seems that cape_universal can damage your CPU by a sequence like >>> >>> config-pin P9_42 gpio high >>> config-pin P9_92 gpio low >>> >>> (I didn't test it, but if you do so, please report.) >> >> >> O, wait, did I miss something here ? Originally I read that as a single >> pin but instead now am seeing two different pins. Are these one of those >> dual accessed pin cases in the BBB ? If so, what's the implications ? >> >> On Wed, Jul 20, 2016 at 11:28 AM, William Hermans <[email protected]> >> wrote: >> >>> You can replace cape_universal by the libpruio universal overlay. That >>>> doesn't enable drivers/subsystems (= saves power and resources >>>> consumptions), but has the same pinmuxing capability. It's even more safe, >>>> since it seems that cape_universal can damage your CPU by a sequence like >>>> >>>> config-pin P9_42 gpio high >>>> config-pin P9_92 gpio low >>>> >>>> (I didn't test it, but if you do so, please report.) >>>> >>> >>> Ok, maybe, but any smart engineer should have pin isolation built into >>> their circuitry. Here, we were using buffers, but now we're going to try bi >>> powered FET's( sorry I'm not an EE so not sure that's the proper term ). >>> But basically a MOSFET that has to be powered from both sides of the >>> connection before the given "buffered" IO can complete it's circuit. >>> >>> >>> Regarding other capes, libpruio ships with a tool to adapt the universal >>> device tree overlay. It can generate overlays that do not claim a specified >>> set of pins. Instead of fiddling with device tree entries, you just list >>> the pins you want to get freed and let the tool deal with the low-level >>> stuff. Such an overlay can get loaded before or after any other cape >>> overlay. >>> >>> In order to replace the config_pin tool, you can write small programs >>> (compiled against libpruio), which do the pinmuxing and enable the >>> subsystems in use (only that ones). >>> >>> BR >>> >>> >>> Here's the deal. I plan on creating a web interface for universal-io + >>> config-pin. So a user can eventually open up the web page that comes with >>> the beaglebone, and configure their IO / peripherals from a web front end. >>> No idea if that is possible with your stuff, but more importantly, I've >>> spent a good amount of my spare time looking into doing this with universal >>> IO. Which my time is much more finite lately than in the past. So I can not >>> afford to go around and research every possible way to do a thing, under >>> the sun. >>> >>> I know universal IO well enough now to make this happen once I get the >>> time to createthe web front end stuff. But I already have the back-end >>> written. Well, I have the Bonejs wrapper library which took me only a few >>> days a couple hours here and there . . .But the rest will take some time as >>> I learn how to get data from the Nodejs backend, to a web front end, such >>> as Angular, and I do not know what else right now . . . >>> >>> Also for what it's worth. You do not need cape_universal=enable does not >>> need to be enabled in order to use config-pin, and universal IO. >>> >>> On Wed, Jul 20, 2016 at 11:06 AM, William Hermans <[email protected]> >>> wrote: >>> >>>> If we create gpio/pinmux group, I think we could keep from burdening >>>> users while moving Cloud9 IDE to the 'debian' user. I believe we also have >>>> a sudoers for the 'debian' user, meaning we could probably at that point >>>> prevent direct root login unless someone does something to disable the root >>>> password. I'd worry about that breaking things like LabVIEW, etc., but if >>>> we can at least try out some minor steps towards security, it will at least >>>> make everyone more aware of the holes and challenges. >>>> >>>> I kind of roughly describe that here: >>>> https://github.com/wphermans/Bonejs/blob/master/documentation/permissions.md >>>> Although there is much mroe to consider than just the little bit I covered >>>> there. But that should be a good start. >>>> >>>> On Wed, Jul 20, 2016 at 11:00 AM, Jason Kridner < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Jun 24, 2016 at 8:10 PM Charles Steinkuehler < >>>>> [email protected]> wrote: >>>>> >>>>>> On 6/24/2016 5:52 PM, William Hermans wrote: >>>>>> > /Note the security 'bar' is not set particularly high, given >>>>>> the/ >>>>>> > /default BBB images have no root password. :)/ >>>>>> > >>>>>> > >>>>>> > Thats been changed, since at least the last couple of images. >>>>>> >>>>> >>>>> I don't think that's the case---we still have no root password, though >>>>> one can be set. The Cloud9 IDE further doesn't require a login. >>>>> >>>>> If we create gpio/pinmux group, I think we could keep from burdening >>>>> users while moving Cloud9 IDE to the 'debian' user. I believe we also have >>>>> a sudoers for the 'debian' user, meaning we could probably at that point >>>>> prevent direct root login unless someone does something to disable the >>>>> root >>>>> password. I'd worry about that breaking things like LabVIEW, etc., but if >>>>> we can at least try out some minor steps towards security, it will at >>>>> least >>>>> make everyone more aware of the holes and challenges. >>>>> >>>>> >>>>>> >>>>>> Ahh...that's probably why you were getting the "askpass" errors. >>>>>> >>>>>> I haven't tried anything more recent than a few months ago. >>>>>> >>>>>> -- >>>>>> Charles Steinkuehler >>>>>> [email protected] >>>>>> >>>>>> -- >>>>>> 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/d19cdd9b-9ae5-08a8-6028-cecbbea7d4f8%40steinkuehler.net >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>>> 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/CA%2BT6QPmBBQk0hy%2Bwz3ktPnaUYNoKC9aSvNK7y-xGDNc7gKaqUg%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmBBQk0hy%2Bwz3ktPnaUYNoKC9aSvNK7y-xGDNc7gKaqUg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>> >> > -- 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/CALHSORoanzL5SU28Wj-tdbxdhgHgAG7ex6xrkHL1X06RZnor5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
