[U-Boot] Merging device trees at runtime for module-based systems

[David Gibson]

On Wed, Oct 31, 2012 at 10:36:08PM -0600, Stephen Warren wrote:
> On 10/31/2012 05:56 PM, Mitch Bradley wrote:
> > On 10/31/2012 1:00 PM, Daniel Mack wrote:
> >> cc devicetree-discuss. Here's a reference to the full thread:
> >>
> >>   http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145221/
> >>
> >> On 26.10.2012 20:39, Stephen Warren wrote:
> >>> On 10/24/2012 03:47 AM, Daniel Mack wrote:
> >>>> Hi,
> >>>>
> >>>> a project I'm involved in uses a module/baseboard combo, and components
> >>>> on either board are described in DT. I'm currently using separate dts
> >>>> files which build upon each other with include statements, which works
> >>>> fine for development.
> >>>>
> >>>> In production though, we will certainly have running changes (and hence
> >>>> different versions) over the lifetime of the product for both the
> >>>> baseboard and the module, and the hardware has support for identifying
> >>>> the versions of both sides at runtime.
> ...
> >> I start to believe that the cleanest solution to this would be to
> >> have full DTC functionality in U-Boot and compile the tree
> > 
> > ... which is exactly the way that Open Firmware does it, since the
> > invention of the device tree.  The model is that the boot firmware,
> > which needs to know the system configuration to do its job anyway,
> > exports that configuration via the device tree.
> 
> Doesn't OF generate the DT from internal data structures (although I
> don't know where those come from...),

Well.. in OF the device tree *is* a core live data structure.  It will
be constructed as devices are probed, firmware level device drivers
are attached to it and it might be modified by client interface
operations.  Traditionally there is no tree in the flattened format,
only the live tree which clients will query with OF calls.  Some
recent OF implementations do use the flat tree in some ways - we've
had some systems where a flattened tree is provided by an early boot
to the full OF; it acts as a skeleton that is then extended in OF's
live tree.  We've also had some OF implementations that for
compatiblity with kernels that expect a flattened tree flatten their
internal tree structure into the FDT format as the last thing before
entering the OS.

> whereas what Daniel mentions above
> is more like the bootloader having access to a bunch of .dts fragments,
> selecting the appropriate subset of those to use, parsing them into an
> internal data structure (i.e. running dtc), and then generating a DTB
> from it. The overall result is that the bootloader causes a DTB to be
> generated at run-time, so at that level it's the same, but the
> implementation seems pretty different.

How OF constructs its internal tree can vary a lot with the OF
implementation, and I'm not terribly clear on what you had in mind, so
I don't think either side is really sufficiently well defined to
really say if they're similar or not.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson