I have the first version of my universal device tree available:
https://github.com/cdsteinkuehler/beaglebone-universal-io
The general idea is to enable virtually all generally useful hardware
via a single device tree, and use the pinmux helper to allow run-time
setup of the pin multiplexing from user-space (no writing custom kernel
drivers or editing and compiling device trees needed!).
This is still a work in progress, but it's stable enough to begin
testing. I would appreciate review by anyone familiar with device tree
files, and particularly anyone using the various special purpose
hardware (I've mostly just used the PRU and GPIO pins so far).
When the device tree is loaded, all I/O pins currently default to GPIO
inputs, with pull up/down resistors enabled matching the hardware reset
defaults. If you would like to use UART4 to transmit some data, the
device is already created (/dev/ttyO4), but it's pins are not connected
to the outside world. Simply use the pinmux nodes in sysfs to set P9
pin 13 to the uart function (uart4_txd):
echo uart > /sys/devices/ocp.*/P9_13_pinmux.*/state
...and you've got UART data coming out P9_13! The individual control
over I/O pin multiplexing with all devices already loaded will hopefully
avoid some of the problems people have been having with trying to load
multiple overlays. This way you don't have to craft a custom device
tree if you want to use the rts/cts lines for a UART, or perhaps don't
need the data in pin of an SPI bus and would like to use it as an output.
GPIO is controlled in the usual way via /sys/class/gpio, which currently
requires you know the kernel gpio number of the BeagleBone pin you want
to manipulate. I hope to code up an application to make this easier,
but it may take some time.
More details and a list of all the valid pinmux values you can use for
the various pins is listed in the README on github.
Comments welcome!
But please stick to the merits or shortcomings of this device tree
overlay. Philosophical musings on kernel internals should go in a new
thread! 
Hi Charles,
I only had a quick look on your work, but there seems to be a mixup in the addresses and also the pin usage values:
For example pin “/* P9_24 (ZCZ ball D15) */” in line 419 should have the address 0x184 and not 0x084, and also the “P9_26_can_pin” (in line 447) as transmitter should have the bit 5 (RX) disabled. It seems that there are more mixups than only these two examples…
Best regards,
Michael
Hi Charles,
I only had a quick look on your work, but there seems to be a mixup in the
addresses and also the pin usage values:
Thanks for the help!
For example pin "/* P9_24 (ZCZ ball D15) */" in line 419 should have the
address 0x184 and not 0x084,
Yep, good catch! I'll double-check all the addresses. There was a lot
of cut-and-paste and manual typing, so I'm sure there are more goofs to
be found.
and also the "P9_26_can_pin" (in line 447) as
transmitter should have the bit 5 (RX) disabled. It seems that there are
more mixups than only these two examples...
I intentionally leave the receive buffer enabled so it's possible to
read the state of the pin (it's just a minor amount of extra power
overhead). If leaving the Rx buffer enabled is inappropriate for some
of the special-purpose modes, it's easy enough to fix.
I'm not generally familiar with using the hardware functions other than
GPIO and direct PRU I/O to know what appropriate settings would be, and
would appreciate any help or pointers. Known working device tree
overlays that exist outside the kernel tree are especially welcome as a
reference.
GPIO is controlled in the usual way via /sys/class/gpio, which currently
requires you know the kernel gpio number of the BeagleBone pin you want
to manipulate. I hope to code up an application to make this easier,
but it may take some time.
I have the first version of a helper application available in the github
repository. Run the config-cape-universal script as root or via sudo to
control pin multiplexing and GPIO direction.
Usage:
config-cape-universal <pin> <mode>
Set <pin> to <mode>, configuring pin multiplexing and optionally
configuring the gpio. Valid <mode> strings vary based on <pin>,
however all pins have a default and gpio mode. To setup gpio
the following <mode> strings are all valid:
gpio :
Set pinmux to gpio, gpio direction and value unchanged
in | input:
Set pinmux to gpio and set gpio direction to input
out | output :
Set pinmux to gpio and set gpio direction to output
high | 1 :
Set pinmux to gpio and set gpio direction to output driving high
low | 0 :
Set pinmux to gpio and set gpio direction to output driving low
config-cape-universal -l <pin>
list valid <mode> values for <pin>
config-cape-universal -q <pin>
query pin and report configuration details
config-cape-universal -f <file>
Read list of pin configurations from <file>, one per line
Comments and white-space are allowed
<pin> is supposed to be something like P8_09, but the code is lax on
what it accepts, so p8x09, p809, 809, and 89 all mean the same thing.
<mode> is more particular at the moment, and is currently case sensitive.
Please test and report back any problems. Also, if you have an
suggestions for improved operation or syntax, please let me know. At
this point, nothing is carved in stone, and I'd rather change things to
get it right than live with what seemed like a good idea to me at the
time! 