Proposal: FIT support for extension boards / overlays

[Simon Glass]

Hi Heinrich,

On Tue, Dec 12, 2023 at 3:43 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> 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?

I don't think so.

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

Do we actually need to know which extensions are required or optional?
Do you have an example?

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

Yes, I mean "optionally extending ext2". Again, I don't consider
required extensions here.

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

Yes, that's right, by applying overlays.

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

Yes, that is the example quoted below.

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

If there is no way to detect the extension, then it cannot work anyway, right?

BTW I am not suggesting that the bus is used for detection, although I
suppose this is possible. More likely there are GPIOs which can be
decoded to indicate the extension, or perhaps an I2C EEPROM.


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