Migrating to sysbuild (NCS 2.8.0) results in CMake error

[Remco Poelstra]

I'm in the process of migrating my project from NCS 2.6.1 to 2.8.0.

My project consists of a BLE application with MCUBoot as the only boot loader.

I've already updated my code so it compiles with HWMv1 and parent/child images under NCS 2.8.0.

I'm now trying to migrate the build system to sysbuild. Therefore I've made the following changes:

1. Moved child_image/mcuboot.conf to sysbuild/mcuboot.conf

2. Removed CONFIG_BOOTLOADER_MCUBOOT=y from the main prj.conf

3. Added a sysbuild.conf with the following contents:

SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
SB_CONFIG_PARTITION_MANAGER=y
SB_CONFIG_DFU_ZIP=y
SB_CONFG_DFU_ZIP_APP=y

When I now try to build the project I get the following error:

FATAL ERROR: command exited with status 1: <long command>

The only error that I can find is all the way at the top:

CMake Error at C:/Users/rpoel/Documents/SRC/T502534-FIRMWARE-Nordic-nRF528xx/external/nrf/sysbuild/CMakeLists.txt:117 (list):
  list GET given empty list
Call Stack (most recent call first):
  cmake/modules/sysbuild_extensions.cmake:583 (nrf_PRE_CMAKE)
  cmake/modules/sysbuild_extensions.cmake:583 (cmake_language)
  cmake/modules/sysbuild_images.cmake:16 (sysbuild_module_call)
  cmake/modules/sysbuild_default.cmake:20 (include)
  C:/Users/rpoel/Documents/SRC/T502534-FIRMWARE-Nordic-nRF528xx/external/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:75 (include)
  C:/Users/rpoel/Documents/SRC/T502534-FIRMWARE-Nordic-nRF528xx/external/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
  C:/Users/rpoel/Documents/SRC/T502534-FIRMWARE-Nordic-nRF528xx/external/zephyr/share/sysbuild-package/cmake/SysbuildConfig.cmake:8 (include)
  template/CMakeLists.txt:10 (find_package)

How can I resolve this error?

Thanks in advance.

Kind regards,

Remco Poelstra

[Amanda Hsieh]

Hi,

Check out the typo.

SB_CONFG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

It's SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256.

 

SB_CONFG_DFU_ZIP_APP=y

It's SB_CONFIG_DFU_ZIP_APP.

Regards,
Amanda H.

[Remco Poelstra]

Ah, stupid me.

Unfortunately, correcting that makes no difference in the build error.

This is the part that generates the error:

  # Calculate the secure board target when building for non-secure board targets
  string(REPLACE "/" ";" split_board_qualifiers "${BOARD_QUALIFIERS}")
  list(GET split_board_qualifiers 1 target_soc) # <--------------------- This is line 117.

Does that provide any clue to what might be wrong? The board definition is found and a full DTS is constructed by Cmake.

[Amanda Hsieh]

What is the nRF Chip on your board? Are you using the board target definition for a non-secure build?

Please be aware that nRF52 chips don't support non-secure build.

The error suggests that the BOARD_QUALIFIERS string doesn't contain the expected number of elements when split by "/". This could happen if your board target is not correctly defined.

To resolve this, ensure that your board target is correctly defined and follows the expected format. For example, if you're using a custom board based on nRF52840, your board target should look something like customboard_nrf52840. See this DevAcademy course: Adding custom board support

[Remco Poelstra]

Thanks for the suggestion.

I updated my custom board to include the chip identifier. This didn't help.

I added a `message(BOARD="${BOARD_QUALIFIERS}")` line in the CMakeLists.txt and it shows that the BOARD_QUALIFIERS variable is empty:  'BOARDS=""'.

Though, the log output shows a few lines earlier: "-- Board: t502534_nrf52840", so I think it finds the board just fine.

I'm not sure what's the difference between a secure and non-secure build. How is this related to the issue I'm seeing here?

[Amanda Hsieh]

Check out this post. 

[Remco Poelstra]

I did find that post during my search, but it refers to NCS 2.7.0, while I'm on 2.8.0. It also mentions that HWMv2 isn't supported, but I'm still on HWMv1.

Are you sure that post is relevant to my case? If so, is there no point in trying to upgrade at this moment? The documentation states that 2.9.0 will drop support for HWMv1 and the parent/child build system. If that's true, when am I supposed to upgrade?

[Amanda Hsieh]

Sorry for the misleading. I go through your reply again and realize that t502534_nrf52840 this is the problem, this is the HWMv1-based syntax, the line string(REPLACE "/" ";" split_board_qualifiers "${BOARD_QUALIFIERS}")expects board name with / HWMv2 but as the board doesn't have / split_board_qualifiers[1] fails. Please use HWMv2 naming: "t502534/nrf52840".

[Remco Poelstra]

Thanks! That solved more or less my problem.

Renaming the HWMv1 board to t502534/nrf52840 was difficult due to the '/' in the folder name, but I migrated the board to HWMv2 and now sysbuild works fine,

Maybe the migration guide should mention that you should first migrate your boards to HWMv2 and only then start migrating to sysbuild. I did not experience any problems using the HWMv2 board with the parent/child build, so that migration path is much more smooth. And converting my board was as simple as running the supplied conversion script.

[BrianW]

Just experiencing the same error, presumably because my board is OOT and HWMv1 also. Did you use a migration script to convert from HWMv1 to v2? or a migration guide somewhere I haven't found yet?

I based my current DTS setup on the nrf5340dk_nrf5340 dev kit, but I can't find this in the 2.8 NCS boards to use as an example...

[Remco Poelstra]

I used this guide, which also mentions the conversion script:

docs.nordicsemi.com/.../migration_hwmv2.html

[BrianW]

Great thanks!

Now I look at it, I had already seen a previous version of this page, but was fooled by this paragraph:

Out-of-tree boards

The nRF Connect SDK provides full backwards compatibility for any existing out-of-tree boards.

As such, the migration from hardware model v1 to hardware model v2 is optional for nRF Connect SDK users that also have out-of-tree boards. If you choose not to convert an out-of-tree board, you will receive a warning when building your application, informing you that the board definition is in a format compatible with hardware model v1.

Sadly this does not appear to be true...

Updating my OOT files to HWMv2 helps the build start, but still stuck on the actual DTS content migration...