Sysbuild Kconfig compliance + misc fromtree #2507
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit b2af352. To be replaced with a new version. Signed-off-by: Grzegorz Swiderski <[email protected]>
This reverts commit 6692263. Signed-off-by: Grzegorz Swiderski <[email protected]>
Add missing quotes around string values, so that they won't be interpreted as undefined symbol names. Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit 17ba479)
…classing
So far, the behavior of different Kconfig checks has been parametrized
using the `run()` method, and every new check has introduced with it a
new argument to that method.
It's possible to replace each `run()` argument by way of overriding
different class methods and making better use of inheritance:
free=False Stub check_no_undef_outside_kconfig()
no_modules=True Stub get_modules()
filename Introduce class member FILENAME
hwm (unused)
This should establish a more scalable and straightforward pattern for
adding future Kconfig checks. It also favors composability, which will
come in handy when implementing checks for sysbuild Kconfig.
Additionally, avoid duplicating `doc` and `path_hint` in every subclass.
Signed-off-by: Grzegorz Swiderski <[email protected]>
(cherry picked from commit 50d9ed5)
HWMv1-specific Kconfig checks were meant to be removed before HWMv2 was merged into `main` (see `collab-hwm` history), but some traces remained. Do another round of cleanup. Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit c0d5e85)
…2 temp dirs
The KCONFIG_BINARY_DIR/{boards,soc,arch}/ directories are only relevant
for `KconfigCheck.get_v2_model()`, so generate them within this method.
Signed-off-by: Grzegorz Swiderski <[email protected]>
(cherry picked from commit 37bce60)
…ecks
Introduce sysbuild-specific variants of existing Kconfig checks:
* SysbuildKconfig
* SysbuildKconfigBasic
* SysbuildKconfigBasicNoModules
This involves a few additions to the base `KconfigCheck` class:
* Supporting a variable symbol prefix, to handle `SB_CONFIG_`.
* Generating extra files, including `Kconfig.sysbuild.modules`.
Although these are never sourced outside of sysbuild Kconfig,
they're still generated for every regular Zephyr build, so it's
natural to let all Kconfig checks follow this behavior.
Signed-off-by: Grzegorz Swiderski <[email protected]>
(cherry picked from commit 7ce6ac2)
Necessary changes for NCS CI. - Add a Jenkinsfile - Add a commit-tags workflow: This enables sauce tag checking in sdk-zephyr - compliance.yml: Disable check for merge commits, since we have upmerges downstream. Also, since in the code we refer to Kconfig symbols that are defined in the sdk-nrf repository, most Kconfig checks will not pass so exclude them. Also, disable any maintainers-related checks - scripts/gitlint: Extend the max commit line lengths for Gitlint to account for sauce tags - Adapt to the changes in: nrfconnect/action-commit-tags#4 Signed-off-by: Carles Cufi <[email protected]> Signed-off-by: Dominik Ermel <[email protected]> Signed-off-by: Martí Bolívar <[email protected]> Signed-off-by: Vinayak Kariappa Chettimada <[email protected]> Signed-off-by: Krishna T <[email protected]> Signed-off-by: Dominik Ermel <[email protected]> Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit ef75b3e) (cherry picked from commit 6692263)
The motivation for this patch was to improve the script's performance, but some stylistic changes and cleanups are included as well. The main optimization concerns the use of PyYAML, as it offers multiple functions for interpreting YAML. The commonly used `load`/`safe_load` converts a YAML stream to a dictionary. There are also `scan`, `parse`, and `compose`, which return intermediate representations, the last one being a graph. [1] Since `gen_driver_kconfig_dts` scans DT bindings for compatible strings, it only needs to look through top level keys in YAML. The intermediate PyYAML graph is sufficient for this, and using it reduces the script's execution time by about 30%, without making the code too complicated. [1] - https://pyyaml.org/wiki/PyYAMLDocumentation Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit 15488be)
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 -------- The `twister.yaml` handling 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. For concrete examples of what this means, please see the newly added platform unit tests. As part of these functional changes, a good chunk of logic is moved out of `TestPlan.add_configurations()` into a new function in `platform.py`. This is because recombining the top-level and variant configs requires direct manipulation of the loaded YAML contents, which would be improper to do outside of the module responsible for encapsulating this data. Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit bb8b059e23c7da869be527b422420b3031f39421)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
manifest-pr-skip