[PATCH 8/9] buildman: Propose a format for extra boards
Heinrich Schuchardt
heinrich.schuchardt at canonical.com
Sat Nov 9 23:55:21 CET 2024
On 08.11.24 16:23, Simon Glass wrote:
> It has become more common to use config fragments to extend or adjust
> the functionality of boards in U-Boot.
>
> Propose a format for how to deal with this. It is not implemented as
> yet.
>
> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---
>
> tools/buildman/buildman.rst | 39 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/tools/buildman/buildman.rst b/tools/buildman/buildman.rst
> index 924564b5700..48705d0e49e 100644
> --- a/tools/buildman/buildman.rst
> +++ b/tools/buildman/buildman.rst
> @@ -1148,6 +1148,45 @@ like::
> This is partly because there is no way for Buildman to know which fragments are
> valid on which boards.
>
> +Specifying the build matrix with fragments
> +------------------------------------------
> +
> +In order to build boards which can use fragments, Buildman needs to know which
> +fragments are valid with which boards. The following scheme is proposed, but not
> +currently implemented.
> +
> +In ``defconfig/``, files with a '.buildman' suffix are used to effectively
> +create new boards for Buildman to build. All such files are processed, but it
> +might be best to put all the information in a single file for now, e.g.
> +``extended.buildman``.
> +
> +The syntax consists of a number of sections, each introduced by a name. For each
> +section the fragment file is named (without the implied ``.config`` suffix),
> +then the targets which can accept that fragment are specified, either by their
> +board name, with wildcards, or a set of ``CONFIG`` options to check. All
> +``CONFIG`` options must match for a board to be included in the set. To specify
> +multiple fragments to be included, add them in the order which they should be
> +applied, one per line.
> +
> +For example::
> +
> + # Build RISC-V QEMU builds with ACPI
> + name: ACPI with supporting boards
> + fragment: acpi
> + targets:
> + qemu_riscv*
> +
> + # Build Android variant of 'k3' boards, with DFU
> + name USB DFU for am62x boards
> + fragment: am62x_r5_usbdfu
> + fragment: am62x_a53_android
> + targets:
> + CONFIG_SYS_SOC="k3"
Thank you for looking into this. I don't think that we will have to
build every board with each fragment. But for every fragment there
should be at least one build.
qemu-riscv64_smode_defconfig + acpi.config and qemu_arm_defconfig +
acpi.config would be enough for acpi.config. x86 anyway uses ACPI.
Best regards
Heinrich
> +
> +Buildman normally ignores these files. To request that Buildman process these
> +extended new 'boards', use the ``-X / --extend`` option. Note that this may
> +significantly increase the number of boards which Buildman builds.
> +
> Building with clang
> -------------------
>
More information about the U-Boot
mailing list