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