gpioctl on beaglebone black

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

gpioctl on beaglebone black

patrick keshishian
Hello,

I'm trying to play with the GPIO on bbb. I must be
misunderstanding how this is supposed to (expected)
to work.

I've been looking through the gpioctl (gpio) manuals,
but i'm still confused, and could use a pointer.

here is a demo:

# gpioctl gpio1 7
pin 7: state 1

# gpioctl gpio1 7 off
pin 7: state 1 -> 0

# gpioctl gpio1 7
pin 7: state 1

hmm...

# gpioctl gpio1 7 off
pin 7: state 0 -> 0

err... help?

--patrick

# sysctl kern.version
kern.version=OpenBSD 5.5-current (GENERIC-OMAP) #3: Mon Jun 16 21:01:38 EDT 2014
    [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC-OMAP

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

Raphael Graf-2
On 06/27/14 06:58, patrick keshishian wrote:

> Hello,
>
> I'm trying to play with the GPIO on bbb. I must be
> misunderstanding how this is supposed to (expected)
> to work.
>
> I've been looking through the gpioctl (gpio) manuals,
> but i'm still confused, and could use a pointer.
>
> here is a demo:
>
> # gpioctl gpio1 7
> pin 7: state 1
>
> # gpioctl gpio1 7 off
> pin 7: state 1 -> 0
>
> # gpioctl gpio1 7
> pin 7: state 1
>
> hmm...
>
> # gpioctl gpio1 7 off
> pin 7: state 0 -> 0
>
> err... help?

Hi,

The direction of the pin has to be configured at securelevel 0.
You can put something like the following line in /etc/rc.securelevel:
gpioctl gpio1 23 set out

Then you should be able to toggle the pin:
# gpioctl gpio1 23 on
pin 23: state 0 -> 1
# gpioctl gpio1 23 off
pin 23: state 1 -> 0


>
> --patrick
>
> # sysctl kern.version
> kern.version=OpenBSD 5.5-current (GENERIC-OMAP) #3: Mon Jun 16 21:01:38 EDT 2014
>      [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC-OMAP

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

patrick keshishian
On 6/27/14, Raphael Graf <[hidden email]> wrote:

> On 06/27/14 06:58, patrick keshishian wrote:
>
> The direction of the pin has to be configured at securelevel 0.
> You can put something like the following line in /etc/rc.securelevel:
> gpioctl gpio1 23 set out
>
> Then you should be able to toggle the pin:
> # gpioctl gpio1 23 on
> pin 23: state 0 -> 1
> # gpioctl gpio1 23 off
> pin 23: state 1 -> 0

Thanks for the hint!

Though, this seems a rather painful way to play with those
pins. Every time one wants to change a pin's direction or
make use of a new pin, one has to reboot.

Oh well... must be some logic behind that.

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

Benjamin Baier
You can set the default securelevel in /etc/rc.securelevel.
The "logic behind that" is described in securelevel(7).

On 06/29/14 06:18, patrick keshishian wrote:

> On 6/27/14, Raphael Graf <[hidden email]> wrote:
>> On 06/27/14 06:58, patrick keshishian wrote:
>>
>> The direction of the pin has to be configured at securelevel 0.
>> You can put something like the following line in /etc/rc.securelevel:
>> gpioctl gpio1 23 set out
>>
>> Then you should be able to toggle the pin:
>> # gpioctl gpio1 23 on
>> pin 23: state 0 -> 1
>> # gpioctl gpio1 23 off
>> pin 23: state 1 -> 0
>
> Thanks for the hint!
>
> Though, this seems a rather painful way to play with those
> pins. Every time one wants to change a pin's direction or
> make use of a new pin, one has to reboot.
>
> Oh well... must be some logic behind that.
>
> --patrick

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

patrick keshishian
On 6/29/14, Benjamin Baier <[hidden email]> wrote:
> You can set the default securelevel in /etc/rc.securelevel.
> The "logic behind that" is described in securelevel(7).

locking down pins when/if another device driver is attached
to them makes sense, but locking down idle pins ... i'm not
too sure. especially since using them requires permission to
the gpio device file in the first place.

--patrick


> On 06/29/14 06:18, patrick keshishian wrote:
>> On 6/27/14, Raphael Graf <[hidden email]> wrote:
>>> On 06/27/14 06:58, patrick keshishian wrote:
>>>
>>> The direction of the pin has to be configured at securelevel 0.
>>> You can put something like the following line in /etc/rc.securelevel:
>>> gpioctl gpio1 23 set out
>>>
>>> Then you should be able to toggle the pin:
>>> # gpioctl gpio1 23 on
>>> pin 23: state 0 -> 1
>>> # gpioctl gpio1 23 off
>>> pin 23: state 1 -> 0
>>
>> Thanks for the hint!
>>
>> Though, this seems a rather painful way to play with those
>> pins. Every time one wants to change a pin's direction or
>> make use of a new pin, one has to reboot.
>>
>> Oh well... must be some logic behind that.
>>
>> --patrick

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

Matthieu Herrb
On Sun, Jun 29, 2014 at 12:31:16AM -0700, patrick keshishian wrote:
> On 6/29/14, Benjamin Baier <[hidden email]> wrote:
> > You can set the default securelevel in /etc/rc.securelevel.
> > The "logic behind that" is described in securelevel(7).
>
> locking down pins when/if another device driver is attached
> to them makes sense, but locking down idle pins ... i'm not
> too sure. especially since using them requires permission to
> the gpio device file in the first place.

The difficulty is that from board to board supported by the same
kernel this wiring of the existing GPIO can vary. So you can't rely on
the kernel to know which pins are safe and wich are not.

There are board design with really dangerous pins that are not
explicitely used by a given driver. Iirc on the armish Thecus N2000
you can shut down the fans (and thus damage the disks insinde by
overheating) or cause an hard reboot.

So better safe than sorry, you really need to know what you're doing.

Nothing prevents you to run permanently at securelevel 0 if you
need it and can afford the risk.

>
> --patrick
>
>
> > On 06/29/14 06:18, patrick keshishian wrote:
> >> On 6/27/14, Raphael Graf <[hidden email]> wrote:
> >>> On 06/27/14 06:58, patrick keshishian wrote:
> >>>
> >>> The direction of the pin has to be configured at securelevel 0.
> >>> You can put something like the following line in /etc/rc.securelevel:
> >>> gpioctl gpio1 23 set out
> >>>
> >>> Then you should be able to toggle the pin:
> >>> # gpioctl gpio1 23 on
> >>> pin 23: state 0 -> 1
> >>> # gpioctl gpio1 23 off
> >>> pin 23: state 1 -> 0
> >>
> >> Thanks for the hint!
> >>
> >> Though, this seems a rather painful way to play with those
> >> pins. Every time one wants to change a pin's direction or
> >> make use of a new pin, one has to reboot.
> >>
> >> Oh well... must be some logic behind that.
> >>
> >> --patrick
>

--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

patrick keshishian
On 6/29/14, Matthieu Herrb <[hidden email]> wrote:

> On Sun, Jun 29, 2014 at 12:31:16AM -0700, patrick keshishian wrote:
>> On 6/29/14, Benjamin Baier <[hidden email]> wrote:
>> > You can set the default securelevel in /etc/rc.securelevel.
>> > The "logic behind that" is described in securelevel(7).
>>
>> locking down pins when/if another device driver is attached
>> to them makes sense, but locking down idle pins ... i'm not
>> too sure. especially since using them requires permission to
>> the gpio device file in the first place.
>
> The difficulty is that from board to board supported by the same
> kernel this wiring of the existing GPIO can vary. So you can't rely on
> the kernel to know which pins are safe and wich are not.
>
> There are board design with really dangerous pins that are not
> explicitely used by a given driver. Iirc on the armish Thecus N2000
> you can shut down the fans (and thus damage the disks insinde by
> overheating) or cause an hard reboot.

Got it. Thanks.

--patrick

> So better safe than sorry, you really need to know what you're doing.
>
> Nothing prevents you to run permanently at securelevel 0 if you
> need it and can afford the risk.
>
>>
>> --patrick
>>
>>
>> > On 06/29/14 06:18, patrick keshishian wrote:
>> >> On 6/27/14, Raphael Graf <[hidden email]> wrote:
>> >>> On 06/27/14 06:58, patrick keshishian wrote:
>> >>>
>> >>> The direction of the pin has to be configured at securelevel 0.
>> >>> You can put something like the following line in /etc/rc.securelevel:
>> >>> gpioctl gpio1 23 set out
>> >>>
>> >>> Then you should be able to toggle the pin:
>> >>> # gpioctl gpio1 23 on
>> >>> pin 23: state 0 -> 1
>> >>> # gpioctl gpio1 23 off
>> >>> pin 23: state 1 -> 0
>> >>
>> >> Thanks for the hint!
>> >>
>> >> Though, this seems a rather painful way to play with those
>> >> pins. Every time one wants to change a pin's direction or
>> >> make use of a new pin, one has to reboot.
>> >>
>> >> Oh well... must be some logic behind that.
>> >>
>> >> --patrick
>>
>
> --
> Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

patrick keshishian
In reply to this post by Matthieu Herrb
Hi, yea, more on this....

On 6/29/14, Matthieu Herrb <[hidden email]> wrote:

> On Sun, Jun 29, 2014 at 12:31:16AM -0700, patrick keshishian wrote:
>> On 6/29/14, Benjamin Baier <[hidden email]> wrote:
>> > You can set the default securelevel in /etc/rc.securelevel.
>> > The "logic behind that" is described in securelevel(7).
>>
>> locking down pins when/if another device driver is attached
>> to them makes sense, but locking down idle pins ... i'm not
>> too sure. especially since using them requires permission to
>> the gpio device file in the first place.
>
> The difficulty is that from board to board supported by the same
> kernel this wiring of the existing GPIO can vary. So you can't rely on
> the kernel to know which pins are safe and wich are not.
>
> There are board design with really dangerous pins that are not
> explicitely used by a given driver. Iirc on the armish Thecus N2000
> you can shut down the fans (and thus damage the disks insinde by
> overheating) or cause an hard reboot.
>
> So better safe than sorry, you really need to know what you're doing.

Your argument about not knowing all the pins on all the
different platforms, etc. I can see the point there, but(!) ...

This prevents one to write a simple one-wire protocol
using the gpio ioctl interface, where a data pin needs to
switch directions between in and out. Which is where
I'm stuck ATM.

> Nothing prevents you to run permanently at securelevel 0 if you
> need it and can afford the risk.

so i tried setting securelevel=0 in /etc/rc.securelevel, but(!) ...

[... boot stuff ...]
setting tty flags
pf enabled
starting network
starting early daemons: syslogd pflogd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
starting pre-securelevel daemons:pin 29: caps: in out pu pd, flags: -> out
checking kern.securelevel: kern.securelevel=0
.
setting kernel security level: kern.securelevel: 0 -> 0
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd sendmail sndiod.
starting local daemons: cron.
Sun Jun 29 19:16:46 PDT 2014

OpenBSD/armv7 (bone.local) (console)
[ ... login and Welcome message ... ]

bone $ sysctl kern.securelevel
kern.securelevel=1

bone $ sysctl kern.version
kern.version=OpenBSD 5.5 (GENERIC-OMAP) #11: Sat Mar  8 12:52:57 EST 2014
    [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC-OMAP

bone $ grep -v -e ^# -e ^\$ /etc/rc.securelevel
Xecurelevel=1
securelevel=0
echo -n 'starting pre-securelevel daemons:'
gpioctl gpio1 29 set out
echo -n "checking kern.securelevel: "
sysctl kern.securelevel
echo '.'


I hope I'm not doing something stupidly wrong. Have
I missed something (not so |)subtle in a manual page?

--patrick


>
>>
>> --patrick
>>
>>
>> > On 06/29/14 06:18, patrick keshishian wrote:
>> >> On 6/27/14, Raphael Graf <[hidden email]> wrote:
>> >>> On 06/27/14 06:58, patrick keshishian wrote:
>> >>>
>> >>> The direction of the pin has to be configured at securelevel 0.
>> >>> You can put something like the following line in /etc/rc.securelevel:
>> >>> gpioctl gpio1 23 set out
>> >>>
>> >>> Then you should be able to toggle the pin:
>> >>> # gpioctl gpio1 23 on
>> >>> pin 23: state 0 -> 1
>> >>> # gpioctl gpio1 23 off
>> >>> pin 23: state 1 -> 0
>> >>
>> >> Thanks for the hint!
>> >>
>> >> Though, this seems a rather painful way to play with those
>> >> pins. Every time one wants to change a pin's direction or
>> >> make use of a new pin, one has to reboot.

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

Matthieu Herrb
On Mon, Jun 30, 2014 at 06:04:11PM -0700, patrick keshishian wrote:
> Hi, yea, more on this....
>
> Your argument about not knowing all the pins on all the
> different platforms, etc. I can see the point there, but(!) ...
>
> This prevents one to write a simple one-wire protocol
> using the gpio ioctl interface, where a data pin needs to
> switch directions between in and out. Which is where
> I'm stuck ATM.

Do you know about gpioow(4) and onewire(4) ? Sure writing kernel
drivers for simple one-wire device is a bit of overkill but it's a
>
> > Nothing prevents you to run permanently at securelevel 0 if you
> > need it and can afford the risk.
>
> so i tried setting securelevel=0 in /etc/rc.securelevel, but(!) ...

you need to set  'option INSECURE' in your kernel config for permanent
insecure mode.

>
> [... boot stuff ...]
> setting tty flags
> pf enabled
> starting network
> starting early daemons: syslogd pflogd.
> starting RPC daemons:.
> savecore: no core dump
> checking quotas: done.
> clearing /tmp
> starting pre-securelevel daemons:pin 29: caps: in out pu pd, flags: -> out
> checking kern.securelevel: kern.securelevel=0
> .
> setting kernel security level: kern.securelevel: 0 -> 0
> creating runtime link editor directory cache.
> preserving editor files.
> starting network daemons: sshd sendmail sndiod.
> starting local daemons: cron.
> Sun Jun 29 19:16:46 PDT 2014
>
> OpenBSD/armv7 (bone.local) (console)
> [ ... login and Welcome message ... ]
>
> bone $ sysctl kern.securelevel
> kern.securelevel=1
>
--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: gpioctl on beaglebone black

patrick keshishian
On 6/30/14, Matthieu Herrb <[hidden email]> wrote:
> On Mon, Jun 30, 2014 at 06:04:11PM -0700, patrick keshishian wrote:
>> This prevents one to write a simple one-wire protocol
>> using the gpio ioctl interface, where a data pin needs to
>> switch directions between in and out. Which is where
>> I'm stuck ATM.
>
> Do you know about gpioow(4) and onewire(4) ? Sure writing kernel
> drivers for simple one-wire device is a bit of overkill but it's a

I noticed them while I was "studying" the gpio manuals.
That may be an option, if i can get my head around how
things are done in kernel land.


>> > Nothing prevents you to run permanently at securelevel 0 if you
>> > need it and can afford the risk.
>>
>> so i tried setting securelevel=0 in /etc/rc.securelevel, but(!) ...
>
> you need to set  'option INSECURE' in your kernel config for permanent
> insecure mode.

ahh... it comes with its very own child-proof cap!

also noticed, following comment in /etc/rc:

        # If we are in secure level 0, assume single user mode.

so  more pitfalls lurking about ...

Thanks again,
--patrick