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

GoogleGroups
1

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
(GitHub - cdsteinkuehler/beaglebone-universal-io: Device tree overlay and support scripts for using most available hardware I/O on the BeagleBone without editing dts files or rebuilding the kernel), 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.
* There seems to be little or no interest in my previous proposal to
use cape EEPROMs to store the overlay fragments. Given some churn in
the devicetree node definitions, it is likely this would have failed
in bad ways anyway. It seems mostly reasonable to expect users to
update their kernel and firmware to gain support for new add-on
hardware and we mostly try to avoid regressions (with the seemingly
ever-living exception of 3D graphics support), so I think I'm better
aligned with the community to drop my older suggestion. Some people,
including CircuitCo, are building capes without configuration EEPROMs
now, so a different recommended mechanism seems like a requirement.
* With the patches in our vendor 3.8 kernels and with all recent
mainline kernels, performing userspace muxing operations has become
easy again. It seems to be possible to turn on drivers not currently
in use without an unacceptable level of bloat or conflict. This has
been partially proven out using Charles' universal cape
(GitHub - cdsteinkuehler/beaglebone-universal-io: Device tree overlay and support scripts for using most available hardware I/O on the BeagleBone without editing dts files or rebuilding the kernel), though I
still have some concerns about conflicts. The result might be that
there is still some number of overlays, but the approach of minimizing
the overlays and instead relying on the existing loading/unloading
mechanisms of the mainline drivers as much as possible feels right to
me.
* It will still be some time before devicetree overlay support is
adopted in the mainline kernel. While I still see a strong need to
have devicetree overlay support and CapeMgr in the mainline, the
desire here is to optimize the user experience in the shortest term
possible. Users get really confused by the errors that get generated
by loading incorrect devicetree overlays and it is always nice when
you can avoid confusing users.

My suggestion is:
* Maintain the source for .dtb and .dtbo files for all BeagleBoard.org
boards at http://github.com/beagleboard/devicetree-source, overriding
the sources in the mainline kernel when performing kernel builds. We
can host pre-built .dtb and .dtbo files at a normailzed location
outside the source repository for those that don't want to perform the
builds, since I don't believe the binary format is changing any time
soon other than the overlay support we utilize. Any patches accepted
into mainline as long as these files still exist there as well should
be merged to try to keep these in-line as long as possible,
anticipating eventual removal from mainline.
* Have cape makers submit pull requests to have their cape enabled in
the single boot-time devicetree overlay for each board they support.
The base drivers should be enabled at the earliest point where they
don't cause a conflict, minimizing what gets put into their overlays.
The final mux configuration and other points of conflict should be
kept in a board-specific overlay to make that configuration available
at boot. If the cape is disabled on the kernel command-line, the
kernel doesn't include CapeMgr support, or the board doesn't include a
configuration EEPROM, users would still have the ability to perform
run-time userspace mux configuration without CapeMgr unless
conflicting drivers need to be loaded.

Alternatively, if we don't think this is where things belong, perhaps
we could try to move all of this into the u-boot sources, though
people using other bootloaders might not find this the most useful
approach.

The pull request for http://github.com/beagleboard/devicetree-source:

The following changes since commit a524bf5d5e173795ce4cb214280f304588b1d78d:

  capes: add BB-VIEW-LCD4-01-00A0 & BB-VIEW-LCD7-01-00A0 (2014-05-29
15:59:31 -0500)

are available in the git repository at:

  git@github.com:jadonk/cape-firmware master

for you to fetch changes up to 9de20db80056b72d6e1f61b68447ba8f2d12cf9c:

  Beagle DTS: remove deleted files from Makefile (2014-06-02 12:35:28 -0400)

2

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

3

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

4

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

5

Hi Jason,

From: Jason Kridner

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

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

6

Here's the most obvious question in the world on this topic. Are capes
hot-pluggable?

Looking at the posts on google+ from David Anders, they're using pin
headers for connectivity, with no additional protection against hot-
plugging, and no sequencing of pin connection. In other words, they are
not hot-pluggable.

So, why do we need to add a load of infrastructure to the kernel to allow
the device tree to be modified at run time? At present, the way the
entire DT infrastructure works is that it assumes the DT remains static
and never changes - this applies not only to the core DT code, but also
to all the drivers which have been converted.

So, you're asking for a feature which is impossible to really make use
of on the hardware which you want to use it.

Why should kernel developers go to the extent of adding support for DT
modification at runtime when the platform you want this for doesn't even
support hotplugging of these capes?

The logical way to deal with this is to have the boot loader merge DT
fragments together before it calls the kernel, so the kernel sees a single
DT blob which describes the whole hardware.

A good way that this could have been done is to put an I2C EEPROM on
each cape, and have that store the DT fragment. The boot loader could
have then read that from each cape, and used that information to build
up the final DT. Why this hasn't been thought of, considering that the
kernel has been moving towards DT for years, is quite unbelievable.

I'm quite sure you're going to say that that introduces additional
hardware expense. Yes it does, but it also eliminates the problem you
are now bringing up.

7

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

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.

Here's the most obvious question in the world on this topic. Are capes
hot-pluggable?

Looking at the posts on google+ from David Anders, they're using pin
headers for connectivity, with no additional protection against hot-
plugging, and no sequencing of pin connection. In other words, they are
not hot-pluggable.

So, why do we need to add a load of infrastructure to the kernel to allow
the device tree to be modified at run time? At present, the way the
entire DT infrastructure works is that it assumes the DT remains static
and never changes - this applies not only to the core DT code, but also
to all the drivers which have been converted.

So, you're asking for a feature which is impossible to really make use
of on the hardware which you want to use it.

Why should kernel developers go to the extent of adding support for DT
modification at runtime when the platform you want this for doesn't even
support hotplugging of these capes?

The logical way to deal with this is to have the boot loader merge DT
fragments together before it calls the kernel, so the kernel sees a single
DT blob which describes the whole hardware.

Frankly, if we're going to push device tree merging to be someone elses
problem, I'd like to push it out to userspace.

A good way that this could have been done is to put an I2C EEPROM on
each cape, and have that store the DT fragment. The boot loader could
have then read that from each cape, and used that information to build
up the final DT. Why this hasn't been thought of, considering that the
kernel has been moving towards DT for years, is quite unbelievable.

I had actually talked about this a long while back (face to face) with
people, but the problem was (and still kind of is) the bindings
changing, etc.

8

And that's a strong argument for having stable bindings - or at the
very least, ensuring that new bindings which are compatible with older
versions.

We all know how to deal with this, we've had these discussions frequently
with the same outcomes. It's really not something that needs discussing
yet again, just to reach the same conclusions.

Look, go back to the x86 model. Why does the kernel run on virtually
any x86 computer there (firmware bugs not withstanding)? It's not only
because the platform is mostly standardised, but also because it's
standardised at the firmware (BIOS) level as well. So there's standard
ways to find out what hardware is fitted, standard ways to find out how
it's wired up (eg, which interrupts) and such like.

Like it or not, with ARM64 moving into the server space, and (I believe)
we're saying that we want FDT inside ACPI - well, as soon as you go down
that path on servers, FDT _has_ to be standardised and stable. Server
space will /not/ stand having to update the FDT in firmware for each
incremental kernel version change, just because we've decided to change
the bindings.

Exactly the same should start applying here. Yes, we may not want bindings
to be entirely frozen, but when we /do/ change them, we must change them
in a way that is compatible with the old bindings.

Like, for instance, the iMX AHCI driver that I've had for the last five
months patches to fix the incomplete DT bindings for: we have platforms
using it which have hard-coded non-hardware default parameters into the
driver. I need different hardware parameters for it to come close to
working on my hardware, so when introducing new properties for these, I
_must_ ensure that when these properties are not specified (as they aren't
for the existing platforms using the driver) that their non-hardware
default values are used. This even means providing negative options to
_disable_ features on the interface, because providing positive "enable
this feature" options would mean that their bindings break.

This is not rocket science.

9

It's important to note that Jason's use case is not the real one driving
runtime DT modification. You'll have to go back to threads like
https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all
hashed out. The clearest use cases are the FPGA folks that are loading
their bitstream from userspace and due to DT-everywhere also need to
initiate runtime modification of the live DT tree from userspace.
There's a lot of discussion over many threads where this has been
debated.

-Matt

10

Okay, so it was debated, and the outcome of that debate has been... no
change. That's probably because it is an incredible amount of work to
achieve it, and none of the overloaded DT maintainers (who don't have
enough time to review new bindings) have any intention of putting their
precious resources towards it.

the way devices are created from the parsed OF tree structures (the
device_node structures) needs to change such that when an OF tree node
is removed, its corresponding device is also removed. This probably
needs a struct device pointer in the device_node struct.

Then there needs to be support to modify the parsed OF tree (not only
to add nodes but also to remove nodes) and do the right thing when a
node is added and/or removed.

However, there's harder cases to solve. There's several instances where
device nodes do not correspond with a struct device, and these nodes are
parsed by the driver. Such things as the of_graph stuff, which describes
the inter-connectivity of a display subsystem or v4l2 subsystem. The
nodes may be specified, but the target device for one of the links may
be disabled at original probe time, but later becomes enabled via
modification - this is one of the difficult cases since it needs the
driver to cooperate with the change, and there's no existing way to
notify it of that change.

As with any kernel change, it needs people to write code. If no one writes
code, no change happens. Endlessly discussing it on mailing lists does not
result in code being written.

However, going back to the original stated platform - none of this
complexity is required there. Once power is applied, the platform
hardware configuration is fixed (unless you want to yank a board off
and risk destroying the hardware in doing so.) So, if Jason's interest
is in the capes, then the simplest and easiest approach is to have the
boot loader deal with it. If it's about FPGAs and dynamically loading
bitstreams into them, then maybe a dynamic device tree is the answer -
but /someone/ then has to create patches to achieve that. If no one is
willing to create those patches, then forget the idea of a dynamic
device tree, because it won't happen on its own.

11

> > Why should kernel developers go to the extent of adding support for DT
> > modification at runtime when the platform you want this for doesn't even
> > support hotplugging of these capes?
>
> It's important to note that Jason's use case is not the real one driving
> runtime DT modification. You'll have to go back to threads like
> https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all
> hashed out. The clearest use cases are the FPGA folks that are loading
> their bitstream from userspace and due to DT-everywhere also need to
> initiate runtime modification of the live DT tree from userspace.
> There's a lot of discussion over many threads where this has been
> debated.

Okay, so it was debated, and the outcome of that debate has been... no
change. That's probably because it is an incredible amount of work to
achieve it, and none of the overloaded DT maintainers (who don't have
enough time to review new bindings) have any intention of putting their
precious resources towards it.

I don't believe this is completely true. Pantelis and Grant are working
together on getting DT overlays upstream. It's pretty far along. It
doesn't mean there aren't serious issues with the way the DT core code
was implement assuming it would be static.

From my rudimentary understanding of the OF code, it seems to mean that
the way devices are created from the parsed OF tree structures (the
device_node structures) needs to change such that when an OF tree node
is removed, its corresponding device is also removed. This probably
needs a struct device pointer in the device_node struct.

Then there needs to be support to modify the parsed OF tree (not only
to add nodes but also to remove nodes) and do the right thing when a
node is added and/or removed.

However, there's harder cases to solve. There's several instances where
device nodes do not correspond with a struct device, and these nodes are
parsed by the driver. Such things as the of_graph stuff, which describes
the inter-connectivity of a display subsystem or v4l2 subsystem. The
nodes may be specified, but the target device for one of the links may
be disabled at original probe time, but later becomes enabled via
modification - this is one of the difficult cases since it needs the
driver to cooperate with the change, and there's no existing way to
notify it of that change.

As with any kernel change, it needs people to write code. If no one writes
code, no change happens. Endlessly discussing it on mailing lists does not
result in code being written.

Yes, I suppose you missed the active work on the DT overlay series. As I
mentioned, there's active development on these things. There's also
active discussion on some of the challenges.

However, going back to the original stated platform - none of this
complexity is required there. Once power is applied, the platform
hardware configuration is fixed (unless you want to yank a board off
and risk destroying the hardware in doing so.) So, if Jason's interest
is in the capes, then the simplest and easiest approach is to have the
boot loader deal with it. If it's about FPGAs and dynamically loading
bitstreams into them, then maybe a dynamic device tree is the answer -
but /someone/ then has to create patches to achieve that. If no one is
willing to create those patches, then forget the idea of a dynamic
device tree, because it won't happen on its own.

https://lkml.org/lkml/2014/5/28/280

-Matt

12

Hi Russell,

CCing gcl.

Why should kernel developers go to the extent of adding support for DT
modification at runtime when the platform you want this for doesn't even
support hotplugging of these capes?

It's important to note that Jason's use case is not the real one driving
runtime DT modification. You'll have to go back to threads like
https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all
hashed out. The clearest use cases are the FPGA folks that are loading
their bitstream from userspace and due to DT-everywhere also need to
initiate runtime modification of the live DT tree from userspace.
There's a lot of discussion over many threads where this has been
debated.

Okay, so it was debated, and the outcome of that debate has been... no
change. That's probably because it is an incredible amount of work to
achieve it, and none of the overloaded DT maintainers (who don't have
enough time to review new bindings) have any intention of putting their
precious resources towards it.

Wait, wait wait. Who said there's no progress there. We're already proceeding
in that direction.

Apparently you are not aware that runtime modification of DT is part of the
DT capabilities since a few years back, as normally used on pSeries class
of machines.

The overlays are a method of having a sane, easy to use method for reconfigurable
hardware.

From my rudimentary understanding of the OF code, it seems to mean that
the way devices are created from the parsed OF tree structures (the
device_node structures) needs to change such that when an OF tree node
is removed, its corresponding device is also removed. This probably
needs a struct device pointer in the device_node struct.

Then there needs to be support to modify the parsed OF tree (not only
to add nodes but also to remove nodes) and do the right thing when a
node is added and/or removed.

Already done.

However, there's harder cases to solve. There's several instances where
device nodes do not correspond with a struct device, and these nodes are
parsed by the driver. Such things as the of_graph stuff, which describes
the inter-connectivity of a display subsystem or v4l2 subsystem. The
nodes may be specified, but the target device for one of the links may
be disabled at original probe time, but later becomes enabled via
modification - this is one of the difficult cases since it needs the
driver to cooperate with the change, and there's no existing way to
notify it of that change.

Actually there is, and we're working on making a generic method of handling
all these cases.

Hint, take a look at of_reconfig_notifier_register please.

As with any kernel change, it needs people to write code. If no one writes
code, no change happens. Endlessly discussing it on mailing lists does not
result in code being written.

The code is already written. If you have any specific objections to the patchset
I've already posted, comments are welcome.

However, going back to the original stated platform - none of this
complexity is required there. Once power is applied, the platform
hardware configuration is fixed (unless you want to yank a board off
and risk destroying the hardware in doing so.) So, if Jason's interest
is in the capes, then the simplest and easiest approach is to have the
boot loader deal with it. If it's about FPGAs and dynamically loading
bitstreams into them, then maybe a dynamic device tree is the answer -
but /someone/ then has to create patches to achieve that. If no one is
willing to create those patches, then forget the idea of a dynamic
device tree, because it won't happen on its own.

The complexity is absolutely required, and it has nothing to do with beaglebone
capes.

The fact of the matter is that reconfigurable hardware is here, on shipping system,
and we, as the linux kernel community have to make sure it works, and that it works in
a sane way.

--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Regards

-- Pantelis

13

"capes" as in Beaglebone capes might not be due to the mechanical constraints you listed.

"capes" as a concept of pluggable hardware might well be. here is a real world example of commercially available pluggable hardware add-ons on a Linux system back from 2008:

http://en.wikipedia.org/wiki/Archos_Generation_6#Accessories

depending on the add-on, different interfaces like GPIO, UART, USB, SPI using the same pins were used and there was no reboot needed to load a new hardware configuration or change the pinmux

14

As others have pointed out, capes aren't the only use case. pseries
already modifies the tree at runtime, and the FPGA users want the
ability to add/remove additional DT blocks. I've also heard from
hobbiest/maker developers that by deferring the load of additional data
to userspace means they don't need to mess with the boot path once it is
working. The feature is coming.

g.

15

Why should kernel developers go to the extent of adding support for DT
modification at runtime when the platform you want this for doesn't even
support hotplugging of these capes?

I'm not convinced you should, but Grant Likely seemed to be much more open
to the idea with the latest attempt https://lkml.org/lkml/2014/5/29/586

A good way that this could have been done is to put an I2C EEPROM on
each cape, and have that store the DT fragment. The boot loader could
have then read that from each cape, and used that information to build
up the final DT. Why this hasn't been thought of, considering that the
kernel has been moving towards DT for years, is quite unbelievable.

I believe that was Jasons original idea.

From a users perspective, a fixed DT fragment in EEPROM quickly ends up
being out of step with OS implementation and simply becomes another
pain point that needs worked around.

Anyway, there already exist capes in large scale production that don't
have the EEPROM. As well as ones that use the required I2C bus for other
purposes, thereby blocking all other capes connected at the same time
from using that mechanism even when they are capable of doing so.
Not forgetting the number of capes that have shipped already without the
DT fragment in their EEPROMS.

Too late to shut the barn door, question is where to go from here.

Consolidation the dt knowledge in one tree is a good idea, regardless of
how it's eventually used.

16

Yes. This was a few years back (a bit before the first beaglebone was
public) so before we had really pushed up on some level of binding
stability.

17

Right, so looking back in the git history, this project has been going
on for... at least four years? Probably longer than the length of time
that we've been converting ARM to DT. At no point during that has anyone
brought up the issue of DT being dynamic, so none of the drivers which
we have been converting caters for this.

Isn't this a bit of a missed opportunity, if this is a direction that
OF wishes to head towards?

Wouldn't it have been relevant to the discussion at kernel summit too,
concerning DRM/v4l2/componentised systems? What if someone comes along
tomorrow with part of their multimedia based system inside a FPGA
which they program up at runtime?

18

Hi Jason,

From: Jason Kridner

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

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
(GitHub - cdsteinkuehler/beaglebone-universal-io: Device tree overlay and support scripts for using most available hardware I/O on the BeagleBone without editing dts files or rebuilding the kernel), 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.

I think you have too much confidence in users. If this doesn't hurt
power users, then why is it bad have an option to spoon feed? This
doesn't prevent anyone with knowledge of DT from doing their own
thing.

(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.

Link? Relevance?

(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/

The tree isn't only for beagleboard.org, but anyone building add-on
boards for beagleboard.org boards. In fact, there are 0 official
add-on boards from beagleboard.org as of now. CircuitCo makes a bunch
and I believe there are some coming from TI soon, but there are none
from beagleboard.org itself and most capes come from other parties.
Registry is at http://beaglebonecapes.com and
BeagleBoard.org - cape.

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.

Great. GitHub - beagleboard/devicetree-source: Sources for devicetree files describing the CPU peripherals

19

The complexity is absolutely required, and it has nothing to do with
beaglebone capes.

The fact of the matter is that reconfigurable hardware is here, on
shipping system, and we, as the linux kernel community have to make
sure it works, and that it works in a sane way.

Right, so looking back in the git history, this project has been going
on for... at least four years? Probably longer than the length of time
that we've been converting ARM to DT. At no point during that has anyone
brought up the issue of DT being dynamic, so none of the drivers which
we have been converting caters for this.

Isn't this a bit of a missed opportunity, if this is a direction that
OF wishes to head towards?

I believe it absolutely is a missed opportunity, but that doesn't mean
it isn't still needed moving forward. We've been using overlays
successfully in the BeagleBoard.org community on BeagleBone Black for
over a year now. It is just a shame we're still shipping a 3.8 kernel.
This universal overlay provides hope to support most add-ons, but it
doesn't address the dynamic nature of some add-on hardware. It is
certainly my hope that this effort doesn't derail the overlay
development work.

20

Hi Russell,

The complexity is absolutely required, and it has nothing to do with
beaglebone capes.

The fact of the matter is that reconfigurable hardware is here, on
shipping system, and we, as the linux kernel community have to make
sure it works, and that it works in a sane way.

Right, so looking back in the git history, this project has been going
on for... at least four years? Probably longer than the length of time
that we've been converting ARM to DT. At no point during that has anyone
brought up the issue of DT being dynamic, so none of the drivers which
we have been converting caters for this.

The timeline does not go that far back. The first (non-DT overlay based)
capebus patchset was posted on October 2012 and after feedback (i.e. it
was deemed to suck) it was pointed that a DT based generic method should
be used; hence DT overlays.

The dynamic DT part has always been part of PPC DT support for pSeries.

Isn't this a bit of a missed opportunity, if this is a direction that
OF wishes to head towards?

I am going to let Grant answer that, but personally I believe a lot of
the troubles we've been having with DT and dynamic device graph changes
can be handled elegantly using something DT overlays (and the follow up
work which is transaction DT support).

Wouldn't it have been relevant to the discussion at kernel summit too,
concerning DRM/v4l2/componentised systems? What if someone comes along
tomorrow with part of their multimedia based system inside a FPGA
which they program up at runtime?

That case might already work on FPGA people's trees. I know Altera for sure
uses overlays, and some xilinx guys popped up on past discussions.
Their vendor trees probably use an older revision of the patches.

BTW, there is nothing special about DRM/v4l2 that can't be handled by a generic
DT mechanism. What makes this such a big problem?

Regards

-- Pantelis