Extend list_boards.py and update boards CMake module to handle HWMv2.
list_boards.py is extended to support board.yml file in each board
folder with various information related to the board, such as vendor,
soc, cpucluster, variants, revisions.
The HWMv2 removes the requirement for a _defconfig file.
It also unifies how board revisions, cpusets, etc is defined which again
provides an option for cleaner build system implementation for handling
of boards and their integration to the build system.
The CMake boards.cmake module is updated to take advantage of the
improved design.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Simply added the missing 'a' in guaranteed. Found this
when I was too lazy to search for the correct spelling
and was hoping to just grep for it.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Adds supports for sysbuild loading project-specific Kconfiguration
fragments that are suffixed with the user-provided value
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Create dedicated function, sysbuild_cache(), for handling sysbuild's
image specific cache file.
This provides a cleaner handling of said cache file, and provides a
mechanism for updating the cache file at later sysbuild CMake stages.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Adjust the order in which image-specific `sysbuild.cmake` files are
iteratively included by sysbuild.
This is motivated by the introduction of `sysbuild_add_dependencies()`.
In the following example:
sysbuild_add_dependencies(CONFIGURE my_sample sample_a sample_b)
the `my_sample` image is expected to be added before this function is
called. Success depends not only on the placement of the call, but on
the order in which new images are added, which itself is influenced by
the order in which `sysbuild.cmake` files are included. This last order
can be tweaked to make the "dependencies" feature more user-friendly.
This is done by rewriting the internal `sysbuild.cmake` processing loop
into a new, general purpose function - `sysbuild_add_subdirectory()` -
which is a wrapper for `add_subdirectory(<source_dir>)` that recursively
includes `sysbuild.cmake` files for all images found in `<source_dir>`.
With the new function, all images that are expected to be found in a
given `<source_dir>` are guaranteed to be added around the same time.
This wasn't the case with the old processing loop, because the image-
specific `sysbuild.cmake` files (where "sub-images" could be defined)
were left to be processed at the very end.
Below is the initial order in which sysbuild will add all images.
Note: the order of Zephyr modules (from 1 to n) is well-defined.
1. Main application (aka DEFAULT_IMAGE)
2. MCUboot (optional)
3. All images added via these directories:
3.1. <module-1>.sysbuild-cmake
3.2. <module-2>.sysbuild-cmake
...
3.n. <module-n>.sysbuild-cmake
4. All images added via these files:
4.1. ${BOARD_DIR}/sysbuild.cmake
4.2. ${APP_DIR}/sysbuild.cmake (aka sub-images of DEFAULT_IMAGE)
These images are intended to be sorted for the users' convenience, from
most to least important in the build system, or least to most dependent
on other images for configuration (potentially).
Finally, the use of `sysbuild_add_subdirectory()` requires updating the
directory structure in sysbuild:
./images
- All images should belong here. The `DEFAULT_IMAGE` should be the
first and only image at the top level, so that it gets added first
and its sub-images get added last.
./images/bootloader
- Moved from ./bootloader.
./images/boards
- Adds images from the board-specific `sysbuild.cmake` file.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This variable was originally provided for two indended purposes:
* Let users manually add a new image in a desired order in the list.
* Let users set build-only images, which are excluded from the list.
Given the recent additions of the `sysbuild_add_dependencies()` function
and the `BUILD_ONLY` parameter, `IMAGES` should be considered obsolete.
Furthermore, the list of images added to sysbuild should be updated
automatically when calling `ExternalZephyrProject_Add()`. This is now
possible by using a GLOBAL property internal to sysbuild.
With that, the `IMAGES` variable can be removed. Its existing usage for
image ordering is replaced with `sysbuild_add_dependencies()` treewide.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Fixes#53650
The existing solution for image ordering involves the `IMAGES` variable,
which sysbuild originally provided to let users manually add a new image
in a desired order. This isn't very flexible for the following reasons:
* The order in which `IMAGES` is updated across multiple modules and
`sysbuild.cmake` files is not well defined.
* Having a single variable means that the same order is used for both
configuration and flashing. Usually, there is no reason for the
flashing order to be the same as the configuration order.
Introduce the `sysbuild_add_dependencies()` function for more fine-tuned
ordering of images. It makes one image depend on other images in either
configuration or flashing order. Its usage is similar to the standard
CMake function `add_dependencies()`, but with an extra parameter to
distinguish between two types of dependencies:
sysbuild_add_dependencies(CONFIGURE my_sample sample_a sample_b)
sysbuild_add_dependencies(FLASH my_sample sample_c sample_d)
CONFIGURE dependencies determine the order in which sysbuild configures
(runs CMake for) the individual images. This is useful if there is some
information from one application's build which needs to be available to
another application.
FLASH dependencies control the sequence of images used by `west flash`.
This could be used if a specific flashing order is required by an SoC,
a runner, or something else. Note that these dependencies are not valid
for images specified as `BUILD_ONLY`.
The internal `sysbuild_images_order()` function is responsible for
assembling two sorted lists of images based on the added dependencies,
with the help of `topological_sort()`.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Refactor image_config.cmake so that it is no longer sourced
unconditionally for all images. Instead image_config.cmake has been
split into BOOTLOADER_image_default.cmake and MAIN_image_default.cmake
and is set as property on the image.
This means the code in image_config.cmake can be split into dedicated
files which depends on the image type. Furthermore it allows sysbuild
modules to append extra config snippets to process for sysbuild kconfig
overwrite, or even remove the default snippet and have full control.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Export Zephyr image byproducts through `BYPRODUCT_<VAR>` cache
variables.
This allow external tools, such as sysbuild, to read information on
products produced by a Zephyr build from the image CMake cache.
For sysbuild, this means that all byproducts will be added to a phony
build target, which again allow sysbuild itself to depends on target
output and properly describe dependencies between byproducts and their
producing targets.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add a new parameter to `ExternalZephyrProject_Add()`, which determines
whether a given sysbuild image should only be built and not considered
for flashing and debugging. By adding the following arguments:
BUILD_ONLY TRUE
the image will be marked as build-only and excluded from `domains.yaml`.
For cases where this setting should be controlled by users or individual
samples, Kconfig can be used:
ExternalZephyrProject_Add(
APPLICATION foo
SOURCE_DIR /path/to/foo
BUILD_ONLY ${CONFIG_FOO_IS_BUILD_ONLY}
)
This would be particularly fitting for "general-purpose" images, defined
in-tree or via Zephyr modules (whose inclusion in the multi-image build
should also be Kconfigurable).
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Fixes an issue with relative paths both with and without using
sysbuild where they would not be updated properly or a warning
would previously be emitted.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Lately, sysbuild started filtering out variable names matching ^BOARD
during sysbuild cache file generation. As a result, one of the cache
variables that is no longer exported to other domains is BOARD_ROOT,
which breaks the recent support for out-of-tree boards in sysbuild.
Of those variables, the only one which is reasonable to filter out is
BOARD itself, because the purpose of that is to substitute a different
value for the one found in sysbuild's own CMake cache, which has the
board revision stripped out.
Update the relevant if-condition and use a single regex for brevity.
Fixes#59114.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
When calling `sysbuild_get(<out-var> VAR <lookup-var> ...)` user
specifically specify the output variable and in such cases the overwrite
warning should not be printed, because such invocation is similar to a
regular `set(<var> <val>)` CMake call.
Only the invocation where the same variable name is used for lookup and
return variable, then the warning must be printed to avoid unintentional
overwriting of existing variables.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Sysbuild now generates a .config.sysbuild config file which specifies
settings controlled by sysbuild.
Any setting specified in this .config will overrule user provided
setting, and a warning will be raised if the sysbuild controlled value
is different from the value specified by the user.
This has the following benefits:
- Allow sysbuild to control any build setting without adjustments to
the existing Kconfig tree
- Allow sysbuild to adjust settings based on knowledge regarding enabled
images / bootloaders.
- Cleanup CMake code, as settings in sysbuild no longer needs to be
propagated using CMake cache variables.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit improves the BOARD handling for Zephyr images.
Concatenate sysbuild BOARD and BOARD_REVISION to BOARD when creating the
image sysbuild cache file. This ensures that the proper sysbuild
BOARD@REVISION can be correctly inherited.
Current solution creates image specific <image>_BOARD cache variables
whenever a board revision is in use, even if the image is expected to
inherit the BOARD@REVISION value from sysbuild.
This improvement means that only when a dedicated board or
board@revision is specified for an image, then an image sysbuild cache
entry will be created.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Align sysbuild with Zephyr CMake so that sysbuild supports
SB_EXTRA_CONF_FILE. Keep support for the old SB_OVERLAY_CONFIG.
This ensures that sysbuild is consistent with Zephyr CMake configuration
file handling.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Adds a new CMake helper function that can be used from sysbuild to
set or update sysbuild CMake cache variables.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Fixes an issue whereby the direct variable was being used instead
of the cache variable when configuring target images.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Provide a uniform way for sysbuild modules to create hooks that are
called at specific time during sysbuild CMake configure time.
A module can create functions following the scheme:
- <module-name>_pre_cmake
- <module-name>_post_cmake
- <module-name>_pre_domains
- <module-name>_post_domains
those functions, if defined, will be called by sysbuild CMake at the
location indicated by the function name.
A new global variable `SYSBUILD_CURRENT_MODULE_NAME` is created, which
a module can use to know it's own name when defining those functions
during sysbuild module CMake inclusion.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Split running CMake from ExternalZephyrProject_add().
This will allow systems to define all Zephyr projects and then at later
stages run the CMake configure stage.
This makes it both cleaner when CMake is invoked as well as prepare for
future work where images could be depending on CMake outcome from other
projects.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Fixes: #52353
If a CMake variable is available in both local scope and as CMake cache
variable, then the use of `${<var>}` fetches the local scoped variable.
If only the cache variable is set, then things works as expected.
Ensure that the cached variable is always the variable being shared to
images by using `$CACHE{<var>}` instead.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Load image kconfig setting into image target properties.
This allows sysbuild to evaluate and check image configuration as part
of CMake invocation.
sysbuild_get() is updated to support reading of CMake cache or Kconfig
settings for an image.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces the possibility of a sample to locate
configuration files for extra images that are used when building with
MCUboot.
This allows use-cases where a sample, A, want to include MCUboot but has
adjustments to the default MCUboot configuration.
By adding a Kconfig fragment `<sample>/sysbuild/mcuboot.conf`, then that
fragment will be used together with the default configuration for
MCUboot.
It is also possible to completely replace the MCUboot configuration.
This is done by creating `<sample>/sysbuild/mcuboot/` folder.
This folder will then be used as the `APPLICATION_CONFIG_DIR` when
building MCUboot.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit loads the CMakeCache of Zephyr projects.
This allows sysbuild to fetch information from Zephyr projects into
sysbuild itself.
This commit is a first step in the process of sharing more knowledge
between images and sysbuild, and pave the way for closer sharing of
settings between images.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Enhance sysbuild controlled configurations.
The current scheme of passing settings using `-D` on the CMake
invocation is vulnerable to quoting and lists.
With `zephyr_get()` in place as a uniform way of handling user
controlled settings (CMake cache / environment / CMake local variable)
we have a mechanism in place for a cleaner handling of sysbuild
controlled settings.
This improves the robustness of variable passing and add the same cleans
up and simplifies the logic in sysbuild.
The Kconfig Zephyr CMake module has been updated accordingly so that
CONFIG settings are taken from the sysbuild shadow cache when sysbuild
is used as higher level build system.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This is the initial commit with system build, sysbuild.
Using CMake as infrastructure together with the Zephyr sysbuild allows
us to support a convenient way of building a sample and allow for extra
images to be built as part of a larger system.
It uses Kconfig for configuration of image builds.
This allows for future extension with additional build images.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Torsten Rasmussen
Daniel Leung
Jamie McCrae
Grzegorz Swiderski