Zephyr: MCUboot-compatible builds in Zephyr

[carlescufi]

The goal is to be able to generate .hex and .bin files from the Zephyr build system that are compatible with MCUboot, either as a "slot0" or as a "slot1" image.

Here's a rough outline of how I see this working:

$ cmake -DBOARD=<board> -DMCUBOOT_SLOT0 -DWITH_MCUBOOT ..
$ cmake -DBOARD=<board> -DMCUBOOT_SLOT1 ..

The first line would generate a .hex or .bin that contains both the MCUboot and the Slot0 images together, with Slot0 signed as necessary by imgtool.py.
The second line would generate a .hex or a .bin with the Slot1 image signed as necessary.

[carlescufi]

Comments welcome, this is just an idea for now

[pfalcon]

image signed as necessary.

IMHO, stuffing signing into Zephyr build system is too much.

Also, we seem to move towards splitting of e.g. emulation to a separate tool instead of "make run" (well, I heard talks about...). Here, instead, more adhoc tools get integrated into Cmake system. No consistent direction of motion...

[carlescufi]

IMHO, stuffing signing into Zephyr build system is too much.

That's where we really need to take a decision. We either go for an external tool that does all of this sort of stuff, or we integrate it into CMake. I think we need quorum to take that decision, so I will ressucitate the old issue and add people there.

[mbolivar]

I think I agree with @pfalcon that putting explicit mcuboot support into Zephyr feels strange.

We have DT partitions that let us build images in an mcuboot compatible way. I think perhaps a more flexible and general approach would be to allow combining multiple DT overlay files we can specify at CMake generation or build convenient time, rather than just having DTC_OVERLAY_FILE and falling back to DTC_OVERLAY_DIR/board.overlay).

This would allow building for mcuboot as a single, perhaps SoC-specific overlay file, but also allow application-specific overlay files too.

[mbolivar]

re: Image signing, I also think it's a strange thing to add directly to Zephyr's CMake build system.

In a non-toy environment, the location of the manufacturer or device specific signing keys probably need to be passed at runtime to the tooling that does the signing (which is, in sufficiently paranoid places, not the same environment as the one that does the building). CMake-generated build systems are not a good fit for this since they require manipulating the environment to pass runtime arguments, and the issue of separate environments pushes me towards separate (but still convenient) tools than the Zephyr build system.

[carlescufi]

An option suggested by @mbolivar would be to have CMake or an external tool drop .conf and .dts files in APPLICATION_BINARY_DIR before actually running Kconfig or dtc.
For this to work we would need to have something similar to what we have here in dts.cmake

[carlescufi]

Current tweaks required to have a Zephyr application boot with MCUboot:

• Set CONFIG_TEXT_SECTION_OFFSET in the app's prj.conf
• If Cortex-M0 with no VTOR, set IRQ_SOFT_RELAY in the app's prj.conf
• Modify the app CMakeLists.txt so that it includes a dts overlay
• Have a dts.overlay file in the app

[SebastianBoe]

IMHO, stuffing signing into Zephyr build system is too much.

I disagree.

It fits nicely into Zephyr's build system because signing from a build system perspective is just files depending on other files with a command or two to implement the dependency rule.

Also, we seem to move towards splitting of e.g. emulation to a separate tool instead of "make run" (well, I heard talks about...). Here, instead, more adhoc tools get integrated into Cmake system. No consistent direction of motion...

I'd say we are consistently moving in the direction of Zephyr using the build system to integrate tools needed by the user. Examples; DTC, Kconfig, gdb, pyocd, gen_syscalls, merge_config, git (for downloading OpenThread), etc.

If this separate tool had existed and been responsible for certain workflows not covered today I would agree we were inconsistent, but today at least things are consistent.

[SebastianBoe]

We have DT partitions that let us build images in an mcuboot compatible way. I think perhaps a more flexible and general approach would be to allow combining multiple DT overlay files we can specify at CMake generation or build convenient time, rather than just having DTC_OVERLAY_FILE and falling back to DTC_OVERLAY_DIR/board.overlay).

This would allow building for mcuboot as a single, perhaps SoC-specific overlay file, but also allow application-specific overlay files too.

Sounds good. No matter how we end up integrating with MCUBoot we probably would want this at some point down the road anyway.

[SebastianBoe]

In a non-toy environment, the location of the manufacturer or device specific signing keys probably need to be passed at runtime to the tooling that does the signing (which is, in sufficiently paranoid places, not the same environment as the one that does the building). CMake-generated build systems are not a good fit for this since they require manipulating the environment to pass runtime arguments, and the issue of separate environments pushes me towards separate (but still convenient) tools than the Zephyr build system.

Toy environments are useful though, for early prototyping work. So I figure why not support both use-cases, especially when supporting signing in the build system appears to be straightforward to implement.

[pfalcon]

So I figure why not support both use-cases

@SebastianBoe, I appreciate your comments, and definitely don't try to argue with you. Instead, just try to pinpoint arguments which may conflict with the desired goal. In this regard, answer to "why" in "why not support both use-cases" would be "because unless 2 ways are well aligned and overlap, that might mean doing double-work (one-time, minor factor) and then double-work in maintenance and support (recurring, major factor)". Surely, if there're no bigger problems in the build system maintenance (e.g. https://github.com/zephyrproject-rtos/zephyr/issues/5605, https://github.com/zephyrproject-rtos/zephyr/issues/5723, https://github.com/zephyrproject-rtos/zephyr/issues/5153, https://github.com/zephyrproject-rtos/zephyr/issues/4917 are resolved/no longer apply), then why not?

[carlescufi]

Closing this for now since we now have CONFIG_BOOTLOADER_MCUBOOT which essentially does everything required to create an MCUboot-compatible binary.