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’"
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 ?
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,
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:
* 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.
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?).
See the readme:
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,
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,
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!
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.
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 . . .
Note the security 'bar' is not set particularly high, given the
default BBB images have no root password. 
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.
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 ?
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.
Hi William!
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
/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.
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.
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.
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 ?
