RFC: Decrease boot time for multi-core system

[ozersa]

What? Multi-core heterogeneous devices integrate multiple processing cores, often with different architectures or capabilities. Each core typically runs its own dedicated firmware, tailored to its specific function. To ensure system integrity and proper initialization, the primary core (sometimes called the master core) is generally responsible for:

• Validating firmware images for all secondary cores.
• Loading and starting the firmware on these cores in the correct sequence.
• Managing inter-core communication and synchronization during boot.

This mechanism ensures secure and reliable startup across all cores in complex embedded systems.

Problem? Depending on the number of cores in the device, multiple signature checks are required, which increases the overall boot time. A long boot time could become a significant issue for the product.

Proposed Solution

Combine all individual images into a single composite image. The main core will copy this combined image into RAM (assuming sufficient RAM capacity), then perform a single validation step. This approach leverages the default MCUboot RAM load mode. After the signature check, the sub-images will be distributed to their respective target addresses based on the header information.

PR that containing proposed solution: https://github.com/mcu-tools/mcuboot/pull/2465

[ozersa]

For this case does it sounds good if imgtool be extended to sign multi images, instead adding a python wrapper to sign each images as combine_images.py. The image tool command might be as "multisign" in here: https://github.com/mcu-tools/mcuboot/blob/main/scripts/imgtool/main.py#L629 ?

[nordicjm]

As posted in the PR that was opened:

Here are some links with things for you to study:

* https://docs.mcuboot.com/design.html#image-format (the whole document, and other pages on the doc site)

* https://docs.mcuboot.com/encrypted_images.html

* https://github.com/mcu-tools/mcuboot/blob/main/boot/bootutil/include/bootutil/image.h#L167

* https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/dfu/img_util/flash_img.c#L26

* https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/dfu/boot/mcuboot.c

* https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt.c

* https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c

* https://github.com/apache/mynewt-mcumgr/tree/master/cmd/img_mgmt (the original MCUmgr code)

From there I suggest you look into things like the image structure, the fields in the image header, how image identification works, how image updates and uploads work. Then bearing in mind the following requirements:

* System should not break how existing bootloaders work or cause them to malfunction

* MCUboot header size shall not be changed

* MCUmgr support must be maintained including support for existing builds of firmware and new firmware should not break how it functions on those devices

* Information available for things like where images should be loaded must not be buried part the way through firmware

* Other features should remain fully functional and remain secure e.g. monotonic counter support, encrypted image support

* Feature should be usable (not that support needs adding for it in the addition PR, but that support _could_ be made to other RTOS's if other users wanted to) on any RTOS/OS

* Be mindful that MCUboot should be optimised for constrained devices and not use excessive flash/RAM, not that usage cannot increase but it should not increase by a large amount that prevents usage on commonly supported (and used) devices

With the above in mind, please have a think and update your RFC with your proposed solution for this which meets the above requirements and I shall review it, thanks!