Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)
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:
From: email@example.com <firstname.lastname@example.org> on behalf of Marc Reilly via Lists.Zephyrproject.Org <email@example.com>
Sent: Monday, December 9, 2019 4:38 PM
Subject: [Zephyr-devel] Managing/structuring multi image/binary projects for (OTA updatable products etc)
I've been looking at making product(s) which can do OTA updates, and how to structure the overall project.
A basic aim is to be able to checkout and build (assuming toolchain and environment is setup) with minimal commands, and also minimal manual 'configuration' changes required for a default build.
I'm not really feeling like I'm seeing a nice solution, so was wondering if anyone else has overcome a similar situation, or anyone has any ideas to progress.
Following, I've tried to summarize the problem & design as I see it to make sure I'm on the right track, and then I've got a few example commands to further illustrate where the problem is for me.
Any and all suggestions welcome.
The product acheives OTA updates, at a general level, by:
- use mcuboot as the bootloader
- app implements SMP service (eg mcumgr/smp_svr example)
- initially program the product with a combination of the mcuboot + app
- further updates can be done OTA, the app handles transmission and copying of the new firmware image to a partition on flash, then resets. the bootloader checks the new firmware image does some partition 'accounting' and then boots the new image.
Typical project elements/dependencies:
- app for the product/device
- board files are defined in the 'app' repo
- common libs (eg for our GATT services which most our devices have)
- zephyr framework
- dependent modules (eg nordic_hal, segger)
- (references the app board file)
This resembles either the T2 or T3 of west's documented tolopogies. [https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#topologies-supported]
- We want 2 primary build artifacts:
- the app (configured as launched from a bootloader)
- bootloader mcuboot
- And then from this with can run a variety of commands to merge and/or sign the build artifacts.
- As a bonus, perhaps another app configuration to make dev/debug easier where the bootloader is not used.
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 firstname.lastname@example.org: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. 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'.
- copy 'glue' script into west installation folder ?
- west commands ? in the manifest repo, or maybe another common lib etc.