On 01/26/18 00:56, Geert Uytterhoeven wrote:
> On Thu, Jan 25, 2018 at 1:29 PM, David Gibson
> <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> On Wed, Jan 24, 2018 at 04:22:15PM -0800, Frank Rowand wrote:
>>> On 01/24/18 13:16, Frank Rowand wrote:
>>>> 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).
>
>> 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@xxxxxxxxxxxxxx
>
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
