Hi All
I am seeking some clarification and/or insights into the current state and future of BBB GPIO and device support.
It is my understanding that the Cape Manager will not be ported to kernels greater than 3.8. This, as far as I can tell, does not seem to be an official position rather it seems there is no momentum behind the Cape Manager in its current form and nobody who has the skills to do so is very keen on working on a port to future kernels. Is that a fair assessment?
I have seen references to a sort of Generic Device Driver which will make it possible to configure the GPIO and muxed devices from user space kind of like a super sysfs. However, I can no longer find the name or the link. Does such a thing exist and if so, is it the likely way forward?
I also have also seen references to a sort of generic .dbs file which contains a number of #includes people can comment and uncomment in order to enable specific cape functionality. Is this anything other than an idea at present and is this likely to be the way device tree support for capes is implemented going forward?
What is currently thought to be the best practice to configure GPIO’s and muxed devices for kernels with no cape manager? I am currently editing the Device Tree .dbs file manually. However, since the .dbs file is complicated and usually requires edits in multiple locations, this is not the easiest of configuration steps to communicate to users. I would appreciate any advice.
In short, what is the current thinking and likely direction on the BBB GPIO and other device configuration? Any insights or comments to clarify where we are and where we are likely to go would be appreciated.
Hi All
I am seeking some clarification and/or insights into the current state and
future of BBB GPIO and device support.
It is my understanding that the Cape Manager will not be ported to kernels
greater than 3.8. This, as far as I can tell, does not seem to be an
official position rather it seems there is no momentum behind the Cape
Manager in its current form and nobody who has the skills to do so is very
keen on working on a port to future kernels. Is that a fair assessment?
"Cape Manager" functionality has been added to newer mainline kernels in
the form of device tree change sets. It is expected this functionality
will be back-ported to the 3.14 kernel likely to become the next
'standard' BeagleBone kernel after 3.8.
I have seen references to a sort of Generic Device Driver which will make
it possible to configure the GPIO and muxed devices from user space kind of
like a super sysfs. However, I can no longer find the name or the link.
Does such a thing exist and if so, is it the likely way forward?
You're probably thinking of my universal cape:
...which can be controlled with the config-pin utility (or manually via
sysfs). This allows user-mode run-time configuration of pin
multiplexing and GPIO state, with most "useful" hardware (UARTs, PWMs,
etc) enabled.
I also have also seen references to a sort of generic .dbs file which
contains a number of #includes people can comment and uncomment in order to
enable specific cape functionality. Is this anything other than an idea at
present and is this likely to be the way device tree support for capes is
implemented going forward?
This sounds like the current state of the 3.14 device tree for the
'Bone. This will likely remain in place (to allow easy user-mode setup
of most common I/O needs), but will be enhanced by the ability to use
device tree changesets once this feature gets back-ported.
What is currently thought to be the best practice to configure GPIO's and
muxed devices for kernels with no cape manager? I am currently editing the
Device Tree .dbs file manually. However, since the .dbs file is complicated
and usually requires edits in multiple locations, this is not the easiest
of configuration steps to communicate to users. I would appreciate any
advice.
I would recommend using the cape-universal features RCN has merged into
the 3.14 'Bone kernels and the config-pin utility for everything you
can. Some things, however, will still require manually editing the
device tree source and installing a new *.dtb file.
Charles - thank you for your advice - it is much appreciated.