Devicetree overlays

In lesson 2, we covered the devicetree, a hierarchical data structure that describes hardware through nodes with belonging properties. It is not recommended to modify the devicetree directly, so instead we use devicetree overlays to do this. The overlay only needs to include the node and property it wants to modify.

&spi1{
	status = "okay";
};

&pinctrl {
	spi1_default: spi1_default {
		group1 {
			psels = <NRF_PSEL(SPIM_MOSI, 0, 25)>;
		};
	};
	spi1_sleep: spi1_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_MOSI, 0, 25)>;
		};
	};
};

The overlay file shown above will set node spi1 to have the status okay, essentially enabling this node. Then it is changing the pin configuration for the SPIM_MOSI line to pin 25 by changing the appropriate sub-nodes and properties in the &pinctrl node. Note that you must change the pin configuration for both the default and sleep states.

If an overlay file sets a node’s property to a value it already has, the node will just remain unchanged.

One easy way to create an overlay file is to create a file with the name of the board and the extension .overlay and place it directly in the application root directory. The build system will automatically search for this file type and include it if it finds one.

However, there are several other ways to include overlay files. See Set devicetree overlays for a list of ways to include a devicetree overlay in your application.

CMake

In the nRF Connect SDK, all applications are CMake projects. This means that the application controls the configuration and build process of itself, Zephyr, and all sourced libraries. The file CMakeLists.txt is the main CMake project file and the source of this build process configuration.

We will take a closer look at some of the functions in the exercise.

Sysbuild

Sysbuild is a high-level build system that simplifies the management of complex multi-image builds. It is an improved and extensible build system for multi-image builds, replacing the nRF Connect SDK-specific Multi-image builds system we had in older nRF Connect SDK versions.

 Sysbuild is mainly used for two use cases: Multi-core applications and bootloaders.

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.

Sysbuild works by configuring and building at least a Zephyr application and, optionally, as many additional projects as you want. The additional projects can be either Zephyr applications or other types of builds you want to run.

To distinguish CMake variables and Kconfig options specific to the underlying build systems, sysbuild uses namespacing. For example, sysbuild-specific Kconfig options are preceded by SB_ before CONFIG and application-specific CMake options are preceded by the application name.

Sysbuild is integrated with west. The sysbuild build configuration is generated using the sysbuild’s CMakeLists.txt file (which provides information about each underlying build system and CMake variables) and the sysbuild’s Kconfig options (which are usually gathered in the sysbuild.conf file).

To learn more about Sysbuild, there is a dedicated lesson on it in the nRF Connect SDK Intermediate course – Lesson 8- Sysbuild

A note on Kconfig.sysbuild

For the nRF5340, we need to run an image on the network core if we want to use the Bluetooth LE radio. This is done automatically by the build system using the Sysbuild feature. Sysbuild is covered in-depth in nRF Connect SDK Intermediate course – Lesson 8 – Sysbuild , so we will not dive into the details yet. Here is a brief explanation of how to add an image to the network core, specifically as done in the Bluetooth LE Fundamentals course, the Wi-Fi Fundamentals course, and the nRF Connect SDK samples.

Sysbuild uses Kconfig in a similar way to the prj.conf/ something.conf we know. However, for Sysbuild, they are named sysbuild.conf/Kconfig.sysbuild.

To select an image for the network core, we set one of the configurations found under the docs for Sysbuild: Enabling images. In most Bluetooth LE samples, IPC Radio is used, so we will also use IPC Radio.

Normally, this can be set in sysbuild.conf by adding:

# Enable IPC Radio for the network core
SB_CONFIG_NETCORE_IPC_RADIO=y
# Configure protocol for IPC Radio
SB_CONFIG_NETCORE_IPC_RADIO_BT_HCI_IPC=y

However, both in DevAcademy courses and the nRF Connect SDK Bluetooth LE samples set these instead in Kconfig.sysbuild , as shown below :

source "${ZEPHYR_BASE}/share/sysbuild/Kconfig"

config NRF_DEFAULT_IPC_RADIO
	default y

config NETCORE_IPC_RADIO_BT_HCI_IPC
	default y

This is because SB_CONFIG_NETCORE_IPC_RADIO only works for multi-core chips (Ex: nRF5340 SoC), so if this is set in sysbuild.conf, the samples would get a warning when building for single-core chips. However, when the configurations are set in Kconfig.sysbuild, the warning does not appear.

For some in-depth Kconfig theory: The reason Kconfig.sysbuild does not generate this warning is that it does not set an existing Kconfig symbol but instead overlays NETCORE_IPC_RADIO, giving it a new default that depends on SUPPORT_NETCORE_IPC_RADIO. Since only the nRF5340 can have SUPPORT_NETCORE_IPC_RADIO, the samples will then ignore the Kconfig.sysbuild for any other board, meaning no warning will be generated.

Trusted Firmware-M (TF-M)

Trusted Firmware-M (TF-M) is a blueprint for constructing a Secure Processing Environment (SPE) tailored to Arm M-profile architectures. TF-M relies on the principle of security through separation to safeguard sensitive credentials and code. Additionally, TF-M extends its protective capabilities to applications by offering security services, including Protected Storage, Cryptography, and Attestation.

The Nordic Semiconductor Series, which implements the Armv8-M architecture (Arm Cortex-M33), incorporates TrustZone technology. This technology enforces hardware-based segregation between Secure and Non-secure Processing Environments, effectively creating separate Trusted and Non-Trusted build images.

This means that we have two options for boards based on the nRF54L/nRF53/nRF91 Series. Either:

Option 1 – <board_target>/ns

Enforce security by separation by utilizing TF-M and have our application run in the Non-Secure Processing Environment and have TF-M run in the Secure Processing Environment.

Option 2 – <board_target>

Do not enforce security by separation by having our application run as a single image with full access privileges.

Let’s take a board with a board target <board_target> as an example. When building an application for the board, you could build for either <board_target> or <board_target>/ns.

• <board_target>: The application is built as a single image without security by separation.
• <board_target>/ns: The application will be built as a Non-Secure image. Hence, you will get security by separation as TF-M will automatically be built as the Secure image. The two images will be merged to form a combined image that will be used when programming or updating the device.

Child and parent images (deprecated)

When using this build system, the multi-image build consistsof a parent image and one or more child images, where the child image is included by the parent image.

This build system was deprecated in nRF Connect SDK v2.8.0 and replaced by Sysbuild; child/parent images will be removed completely in a future release.