On Mon, Mar 19, 2018 at 04:11:28PM +0530, Srivatsa Vaddagiri wrote: > * 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. "I think will have some impact" isn't really enough justification. I'm looking for a concrete case with measured latency that's too high - and an indication that the change makes a significant difference. Given the usually small size of dtbs, it's not at all obvious to me that pre-merging them would save 10ms. > > 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 -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
