This lesson aims to explain Sysbuild, its use case, and how to use it. Sysbuild became available in nRF Connect SDK version 2.7.0 and is enabled by default for all nRF Connect SDK projects from version 2.8.0 onwards.
To quote Sysbuild documentation: “Sysbuild is a higher-level build system that can be used to combine multiple other build systems together. It is a higher-level layer that combines one or more Zephyr build systems and optional additional build systems into a hierarchical build system.”
In other words, Sysbuild runs before the normal Zephyr build system and will help you handle multiple builds as one. To give this context, let’s look at some use cases for Sysbuild.
Sysbuild is an improved and extensible system for multi-image build, replacing the nRF Connect SDK-specific Multi-image builds system we had in older nRF Connect SDK versions. When comparing these two, the key advantages of Sysbuild are as follows:
In the nRF Connect SDK, Sysbuild is mainly used for two use cases: Multi-core applications and bootloaders.
For a multi-core application, we want to build two images: one for the main core and one for another core. For example, on the nRF54L15 SoC, this could be one for the application core and one for the RISC-V fast lightweight peripheral processor (FLPR) core. With Sysbuild, we can add build configurations and code for both images to one project and then build once for both. This significantly reduces the complexity of working with multiple cores since you are working on a single project. Without Sysbuild, you would be managing two projects and need to perform many tasks manually.
When the board target has a debugger or is connected to a debugger, Sysbuild will also manage both images for easy flashing to the chip.
For bootloaders, the same is done, but instead of building one image for each core, images are built for different addresses on the same core. These are then merged into merged.hex
so you can flash only one file to the chip.
Since Sysbuild is enabled by default, it will also be active for builds with a single image.
Sysbuild also has a couple of other use cases than what is presented above. See “Migrating from multi-image builds to Sysbuild” for a list of options.
Although you can add your own custom image for another core or as a bootloader, this is not common for most users.
Most users will instead use Sysbuild to configure extra images provided by the nRF Connect SDK. The nRF Connect SDK v2.9.0 includes two bootloaders and five images for the nRF5340 network core as default images. A list of images can be found at Sysbuild images docs.
These are the available images:
These default images come pre-configured, but in many use cases, they need to be reconfigured for specific projects. For example, MCUboot has logging enabled by default. It is recommended that you disable logging for MCUboot for a release project, and to do that you need to be familiar with Sysbuild.
In the next part, we will learn how to apply configurations to all images of a Sysbuild project.
Sysbuild Kconfig symbols can be used to include default images in a project. Configuration specifics will be covered in a later topic “Sysbuild configuration“, but know that the configuration values needed can be found at Migrating from multi-image builds to Sysbuild.
Here are some rules for Sysbuild and the images in a project:
As you can see from the rules above, everything goes in one direction. The image below tries to illustrate this.
Arrows in this figure are actions performed. To explain the arrows:
Here are the places where documentation on Sysbuild can be found.