[NCS 2.7.0] Sysbuild + MCUBOOT. Including out of tree driver with MCUBOOT sysbuild?

[SimonBursten]

I am currently migrating from ncs 2.5.0 to 2.7.0 and am trying to move to using sysbuild instead of child / parent image. I have an out of tree flash driver that currently gets built and configured as part of the mcuboot child image build.

So far, organising the configs and overlays for mcuboot and my app is pretty straightforward (they are organized under sysbuild/), but when I try to enable my out of tree flash driver in sysbuild/mcuboot/boards/[board].conf it says my config symbols are undefined.

In the child / parent image set up we simple did something like this in app/CMakeLists.txt

list(append zephyr_extra_modules ${cmake_current_list_dir}/../drivers/flash/my_out_of_tree_driver/)

this doesn't seem to work. neither does adding another CMakeLists.txt file in the sysbuild/mcuboot directory. What's the best way to let the mcuboot sysbuild know about the location of my driver?

[SimonBursten]

just noticed a mistake, the CMakeLists.txt line we are using is actually:

list(append mcuboot_DTS_ROOT ${cmake_current_list_dir}/../drivers/flash/my_out_of_tree_driver/)

[Marte Myrvold]

Hi,

Can you share the full build log?

Best regards,
Marte

[SimonBursten]

I've narrowed it down. in my application devicetree.h I can see bindings were taken from my driver directory, where as for mcuboot they weren't.

for example, here is my devictree.h header before moving to sysbuild

and after

At the moment i'm setting these variable in sysbuild.cmake which seems to allow sysbuild to actually build, but the devicetree for mcuboot isnt taking it into account. How can I manipulate DTS_ROOT for the mcubuild portion of the sysbuild?

[SimonBursten]

i also saw this answer, which seems like it might be related, but that's really not an approach i want to take

devzone.nordicsemi.com/.../recognizing-out-of-tree-device-driver-bindings-for-mcuboot-child-image

[Marte Myrvold]

Hi,

With child and parent images, the child images inherit things from the parent image. This can be useful in some cases, but the dependency between the images would make things more complicated in many other situations. Sysbuild, on the other side, operates with decoupled images. Because of this, you cannot make changes in the main project that impact the other images with sysbuild, as you have guessed.

The reason sysbuild.cmake does not work is likely because sysbuild.cmake is not a CMake script for all images but for sysbuild itself and how sysbuild handles the images.

Zephyr has three different types of applications: repository, workspace, and freestanding. We recommend using the workspace for out-of-tree drivers.
With the workspace application, you add drivers to the full nRF Connect SDK, and not just to your application. It will be a west project that you set up much like our SDK, but that includes our SDK as part of your application.
In this way, you can have a "drivers" folder in your project (one layer down from the application itself) that will be included as if it were part of the SDK itself.

I recommend taking a look at Lesson 7 – Device driver model in our nRF Connect SDK Intermediate course on DevAcademy, which covers how to implement a custom driver.

Best regards,
Marte

[SimonBursten]

i was able to find a simpler solution by adding sylinks to my boards dts/bindings folder. sysbuild looks in the application folder and the board folder for DTS files by default

[Dominic]

Hi. Thanks for sharing this problem and solution. I too needed sysbuild to include out of tree drivers for MCUBOOT.

I followed your approach and set the mcuboot_EXTRA_ZEPHYR_MODULES to point to my drivers folder in my sysbuild.cmake and it works! So thanks for sharing. 

However I don't know if this can help your situation: I don't need to set the dts_root because I structure my out of tree "drivers" folder to follow zephyr's module structure (which includes a Zephyr folder containing module.yaml). That points the dts_root to the same folder, along with the start of my KConfig chain. My out of tree dts reside along side my drivers. Additionally, whole folder is a git  submodule which I can pull in other projects. You then don't need to worry about creating symlinks for each project. 

Hope that helps! 

Dom