Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Joel A Fernandes <agnel.joel@gmail.com>]

Hi Grant,

On Fri, Nov 9, 2012 at 3:22 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> (2)
>> Also this discussed a while back but at some point is going to brought
>> up again-  loading of dt fragment directly from EEPROM and merging at
>> run time. If we were to implement this in kernel, we would have to add
>> cape specific EEPROM reading code, merge the tree before it is
>> unflattened and parse.
>
> Unless it is required for boot to userspace I'm not considering
> merging before userspace starts. That's well after the tree is
> unflattened into the live form. If it is require to boot then I agree
> that is should be done in firmware. I see zero problem with having a
> beaglebone specific cape driver that knows to read the eeprom and
> request a specific configuration file. Heck, the kernel doesn't even
> need to parse the eeprom data. It can be read from userspace and
> userspace decides which overlay to provide. There's nothing stopping
> userspace from reading the eeprom, looking up the correct dts for the
> board, downloading the file from the Internet, compiling it with dtc
> and installing it.... and yes that is getting a little extreme.

Actually, I was speaking of the case where today we read EEPROM anyway
for capes before userspace, so it would convenient do the overlay this
way. Further, userspace doesn't have to do any parsing as
kernel/u-boot could blindly load the dtb overlay directly from EEPROM
regardless of which cape. So we don't have do any revision detection
and dtb search, the dtb itself being in the EEPROM.
That way no matter what the userspace is, the cape hardware is already
configured and ready to use by userspace. This might be a corner-case
just for beaglebone though, and if requesting overlay from userspace
is a more general solution for all usecases, then probably we should
go with that approach. OTOH, I guess there's no harm in doing some
overlays from kernel for some cases, and userspace for others.

>> The code that does
>> the tree walking can then just strcmp the node name while it walks the
>> tree instead of having to find a node with a phandle number. I guess
>> the reason is phandles are small to store as data values. Another
>> approach can be to arrange the string block in alphabetical order
>> (unless it already is), and store phandle as index of the node name
>> referenced relative to the starting of the strong block. This will not
>> affect nodes in dtb being moved around since they will still have the
>> same index value. the problem being adding or removing nodes Changes
>> the index of all other nodes in the string block as well.. Hmm.
>
> And that still doesn't help find all the phandle locations in the tree
> for doing fixups. It would need to be a table of
> nodes+properties+offsets that contain phandles for fixup to work, but
> I shy away from that approach because I think it will be fragile.

I guess this approach (which wouldn't work for other reasons) was
intended to serve the same purpose as Hashing, having a phandle that
doesn't easily change hence not requiring overlay fixups.

Actually I'm a bit confused if how maintaining a list of
name/node-paths for fix up will even work, because node names are not
unique as we discussed. Also node paths can change, so what will the
overlay dtb store in its fixup table (say there is one)? A table of
node,properties etc as you mentioned might not be unique as there can
be 2 nodes with same name and properties. Also if we use node path,
instead of node name, in this table, then moving nodes around wont be
possible as the fixup table will be pointing to node path references
that have now changed- how will the kernel now what's the node's new
actual path, say, if there are 2 nodes with the same name? Only thing
possible is, to do a _mandatory_ recompile of overlay dtb if a node's
path changes.

Would be you be in agreement that- When a node's path changes in base
dtb, Overlays have to be recompiled and a new fixup table has to be
created, or a new hash has to be generated out of the new node path
regardless. So moving nodes around in base dtb can't be dynamically
accommodated without recompiling overlay.

Considering the above is ok, the only 2 approaches I can see for
phandle resolutions are:
(1) hashing of the full node path and avoiding runtime fixups.
(2) Using today's linear phandle increment approach, maintaining a
table in the overlay with the key as 'node path' and value as 'phandle
fixup offset', and then doing runtime fixups.

I believe (2) is considered fragile and it does the same thing as (1)
except that (2) can even handle collisions but at the cost of storing
the full node path in the overlay's fixup table. So (1) looks like our
only possible and meaningful approach. Do you agree with this
analysis? Or, maybe I am missing something.

Regards,
Joel