cape-universal & 4.1.x = default.. ;)

[Robert Nelson]

Hey Guys,

In the v4.1.x-ti tree, we have a couple more hdmi-audio pins but
otherwise i've enabled everything in cape-universal now:

https://github.com/beagleboard/bb.org-overlays/commits/master

I'd like to enable cape-universal by default on bootup, under the
conditions that:

/boot/uEnv.txt
no custom dtb= is defined
no custom cape_enable= is defined

and no other capes are enable in the slots..

Currently you can enable it via:

config-pin overlay cape-universal

Thoughts?

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

[William Hermans]

Sounds reasonable to me. This is Charles S' universal IO ? Seems like it but . . . no hands on with it to date. Any non trivial implication that you can think of ?

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Tue, Jul 21, 2015 at 11:37 AM, William Hermans <yyr...@gmail.com> wrote:
> Sounds reasonable to me. This is Charles S' universal IO ? Seems like it but
> . . . no hands on with it to date. Any non trivial implication that you can
> think of ?

root@beaglebone:~# config-pin overlay cape-universal

root@beaglebone:~# config-pin -l P9.24
default gpio gpio_pu gpio_pd uart can i2c pruin
root@beaglebone:~# config-pin -l P9.26
default gpio gpio_pu gpio_pd uart can i2c pruin

root@beaglebone:~# config-pin P9.24 can
root@beaglebone:~# config-pin P9.26 can

root@beaglebone:~# config-pin -q P9.24
P9_24 Mode: can
root@beaglebone:~# config-pin -q P9.26
P9_26 Mode: can

At which point can1 interface is wired to P9.24/P9.26 pin's...

Regards,

[William Hermans]

Not sure I would ever use it, but as long as it would not conflict with eeprom based, or standard capes. I see no reason why not to include it.

[William Hermans]

e.g. I do not fool around with hardware - much. From the physical aspect anyway. I usually intrenched in something like I'm doing now. Which is basically a CANBus to http + websockets interface.

[Robert Nelson]

On Tue, Jul 21, 2015 at 11:55 AM, William Hermans <yyr...@gmail.com> wrote:
> Not sure I would ever use it, but as long as it would not conflict with
> eeprom based, or standard capes. I see no reason why not to include it.

My thoughts too, just want to make sure we don't load it over
something else. ;) Just remembered two other places...

/boot/uEnv.txt
no custom dtb= is defined
no custom cape_enable= is defined

/proc/cmdline
no extra cape_enable's..

/etc/default/capemgr (that 3.8.x hack i did..)

and no other capes are enable in the slots..

[Charles Steinkuehler]

Sounds good to me, assuming it doesn't interfere with any of the stock
software Jason's running.

[Jason Kridner]

Well, the BoneScript and PyBBIO libraries both need to be updated for
4.1. Shouldn't be that hard with a focused effort. Patches welcome.

[g...@novadsp.com]

Hi Robert,

> I'd like to enable cape-universal by default on bootup, under the conditions
> that:
>
> /boot/uEnv.txt
> no custom dtb= is defined
> no custom cape_enable= is defined

Is there a document anywhere which describes the hierarchy of the uEnv files and how they define/override booting/environment/kernel args etc?

TAIA

Jerry

[Robert Nelson]

Not really, as with uEnv.txt your free to update any variable and
create variables...

For boot order you can take a look at this:
http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

But the real important one is:

"mmcargs=setenv bootargs console=${console} " \
"${optargs} " \
"${cape_disable} " \
"${cape_enable} " \
"root=${mmcroot} " \
"rootfstype=${mmcrootfstype} " \
"${cmdline}\0" \

and

"if test -n ${dtb}; then " \
"setenv fdtfile ${dtb};" \
"echo using ${fdtfile} ...;" \
"fi;" \

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

Regards,

[g...@novadsp.com]

Cool, thanks.

>
> Not really, as with uEnv.txt your free to update any variable and create
> variables...
>
> For boot order you can take a look at this:
> http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

That's one of the critters ...

>
> But the real important one is:
>
> "mmcargs=setenv bootargs console=${console} " \
> "${optargs} " \
> "${cape_disable} " \
> "${cape_enable} " \
> "root=${mmcroot} " \
> "rootfstype=${mmcrootfstype} " \
> "${cmdline}\0" \
>

Yep.

Question: Is it possible to override the TFTPROOT setting? i.e. set up each board so they reference different sub-directories on the TFTP server? Can this be done in uEnv alone?

TAIA

Jerry

[Robert Nelson]

So it's setup as:

"server_ip=192.168.1.100\0" \
"gw_ip=192.168.1.1\0" \
"netmask=255.255.255.0\0" \
"hostname=\0" \
"device=eth0\0" \
"autoconf=off\0" \
"root_dir=/home/userid/targetNFS\0" \
"nfs_options=,vers=3\0" \
"nfsrootfstype=ext4 rootwait fixrtc\0" \
"nfsargs=setenv bootargs console=${console} " \

"${optargs} " \
"${cape_disable} " \
"${cape_enable} " \

"root=/dev/nfs rw " \
"rootfstype=${nfsrootfstype} " \
"nfsroot=${nfsroot} " \
"ip=${ip} " \
"${cmdline}\0" \

Just set each bbb to have a different "root_dir=" ..

[Alexander Hiam]

Robert, that sounds great to me.

Well, the BoneScript and PyBBIO libraries both need to be updated for
4.1. Shouldn't be that hard with a focused effort. Patches welcome.

My thoughts now, if cape-universal is loaded by default, would be to use cape-universal in BoneScript/PyBBIO if it's loaded, and otherwise to use the current custom overlay method. How's that sound to you, Jason?
 

[g...@novadsp.com]

Hi

> "root_dir=/home/userid/targetNFS\0" \

> Just set each bbb to have a different "root_dir=" ..

Yep, I get (and do) that for NFS. But can you do the same with TFTP booting? Is there a TFTP root dir var?

TAIA

[Robert Nelson]

We just load them blindly:

+ "tftp ${loadaddr} ${bootfile}; " \
+ "tftp ${fdtaddr} dtbs/${fdtfile}; " \

(uname_r)
+ "tftp ${loadaddr} vmlinuz-${uname_r}; " \
+ "tftp ${fdtaddr} dtbs/${uname_r}/${fdtfile}; " \

I guess we could do: ${tftp_dir}

+ "tftp ${loadaddr} ${tftp_dir}/${bootfile}; " \
+ "tftp ${fdtaddr} ${tftp_dir}/dtbs/${fdtfile}; " \

(uname_r)
+ "tftp ${loadaddr} ${tftp_dir}/vmlinuz-${uname_r}; " \
+ "tftp ${fdtaddr} ${tftp_dir}/dtbs/${uname_r}/${fdtfile}; " \

[Robert Nelson]

On Wed, Jul 22, 2015 at 9:21 AM, Alexander Hiam <al...@graycat.io> wrote:
> Robert, that sounds great to me.
>
>> Well, the BoneScript and PyBBIO libraries both need to be updated for
>> 4.1. Shouldn't be that hard with a focused effort. Patches welcome.
>>
> My thoughts now, if cape-universal is loaded by default, would be to use
> cape-universal in BoneScript/PyBBIO if it's loaded, and otherwise to use the
> current custom overlay method. How's that sound to you, Jason?

Okay this now enabled:

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L213

#default (dtb=am335x-boneblack.dtb)
config-pin overlay cape-universaln

#dtb=am335x-boneblack-overlay.dtb
config-pin overlay cape-universal
config-pin overlay cape-univ-hdmi
config-pin overlay cape-univ-audio
config-pin overlay cape-univ-emmc

#dtb=am335x-boneblack-emmc-overlay.dtb
config-pin overlay cape-universal
config-pin overlay cape-univ-hdmi
config-pin overlay cape-univ-audio

#dtb=am335x-boneblack-hdmi-overlay.dtb
config-pin overlay cape-universal
config-pin overlay cape-univ-emmc

#dtb=am335x-boneblack-nhdmi-overlay.dtb
config-pin overlay cape-universal
config-pin overlay cape-univ-audio
config-pin overlay cape-univ-emmc

I think this takes care of all the pin's..

Regards,

[g...@novadsp.com]

>
> I guess we could do: ${tftp_dir}
>

> + "tftp ${loadaddr} ${tftp_dir}/${bootfile}; " \ "tftp ${fdtaddr}
> + ${tftp_dir}/dtbs/${fdtfile}; " \
>
> (uname_r)
> + "tftp ${loadaddr} ${tftp_dir}/vmlinuz-${uname_r}; " \ "tftp ${fdtaddr}
> + ${tftp_dir}/dtbs/${uname_r}/${fdtfile}; " \

Yep, that's what I had in mind. Let me see if I can make the changes here. If so I can do a PR on Github.

Thanks again.

Jerry

[Robert Nelson]

Pushed:

https://github.com/RobertCNelson/Bootloader-Builder/commit/92a2bb7cce78b7d8b265b0ac70bb7fcc0f4b444b

Currently building, once built, it'll be the default..

[g...@novadsp.com]

>
> Pushed:
>
> https://github.com/RobertCNelson/Bootloader-
> Builder/commit/92a2bb7cce78b7d8b265b0ac70bb7fcc0f4b444b
>

Ideal. Cheers.

[Kridner, Jason]

> On Jul 22, 2015, at 3:29 PM, Robert Nelson <robert...@gmail.com> wrote:
>
>> On Wed, Jul 22, 2015 at 9:21 AM, Alexander Hiam <al...@graycat.io> wrote:
>> Robert, that sounds great to me.
>>
>>> Well, the BoneScript and PyBBIO libraries both need to be updated for
>>> 4.1. Shouldn't be that hard with a focused effort. Patches welcome.
>> My thoughts now, if cape-universal is loaded by default, would be to use
>> cape-universal in BoneScript/PyBBIO if it's loaded, and otherwise to use the
>> current custom overlay method. How's that sound to you, Jason?

Yeah, I also like this loaded by default. Much cleaner for the script code. Disable only if an EEPROM says load something in conflict or a command-line option says so.

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

[not...@gmail.com]

This will break any scripts and libraries that load overlays as needed.  I don't see how loading it by default benefits anything :(

[not...@gmail.com]

Also the only updates I needed for the beaglebone gem was to change a single line to look for the new slots file, everything else worked the same, so I assume not much else is needed for pybbio and bonescript.  With this auto-loading however, it breaks loading overlays for these libraries unless its disabled.  Loading this also slows down boot time by a few seconds.

On Tuesday, July 21, 2015 at 12:26:36 PM UTC-4, RobertCNelson wrote:

[Robert Nelson]

On Wed, Oct 14, 2015 at 2:48 AM, <not...@gmail.com> wrote:
> Also the only updates I needed for the beaglebone gem was to change a single
> line to look for the new slots file, everything else worked the same, so I
> assume not much else is needed for pybbio and bonescript. With this
> auto-loading however, it breaks loading overlays for these libraries unless
> its disabled. Loading this also slows down boot time by a few seconds.

I just added a cmdline switch for this: (/boot/uEnv.txt)

cmdline="${cmdline} cape_universal=enable"

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

cape universal will be enabled by default, but a user can now more
easily disable it in /boot/uEnv.txt

Regards,

[Robert Nelson]

and the boot script change:

https://github.com/RobertCNelson/boot-scripts/commit/7730db559cf4b03b0d845b2bdc3e04542a7dcff6

[Rob Mosher]

<rcn-ee> nyt, btw, ping charles on that email thread.. we should have
slew rate controls ...

Also just my $0.02, I'd like to see the universal overlay loaded when
needed (via config-pin?) and not during boot by default. This will
continue to let anything else that loads overlays function as they were
without change (beaglebone gem, pybbio, etc)

[Rob Mosher]

<rcn-ee> nyt, btw, ping charles on that email thread.. we should have
slew rate controls ...

Also just my $0.02, I'd like to see the universal overlay loaded when
needed (via config-pin?) and not during boot by default. This will
continue to let anything else that loads overlays function as they were
without change (beaglebone gem, pybbio, etc)

[William Hermans]

@Robert

So I decided to give universal-io a go for the first time( finally ), but . . . trying to follow along with Charles' examples on github . . .

william@beaglebone:~$ sudo config-pin -l P9.14
sudo: config-pin: command not found

 At this point, I do not know what is going on. So I check around a little.
william@beaglebone:~$ dmesg |grep universal
[    0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M quiet cape_universal=enable ipv6.disable=1

william@beaglebone:~$ cat /boot/uEnv.txt | grep cmdline
cmdline=coherent_pool=1M quiet cape_universal=enable ipv6.disable=1
#cmdline=ipv6.disable=1
#cmdline=coherent_pool=1M quiet cape_universal=enable video=HDMI-A-1:1024x768@60e
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

At which point, I am stuck. I did on a previous boot also manually load the universaln overlay. I did notice a lot more noise from dmesg in relation to pings being configured. But still no config-pin utility . . .

What am I missing ?

[William Hermans]

Still no dice . . .

william@beaglebone:~$ dmesg |grep univ
[    0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8 bone_capemgr.enable_partno=cape-universaln root=/dev/mmcblk0p1 rootfstype=ext4 rootwait ipv6.disable=1
[    5.541989] bone_capemgr bone_capemgr: enabled_partno PARTNO 'cape-universaln' VER 'N/A' PR '0'
[    5.563179] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,cape-universaln'
[    5.704778] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0
[    5.713400] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1
. . .

[    6.198582] gpio-of-helper ocp:cape-universal: Allocated GPIO id=32
[    6.204916] gpio-of-helper ocp:cape-universal: ready
[    6.320586] bone_capemgr bone_capemgr: slot #4: dtbo 'cape-universaln-00A0.dtbo' loaded; overlay id #0
william@beaglebone:~$ sudo config-pin
[sudo] password for william:

sudo: config-pin: command not found

william@beaglebone:~$ uname -r
4.4.9-bone-rt-r10

william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-05-01

william@beaglebone:~$ cat /boot/uEnv.txt |grep cmdline

#cmdline=coherent_pool=1M quiet cape_universal=enable ipv6.disable=1

cmdline=ipv6.disable=1
#cmdline=coherent_pool=1M quiet cape_universal=enable video=HDMI-A-1:1024x768@60e
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

william@beaglebone:~$ cat /boot/uEnv.txt |grep universaln
cape_enable=bone_capemgr.enable_partno=cape-universaln

--

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f35e0bef-730f-4ddb-bc64-1abb8e4a24e8%40googlegroups.com.

[William Hermans]

My cure . . .

william@beaglebone:~$ wget https://raw.githubusercontent.com/cdsteinkuehler/beaglebone-universal-io/master/config-pin
william@beaglebone:~$ sudo chmod +x config-pin
[sudo] password for william:
william@beaglebone:~$ sudo cp ./config-pin /usr/bin
william@beaglebone:~$ config-pin -l P8.07
default gpio gpio_pu gpio_pd timer

[William Hermans]

I thought, perhaps incorrectly that config-pin came shipped by default.

[Charles Steinkuehler]

It does, but it depends on the image you start with. Usually it's
found in /opt/source/beaglebone-universal-io/, with a symlink for
config-pin in /usr/local/bin/config-pin:

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-wheezy.sh#L389-L396

> <mailto:beagleboard...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/f35e0bef-730f-4ddb-bc64-1abb8e4a24e8%40googlegroups.com

> <https://groups.google.com/d/msgid/beagleboard/f35e0bef-730f-4ddb-bc64-1abb8e4a24e8%40googlegroups.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...@googlegroups.com

> <mailto:beagleboard...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/beagleboard/CALHSORqZwjcxuJKZDirbD8J80mgetcgxNRxgbcgMraGjLyOk7w%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CALHSORqZwjcxuJKZDirbD8J80mgetcgxNRxgbcgMraGjLyOk7w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
>

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

It does, but it depends on the image you start with.  Usually it's
found in /opt/source/beaglebone-universal-io/, with a symlink for
config-pin in /usr/local/bin/config-pin:

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-wheezy.sh#L389-L396

Oh, ok. I start with the console images always, and this is not the first time I've not been able to find config-pin. But after some investigation, and a system wide search for the file 'config-pin' turned up nothing. It was then just a matter of realizing that I had everything in place already except config pin. So I read the Makefile figured out where make install would put the file . . .and went from there ;)

[William Hermans]

@Charles

So I'm not sure if this is normal or not. Thought I'd bring it to your attention in case it's not.

william@beaglebone:~$ sudo chown root:gpio /usr/bin/config-pin
william@beaglebone:~$ config-pin  P8.07 hi
william@beaglebone:~$ cat /sys/devices/platform/ocp/ocp:cape-universal/status
. . .
32 P8_07                     66 IN  0

That should be OUT, and 1 ? the gpio sysfs stuff reports correctly though

william@beaglebone:~$ cat /sys/class/gpio/gpio66/direction
out
william@beaglebone:~$ cat /sys/class/gpio/gpio66/value
1
 william@beaglebone:~$ config-pin -q P8.07
P8_07 Mode: gpio Direction: out Value: 1

As does the config-pin query option.

[Charles Steinkuehler]

The status file is created by the kernel logic, and I believe simply
reflects the load-time configuration of the GPIO, which all default to
inputs when the overlay loads)...but I haven't crawled through the
kernel code to figure out exactly what it's doing to create the status
file. I suspect the kernel logic generating the status file doesn't
understand the GPIO have been exported and are not directly controlled
by the cape-universal overlay. Honestly, I'm not sure I've ever
looked at the contents of the status file previously.

Anyway, I get the same results on my system here, so I don't think
it's anything you need to worry about:

machinekit@beaglebone:~$ config-pin P8.07 hi
machinekit@beaglebone:~$ cat /sys/devices/ocp.3/cape-universal.51/status
...
34 P8_09 69 IN 0
35 P8_08 67 IN 0
36 P8_07 66 IN 0
machinekit@beaglebone:~$ cat /sys/class/gpio/gpio66/direction
out
machinekit@beaglebone:~$ cat /sys/class/gpio/gpio66/value
1

On 6/23/2016 4:30 PM, William Hermans wrote:
> @Charles
>
> So I'm not sure if this is normal or not. Thought I'd bring it to your attention
> in case it's not.
>
> william@beaglebone:~$ sudo chown root:gpio /usr/bin/config-pin
> william@beaglebone:~$ config-pin P8.07 hi
> william@beaglebone:~$ cat /sys/devices/platform/ocp/ocp:cape-universal/status
> . . .

> 32 P8_07 66 *IN 0
>
> *
> That should be OUT, and 1*? *the gpio sysfs stuff reports correctly though*
> *

>
> william@beaglebone:~$ cat /sys/class/gpio/gpio66/direction
> out
> william@beaglebone:~$ cat /sys/class/gpio/gpio66/value
> 1
> william@beaglebone:~$ config-pin -q P8.07
> P8_07 Mode: gpio Direction: out Value: 1
>
> As does the config-pin query option.
>
>
> On Thu, Jun 23, 2016 at 12:05 PM, William Hermans <yyr...@gmail.com
> <mailto:yyr...@gmail.com>> wrote:
>
> It does, but it depends on the image you start with. Usually it's
> found in /opt/source/beaglebone-universal-io/, with a symlink for
> config-pin in /usr/local/bin/config-pin:
>
> https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-wheezy.sh#L389-L396
>
>
> Oh, ok. I start with the console images always, and this is not the first
> time I've not been able to find config-pin. But after some investigation,
> and a system wide search for the file 'config-pin' turned up nothing. It was
> then just a matter of realizing that I had everything in place already
> except config pin. So I read the Makefile figured out where make install
> would put the file . . .and went from there ;)
>
>

> --
> 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...@googlegroups.com
> <mailto:beagleboard...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/beagleboard/CALHSORrO-zF%3DzVRVFiYJmsuQFzGUE79bczDXg_G2w18m%3DxSbCg%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CALHSORrO-zF%3DzVRVFiYJmsuQFzGUE79bczDXg_G2w18m%3DxSbCg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[William Hermans]

Thanks Charles.

Yes, initially I was thinking that perhaps that file reflected what the current values of pins were. But after thinking while waiting for your reply I was thinking that too. Initial state of the pins at the time the overlay was loaded.

Another question regarding config-pin . . .I have a Nodejs project here: https://github.com/wphermans/Bonejs, but I just now wrote a Nodejs( Javascript ) wrapper for config-pin and wanted to make sure that would be ok. I do also have plans on using that wrapper for a much bigger, and cooler project, which was requested by Robert not long ago . . .

No idea how long it'll take me with other priorities in the mix too. But I figured I should ask.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c3dcd834-f69a-21ff-fbb6-4ce99ed12644%40steinkuehler.net.

[William Hermans]

By the way, it's just a wrapper for Nodejs, but otherwise I'm not changing a thing. So far all I really want / need is:

"use strict";
var fs = require('fs');
var exec = require('child_process').exec;

exports.config = function(pin, value){
   
    var params = pin + ' ' + value;
    var child = exec('/usr/bin/config-pin ' + params, (error, stdout, stderr) => {
        if(error){throw error;}      
    });
};

exports.listModes = function(pin, callback){
   
    var params = pin;
    var child = exec('/usr/bin/config-pin -l ' + params, (error, stdout, stderr) => {
        if(error){throw error;}

        callback(stdout);      
    });
};  

william@beaglebone:~/dev/bonejs$ node config-pin-example.js

default gpio gpio_pu gpio_pd timer

So the wrapper is really simple. But what I plan on doing with said wrapper will be really neat I think. How does configurering your pin modes from a web page sound ? ;)

[Charles Steinkuehler]

On 6/23/2016 5:22 PM, William Hermans wrote:
> Thanks Charles.
>
> Yes, initially I was thinking that perhaps that file reflected what the current
> values of pins were. But after thinking while waiting for your reply I was
> thinking that too. Initial state of the pins at the time the overlay was loaded.
>
> Another question regarding config-pin . . .I have a Nodejs project here:
> https://github.com/wphermans/Bonejs, but I just now wrote a Nodejs( Javascript )
> wrapper for config-pin and wanted to make sure that would be ok. I do also have
> plans on using that wrapper for a much bigger, and cooler project, which was
> requested by Robert not long ago . . .
>
> No idea how long it'll take me with other priorities in the mix too. But I
> figured I should ask.

Wrap away!

I'm just happy the universal overlay concept has caught-on. I wanted
people to be able to do most simple things without having to craft
custom device-tree overlays. Using a custom overlay is still the most
flexible option, but there's a pretty high barrier to entry.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

On 6/23/2016 5:26 PM, William Hermans wrote:
>
> So the wrapper is really simple. But what I plan on doing with said wrapper will
> be really neat I think. How does configurering your pin modes from a web page
> sound ? ;)

That sounds pretty awesome!

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

Wrap away!

I'm just happy the universal overlay concept has caught-on.  I wanted
people to be able to do most simple things without having to craft
custom device-tree overlays.  Using a custom overlay is still the most
flexible option, but there's a pretty high barrier to entry.

Ok awesome.

I've actually really liked the idea of universal-io ever since you put the project up, and made it known. Really an awesome idea. At the time it was very obvious to me that this would be something really cool. But I was wrapped up in my own little world, doing my own thing, and since I use console images that do not always, or ever seem to have config-pin enabled by default ? Not really sure, but every time I went to tinker with config-pin . . . "command not found". It's just that this time, my own little world collided with universal-io. So I gave some thought into what actually was not working, and how to make it work.

I do have to say, that I'm every bit as impressed with universal-io now, as I was back when you put it into the wild. I quite honestly think that universal-io + config-pin is every bit as good as device tree files. At least in what universal-io can do. I do not know if it has any short comings. but from what I can see . . . there are none ?

--
Charles Steinkuehler
cha...@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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b8bacad4-1c9c-46fe-1cdf-243632cb85cd%40steinkuehler.net.

[William Hermans]

Ok so one not so fun issue . . .

william@beaglebone:~/dev/bonejs$ config-pin P8.07 low
sudo: no askpass program specified, try setting SUDO_ASKPASS
Cannot write gpio direction file: /sys/class/gpio/gpio66/direction

EXCEPT
william@beaglebone:~/dev/bonejs$ ls -al /sys/class/gpio/gpio66/direction
-rwxrwx--- 1 root gpio 4096 Jun 23 14:17 /sys/class/gpio/gpio66/direction

william@beaglebone:~/dev/bonejs$ getent group gpio
gpio:x:1001:william

I've a feeling I know how to fix this though . . . will require editing config-pin . . .

[William Hermans]

Okay . . .

Went through the file and replaced sudo -A for '' ( empty string- or null ). And then had to add to my udev rules file . . .

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

[William Hermans]

Charles,

So one thing I do find kind of confusing. Is which universal-io device tree to load at boot. Basicaly, my board is currently set stock + hdmi audio, and video disabled.

Could you please give me a rundown on what each dtb is for ? I'll document that information and write up a blog post on it for future reference.

Additionally, while I'm here posting questions. What would be the best way to have pins enabled in a specific way at boot ? Just modify the dtbs file to reflect my preferences, and recompile ?

[William Hermans]

Just as an indication of what I'm looking at.

debian@beaglebone:~$ ls /lib/firmware/ |grep univ
cape-univ-audio-00A0.dtbo
cape-univ-emmc-00A0.dtbo
cape-univ-hdmi-00A0.dtbo
cape-universal-00A0.dtbo
cape-universaln-00A0.dtbo
univ-all-00A0.dtbo
univ-bbgw-00A0.dtbo
univ-emmc-00A0.dtbo
univ-hdmi-00A0.dtbo
univ-nhdmi-00A0.dtbo

My guess is that I want the last one, but without checking the source ( which I can do on github now that I think on it ), how could I know ? Ill check on github for now . . .

[Charles Steinkuehler]

On 6/24/2016 12:22 PM, William Hermans wrote:
> Charles,
>
> So one thing I do find kind of confusing. Is which universal-io device tree to
> load at boot. Basicaly, my board is currently set stock + hdmi audio, and video
> disabled.
>
> Could you please give me a rundown on what each dtb is for ? I'll document that
> information and write up a blog post on it for future reference.

See the readme:

https://github.com/cdsteinkuehler/beaglebone-universal-io

* cape-universal Exports all pins not used by HDMIN and eMMC
(including audio)

* cape-universaln Exports all pins not used by HDMI and eMMC (no audio
pins are exported)

* cape-univ-emmc Exports pins used by eMMC, load if eMMC is disabled

* cape-univ-hdmi Exports pins used by HDMI video, load if HDMI is
disabled

* cape-univ-audio Exports pins used by HDMI audio

> Additionally, while I'm here posting questions. What would be the best way to
> have pins enabled in a specific way at boot ? Just modify the dtbs file to
> reflect my preferences, and recompile ?

That's probably the best option if you need things setup early on,
otherwise you can just run a config-pin script sometime in the boot
sequence.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

On 6/24/2016 12:27 PM, William Hermans wrote:
> Just as an indication of what I'm looking at.
>
> debian@beaglebone:~$ ls /lib/firmware/ |grep univ
> cape-univ-audio-00A0.dtbo
> cape-univ-emmc-00A0.dtbo
> cape-univ-hdmi-00A0.dtbo
> cape-universal-00A0.dtbo
> cape-universaln-00A0.dtbo

The above should match the README from the beaglebone-universal-io
repo. The stuff below is likely from Robert Nelson and I'm not sure
what the difference is (perhaps versions for newer kernels?).

> univ-all-00A0.dtbo
> univ-bbgw-00A0.dtbo
> univ-emmc-00A0.dtbo
> univ-hdmi-00A0.dtbo
> univ-nhdmi-00A0.dtbo
>
> My guess is that I want the last one, but without checking the source ( which I
> can do on github now that I think on it ), how could I know ? Ill check on
> github for now . . .

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

See the readme:

https://github.com/cdsteinkuehler/beaglebone-universal-io

Ok, my bad. How did I miss that ?

That's probably the best option if you need things setup early on,
otherwise you can just run a config-pin script sometime in the boot
sequence

Ok, thank you. I guess it's only those two options heh. Just making sure . . .

--
Charles Steinkuehler
cha...@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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c40f789f-5ca5-fb6c-b303-ebe3092666b9%40steinkuehler.net.

[William Hermans]

Charles,

So, a minor complaint. None of your overlays configures *ALL* pins not used by hdmi( audio and video ) and all other pins not in use by the system ( eMMC, i2c-0/2, etc ). I had to use a cape I suppose Robert created:

debian@beaglebone:~$ dmesg |grep univ
[    0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8 bone_capemgr.enable_partno=univ-all root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M quiet cape_universal=enable
[    2.926016] bone_capemgr bone_capemgr: enabled_partno PARTNO 'univ-all' VER 'N/A' PR '0'
[    2.926083] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,univ-all'

. . . Lots of noise . . .
[    5.293487] bone_capemgr bone_capemgr: slot #4: dtbo 'univ-all-00A0.dtbo' loaded; overlay id #0

Here is the whole story. I was able to use config-pin to load the overlay that exports all hdmi pins, and all that. The problem is, I modified your version of config-pin because I do not wish to setup a sudo "rule". Instead, I use a udev rule to change the group for the pin files, and loading that overlay through config-pin was not working. Since parts of that udev rule *HAS* to be done at boot.

Anyway, using the overlay Robert seems to have created ( univ-all ) seems to do the trick . . . Now, for your amusement . . .

testing of a custom board( cape ) using Javascript ;) and *yes*, it works perfectly.

"use strict";
(function() {
        var cp = require('./config-pin.js');
        var leds = ['P8.26', 'P8.18', 'P8.07', 'P8.08', 'P8.09', 'P8.10'];
        var relays = ['P8.27', 'P9.31', 'P9.29', 'P9.25', 'P9.30', 'P9.12'];
       
        leds.forEach(function(s) {
                cp.config(s, 'low');
        });
        relays.forEach(function(s) {
                cp.config(s, 'hi');
        });

        setTimeout(function() {
                leds.forEach(function(s) {
                        cp.config(s, 'hi');
                });
                relays.forEach(function(s) {
                        cp.config(s, 'low');
                });
        }, 2000);
})();

[Charles Steinkuehler]

On 6/24/2016 4:42 PM, William Hermans wrote:
> Charles,
>
> So, a minor complaint. None of your overlays configures *ALL* pins not used by
> hdmi( audio and video ) and all other pins not in use by the system ( eMMC,
> i2c-0/2, etc ). I had to use a cape I suppose Robert created:

Robert is really the maintainer of these capes, since he's pulled the
overlay into the kernel source and keeps it updated for newer kernels.

> Here is the whole story. I was able to use config-pin to load the overlay that
> exports all hdmi pins, and all that. The problem is, I modified your version of
> config-pin because I do not wish to setup a sudo "rule". Instead, I use a udev
> rule to change the group for the pin files, and loading that overlay through
> config-pin was not working. Since parts of that udev rule *HAS* to be done at boot.

The config-pin script was written for the desktop images. Since
you're starting from a console image, the sudo configuration isn't
working "out of the box". That said, tweaking the udev rules to
change ownership (and/or modifying the supplemental groups for the
default user) seems like a better fix, with no sudo required. I'm
sure Robert would appreciate a PR against the image creation scripts
to clean this up! ;-)

Great work!

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

I pasted my udev rule here last night, but also I have it listed in the permissions.md file of my bonejs github project. I'm going through changing my documentation structure. So hopefully I can cover more, and hopefully cleaner / clearer.

You, Robert, or anyone can just grab that udev rule, and use it how you see fit.

--
Charles Steinkuehler
cha...@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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ee786198-98fd-4ac5-a6f1-db6730bdd213%40steinkuehler.net.

[William Hermans]

https://github.com/wphermans/Bonejs/blob/master/permissions.md is the link to the file where I discuss what I personally do for permissions, etc.

One thing to point out though. sudo can be more exact, in that you can specify an exact command( including parameters ) that a normal user can use ( with sudo of course ), and can make it so those user do not need to provide a passwd - If you so wish.

I think the absolute best way to secure a system is use a supervisor / worker "technique". Basically, a form of IPC, where the worker application is required to ask a supervisor service to perform various tasks . . . but who has time to implement all that in the short term ? Not I . . .

[Charles Steinkuehler]

On 6/24/2016 5:41 PM, William Hermans wrote:
> One thing to point out though. sudo can be more exact, in that you can specify
> an exact command( including parameters ) that a normal user can use ( with sudo
> of course ), and can make it so those user do not need to provide a passwd - If
> you so wish.

Note the security 'bar' is not set particularly high, given the
default BBB images have no root password. :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

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.

--
Charles Steinkuehler
cha...@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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3eca5545-2827-1342-c9d3-8f19946b1906%40steinkuehler.net.

[Charles Steinkuehler]

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.

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
cha...@steinkuehler.net

[William Hermans]

SO, after talking with Robert and finding that all these kernel modules that get loaded from cape_universal=enable. I wonder how this impacts other capes such as the Logic supply RS232 / CAN cape that automatically loads it's own device tree  overlay.

Could capes such as this be loaded first, and then still have universal-io capabilities ?

[William Hermans]

I guess maybe the thing to do would be to edit the universalio overlay file of choice. So that it did not touch the needed pins / peripherals used by a given cape with eeprom.

On Tue, Jul 19, 2016 at 10:54 AM, William Hermans <yyr...@gmail.com> wrote:

SO, after talking with Robert and finding that all these kernel modules that get loaded from cape_universal=enable. I wonder how this impacts other capes such as the Logic supply RS232 / CAN cape that automatically loads it's own device tree  overlay.

Could capes such as this be loaded first, and then still have universal-io capabilities ?

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3cd02243-1ea4-4598-8552-ae3513aefd66%40googlegroups.com.

[TJF]

Hi William!

Am Dienstag, 19. Juli 2016 19:54:02 UTC+2 schrieb William Hermans:

SO, after talking with Robert and finding that all these kernel modules that get loaded from cape_universal=enable. I wonder how this impacts other capes such as the Logic supply RS232 / CAN cape that automatically loads it's own device tree  overlay.

Could capes such as this be loaded first, and then still have universal-io capabilities ?

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

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

[Jason Kridner]

On Fri, Jun 24, 2016 at 8:10 PM Charles Steinkuehler <cha...@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
cha...@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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d19cdd9b-9ae5-08a8-6028-cecbbea7d4f8%40steinkuehler.net.

[William Hermans]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmBBQk0hy%2Bwz3ktPnaUYNoKC9aSvNK7y-xGDNc7gKaqUg%40mail.gmail.com.

[William Hermans]

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.

[William Hermans]

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 ?

[John Syne]

On Jul 20, 2016, at 8:46 AM, TJF <jeli.f...@gmail.com> wrote:

Hi William!

Am Dienstag, 19. Juli 2016 19:54:02 UTC+2 schrieb William Hermans:

SO, after talking with Robert and finding that all these kernel modules that get loaded from cape_universal=enable. I wonder how this impacts other capes such as the Logic supply RS232 / CAN cape that automatically loads it's own device tree  overlay.

Could capes such as this be loaded first, and then still have universal-io capabilities ?

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

Looking at:

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin

Nothing bad will happen. The first command will set GPIO high and the next will change the GPIO to low. Besides, the AM335x won’t allow an output conflict. 

Regards,

John

(I didn't test it, but if you do so, please report.)

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/87197b98-c1dc-472e-9919-cd2b4fa4aab5%40googlegroups.com.

[TJF]

Am Mittwoch, 20. Juli 2016 21:36:59 UTC+2 schrieb john3909:

Looking at:

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin

Nothing bad will happen. The first command will set GPIO high and the next will change the GPIO to low. Besides, the AM335x won’t allow an output conflict.

Nothing bad, did you test?

Yes, one CPU ball (7) goes high, the other (114) low. No conflict at the AM335x. But both balls are hard wired to a single header pin on the BB board. Neither the BB hardware has any protection nor the software (kernel driver or config-pin/cape_universal).

BR

[John Syne]

Ah, I missed that you are controlling two different GPIO connected to the same pin. I don’t know why you keep on bringing stuff up like this, because any sensible developer would obviously avoid something like this. Gerald was attempting to bring out all the features on the AM335x even when he didn’t have sufficient connector pins. Clearly, if you want the one GPIO to be an output, the other must be configured as an input.

Regards,

John

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b8587ab0-6626-464e-a87b-43c940992505%40googlegroups.com.

[John Syne]

Now I see why I didn’t see this before. On the Pinmux spreadsheet, they are labelled as P9_42A and P9_42B. I don’t know where you get P9_92 since there is no pin 92 on the P9 connector. 

P9_42A	89	0x964/164	GPIO0_7	7	gpio0[7]
P9_42B	104	0x9a0/1a0	GPIO0_7	114	gpio3[18]

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORr%3D9%3D9rJdh7d5RAMe7WbuSMv1x8w2k2NVNbbZQN9AdUwA%40mail.gmail.com.

[Charles Steinkuehler]

On 7/20/2016 5:43 PM, John Syne wrote:
> Now I see why I didn’t see this before. On the Pinmux spreadsheet, they are
> labelled as P9_42A and P9_42B. I don’t know where you get P9_92 since there is
> no pin 92 on the P9 connector.

Pin "92" is my fault.

I used the convention of adding 50 to the pin number for the "secondary"
I/O pin connected to the same P8/P9 header:

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin#L586-L591

...there's a Pin 91 as well. :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[John Syne]

I see where you are coming from, but that is very confusing to me and I suspect several other developers as well. P9_42 means something (Connector P9, Pin 42) so just adding an arbitrary 50 for a secondary function doesn’t make sense to me. Why not use the A & B suffix? Surely this just needs modification to your regular expressions?

Regards,
John

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/25b0254b-bb74-5ae5-4555-5bd9bdc391ff%40steinkuehler.net.

[TJF]

Am Donnerstag, 21. Juli 2016 07:35:23 UTC+2 schrieb john3909:

Why not use the A & B suffix? Surely this just needs modification to your regular expressions?

Just renaming doesn't solve the issue. There's just one P9_42 and the features of P9_92 should get merged in to this pin. Check the libpruio overlay on how to handle this in a save manner.

But the point is: both (cape_universal and libpruio overlays) are just bad workarounds. They load a lot of pin configurations in kernel space memory, while just a few are used. A full featured dtbo file (67 header pins) has 135140 bytes. Handling all that pre-configurations slows down boot time and blocks a lot of kernel memory. And finally the configuration necessary for a special usecase is still missing.

From my point of view the kernel driver pinctrl-single should get patched:

1. It should protect the system (when one CPU ball gets set, the other should automatically get in input state - for CPU balls connected to P9_41 and P9_42).
2. It should get an API in /sys/devices/ocp to set any pin configuration (as stated in our March discussion).

This API would be the correct basis for Williams web interface (and for config-pin or libpruio pinmuxing).

BR

[John Syne]

I hear where you are coming from and I think you have a valid argument here. First, I think this mailing list is the wrong forum to discuss this issue and second, I’m not sure which driver needs to be updated to implement this feature. I think from our last discussion gpiolib seemed like the right place to implement this feature, but pinctl-single could also be the right place. I haven’t looked into this for a while.

I would suggest posting a RFC to the Linux or Linux-ARM mailing list and see what feedback you get. Any changes here will affect all architectures so best to iron this out with all the stakeholders.

Regards,
John

> On Jul 21, 2016, at 8:39 PM, Jelena Freiherr <jeli.f...@gmail.com> wrote:
>
> Am Donnerstag, 21. Juli 2016 07:35:23 UTC+2 schrieb john3909:
>>
>> Why not use the A & B suffix? Surely this just needs modification to your
>> regular expressions?
>>
>
> Just renaming doesn't solve the issue. There's just one P9_42 and the
> features of P9_92 should get merged in to this pin. Check the libpruio
> overlay on how to handle this in a save manner.
>
> But the point is: both (cape_universal and libpruio overlays) are just
> bad workarounds. They load a lot of pin configurations in kernel space
> memory, while just a few are used. A full featured dtbo file (67 header
> pins) has 135140 bytes. Handling all that pre-configurations slows down
> boot time and blocks a lot of kernel memory. And finally the
> configuration necessary for a special usecase is still missing.
>
> From my point of view the kernel driver pinctrl-single should get patched:
>

> 1. It should protect the system (when one CPU ball gets set, the

> other should automatically get in input state - for CPU balls
> connected to P9_41 and P9_42).

> 2. It should get an API in /sys/devices/ocp to set any pin

> configuration (as stated in our March discussion

> <https://groups.google.com/d/msg/beagleboard/ZTKntXOXGyc/GLBOQ2r5BQAJ>).

>
> This API would be the correct basis for Williams web interface (and for
> config-pin or libpruio pinmuxing).
>
> BR
>

> --
> 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/2D5Pz3r7ZZ8/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/9ff475ab-0f97-4fc0-906c-49d989b8ef8a%40googlegroups.com.

[Jelena Freiherr]

Am 22.07.2016 um 07:17 schrieb John Syne:
> First, I think this mailing list is the wrong forum to discuss this issue

We have two issues here. OK, for the API the forum may be the wrong place.

But the CPU protection is a Beaglebone only issue. I think Gerald made a
good job when he provided more CPU balls then header pins available. We
just need software to handle that trick in a safe manner. I think this
issue needs a patch in the Beaglebone kernel, only. Where, if not in
this forum, should I discuss this?

> I would suggest posting a RFC to the Linux or Linux-ARM mailing list and see what feedback you get. Any changes here will affect all architectures so best to iron this out with all the stakeholders.

I haven't done this yet. When I google, I get several links to different
places. Can you please provide links where to find the lists you're
talking about.

> and second, I’m not sure which driver needs to be updated to implement this feature. I think from our last discussion gpiolib seemed like the right place to implement this feature, but pinctl-single could also be the right place. I haven’t looked into this for a while.

Before posting an RFC, we should find the right places for changes, at
least for the CPU safety issue. I'm sure gpiolib is the wrong driver.
Device tree entries for pinmuxing look like

> B68_2F: 68_2F {pinctrl-single,pins = <0x164 0x2F 0x1A0 0x2F>;};

This pinctrl-single driver seems to be the right one.

And since I'm not familiar with kernel drivers, I'd really appreciate
your help to find the right driver to implement the API. This would help
me to write the RFC up.

First I thought a single entry in /sys/devices/ocp could do the job. But
I guess that may violate the security concept, since each CPU ball could
get accessed that way. So the API should provide access only for claimed
pins (each with a folder containing a state file). And therefor, an
adaption in bone-pinmux-helper may be necessary as well.

Your appraisal is much appriciated.

BR

[Charles Steinkuehler]

On 7/21/2016 12:35 AM, John Syne wrote:
> I see where you are coming from, but that is very confusing to me and
> I suspect several other developers as well. P9_42 means something
> (Connector P9, Pin 42) so just adding an arbitrary 50 for a secondary
> function doesn’t make sense to me. Why not use the A & B suffix?
> Surely this just needs modification to your regular expressions?

I used a number because one place where I need to reference pin numbers
requires using integer values and I wanted to be consistent.

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

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;
};

[William Hermans]

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.

[William Hermans]

On Wed, Jul 20, 2016 at 6:01 PM, Charles Steinkuehler <cha...@steinkuehler.net> wrote:

On 7/20/2016 5:43 PM, John Syne wrote:

Now I see why I didn’t see this before. On the Pinmux spreadsheet, they are
labelled as P9_42A and P9_42B. I don’t know where you get P9_92 since there is
no pin 92 on the P9 connector.

Pin "92" is my fault.

I used the convention of adding 50 to the pin number for the "secondary" I/O pin connected to the same P8/P9 header:

Ah I've noticed those before. Never had a use, so I just steer clear of them.

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin#L586-L591

...there's a Pin 91 as well.  :)

Yeah, this is something I've noticed recently while pouring over universaln / univ-all overlays.

--
Charles Steinkuehler
cha...@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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/25b0254b-bb74-5ae5-4555-5bd9bdc391ff%40steinkuehler.net.

[Charles Steinkuehler]

On 7/27/2016 12:33 AM, William Hermans 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>;

> dir-changeable;
> };

The pin exporting is done by the gpio-of-helper kernel module, so you
can use anything that driver understands, like init-high or init-low:

P8_07 {
gpio-name = "P8_07";
gpio = <&gpio2 2 0>;

output;
init-high;
};

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

Thanks Charles. Read this last night, and been meaning to thank you for the information. But kept getting sidetracked . .. gpio-of-helper, I have not been able to find decent documentation on that, but I have not looked recently. Probably somewhere in linux/documentation/ . . .

--
Charles Steinkuehler
cha...@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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/27596900-6b9a-88fb-25b3-79427dd4758d%40steinkuehler.net.

[William Hermans]

Charles,

Also, I've been meaning to ask you what you'd think of individual pin overlay files based on universal-IO. I have all of P8 done, or most of( I don't wont touch the eMMC pins - but HDMI + audio is fair game).

I got bored, when our internet bouncing equipment got struck by lightning again this year, and we were without internet for several days again . . .

william@eee-pc:~$ ls share/dtb-single/
template-dts.dts     univ-P8_11-00A0.dts  univ-P8_16-00A0.dts  univ-P8_27-00A0.dts  univ-P8_32-00A0.dts  univ-P8_37-00A0.dts
univ-P8_07-00A0.dts  univ-P8_12-00A0.dts  univ-P8_17-00A0.dts  univ-P8_28-00A0.dts  univ-P8_33-00A0.dts  univ-P8_38-00A0.dts
univ-P8_08-00A0.dts  univ-P8_13-00A0.dts  univ-P8_18-00A0.dts  univ-P8_29-00A0.dts  univ-P8_34-00A0.dts  univ-P8_39-00A0.dts
univ-P8_09-00A0.dts  univ-P8_14-00A0.dts  univ-P8_19-00A0.dts  univ-P8_30-00A0.dts  univ-P8_35-00A0.dts  univ-P8_40-00A0.dts
univ-P8_10-00A0.dts  univ-P8_15-00A0.dts  univ-P8_26-00A0.dts  univ-P8_31-00A0.dts  univ-P8_36-00A0.dts

Was considering how one might implement peripherals into the mix. But I think it should be possible to create individual peripheral overlays, and then just add those in addition to needed pins ? I have not looked too deeply into that yet.

[Charles Steinkuehler]

On 7/28/2016 2:52 AM, William Hermans wrote:
> Charles,
>

> Also, I've been meaning to ask you what you'd think of individual pin overlay
> files based on universal-IO. I have all of P8 done, or most of( I don't wont
> touch the eMMC pins - but HDMI + audio is fair game).

<snip>

> Was considering how one might implement peripherals into the mix. But I think it
> should be possible to create individual peripheral overlays, and then just add
> those in addition to needed pins ? I have not looked too deeply into that yet.

An "exploded" universal overly should work fine. The basic idea
remains to allow pin-muxing in user-space, but breaking out the
peripherals individually would allow lower power operation by only
loading what's necessary. I'm not sure how much benefit there is to
breaking out each pin individually, but there shouldn't be any harm
(besides having to load a lot more overlays to get something done).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Jason Kridner]

On Wed, Jul 20, 2016 at 2:28 PM William Hermans <yyr...@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.

Hurray!  We actually had that kinda working way-back-when. I didn't leave the code in a working state and it isn't that interesting to pick through, but I did shove some of the bits off into the 'attic': https://github.com/jadonk/bone101/blob/with-attic/attic/pinMux.html 

Note we also have something more involved to extract running data that is currently going through a code re-write. The destination is https://github.com/jadonk/bone101/tree/gh-pages/Support/bone101/UI, but the live-mostly-working version is at http://jadonk.github.io/Beaglebone-UI/BBUI.html: 

 

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

Just wanted to point this out in case you wanted to examine this Canvas-based front-end.  The socket.io RPC connection that bonescript creates is probably its greatest feature, but also its biggest security hole.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORp%3Dp5bycRkzmjcRzRAsPnE4%2B%3DDSZoPFFCjLN-bhxCEZGw%40mail.gmail.com.

[William Hermans]

I think what would be super useful, if a web interface, or maybe even native app that did pinmux for people. Select a few options from dropdowns, click a few checkboxes, and viola ! Have it generate a *dts file for you.

I will say, and agree that this platform is not like something like the rPI( Arduiono-esque). In that it's a platform that is more geared towards the professional spectrum of embedded Linux. But there is not reason why creating an overlay has to turn into brain surgery. Or take a new user months to figure out. Tom King's son wrote one 2-3 years ago, except to me it's always been unclear what exactly it does, and why. From the perspective of  a person being a device tree overlay newb, and knowing what to select for options.  Anyway, TI has a muxing tool, for many of their processor. I think there is one for the AM355x set too. But the way TI does thing, with apps of this nature always grates on me . . . For starters I'm a huge anti-proponent of the Java language, and JRE in general. Where the developers from TI seems to love and only know Java . . . *bleech*. Yes, an overstatement. Anyway, no one says I have to use these apps, and I don't. But I do think there should be better native tools available from the community. Does it mean I'm willing to contribute to such a project myself ? Yes, but finding the actual time( because of priorities ), is usually *the* roadblock. That, and I often find myself interested in odd problems to be solved, and find myself off on a wild tangent . . .chasing rabbits.

This is one of the major reasons why I think single pin device tree source files are a good thing. It makes it much easier for the beginner to look, and see what's going on. In my mind, this is "just another reason" why I think universal io is an awesome project. It makes it easier for device tree overlay newbs to see what's happening. Not to mention, my Bonejs project needed a way to have pins muxed. But I wanted to keep pin muxing separate from Bonejs. As it's my own opinion that pin muxing, and the idea behind Bonejs are two seperate "things", and should be kept separate. For several reasons, but mainly to keep things simple, and far less complex.

[William Hermans]

Charles,

The idea I had in my mind is that someone could potentially, more easily. Figure out how to use device tree files. By examining something that is closer to self explanatory, and not a wall of code to hurdle. I think your overlays illustrate very well how device tree files work, but that wall of code obstacle makes it much harder to read through. This way, you can see what exactly is needed for a single pin, and by extension should be able to make it much easier for a beginner to combine pins into their own overlay file. That's how it worked for me anyway. I understand device tree source files, pin muxing, and all this much better. Granted, I still do not know *everything*, but that's ok. I feel really good about how much I understand right now.

Also, as I mentioned above. I needed a way to mux pins for my Bonejs project, and I think this is the perfect, and most "generic" way of fitting all needs, for any potential users of Bonejs. But, I am still open to other ideas / options.

--
Charles Steinkuehler
cha...@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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6b589e72-2518-5be1-76b9-acd3312bb5f8%40steinkuehler.net.

[Mike]

On 07/28/2016 03:20 PM, William Hermans wrote:
> I think what would be super useful, if a web interface, or maybe even
> native app that did pinmux for people. Select a few options from
> dropdowns, click a few checkboxes, and viola ! Have it generate a *dts
> file for you.

http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator#dtogenerator

Mike

[William Hermans]

Hi Mike,

Yeah, that's pretty cool, except it does need an update at minimum when showing sysfs paths for *ocp* targets

. Also I'm not entirerly sure it generates correct overlay files for( at minimum ) ehrpwm* and kernels 4.1.x+

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/8ab582f3-53bc-4bbb-4b7d-506f3e8d1aa2%40gmail.com.

[William Hermans]

So . . . yeah. For 4.x kernels it's broken.

william@beaglebone:~$ ls /sys/class/pwm/
william@beaglebone:~$ nano bspwm_P9_22_13-00A0.dts
william@beaglebone:~$ dtc -O dtb -o bspwm_P9_22_13-00A0.dtbo -b 0 -@ bspwm_P9_22_13-00A0.dts
Error: bspwm_P9_22_13-00A0.dts:53.2-54.1 syntax error
FATAL ERROR: Unable to parse input tree

At minimum and just at a glance.

 fragment@20 {
        target = <&epwmss0>;
        __overlay__ {
            status = "okay";
        };
    };

    fragment@21 {
        target = <&ehrpwm0>;
        __overlay__ {
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <>;
        };
    };

Fragment @20 here is from a working overlay file. epwmss* is required to use ehrpwm* modules in kernel 4.x. Additionally . . . there's a syntax error that I do not care to look into . . .