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

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

Dominic — Thu, 12 Dec 2024 17:27:07 GMT

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

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

SimonBursten — Tue, 10 Dec 2024 14:12:45 GMT

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

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

Marte Myrvold — Tue, 10 Dec 2024 09:05:28 GMT

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

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

SimonBursten — Thu, 05 Dec 2024 18:51:09 GMT

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

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

SimonBursten — Thu, 05 Dec 2024 17:08:57 GMT

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?

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

Marte Myrvold — Mon, 25 Nov 2024 14:35:53 GMT

Hi,

Can you share the full build log?

Best regards,
Marte

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

SimonBursten — Sun, 24 Nov 2024 14:55:17 GMT

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/)