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 <yyrk...@gmail.com> 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 <yyrk...@gmail.com>
> 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 <yyrk...@gmail.com>
>> 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 <
>>> jason.krid...@hangerhead.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jun 24, 2016 at 8:10 PM Charles Steinkuehler <
>>>> char...@steinkuehler.net> 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
>>>>> char...@steinkuehler.net
>>>>>
>>>>> --
>>>>> 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+unsubscr...@googlegroups.com.
>>>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>>> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CALHSORpp974_iOspsp%3D2RrOVHugNzX4T-K8%2BxWrKin5Row52Pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
