twister: Account for board & SoC extensions

[57300]

Problem

Board & SoC extensions are used to define out-of-tree board variants or SoC qualifiers. When a board is extended, it has multiple directories associated with it (each with its own board.yml), where twister should be able to find additional platform files to support these qualifiers. Currently, this doesn't work, because twister only traverses the primary BOARD_DIR and ignores the rest.

The fix would've been trivial in the case of "legacy" platform files, i.e. those of the form <normalized_board_target>.yaml, but it's less straightforward for the newly introduced twister.yaml format.

A twister.yaml file contains platform configuration that can be shared by multiple board targets and tweaked for specific targets by using the top-level variants key. Normally, there is at most one twister.yaml per board, but the file isn't necessarily unique to one board. Instead, it's unique to one directory, which may define multiple boards (as is the case with e.g. boards/qemu/x86/).

With extensions in the picture, the goal is to initialize platforms when given multiple twister.yaml per board. The OOT files are expected to only provide information about OOT board targets, without being able to override in-tree targets (same principle as in the Zephyr build system).

Solution

Scanning for twister.yaml is broken up into multiple passes - first loading all the files, then splitting the variants keys apart from the shared configuration, before constructing the Platform instances.

The purpose of the split is to treat the variant information as global, instead of making unnecessary or faulty assumptions about locality. Remember that the build system can derive board target names not only from board.yml, but from soc.yml too. Considering that any board may end up using an OOT-extended SoC (and hence multiple soc.yml files), not every board target can be said to belong to some board dir.

Unlike the variant data, the remaining top-level config is still rooted to the primary BOARD_DIR and inherited by the extension dirs from there. This is quite intuitive in most imagined cases, but there is a caveat: if a twister.yaml resides in an extension dir, then it is allowed to have a top-level config of its own, but it will be silently ignored. This is to support corner cases where, much like how a single board dir can define multiple boards, a single board dir can also extend multiple boards, or even do both. In those cases, the primary BOARD_DIR rule should make it unambiguous which config belongs to which board, even if it may seem counter-intuitive at first.

To-do

• Fix CI: boards: Fix copy-paste errors #84947
• Add unit tests