On Mon, Mar 19, 2018 at 11:20:19AM +0530, Srivatsa Vaddagiri wrote: > * Maxime Ripard <maxime.ripard@xxxxxxxxxxx> [2018-03-18 19:09:16]: > > > > In addition to compiling DT code outside core kernel tree, we also want to merge > > > the blobs back to respective blobs found in kernel build tree (soc.dtb or > > > boardX.dtbo), as otherwise relying on bootloader to do all the overlay impacts > > > boot-time. > > > > > > This brings up the need to merge two overlay blobs (fingerprint-overlay.dtbo + > > > boardX.dtbo), which currently doesn't seem to be supported and which this patch > > > series aims to support. > > > > If I understood you right, you want in your "feature" overlay to > > depend on nodes that are only defined in your board overlay? > > Actually the feature overlay can depend on nodes that are both in soc dtb and > board overlay. To explain this further, feature overlay can be split into two > portions: > > feature-soc.dts -> this part represents feature DT code that is common across > all board configuration using given SOC. This will attempt to changde nodes > found only in soc.dts > > feature-boardX.dts -> this part represents feature DT code that is specific to a > given board . It can attempt to change nodes in both boardX.dts as well as > soc.dts > > 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. 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. For one thing, you're changing an established interface in a non-compatible way. But more importantly, overlay application and overlay merge are quite different operations, so they shouldn't be overloaded into a single entry point. > feature-soc.dtbo needs to merge with soc.dtb (found in kernel obj tree) > feature-boardX.dtbo needs to merge with boardX.dtbo (found in kernel obj tree) > > > If so, why not simply merge the __symbols__ node when we apply an > > overlay with the base tree, and just call fdt_apply_overlay as many > > times as needed? > > Not sure if I follow you here. Please see my comment on not wanting to merge > feature DTBOs at runtime in bootloader. -- 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
