It would be great if you could take a look at this and see if it is suitable for you and if I’m headed down the right path. There is a pre-built linux-image package and if you use one of Robert’s recent test images, you can simply use ‘dpkg -i XXX.deb && reboot’ to install it.
It would be great if config-pin was updated to work with this. Right now, I have commented out the exit statement where cape-universal isn’t detected.
For patches and links to the build, see https://github.com/beagleboard/linux/pull/6
This would mean that userspace configuration of these pins would no longer require an overlay unless you needed to load a driver not already configured. I haven’t gone and enabled many of the peripherals yet, so those patches are still desired. I’m going to start adding this to my bonescript code for testing it and will bring in the additional overlay parts for the peripherals as I need them.
I do not have time to test this myself currently Jason. But one thing worth mentioning. PLEASE, do not make this part of a huge META package. In other words make it nice for people who wish to use this, and not 500 other unnecessary packages . . .
I just pulled this and pushed it out..
It'll be part of "3.14.17-ti-r18"
sudo apt-get update
sudo apt-get install linux-image-3.14.17-ti-r18
Which include 1Ghz for ES 2.0 parts and pruss is no enabled too.
It would be great if you could take a look at this and see if it is
suitable for you and if I'm headed down the right path. There is a
pre-built linux-image package and if you use one of Robert's recent test
images, you can simply use 'dpkg -i XXX.deb && reboot' to install it.
This is great news, and what I was hoping for when I started working on
a universal device-tree overlay!
It would be great if config-pin was updated to work with this. Right now, I
have commented out the exit statement where cape-universal isn't detected.
I'll see if I can find some spare time soon to test and get some better
checks into the config-pin script.
I've also been thinking config-pin should perhaps be something other
than a bash script for speed (perhaps Python?), but I'm not sure if it's
the shell or sysfs that's so sluggish when setting up a large number of
pins. Using something other than bash would also make it possible to
factor some of the pin intelligence into user-mode (instead of kernel
code or the device-tree). It would be nice if it was possible to do
something like enable a UART and have it's pin mux setup correctly, but
*ALSO* be able to do something like just enable the Tx pin without
generating a custom device-tree. Thoughts?
Ultimately, config-pin should probably get turned into something that
can generate DT changesets and ask the kernel to apply them. I
currently have no idea what this interface is going to look like.
It would be nice if it was possible to do
something like enable a UART and have it’s pin mux setup correctly, but
ALSO be able to do something like just enable the Tx pin without
generating a custom device-tree. Thoughts?
Sounds very flexible, and also very complex to implement. If you can pull it off I’d say it would be an excellent addition.
I've made some changes to config-pin that should help it deal with
running on a 3.14+ kernel that doesn't have capemgr:
I also tried to (more) gracefully handle the instance where config-pin
was called for a GPIO pin that has not been exported (as is the case
with all I/O pins and the default 3.14 device-tree). Now if you ask
config-pin to setup a pin in GPIO mode and the pin is not exported, it
will complain about not being able to set the direction, but will still
update the pinmux value correctly. Setting a pin to something other
than GPIO will not trigger this warning. Example:
debian@beaglebone:~$ uname -a
Linux beaglebone 3.14.17-ti-r18 #1 SMP Fri Sep 5 00:21:05 UTC 2014
debian@beaglebone:~$ config-pin p8.10 in+
WARNING: GPIO pin not exported, cannot set direction or value!
debian@beaglebone:~$ config-pin p8.10 timer
Next up, I plan to try and see if I can extend the pinmux helper with a
mode (settable via device-tree) so the device tree can specify an
initial mode for the pins, but the pinmux settings will still be
changeable at run-time via sysfs and config-pin.
Ideally, it should be possible to use most of the BBB special-purpose
hardware without having to craft a custom device tree file!