* David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> [2018-03-19 17:14:01]: > > We could compile both feature-soc.dts and feauture-boardX.dts as > > feature-soc.dtbo/feature-boardX.dtbo respectively and overlay them one after > > other at runtime (in bootloader), but that introduces impact to boot-time. This > > is the reason why we want to merge offline at compile time. > > Is the difference actually significant? I wouldn't have expected > pre-merging the dtbos to actually speed up the application all that > much, since the application itself should be roughly linear in the > total number of fragments, which won't change. I think currently bootloader looks for a matching board.dtbo and stops the search at the first match? By splitting board overlay file into multiple fragments/overlay blobs, bootloader has to spend more time looking for all matches, which I think will have some impact. Even 10ms impact is a concern for some usecases like automotive/IoT devices. > That said, I don't have an inherent problem with adding code to merge > overlays to libfdt. I *do* have a problem with changing the existing > fdt_overlay() function to do it though. Ah ok sure ..makese sense to split the interface. Second version will incorporate all your comments! Thanks, vatsa -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
