Sysbuild configuration for a updatable section containing firmware image and meta-data for external component

RE: Sysbuild configuration for a updatable section containing firmware image and meta-data for external component

Vidar Berg — Fri, 17 Jan 2025 17:59:28 GMT

Thanks, I think I have a better understanding of the setup now. MCUboot is generally designed to have one pair of image slots for each firmware image type, which doesn't make sense for the IMU image in this case as it is neither going to be executed or swapped locally. It's made to handle images that are to be run on the same device.

Our MCUboot fork does include patches that allow the main secondary slot to be reused for MCUboot updates when MCUboot is used as a second stage bootloader, and it should of course be possible to add similar modifications to support your requirements.

[quote user="anthony.asterisk"]This seems to be designed around the idea every primary being paired with a corresponding secondary, I suppose so there is always a back-up copy available[/quote]

The CPU will usually be executing code from the primary while the update image is being written to the secondary slot.

RE: Sysbuild configuration for a updatable section containing firmware image and meta-data for external component

Anthony Ambuehl — Wed, 15 Jan 2025 16:44:32 GMT

No the motion fusion IMU does not have NV storage. The firmware gets loaded at every startup. The host interface reports whether firmware has been loaded and some version/hash of the image. If firmware isn't ready or the version/hash don't match the meta data of the image in ext_fw partition, then the driver downloads the data from internal flash to the IMU. The download takes 30-40 seconds so I try to avoid doing it unless needed.

I've made progress in getting mcuboot to swap the main application firmware. I'm implementing this initially with the secondary partitions on the external flash, although this isn't what I really want for the production release.

One issue I ran into was a bit surprising. When performing swap move, mcuboot requires the primary and secondary partition be the nearly the same length, with only the primary being 1 block larger than the secondary. This seems to be designed around the idea every primary being paired with a corresponding secondary, I suppose so there is always a back-up copy available. This isn't the way I was intending to use it. I guess this is necessary because mcuboot doesn't have any information about how much of the secondary partition is actually being used and therefore cannot check if the secondary image would fit into the space of the primary image.

I believe it is possible to make mcuboot work with multiple primaries of different sizes and a single secondary, isn't that how updates work with multiple cores?

RE: Sysbuild configuration for a updatable section containing firmware image and meta-data for external component

Vidar Berg — Wed, 15 Jan 2025 12:57:53 GMT

Does the IMU have NV storage for the firmware, or does it rely on the nRF to load the FW on every boot? Also, does the IMU perform any validation and activation steps for the FW update it receives from the nRF?

RE: Sysbuild configuration for a updatable section containing firmware image and meta-data for external component

Anthony Ambuehl — Tue, 14 Jan 2025 18:38:00 GMT

Well my main reasoning is that mcuboot has the keys and crypto libraries to verify the image, and is trusted to complete the firmware swap correctly. In my other projects guaranteeing the safety and security of firmware updates was extremely high importance.

Also since this external firmware is loaded during the driver initialization process, it would also be necessary to restart the application regardless.

RE: Sysbuild configuration for a updatable section containing firmware image and meta-data for external component

Vidar Berg — Mon, 13 Jan 2025 13:50:25 GMT

Thanks for the clarification. I didn't know bosch had IMUs with their own MCU, so I assumed it was simply a library for the NRF application to process the IMU sensor data.

[quote user=""]What configuration will I need to add for mcuboot to be able to update (one-at-a-time) both the application and the ext_fw partition?[/quote]

This seems like something that should be handled in the application. MCUBoot does not support updating external DFU targets. Or is there a reason you want to do this in the bootloader?

RE: Sysbuild configuration for a updatable section containing firmware image and meta-data for external component

Anthony Ambuehl — Fri, 10 Jan 2025 16:12:46 GMT

The IMU firmware gets downloaded to a processor inside the IMU. It has no linkage with the application. Its similar to modem firmware.

We have external flash, and I will temporarily proceed with using the external flash to reach short term deadlines, but in the long term the end-user application needs the entire flash for the best user experience.

Is there someone at Nordic who can work with me to create a sample with multiple updatable sections?

RE: Sysbuild configuration for a updatable section containing firmware image and meta-data for external component

Vidar Berg — Fri, 10 Jan 2025 14:58:16 GMT

Hello,

We do not have ready support for mutliple app images. If your design already includes external flash, I recommend relocating your secondary partition to this flash. Is the IMU a standalone separately linked application with its own vector table, or is it going to be linked as part of the main application? If it is the latter, it could make sense to have a look at the QSPI XIP split image implementation to see how you can split the app into two separate memory areas.

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/sysbuild_image_ids.html