Re: [RFC] devicetree: new FDT format version

On 01/26/18 00:56, Geert Uytterhoeven wrote:

On Thu, Jan 25, 2018 at 1:29 PM, David Gibson
[off-list ref] wrote:

quoted

On Wed, Jan 24, 2018 at 04:22:15PM -0800, Frank Rowand wrote:

quoted

On 01/24/18 13:16, Frank Rowand wrote:

quoted

What you say makes sense.  So I'll reverse myself and say that for
Linux, we should update the FDT read code to scan all chained
overlay FDT(s) as well as the base FDT.

< snip >

What I wrote was somewhat ambiguous.  What I meant by "FDT read
code" was functions that check for existence of nodes in the
FDT or read property values from the FDT.

Oh.. not just FDT unflattening code.

The trouble with this is that scanning for a specific node or property
in a set of chained overlays is highly nontrivial.  Even if you set
aside the arguably self-imposed design constraints in libfdt, you
can't just do the same lookup in each fragment: along the way you need
to resolve the path at which each fragment applies.  That in itself is
non-trivial.  If you have overlays applying on top of other overlays,
that could involve recursive lookups of things from previous overlays.
It's spectacularly complicated and we have to do it on *every single*
read operation.

Either fully applying the overlay in flattened form, or (even

Applying the overlays in flattened form sounds like a good idea to me.

I'm having trouble envisioning what "apply an overlay in flattened form"
means.

I'll provide a simple example to illustrate.

  - Base devicetree contains one non-root node which contains one property.
  - Overlay devicetree adds one property to that same node.

The before and after dt_struct block of the FDTs would contain (vastly
simplified, ignoring tags, not notating nesting of nodes, ignoring
root node, etc):

(1) base FDT dt_struct:
  [node1] [prop1 value length] [prop1 name offset] [prop1 value]

(2) overlay FDT dt_struct:
  [fragment 1 node] [__overlay__ node (for node1)] [prop2 value length] [prop2 name offset] [prop2 value]

(3) resulting FDT after applying overlay to base:

  [node1] [prop1 value length] [prop1 name offset] [prop1 value] [prop2 value length] [prop2 name offset] [prop2 value]

  - dt_string block updated to add the string for prop2 name (if not already in block)
  - prop2 name offset updated for offset in updated dt_string block

Is creating (3) from (1) and (2) what is meant by "apply an overlay
in flattened form"?

Getting from (1) and (2) to (3) does not look trivial.  Am I missing
something?

-Frank

It still adds complexity, but handling multiple overlays can be done by a
simple iteration, not recursion.
The end result will always consume less memory, and will thus fit in the
original block of memory allocated for base FDT and overlay FDTs, unless
the base FDT and overlay FDTs are in FLASH (this assumes chaining really
means appending, not using an external chaining mechanism).

quoted

temporarily) unflattening the tree are better solutions.

Temporary unflattening sounds like a waste to me: it must be redone again
later anyway. Applying the FDT overlays early on will make that later step
simpler (no more overlays to handle).
So if you need information from an FDT, you can help later steps by
applying the FDT overlays right away.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds