Proposal: FIT support for extension boards / overlays

[Chen-Yu Tsai]

On Tue, Dec 12, 2023 at 10:06 PM Simon Glass <sjg at chromium.org> 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";
>     };
>   };
>
>   extensions {
>     ext-1 {
>         fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
>         kernel = "kernel-1";
>         compatible = "vendor,combined-device1";

I think the example would be a bit better if the extension compatibles
were something like "vendor,device-X-feature-Y", so as not to be confused
with device-specific compatibles for the configurations.

>         extensions = "ext-3";

I assume this means "existence of ext-1 makes ext-3 a valid option"?

I think a valid example would come in the form of:
- ext-1 as a M.2 E-key hat, and
- ext-3 as a WiFi/BT combo adapter for the M.2 slot, with BT UART and/or
  GPIOs described

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

I thought this was already supported? At least that is what the FIT image
spec says:

    Unit name of the corresponding fdt blob (component image node of a
    "fdt type"). Additional fdt overlay nodes can be supplied which
    signify that the resulting device tree blob is generated by the
    first base fdt blob with all subsequent overlays applied.

> Comments welcome.

Very happy to see this. This could help cut down the DT duplication for
some of the ARM Chromebooks.


Thanks
ChenYu