Proposal: FIT support for extension boards / overlays

From: Simon Glass <sjg@chromium.org>
To: U-Boot Mailing List <u-boot@lists.denx.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Chen-Yu Tsai <wenst@chromium.org>, Tom Rini <trini@konsulko.com>,
	U-Boot Custodians <u-boot-custodians@lists.denx.de>,
	 Andrew Davis <afd@ti.com>
Subject: Proposal: FIT support for extension boards / overlays
Date: Tue, 12 Dec 2023 07:05:56 -0700	[thread overview]
Message-ID: <CAPnjgZ06s64C2ux1rABNAnMv3q4W++sjhNGCO_uPMH_9sTF7Mw@mail.gmail.com> (raw)

Hi,

The devicetree files for a board can be quite large, perhaps around
60KB. To boot on any supported board, many of them need to be
provided, typically hundreds.

All boards for a particular SoC share common parts.  It would be
helpful to use overlays for common pieces, to reduce the overall size.

Some boards have extension add-ons which have their own devicetree
overlays. It would be helpful to know which ones should be applied for
a particular extension.

I propose implementing extensions in FIT. This has a new '/extensions'
node, so you can specify what extensions are available for each FIT
configuration.

For example:

/ {
  images {
    kernel {
      // common kernel
    };

    fdt-1 {
      // FDT for board1
    };

    fdto-1 {
      // FDT overlay
    };

    fdto-2 {
      // FDT overlay
    };

    fdto-3 {
      // FDT overlay
    };
  };

  configurations {
    conf-1 {
        compatible = ...
        fdt = "fdt-1";
        extensions = "ext1", "ext-2";
    };
  };

  extensions {
    ext-1 {
        fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
        kernel = "kernel-1";
        compatible = "vendor,combined-device1";
        extensions = "ext-3";
    };

    ext-2 {
        fdto = "fdto-2";   // fdt overlay for this 'cape'
        compatible = "vendor,device2";
    };

    ext-3 {
        fdto = "fdto-3";
        compatible = "vendor,device3";
    };
  };
};

So FIT configurations have a list of supported extensions. The
extensions are hierarchical so that you can have ext-1 which can
optionally have ext-2 as well. This allows boards to share a common
SoC to add in overlays as needed by their board. It also allows common
'capes' or 'hats' to be specified only once and used by a group of
boards which share the same interface.

Within U-Boot, extensions actually present are declared by a sysinfo
driver for the board, with new methods:

get_compat() - determine the compatible strings for the current platform
get_ext() - get a list of compatible strings for extensions which are
actually present

The extension compatible-strings are used to select the correct things
from the FIT, apply the overlays and produce the final DT.

To make this simpler for the common case (without extensions), we can
allow multiple FDT images for a configuration, with the first one
being the base SoC .dtb and the others being the .dtbo overlay(s) for
the board:

confi-1 {
        compatible = ...
        fdt = "fdt-1", "fdto-1";
};

Comments welcome.

Regards,
Simon