Re: Merging device trees at runtime for module-based systems

Re: Merging device trees at runtime for module-based systems

[Daniel Mack]

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.
>>
>> So let's say we have n versions of the baseboard and m versions of the
>> module, we would much like to only prepare n + m files, instead of n * m
>> by pre-compiling every possible combination (some of which may actually
>> never occur 'in the wild').
>>
>> So my question is: is it possible to do that kind of assembly of a
>> number of files at runtime in U-Boot? I guess all it takes is merging a
>> number of trees together, right? I browsed through the APIs but couldn't
>> yet find an clear approach to that kind of problem. If not, what would
>> it take to add that functionality? I can probably help with the
>> implementation if someone tells me what would be the right way.
> 
> Yes, solving this would be very useful; it's a wide-spread problem.
> 
> Some thoughts though:
> 
> Simply overlaying two DTBs on top of each-other (in the same fashion
> that dtc's /include/ statement would do at compile-time) might not be
> fully general enough, although perhaps it would be sufficient for your
> immediate needs.
> 
> For example, lets say that a GPIO is routed from a device on the main
> board to a device on a daughter board, or even from one daughter board
> into the main board and back out to a different daughter board. Now,
> consider that the different board(s) that are the source of the GPIO
> might use completely different SoCs or versions of the SoC, which might
> require using a different GPIO specifier to represent the signal. That
> means you need to change the .dtb file for the "client" of the GPIO
> depending on the HW or .dtb that provides the GPIO. That's certainly not
> a simple matter of merging multiple .dtb blobs together.

Hmm. After implementing a very simple overlay approach, I can now see
your point :) Yes in fact, that's a real problem.

> The same issue could easily apply to I2C or SPI buses, chip selects, etc.
> 
> One solution would be to explicitly represent a connector or
> connection-point in DT, such that the connector can implement the naming
> of all signals that pass through it, and provide a translation point for
> hooking the two DT fragments together. This seems within the spirit of DT.

Yes, but you still can't handle references that way.

Let me try and conclude this for others. Say the "module" tree "A" looks
something like this:

	/ {
		multi-regulator {
			vcc1v8: regulator@0 {
				/* ... */
			};
		};
	};

... and the baseboard ("B"), that makes use of (and hence depends on)
the module, has something like this:

	/ {
		consumer {
			main-supply = <&vcc1v8>;
		};
	};

Now, let's say in a subsequent version of the module, we change whatever
provides that supply for 1.8 volts, but the consumer on the baseboard
shouldn't care much of course, thanks to all the abstraction layers that
we have now in the kernel.

However, the problem here is that I can't just compile trees A and B
individually into .dtbs that get merged later, because dtc will bail on
the unresolved reference of &vcc1v8 of course. And cases like this are
the whole reason why I started to think about modularization of trees in
the first place.

So the simple overlay method doesn't help here at all, even though I can
share the code if anyone's interested.

> Another solution might be some form of variables/macros/code in the DTB
> that can be used to parameterize other DTBs that get merged with it.
> This is probably an enormous can of worms.

Yes, exactly, a can of worms and most probably unmaintainble in real
life. I start to believe that the cleanest solution to this would be to
have full DTC functionality in U-Boot and compile the tree from dts, but
then again I have no clue on how to handle the file lookups that arise
from includes. Do you think it would it be worth going that way?

If not, I guess we're down to n*m files eventually, which is really sad
as they might even become a storage problem at some point.


Thanks for your input,
Daniel

Re: Merging device trees at runtime for module-based systems

[Stephen Warren]

On 10/31/2012 05: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.
>>>
>>> So let's say we have n versions of the baseboard and m versions of the
>>> module, we would much like to only prepare n + m files, instead of n * m
>>> by pre-compiling every possible combination (some of which may actually
>>> never occur 'in the wild').
>>>
>>> So my question is: is it possible to do that kind of assembly of a
>>> number of files at runtime in U-Boot? I guess all it takes is merging a
>>> number of trees together, right? I browsed through the APIs but couldn't
>>> yet find an clear approach to that kind of problem. If not, what would
>>> it take to add that functionality? I can probably help with the
>>> implementation if someone tells me what would be the right way.
>>
>> Yes, solving this would be very useful; it's a wide-spread problem.
>>
>> Some thoughts though:
>>
>> Simply overlaying two DTBs on top of each-other (in the same fashion
>> that dtc's /include/ statement would do at compile-time) might not be
>> fully general enough, although perhaps it would be sufficient for your
>> immediate needs.
>>
>> For example, lets say that a GPIO is routed from a device on the main
>> board to a device on a daughter board, or even from one daughter board
>> into the main board and back out to a different daughter board. Now,
>> consider that the different board(s) that are the source of the GPIO
>> might use completely different SoCs or versions of the SoC, which might
>> require using a different GPIO specifier to represent the signal. That
>> means you need to change the .dtb file for the "client" of the GPIO
>> depending on the HW or .dtb that provides the GPIO. That's certainly not
>> a simple matter of merging multiple .dtb blobs together.
> 
> Hmm. After implementing a very simple overlay approach, I can now see
> your point :) Yes in fact, that's a real problem.
> 
>> The same issue could easily apply to I2C or SPI buses, chip selects, etc.
>>
>> One solution would be to explicitly represent a connector or
>> connection-point in DT, such that the connector can implement the naming
>> of all signals that pass through it, and provide a translation point for
>> hooking the two DT fragments together. This seems within the spirit of DT.
> 
> Yes, but you still can't handle references that way.
> 
> Let me try and conclude this for others. Say the "module" tree "A" looks
> something like this:
> 
> 	/ {
> 		multi-regulator {
> 			vcc1v8: regulator@0 {
> 				/* ... */
> 			};
> 		};
> 	};
> 
> ... and the baseboard ("B"), that makes use of (and hence depends on)
> the module, has something like this:
> 
> 	/ {
> 		consumer {
> 			main-supply = <&vcc1v8>;
> 		};
> 	};
> 
> Now, let's say in a subsequent version of the module, we change whatever
> provides that supply for 1.8 volts, but the consumer on the baseboard
> shouldn't care much of course, thanks to all the abstraction layers that
> we have now in the kernel.
> 
> However, the problem here is that I can't just compile trees A and B
> individually into .dtbs that get merged later, because dtc will bail on
> the unresolved reference of &vcc1v8 of course. And cases like this are
> the whole reason why I started to think about modularization of trees in
> the first place.
> 
> So the simple overlay method doesn't help here at all, even though I can
> share the code if anyone's interested.

Yes, you've understood me exactly.

The connector-base approach I was thinking about might look (very very)
roughly as follows:

main board:

	/ {
		multi-regulator {
			vcc1v8: regulator@0 {
				/* ... */
			};
		};
		connector {
			compatible = "vendor,board-socket-a";
			vcc1v8-supply = <&vcc1v8>;
		};
	};

child board:

	/ {
		connector {
			compatible = "vendor,board-plug-a";
			vcc1v8: regulator {
			};
		};
		consumer {
			main-supply = <&vcc1v8>;
		};
	};

... plus some logic so that the "driver"s for the two connector nodes
get linked together, such that the code forwards "requests" for the
regulator that the plug receives on to the node for the socket, which
then lists the actual provider.

Obviously, the above DT is an extremely rough sketch, and we need to
think about:

a) Exactly how the plug/socket get linked together.

b) Can we make a generic driver for the plug/socket, so we don't have to
write a driver for each board's connector design. The driver would have
to forward all kinds of regulator, GPIO, interrupt, ... requests it
receives at one node, on to the node that's listed in the other
connector node. Kinda like "ranges" but for arbitrary resources, not
just memory maps, in a way.

Re: Merging device trees at runtime for module-based systems

[Daniel Mack]

On 01.11.2012 00:13, Stephen Warren wrote:
> On 10/31/2012 05: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.
>>>>
>>>> So let's say we have n versions of the baseboard and m versions of the
>>>> module, we would much like to only prepare n + m files, instead of n * m
>>>> by pre-compiling every possible combination (some of which may actually
>>>> never occur 'in the wild').
>>>>
>>>> So my question is: is it possible to do that kind of assembly of a
>>>> number of files at runtime in U-Boot? I guess all it takes is merging a
>>>> number of trees together, right? I browsed through the APIs but couldn't
>>>> yet find an clear approach to that kind of problem. If not, what would
>>>> it take to add that functionality? I can probably help with the
>>>> implementation if someone tells me what would be the right way.
>>>
>>> Yes, solving this would be very useful; it's a wide-spread problem.
>>>
>>> Some thoughts though:
>>>
>>> Simply overlaying two DTBs on top of each-other (in the same fashion
>>> that dtc's /include/ statement would do at compile-time) might not be
>>> fully general enough, although perhaps it would be sufficient for your
>>> immediate needs.
>>>
>>> For example, lets say that a GPIO is routed from a device on the main
>>> board to a device on a daughter board, or even from one daughter board
>>> into the main board and back out to a different daughter board. Now,
>>> consider that the different board(s) that are the source of the GPIO
>>> might use completely different SoCs or versions of the SoC, which might
>>> require using a different GPIO specifier to represent the signal. That
>>> means you need to change the .dtb file for the "client" of the GPIO
>>> depending on the HW or .dtb that provides the GPIO. That's certainly not
>>> a simple matter of merging multiple .dtb blobs together.
>>
>> Hmm. After implementing a very simple overlay approach, I can now see
>> your point :) Yes in fact, that's a real problem.
>>
>>> The same issue could easily apply to I2C or SPI buses, chip selects, etc.
>>>
>>> One solution would be to explicitly represent a connector or
>>> connection-point in DT, such that the connector can implement the naming
>>> of all signals that pass through it, and provide a translation point for
>>> hooking the two DT fragments together. This seems within the spirit of DT.
>>
>> Yes, but you still can't handle references that way.
>>
>> Let me try and conclude this for others. Say the "module" tree "A" looks
>> something like this:
>>
>> 	/ {
>> 		multi-regulator {
>> 			vcc1v8: regulator@0 {
>> 				/* ... */
>> 			};
>> 		};
>> 	};
>>
>> ... and the baseboard ("B"), that makes use of (and hence depends on)
>> the module, has something like this:
>>
>> 	/ {
>> 		consumer {
>> 			main-supply = <&vcc1v8>;
>> 		};
>> 	};
>>
>> Now, let's say in a subsequent version of the module, we change whatever
>> provides that supply for 1.8 volts, but the consumer on the baseboard
>> shouldn't care much of course, thanks to all the abstraction layers that
>> we have now in the kernel.
>>
>> However, the problem here is that I can't just compile trees A and B
>> individually into .dtbs that get merged later, because dtc will bail on
>> the unresolved reference of &vcc1v8 of course. And cases like this are
>> the whole reason why I started to think about modularization of trees in
>> the first place.
>>
>> So the simple overlay method doesn't help here at all, even though I can
>> share the code if anyone's interested.
> 
> Yes, you've understood me exactly.
> 
> The connector-base approach I was thinking about might look (very very)
> roughly as follows:
> 
> main board:
> 
> 	/ {
> 		multi-regulator {
> 			vcc1v8: regulator@0 {
> 				/* ... */
> 			};
> 		};
> 		connector {
> 			compatible = "vendor,board-socket-a";
> 			vcc1v8-supply = <&vcc1v8>;
> 		};
> 	};
> 
> child board:
> 
> 	/ {
> 		connector {
> 			compatible = "vendor,board-plug-a";
> 			vcc1v8: regulator {
> 			};
> 		};
> 		consumer {
> 			main-supply = <&vcc1v8>;
> 		};
> 	};

... which doesn't eally make the individual bits more readable.

> ... plus some logic so that the "driver"s for the two connector nodes
> get linked together, such that the code forwards "requests" for the
> regulator that the plug receives on to the node for the socket, which
> then lists the actual provider.
> 
> Obviously, the above DT is an extremely rough sketch, and we need to
> think about:
> 
> a) Exactly how the plug/socket get linked together.
> 
> b) Can we make a generic driver for the plug/socket, so we don't have to
> write a driver for each board's connector design. The driver would have
> to forward all kinds of regulator, GPIO, interrupt, ... requests it
> receives at one node, on to the node that's listed in the other
> connector node. Kinda like "ranges" but for arbitrary resources, not
> just memory maps, in a way.

I really wonder if that's not fixing the wrong end after all. I mean, in
dts files and using includes, all this works just beautifully, and what
I really want is the same kind of flexibility in the bootloader.

Any good reason for not doing the dt complilation at runtime? For the
include issue, one could argue that /include/ statements are not
allowed, but the same behaviour can be achieved by simply concatinating
all the dts files right away.


Daniel

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

[Mitch Bradley]

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.
>>>
>>> So let's say we have n versions of the baseboard and m versions of the
>>> module, we would much like to only prepare n + m files, instead of n * m
>>> by pre-compiling every possible combination (some of which may actually
>>> never occur 'in the wild').
>>>
>>> So my question is: is it possible to do that kind of assembly of a
>>> number of files at runtime in U-Boot? I guess all it takes is merging a
>>> number of trees together, right? I browsed through the APIs but couldn't
>>> yet find an clear approach to that kind of problem. If not, what would
>>> it take to add that functionality? I can probably help with the
>>> implementation if someone tells me what would be the right way.
>>
>> Yes, solving this would be very useful; it's a wide-spread problem.
>>
>> Some thoughts though:
>>
>> Simply overlaying two DTBs on top of each-other (in the same fashion
>> that dtc's /include/ statement would do at compile-time) might not be
>> fully general enough, although perhaps it would be sufficient for your
>> immediate needs.
>>
>> For example, lets say that a GPIO is routed from a device on the main
>> board to a device on a daughter board, or even from one daughter board
>> into the main board and back out to a different daughter board. Now,
>> consider that the different board(s) that are the source of the GPIO
>> might use completely different SoCs or versions of the SoC, which might
>> require using a different GPIO specifier to represent the signal. That
>> means you need to change the .dtb file for the "client" of the GPIO
>> depending on the HW or .dtb that provides the GPIO. That's certainly not
>> a simple matter of merging multiple .dtb blobs together.
> 
> Hmm. After implementing a very simple overlay approach, I can now see
> your point :) Yes in fact, that's a real problem.
> 
>> The same issue could easily apply to I2C or SPI buses, chip selects, etc.
>>
>> One solution would be to explicitly represent a connector or
>> connection-point in DT, such that the connector can implement the naming
>> of all signals that pass through it, and provide a translation point for
>> hooking the two DT fragments together. This seems within the spirit of DT.
> 
> Yes, but you still can't handle references that way.
> 
> Let me try and conclude this for others. Say the "module" tree "A" looks
> something like this:
> 
> 	/ {
> 		multi-regulator {
> 			vcc1v8: regulator@0 {
> 				/* ... */
> 			};
> 		};
> 	};
> 
> ... and the baseboard ("B"), that makes use of (and hence depends on)
> the module, has something like this:
> 
> 	/ {
> 		consumer {
> 			main-supply = <&vcc1v8>;
> 		};
> 	};
> 
> Now, let's say in a subsequent version of the module, we change whatever
> provides that supply for 1.8 volts, but the consumer on the baseboard
> shouldn't care much of course, thanks to all the abstraction layers that
> we have now in the kernel.
> 
> However, the problem here is that I can't just compile trees A and B
> individually into .dtbs that get merged later, because dtc will bail on
> the unresolved reference of &vcc1v8 of course. And cases like this are
> the whole reason why I started to think about modularization of trees in
> the first place.
> 
> So the simple overlay method doesn't help here at all, even though I can
> share the code if anyone's interested.
> 
>> Another solution might be some form of variables/macros/code in the DTB
>> that can be used to parameterize other DTBs that get merged with it.
>> This is probably an enormous can of worms.
> 
> Yes, exactly, a can of worms and most probably unmaintainble in real
> life. 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.

 from dts, but
> then again I have no clue on how to handle the file lookups that arise
> from includes. Do you think it would it be worth going that way?
> 
> If not, I guess we're down to n*m files eventually, which is really sad
> as they might even become a storage problem at some point.
> 
> 
> Thanks for your input,
> Daniel
> 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

Re: Merging device trees at runtime for module-based systems

[Stephen Warren]

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...), 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.

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

[Mitch Bradley]

On 10/31/2012 6:36 PM, 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...), 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.

Yes, which is why I cut the cited sentence at the place I did (before
the part about dts fragments).

> 

Re: [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

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

[Grant Likely]

On Wed, Oct 31, 2012 at 11:00 PM, Daniel Mack <zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> cc devicetree-discuss. Here's a reference to the full thread:
>
>   http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145221/

Interesting. I only just was made aware of this thread. There is a
similar discussion going on kicked off by the BeagleBone folks where
they want to insert additional DT data from Linux userspace. Whether
the data is merged at U-Boot time or kernel time, I expect that the
required data format will be very similar.

https://lkml.org/lkml/2012/10/31/502
https://lkml.org/lkml/2012/11/5/615

I'm trying to draft up a document that captures the requirements and
lay out what needs to be done to the tools, U-Boot and the kernel.

g.