Zephyr generic multi-image

[tejlmand]

This is a meta issue trying to collect use-cases related to Zephyr multi-image builds.

Building of multiple images through a single build invocation together with flashing capabilities is a recurring feature request.

This meta issue tries to collect all the different scenarios which have been requested, including those which have a custom solution.

What is desired is an overall solution that is well designed and flexible enough to be extendable, both within Zephyr itself, but to the extend possible also providing hooks for downstream users.

Some examples:

• Building and flashing of MCUBoot together with a Zephyr sample
• Building and flashing of a custom bootloader together with a Zephyr sample
• Building and flashing of a custom sample together with a Zephyr sample, for example Trusted-firmware-M
• Building and flashing of a multi-core SoC where both images are Zephyr based, for example: ipc/openamp
• Building and flashing of a multi-core SoC where one image is non-Zephyr based.
• Building and flashing of a multi-core SoC, where the cores have different architectures.

Considerations:

• Sharing of configuration data: Configuration data may need to be shared between projects. One example is signing key when building a sample with MCUBoot. In such case the keys used for signing and verification must both be know to the build system. In this particular case the high level build system should be the configuration entry point and setting shared to the images. This implies that settings that might be received from higher level should not be per-image configurable when handled by multi image build system.
• Sharing of build information: A given image may need to have knowledge of output data / libraries from another image, for example: Sample may need to have access to library and headers created by TF-M project. Sample may need to have have to location and size information of an image.

Tasks covered with this meta issue:

• [x] High level architectural design of an extendable solution See: https://docs.google.com/presentation/d/1d4Jr7DPiAJdTqQGLzY3Zn6hbytdA0NlMl4ug91idHA8
• [x] Implementation of a framework, fixed by #40555
• [x] Support for MCUBoot use-case, see #40309, fixed by #40555
• [ ] Support for custom bootloader
• [x] Image dependency handling, see #53650
• [ ] Multicore SoC image support
  • [x] SoC specific extensibility, see #43488
  • [x] Convert samples under sample/subsys/ipc to multi image framework
  • [ ] Convert following use-cases to multi image framework
    • Board: mps2_an521 multi image
• [x] Ability to define settings in sysbuild Kconfig which are then propagated to images, see #53126.
• [ ] #70099
• [ ] Packaging. When building for multi-targets, it should be possible to easily define images that must be packaged together along with additional package information, to facilitate distribution of software for a complete systems.
• [x] Support for processing of commands for west flash that need grouping or executing as a whole, including the ability to flash a set of images prior to rebooting the host CPU i.e. due to security modes being enabled if a reset occurs before all images have been programmed https://github.com/zephyrproject-rtos/zephyr/issues/50421

Other related issues which benefits Sysbuild:

• 53706

[danieldegrasse]

41697 tracks the use case required for #41579, namely the requirement to share information about a secondary image with a primary image in order to enable the primary core image to copy the secondary image from flash to ram

[hubertmis]

I would like to clarify a little the use-cases described as

• Building and flashing of a multi-core SoC where both images are Zephyr based, for example: ipc/openamp

There are some samples in the Zephyr tree which by design can run only on multi-core SoC (like linked openamp samples). However, most of the available samples can run on single-core or multi-core SoCs. When these samples run on multi-core SoC, some require one image, other more.

For example net/sockets/echo_client requires two images if it is configured to use 802.15.4 radio on nRF53 SoC. If you build this sample, you must manually prepare, build, and flash matching configuration of boards/nrf/ieee802154/802154_rpmsg. Similarly, if you build any Bluetooth sample for nRF53, you must manually prepare, build, and flash matching configuration of bluetooth/hci_rpmsg to run on the Net core.

I would like multi-image builds to be able to catch such multi-core dependencies and automatically configure and build appropriate child images like:

• if CONFIG_BT on CONFIG_SOC_NRF5340_CPUAPP then build _hcirpmsg
• if CONFIG_IEEE802154 on CONFIG_SOC_NRF5340_CPUAPP then build _802154rpmsg
• if CONFIG_IEEE802154_2015 on CONFIG_SOC_NRF5340_CPUAPP then enable CONFIG_NRF_802154_ENCRYPTION for _802154rpmsg build
• if CONFIG_BT and CONFIG_IEEE802154 on CONFIG_SOC_NRF5340_CPUAPP then trigger build error - cannot generate matching child image

Would such child-image configuration/build helper fit in scope of multi-image building initiative?

[tejlmand]

I would like multi-image builds to be able to catch such multi-core dependencies and automatically configure and build appropriate child images like: ... <cut specific examples> ... Would such child-image configuration/build helper fit in scope of multi-image building initiative?

yes, this should definitely be considered, albeit probably in a slightly adjusted way than the specific example given.

For example, it must always be possible for a user to decide not to build a given image. Even though a user enables CONFIG_BT in application on nRF5340, it could be that the user wants a different child image which provides similar functionality and thus choose not to use hci_rpmsg. Oone option in this regard could be to provide default images that can ensure a proper image for secondary cores while allowing user to still disable. This must of course be combined with a mechanism for a sample to request certain conditions to be met, else a build / configuration failure to be raised.