Shared config values in multi-image build

RE: Shared config values in multi-image build

Maria Gilje — Fri, 26 Jan 2024 07:38:07 GMT

Some extra insight:

Sysbuild is in an experimental state, and is supported for Nordic boards. If you are using a custom nRF5340 board, you should not use sysbuild at this stage.

For the default installation of NCS, using ZEPHYR_BASE/../nrf is going to work. But there could be cases where the folder structure or folder names has been changed. Using ZEPHYR_NRF_MODULE instead is therefore safer.

The full command is then

set(-Drpc_host_EXTRA_CONF_FILE="\${ZEPHYR_NRF_MODULE_DIR}/samples/bluetooth/peripheral_hids_mouse/shared-fragment.conf")

BR,

Maria

RE: Shared config values in multi-image build

Maria Gilje — Thu, 25 Jan 2024 11:57:54 GMT

Hello,

Sorry about the delay.

[quote user="JordanK"]1. Is there a way to specify a CMake flag in a sysbuild config (i.e. in sysbuild.cmake)?[/quote]

You can add a CMake flag in sysbuild.cmake. I created a sysbuild.cmake in the Peripheral HIDS mouse sample directory which included

set(-Drpc_host_EXTRA_CONF_FILE="<absolute-path-to-project-directory>/shared-fragment.conf")

set(-DEXTRA_CONF_FILE=shared-fragment.conf)

which had the same outcome as adding the CMake flags to the Extra CMake arguments in the build configuration.

You can use the ZEPHYR_BASE variable in the path. For example \${ZEPHYR_BASE}/../nrf/bluetooth/samples/peripheral_hids_mouse/shared-fragment.conf

[quote user="JordanK"]3. What's the best way to specify the "path-to_" in the <path-to_your-shared-fragment.conf>? I tried using a CMAKE variable (-Drpc_host_OVERLAY_CONFIG=${CMAKE_SOURCE_DIR}/overlay-shared.conf) because, as I'm sure you know, it otherwise attempts to use the child image's source directory as the path root. This didn't work though (it still used the child image's source directory). I also tried the CMAKE_CURRENT_SOURCE_DIR (no difference), CMAKE_BINARY_DIR (uses the build directory), and PROJECT_SOURCE_DIR (doesn't seem to be set) variables, none of which worked.[/quote]

CMake variables can be used from command line*. This is essentially what is done when applying flags to the build command or adding the command in sysbuild.cmake. In conclusion, the best way is to use sysbuild.cmake to add the CMake argument for specifying the path to the shared Kconfig fragment.

* Edit: This is not 100% correct:

If the CMake variable is defined early and is internal, it can be used in the path and the build system will resolve it. The ZEPHYR_BASE variable is an example of an early defined internal CMake variable. You can read more on these configurations in The Initial Configuration part of the Setting Kconfig configuration documentation.

Best regards,

Maria

RE: Shared config values in multi-image build

Kyle — Sat, 20 Jan 2024 04:20:05 GMT

Hi Maria, were you able to get any info on items 1 and 3?

RE: Shared config values in multi-image build

Maria Gilje — Thu, 04 Jan 2024 09:07:32 GMT

Hello,

Great to see this was helpful.

Comments and answers to your questions:

1. Sysbuild is pretty new for me, so I have to ask my colleagues about this.

2. Good catch. OVERLAY_CONFIG has been replaced by EXTRA_CONF_FILE from NCS v2.5.0 (Zephyr v3.4.99 as well). My previous answer is valid for NCS versions < 2.5.0. For NCS v2.5.x, you use EXTRA_CONF_FILE to apply Kconfig fragments to your build. The change is listed in the release notes for Zephyr 3.4.0 under Build system and infrastructure.

3. I found that specifying the relative path and the absolute path worked. I get that this is tedious, so I will post a question internally to see if some of the developers has some tips.

Best regards,

Maria

RE: Shared config values in multi-image build

Kyle — Wed, 03 Jan 2024 17:43:09 GMT

Thanks Maria, this is super helpful. A few additional questions:

1. Is there a way to specify a CMake flag in a sysbuild config (i.e. in sysbuild.cmake)?

2. What is the difference between the OVERLAY_CONFIG and EXTRA_CONF_FILE build variables? I'm guessing that EXTRA_CONF_FILE is the new version (it's listed in the "latest" Zephyr documentation) and OVERLAY_CONFIG is an old term (it's last shown in the 3.3.0 Zephyr documentation)? Since nRF Connect SDK 2.5.1 is using Zephyr 3.4.99 though, it would seem that I should be using EXTRA_CONF_FILE instead?

3. What's the best way to specify the "path-to_" in the <path-to_your-shared-fragment.conf>? I tried using a CMAKE variable (-Drpc_host_OVERLAY_CONFIG=${CMAKE_SOURCE_DIR}/overlay-shared.conf) because, as I'm sure you know, it otherwise attempts to use the child image's source directory as the path root. This didn't work though (it still used the child image's source directory). I also tried the CMAKE_CURRENT_SOURCE_DIR (no difference), CMAKE_BINARY_DIR (uses the build directory), and PROJECT_SOURCE_DIR (doesn't seem to be set) variables, none of which worked.

RE: Shared config values in multi-image build

Maria Gilje — Wed, 03 Jan 2024 14:02:47 GMT

Hello,

Well done on the research you have done on this. The way to use a shared fragment on two images is to use extra CMake arguments when building.

[quote user=""]Specify a shared fragment for both the child image ("rpc_host") and the parant/application image. Since the child image is enabled by "CONFIG_BT_RPC_STACK", though, and not by any kind of West build configuration, I can't find a way to apply a fragment to it.[/quote]

This is the way to go. You can add the CMake flag -Drpc_host_OVERLAY_CONFIG=<path-to_your-shared-fragment.conf> and -DOVERLAY_CONFIG=<your-shared-fragment>.conf to the build command to apply the fragment to both the RPC host child image and the application image. When building the child image, the build system will search in the child image application directory, so you need to specify the whole relative path from the child image application directory to your shared fragment or the full absolute path to your shared fragment.

[quote user=""]As a separate, semi-related question: the CONFIG_BT_RPC_STACK config value (and Bluetooth over RPC in general) is marked in the SDK as "EXPERIMENTAL". The nRF5340, however, has been out for almost 4 years now, so I would expect that there would be production-grade options for utilizing the networking core. If BLE over RPC is experimental, what's the recommended production-grade option for offloading BLE to the network core?[/quote]

HCI RPMsg is not experimental, though it is part of a dual chip configuration, so it is only the Bluetooth LE controller which is on the network core.

If you want to know anything about future features or our roadmap in general, please contact your Regional Sales Director.

Best regards,

Maria