On Tue, Dec 12, 2023 at 10:06 PM Simon Glass <s...@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
