[U-Boot] Questions/RFC about overlay compatible strings and device tree compression in uImage.FIT

[Julius Werner]

Hi U-Boot developers,
(I picked a few of you out that seem to be most related to this code,
hope that's okay,)

I am interested in booting device trees with overlays from a FIT image
(actually for a different bootloader, but we're trying to stay
compatible with U-Boot's FIT format so I'm asking here), and I came up
with some questions about how this is supposed to work that I hope you
can answer:

I found the basic description of overlay support in FIT here:
https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/overlay-fdt-boot.txt
However, what it doesn't really say is how compatible string matching
works in the face of overlays. From my reading of the code it seems
that U-Boot tries to match the compatible string in the FDT that is
listed leftmost in the 'fdt' property of the config node
(fit_conf_find_compat() just calls fdt_getprop(fit, "fdt") and uses
the result as a string, so since the different FDT names in the
property are separated by '\0' chars I assume that will act on the
first name?), which according to the documentation should be the base
device tree.

Is that correct? I don't see how that would make sense... for overlays
to make sense you would want to have multiple config nodes that all
use the same base device tree and stack different overlays on top of
it (the example in the docs also looks that way). But if the
compatible string matcher only checks the base device tree, all of
those config nodes will have the same strings to match -- how could it
find the right node? I think the correct scheme would be to scan
through all overlays from right to left (i.e. in reverse application
order) until you find a compatible string somewhere. Was the current
overlay support just only implemented with pre-selected config nodes
(i.e. passing a fit_uname_configp to boot_get_fdt_fit()) in mind?

On a somewhat related note, I was also thinking about allowing
compression for the 'data' property of individual fdt at X nodes (similar
to how you can already do it for kernel at X nodes), which can cut them
down to about 15% of their size with LZ4 or even 5% with LZMA. The
main problem with this is that you would have to decompress all device
trees during the compatible string match to get at their embedded
compatible strings. An obvious solution would be to copy the
compatible string out into an explicit property in the config node at
build time, so that the 'fdt' property (and the node it points to)
doesn't have to be parsed before you're actually loading the full DT
(and at that time you could decompress only the one(s) you're using).
This would also help the compatible string problem with overlays,
since then the config node has the compatible string right there and
you don't need to worry about which overlay to extract it from
anymore. Would it be an acceptable change if I added support for that
to U-Boot? Of course, the code could gracefully fall back to scanning
the whole FDT (decompressing if necessary) if the config node has no
'compatible' property.

Please let me know what you think!

Thanks,
Julius