Proposal: FIT support for extension boards / overlays

[Andrew Davis]

On 12/12/23 8:05 AM, 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.
> 

For this to save much size we would need to have the SoC split
from each board that uses it. We don't have that in DT today.
There are some efforts in progress to help on this but until
then we will not get much here.

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

Are you suggesting an 'extension' that lists every 'cape', then for each
board that has a 'cape' header we list that 'hierarchical extension'
to suggest support?

Seems reasonable, but we don't have universal DTB overlays today. Each
overlay needs to be built for a specific board due to several reasons
(I have some plans to help solve this but the upstream kernel path might
be a ways out).

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

These extension compatible-strings, could they just be the name of
the overlay file? That is what we do today with our name_overlays[0].
The benefit is these names can be used to load and apply overlays in
the non-FIT case just the same.

If we name the configuration nodes after the DTBO that they contain
then I'm not sure what this 'extensions' list gains us over having
a list of overlays to apply like we do today.

Andrew

[0] https://github.com/trini/u-boot/blob/master/board/ti/am65x/evm.c#L189

> 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