Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)

Marc Reilly

Hi Marti, Sebastian, list

Thanks for the ideas, my replies are inline below.

> Hi, I see you are using nrf.
> Signing, building, and hex merging of multiple images in a single west command is supported
> out-of-the box with the nRF Connect SDK, which uses a patched Zephyr.

> So if not using vanilla Zephyr is an option then see:

I second Sebastian's suggestion to look at nRF Connect SDK (NCS).
It has useful features for building OTA binaries for nRF devices.

 .. it looks like the NCS capabilities will do what I wanted with regard to building a bootloader + app in one go. I haven't had time to look at it properly, but it seems like the strategy is to make the bootloader an extra output of the primary 'app' project (ie extra targets in the app project cmake).
This is a different approach than what I was thinking of. I was envisaging that the bootloader and app were treated as more isolated projects, and were configured and glued together by another higher level _something_.

Traditionally, I tend away from relying too much on vendor 'BSP's for the long term, they've tend to stagnate or diverge too much from mainline as time goes on.
Does anyone know if there are any plans to bring NCS's 'multi-image' functionality into mainline zephyr?


> -----
> West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example:
> west init -m git@...:SomeManifestRepo.git
> west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app
> west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app
> west sign ...
> However, it would be nice to be able to glue this all together with
> some script etc to simplify the extra elements of the west commands
> ('theboard' 'BOARD_ROOT') etc.

No matter what you choose to use (mainline or NCS), though, you can
always tell 'west build' your default board like this:

  west config build.board theboard

The build.board value will be used if you don't provide --board
(provided BOARD is also unset in the calling environment).

This is useful to know, thanks !

I thought about your BOARD_ROOT question. I've gotten other similar
requests recently, and I agree it would be useful, so I've proposed a
new "build.cmake-args" config option:

With the patch from #21251, you can save your BOARD_ROOT like this:

  west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Your one-time setup work would then be:

  west init -m git@.../SomeManifestRepo.git
  west update
  west config build.board theboard
  west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Note that plain 'west config var val' sets configuration options locally
(just for your west installation). See the --global and --system options
in the 'west config' documentation for alternatives.

  # build and flash
  west build -d build-mcuboot -s mcuboot/boot/zephyr
  west build -d build-app -s app
  west sign ...

> And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'.
> Alternatives:
>  - copy 'glue' script into west installation folder ?
>  - west commands ? in the manifest repo, or maybe another common lib etc.

I hope the above is what you're looking for.

I think what I was envisaging was something to glue together the above commands (and keep some separation between the specific 'app' and the bootloader), I thought this would be 'west', but maybe not.. to take this approach would mean having to invoke the build/sign/whatever commands from the 'west installation' folder, and it would only be available from the manifest repo folder.

Note 'west build' can only compile one Zephyr application at a time.
The NCS can build application and mcuboot binaries at once out of the
box, for reference.

Please test and comment in the PR if you get a chance.

Done!, thanks.

Join to automatically receive all group messages.