Attachments (1) Download All
Nordic Case Info
  • Case ID: 339967
Options

Migrating a Zephyr Project from Child/Parent Build System to Sysbuild: First Steps and Questions

Andrea Verdecchia

I'm trying to migrate my project from the child/parent build system to the new sysbuild system in Zephyr, and I'm finding it a bit unclear. I came across a helpful post that partially explains how to structure the new project. Let me start by showing my current project, which has a structure similar to the one described in the post I found:

CMakeLists.txt is:

prj.conf is:

child_image/mcuboot/prj.conf is:

child_image/mcuboot/board/gravity_sensor.conf is:

From what I understand, the first step is to delete the child_image folder, create a sysbuild folder, and add a sysbuild.conf file. But what exactly should I include in these two elements, and what modifications, if any, do I need to make to prj.conf and CMakeLists.txt?

Following the post I found, I modified the project as follows:

CMakeLists.txt is:

prj.conf is:

sysbuild/mcuboot/prj.conf is void and sysbuild.conf is:

sysbuild/mcuboot/board/gravity_sensor.conf is:

However, when I try to build the project, I still get an error:

What am I doing wrong?

Parents
  • 0

    I reanalyzed the issue and noticed that the error might have been due to using HWMv1 instead of HWMv2. So, I created a new board using the nRF Connect tool in VS Code, which generated the files according to the new protocol.

    I copied the new files into my project, but during compilation, I still encounter errors, different from the previous ones:

Reply
  • 0

    I reanalyzed the issue and noticed that the error might have been due to using HWMv1 instead of HWMv2. So, I created a new board using the nRF Connect tool in VS Code, which generated the files according to the new protocol.

    I copied the new files into my project, but during compilation, I still encounter errors, different from the previous ones:

Children
  • 0 in reply to Andrea Verdecchia

    Hi,

    From what I understand, the first step is to delete the child_image folder, create a sysbuild folder, and add a sysbuild.conf file. But what exactly should I include in these two elements, and what modifications, if any, do I need to make to prj.conf and CMakeLists.txt?

    Yes, this is correct. You'll need to move the child_image overlays and configurations present within the child_image folder and place them within the sysbuild folder which contains the new companion components, which replaces the child_image system.

    In addition, you need to consult the sysbuild migration guide https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/migration/migration_sysbuild.html and the three links here:

    The last link, sysbuild forced options, shows a list of which options that were previously defined within prj.conf that you now need to add to sysbuild.conf. If these configurations are present within prj.conf but not within sysbuild.conf they will be ignored.

    project as follows:

    The structure looks good to me at first glance, but I need to check up on the individual configuration for sysbuild for the various boards. I believe that there might be some limitations there.

    Andrea Verdecchia said:
    I reanalyzed the issue and noticed that the error might have been due to using HWMv1 instead of HWMv2. So,

    Yup, that is correct! As the warning states: 

    There's a guide for how to migrate here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/migration/migration_hwmv2.html 

    Andrea Verdecchia said:
    I copied the new files into my project, but during compilation, I still encounter errors, different from the previous ones:

    The next set of warnings seems to be Kconfig related, i.e "error: Aborting due to Kconfig warnings". This is most likely due to either changes in the configurations in between the upmerge you've done, or that there is something that should've been a SB_Configuration instead of a prj.configuration. It will require some manual labour from you to go through the migration notes for the respective versions you've gone through.

    Let me know if this is enough to get you pointed, and I'll get back to you w.r.t the multiple sysbuild/board configurations.

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Thank you very much for your advice. I checked the links you sent me and reviewed everything. In my opinion, everything should be configured correctly, but I keep getting errors/warnings regarding some configurations in prj.conf and in the file generated by the nRF Connect script for VS Code when creating the board from scratch: CONFIG_ARM_MPU, CONFIG_HW_STACK_PROTECTION, CONFIG_FLASH_MAP, etc.

    If you want to take a look, I have stripped my project down to the bare minimum, keeping only the structure and configuration files intact. I am trying to use NCS 2.9.0. You can find the project here.

  • 0 in reply to Andrea Verdecchia

    Hi,

    Just FYI, the sysbuild course was just released on the academy pages https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-sysbuild/ 

    AHaug said:
    but I need to check up on the individual configuration for sysbuild for the various boards. I believe that there might be some limitations there.

    It does look like we don't support individual sysbuild configurations for the various boards as of now, meaning that sysbuild/mcuboot/boards does not work in sysbuild as of now. This worked with child_image because Key was an MCUboot-specific options, but now it is a sysbuild option. 

    Could you strip down the port of your application even further and see if you're able to make it work without sysbuild specific board configurations, i.e this:

    I've also started an ongoing internal discussion w.r.t this is possible, but if you're able to get the latest suggestion compiling and flashing (and to whatever extent it will be running), then the root case is indeed this.

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Looks like the individual board configuration is working as it should. Issue should not be there. See https://github.com/nrfconnect/sdk-nrf/tree/main/samples/nrf5340/extxip_smp_svr/sysbuild/mcuboot as an example.

    This loops back to having to individually go through the configurations to isolate the issue.

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Thank you very much for your suggestions. I hadn't seen the tutorial on the academy. Things are much clearer now.

    After that, I tried creating a project from scratch, also creating a new board from scratch, then gradually adding the configurations of my project to be converted, and finally adding all the application sources.

    Everything works fine until I start having issues with the creation of the MCUBoot configuration file. Apparently, the configuration file, which I named mcuboot.conf, must necessarily be in the sysbuild/ folder and nowhere else. Even if I create an empty folder named mcuboot/, I get a compilation error.

    The different cases are as follows:

    If I have

    This is ok!

    If I have

    it give me error:

    If I have

    it give me error:

    Did I miss something?

Terms of service