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

[Tom Rini]

On 06/17/2014 05:09 AM, Russell King - ARM Linux wrote:
> On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote:
>> Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
>>
>> On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner <jkridner at gmail.com> wrote:
>>> 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.

-- 
Tom