Fixing the "known issue" Partitioning limitation with MCUboot swap move

[variant]

The subject issue is documented here as "NCSDK-20567: Partitioning limitation with MCUboot swap move":


This issue has been open for while. 

These two DevZone tickets refer to this issue and mention the impact is that you can use only around 95% of the flash space:
1. https://devzone.nordicsemi.com/f/nordic-q-a/112343/mcuboot-image-in-the-primary-slot-is-not-valid-unable-to-find-bootable-image

2. https://devzone.nordicsemi.com/f/nordic-q-a/107599/mcuboot-sign-image-possible-wrong-slot-size/475558

Here are my questions:

1. In the Workaround description, there is a formula to calculate the approximate size limitation. What CONFIG item is referred to for mcuboot_primary_size?  I am not able to figure out how to use that equation to result in a value of approximately 95% of the "Region Size" for the application image indicated in the build log.

2. Why is "additional" margin suggested?  Can that margin be quantified?

3. Are there still plans to fix this?  A lot of internal flash space seems to be wasted due to this issue.

4. When the fix is available, do you think the fix can be patched by us to an earlier NCS version, such as NCS 2.6?

[Dominik-NS]

Hi,

The BOOT_MAX_IMG_SECTORS is actually mentioned in NCSDK-20567, as CONFIG_BOOT_MAX_IMG_SECTORS, and how it weights against (image_slot_size_in_bytes - erase_page_size_in_bytes) / erase_page_size_in_bytes. Unfortunately I did calculations from the point of hardware to software impact and so there was no clear indication how the BOOT_MAX_IMG_SECTORS  impacts calculations, as a software configuration item.

The BOOT_MAX_IMG_SECTORS  does indeed impact size of footer. It is mainly used, in MCUboot, to calculate log size and to allocate array of sectors (erase units on device) (as explained in NCSDK-20567)

Internal details are below, if interested.

The first usage is done here boot_status_internal_off (note that this is unfortunate name for a partial offset, not full offset from the end of slot):
https://github.com/nrfconnect/sdk-mcuboot/blob/b82206c15fff357c151c24bf97c99c4348d14a46/boot/bootutil/src/swap_move.c#L221 (for MOVE algorithm, SCRATCH has own function for that) - basically the function is called given write-block-size of a device (elem_sz) and calculates log for 3 states (BOOT_STATUS_MOVE_STATE_COUNT) per page/sector moved (BOOT_MAX_IMG_SECTORS).
Above can also be seen in swap_read_status_bytes https://github.com/nrfconnect/sdk-mcuboot/blob/b82206c15fff357c151c24bf97c99c4348d14a46/boot/bootutil/src/swap_move.c#L204 when calculating maximum expected log entries, without footer "header" (that is why it is "partial").

The other usage is in allocating table for sector information; the array is used to store information on offset and size of each sector that covers slot - this happens, because MCUboot has been designed with devices with non-uniform sector layout, like stm32, where each sector can have different size, https://github.com/nrfconnect/sdk-mcuboot/blob/b82206c15fff357c151c24bf97c99c4348d14a46/boot/bootutil/src/loader.c#L96.
The BOOT_MAX_IMG_SECTORS needs to be provided by user, because it is not always possible to get that info from DTS, for example spi devices do not have such info and so far non-uniform devices have no such definition.

Regards,
Dominik

[Dominik-NS]

One more update.

As it may be tempting to set the BOOT_MAX_IMG_SECTORS to (image_slot_size_in_bytes - erase_page_size_in_bytes) / erase_page_size_in_bytes, it would not be correct.
The BOOT_MAX_IMG_SECTORS needs to be set to highest of image_slot_size_in_bytes / erase_page_size_in_bytes of two values, assuming two slots may have different sizes, as it has to hold information on layout for both slots, as we will erase any page in the slot range.

So in reality, after the BOOT_MAX_IMG_SECTORS  has been established, the trailer itself, can be calculated as
(((BOOT_MAX_IMG_SECTORS * write_block_size) * 3 + 80.

But aside from the above value, the image will also loose one additional page for the "move" page.