Re: [PATCH 2/4] fdtfactor: Add tool to split DTBs into a base DTB and overlays

[Doug Anderson]

Hi

On Wed, Oct 28, 2026 at 2:57 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> > > +* **Multi-level overlays**: Support hierarchical overlay layers (for
> > > +  example, SoC base -> board family intermediate overlay -> SKU leaf
> > > +  overlay) when multiple boards share large sub-trees not present across
> > > +  all boards.
> >
> > That sounds like a useful extension for the future.  An interim step
> > would be to extend to instead of taking a bunch of dtbs as input, take
> > a single (already generated) base dtb and a bunch of dtbos.  You'd
> > leave the given base alone, but find further common things between the
> > dtbs, in the context of that base.  The idea is you'd run fdtfactor
> > once on the raw dtbs, then run it again on a subset of the dtbos
> > emitted from the first pass to find further commonalities in that
> > subset.
>
> Improved the TODO to incorporate this.

So interesting story. Earlier today I responded to David's question in
my v3 about the arbitrary 50% overlap [1]. My current v4 draft makes
this a parameter. It made me think that this is exactly what we need
here for multi-level overlays.

Using the same 438-DTB Qualcomm `image.fit` I talked about in my
response earlier today [1], I ended up running several passes of
`fdtfactor` where I varied the overlap in each pass. Here are a few
notable numbers. I've also added in data with an experiment I did with
FDT_DECOMPOSE=1 (see the kernel Makefile) and fdtfactor (these are
gziped size of all dtbs):

* No fdtfactor, no FDT_DECOMPOSE: 9.27 MB
* No fdtfactor, yes FDT_DECOMPOSE: 6.94 MB
* Yes fdtfactor, no FDT_DECOMPOSE: 3.59 MB
* Yes fdtfactor, yes FDT_DECOMPOSE: 3.03 MB
* 5-pass fdtfactor, yes FDT_DECOMPOSE: 2.03 MB

Neat, huh? The 5-pass fdtfactor used the thresholds "[98, 92, 82, 68,
50]" for the 5 passes. NOTE that with the same 5 passes but _without_
FDT_DECOMPOSE, I still got to 2.06 MB, so nearly the same. Also note
that a 2-pass fdtfactor [85, 50] atop FDT_DECOMPOSE still ended up
with a respectable 2.39 MB.

For now, this is still future work that can be in the TODO, but I
don't think it would be hard to implement.


[1] https://lore.kernel.org/r/CAD=FV=WGTD8FtjPFE5mFSJP343Z9-2HNXHH3g4usqpWPVuwPUg@xxxxxxxxxxxxxx/