RE: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

Hi Jason,

From: Jason Kridner

Adding devicetree and linux-arm-kernel lists based on feedback on IRC...

On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner [off-list ref] wrote:

quoted

I'd like to discuss moving our current library of cape devicetree
overlay sources into a single tree, including the boot .dtb files for
BeagleBoard.org boards and moving towards enabling as much of the cape
support into a single boot-time .dtb file with an approach similar to
the cape-universal overlay
(https://github.com/cdsteinkuehler/beaglebone-universal-io), but not
in an overlay.

First of all, I want to note this doesn't change my view on the
importance of mainline support for devicetree overlays. They are still
absolutely critical and highly useful, solving problems that cannot be
solved through boot-time devicetrees. I'm simply looking for an
approach that will complement the availability of overlays and provide
the best user experience.

Robert has been talking about the actions required to clean-up Debian
Jessie support in another thread
(https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ)
and I suggested we should add a bit of a detour by cleaning up the
cape support for the mainline kernel and switching away our primary
process of supporting capes from using overlays to using a single
devicetree file provided at boot. I promised a pull-request and hadn't
gotten around to sending it until now (below). No architecture changes
have been made in my pull-request, just bringing in the kernel
devicetree source history. This suggestion is based on several
assumptions, any number of which might be wrong.

The assumptions (for which I'm looking for feedback/corrections):
* The overlays pretty much all need to be compiled into the kernel if
they are going to be loaded using kernel command-line arguments or
/etc/capemgr for the majority of distros. While many cape devicetree
use cases are perfectly happy with loading at run-time rather than
boot-time, it seems there should be a mechanism for pushing cape
support into the category of being available at boot-time across
distributions.
* The devicetree sources, including the primary boot .dts files, will
eventually be removed from the kernel source tree. I'm not too sure if
and when it'll really happen, but starting up a project to maintain
the definitive beagleboard.org board devicetree files outside the
kernel seems to make sense. Given the interdependency of the boot .dtb
and the overlay .dtbo files, combining them into a single repository
where every distribution can pick them up seems like a natural and
obvious choice. There are of course some dependencies on kernel
versions, but I believe most of those have settled out by now and we
should be OK moving forward.

+1
Yes, moving cape DTS out of kernel tree should help developers.
There are quite a few cape patches floating in mail-lists, but as cape
DTS is still not accepted in mainline so they get lost and forgotten.
So one place for collecting all this is a good idea.


However, somehow the universal I/O DTS looked seemed complicated:
(1)
All capes work standalone, but due to share pin-mux some cape
combinations cannot be used simultaneously. But most users of
BeagleBone are already well-versed with DT and kernel infrastructure,
so they need not be spoon fed to get a out-of-box working solution
for each combination. If there is proper documentation is available
about compatibility of capes with each other, then users will figure
out themselves.

(2)
Also, there was a talk of enabling and disabling DT fragments via u-boot.
That should also be explored instead of complicating cape DTS.

(3)
BeagleBone community and outside are coming out with new featured
capes, which might possess a challenge to get a absolute non-conflicting
universal I/O DTS. What might be working today might have conflicts
tomorrow with introduction of new capes.
We should be open to be compatible to capes developed outside
Beaglebone.org. In my view this is important for longer term.
Example: http://valentfx.com/logi-bone/

So, plz review my feedback and if you plan to create an external tree
for beaglebone Capes, I would be happy to submit some cape patches.


with regards, pekon