Re: [PATCH 0/4] fdtfactor: Introduce fdtfactor to auto-factor overlays

[Doug Anderson]

Hi Simon,

On Mon, Oct 26, 2026 at 8:31 AM Simon Glass <sjg@xxxxxxxxxxxx> wrote:
>
> Hi Doug,
>
> On 2026-10-15T18:21:33, Douglas Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> > The fdtfactor tool can either work directly on a set of compiled devicetree
> > files or it can work on FIT (flattened image tree) file. The idea is that
> > you'd create the FIT file containing all of the duplicated devicetree
> > files and then fdtfactor would "optimize" them.
>
> This is an excellent idea. I have been thinking about something like
> this for some years but then when Chen-Yu Tsai wrote something which
> used the kernel build (Linux 17c31aded9a1 scripts/make_fit: Support
> decomposing DTBs) I forgot about it all. So thanks for taking it on!
>
> Ths script's post-processing of a finished FIT only works for a narrow
> set of images. Apart from signatures nodes (where I think it should
> error), it also rejects FITs with external data[1], which mkimage -E
> produces and binman[2] uses a lot. Of course, mkimage does support
> making the data internal, so it's easy enough to work around, but also
> likely easy enough to support in this tool once the initial version is
> in.

Sure, if you want to make additional improvements that'd be cool.
Keeping it out of here since this patch series is already giant
enough. ;-)


> As an aside, this would be a great feature to add to binman - trivial
> once your script is applied.
>
> > Add 3-board test cases covering default mode and `--strip-local-fixups`
> > to the `fdtoverlay` test suite.
>
> Please can you move the tests from all three patches out of
> fdtoverlay_tests() into a separate fdtfactor test set? Then they can
> be run on their own with run_tests.sh -t and skipped cleanly when
> Python or lz4 is not available.

Done.


> > 3. Better savings than just a simple partitioning, like between SoC and
> >    boards.
>
> It would be worth including numbers for a plain SoC/board split on
> trogdor compared with fdtfactor. The whole set compressed with a
> large-window compressor would also help (as David suggests). That
> would show how much of the 87.5% comes from the factoring itself.

I decided not to do this on trogdor. Trying to make the trogdor base
SoC compile as its own base dtb seems like it would be a lot of
trouble. Maybe I'm wrong and it wouldn't be too bad, but instead I did
something even better (at least, in my opinion).

Instead, I ran fdtfactor on the downstream Pixel 10 devicetree files.
Those _are_ already using a play SoC/board split. I'll include details
and numbers in the cover letter of v2.

As I responded to David, I'm not sure I can test the large window
compressor since device tree files are compressed separately.

-Doug