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... 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@X nodes (similar to how you can already do it for kernel@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