Zephyr image dependencies / flash dependencies

[tejlmand]

Part of: #41640

When using sysbuild to control multiple images, then it may be necessary to ensure images are CMake configured / build,and flash in a certain order.

In this initial sysbuild implementation, #40555, a dedicated IMAGE variable is used for tracking images and their flash order.

With this improvement, the IMAGE list should be transformed into a general target property in sysbuild (implementation details to be discussed) and the ExternalZephyrProject_Add() should support a DEPENDS argument.

The DEPENDS must ensure that CMake configure is executed for the depends target before the target that specifies such dependency.

For flash order handling it must be possible for a target to specify a FLASH_DEPENDS.
Flash depends targets must always be flashed before the the target which specifies such dependency.

If a target specifies DEPENDS, but not FLASH_DEPENDS, then targets specified using DEPENDS should also be used as FLASH_DEPENDS.

Multi-core SoCs are organized as a set of logical boards in Zephyr, where each core is identified using a board name.
For such boards it must also be possible to define a SoC / interboard flash order.
Sysbuild supports the use of a <BOARD_DIR>/sysbuild.cmake file.
Consider if this file is suitable to use for such description, similar to how boards.cmake are used for creation of the runners.yaml.

In boards v2 it can then be considered if boards.cmake can be defined in a way that is compatible for use by Sysbuild as well as Zephyr CMake build system.

[nordicjm]

For flashing, the flash order is more dependent on the different boards than it is the images of one particular board, e.g. for nrf5340 then the flash order should be: network core, application core secure, application core non-secure. This level of flashing ability is required, without needing images to specify their dependency on other images e.g. smp_svr makes use of bluetooth so needs the hci_rpmsg project for the network core, it also pulls in mcuboot for the application core and, in theory, could pull in mcuboot for the network core in the future - hci_rpmsg cannot have knowledge of smp_svr or mcuboot.

In terms of flashing order at a specific board level, this is really already handled today, e.g. mcuboot prepends to the images list whilst other images append. Unless there is something crucial like a full flash erase in an image (and I would argue that this should actually be removed from mcuboot entirely - if you want to do a full flash erase, there should be a generic west flash argument for it, like there is with the nrfjprog runner. An image should not decide on its own to erase the whole flash of a micro)

[tejlmand]

For flashing, the flash order is more dependent on the different boards than it is the images of one particular board, e.g. for nrf5340 then the flash order should be: network core, application core secure, application core non-secure.

that can also be true, but not the only need.
There may still be images that depends on outcome of other images.
Could be images where an artifact is produced and later consumed by another image (an example can be TF-M).
There can be images which writes special values to register thus locking a device, such image could be required to be flashed last, regardless of board order.

One use-case does not rule out another, so both are needed: image dependencies and inter board flash order / dependencies.

hci_rpmsg cannot have knowledge of smp_svr or mcuboot.

and it should not. It should never setup dependencies to everything, it should only setup a dependency to a specific other image if such a dependency exists.

and I would argue that this should actually be removed from mcuboot entirely - if you want to do a full flash erase, there should be a generic west flash argument for it

there we agree, but that problem is orthogonal to this issue.
The feature in this issue is still needed regardless of whether mcuboot is having this setting or not.

[Laczen]

@tejlmand, I understand that both "dependencies" are required, why not call them:
a. IMAGE_GENERATE_DEPENDENCY: when a image is generated the dependency image already needs to be generated,
b. IMAGE_LOAD_DEPENDENCY: when a image is loaded, the dependency image needs to be in place,

The first is used during image generation, the second during image assembly and flashing.

[nordicjm]

The DEPENDS must ensure that CMake configure is executed for the depends target before the target that specifies such dependency.

This requires introducing a new "hook" for supporting this in modules, at present, the main application is added, then mcuboot (if enabled), so these will need to be swapped to support the DEPENDS argument. Then if that feature is to be expanded by modules, they might want to add a bootloader, but they might also want to add an extra image that depends on e.g. mcuboot, so modules would need to be able to add images at the beginning and at the end. It's then possible that those images might want to add dependencies to normal images - e.g. hello_world, when that image is added (possibly by a callback function) checking if it should add a dependency to mcuboot or another bootloader (or possibly by variable e.g. CORE_BOOTLOADER).