Proposal: FIT support for extension boards / overlays

[Heinrich Schuchardt]

On 12.12.23 15:05, Simon Glass wrote:
> 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";

Shouldn't there be braces around the item list?

How do you specify optional and required but otherwise unrelated
extensions for a configuration?

>      };
>    };
>
>    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

ext2 seems not to be related to ext-3. Do you mean ext-3 optionally
extending ext-1? How would you specify that ext-n is required for ext-m
to work?

The sequence of applying overlays may make a difference. I cannot see
that your current suggestion defines a sequence in which the overlays
are applied.

> 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

Do you expect U-Boot to have code that injects device-tree fragments
with a compatible string into the control FDT after discovering add-ons?

Why can't we simply write the compatible constraint into the overlay
definition (fdto-#) and enumerate the overlays in the configuration?

On some busses detection is problematic. Two alternative add-ons may use
the same SPI address but need different FDT overlays.

Best regards

Heinrich


>
> 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