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?

[Vidar Berg]

Hi,

The size of the primary slot is defined by the PM_MCUBOOT_PRIMARY_SIZE symbol in pm_config.h which is generated by the partition manager during the build.

Fixing this issue is still in our backlog. I’ve requested that we prioritize addressing it so you can receive a build time error if the image will exceed the maximum size for the secondary slot. As you may know, the reason the FW image can't fill the whole partition is that we need to leave room for the image trailer at the end. 

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.

The percentage will vary depending on the size of the partition. Larger partitions can have utilization above 95%

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

This was to account for any changes in the image trailer size. For example, the image trailer becomes larger if encryption is enabled. The best way to verify that there is enough room for the image trailer with your configuration is to test the DFU of the image locally before distributing the update. If the image is too large, the bootloader will fail to copy the update to the primary slot. It is also important that you are using the same static partition layout across FW versions (Configuring static partitions)

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?

The planned fix is to calculate the actual space available for the firmware image at build time and provide the user with an error if the image is too large for DFU.

Best regards,

Vidar

[variant]

Thanks Vidar for the very detailed and clear reply.
I will have a follow-up question on your answer shortly.  I haven't had a chance to research something yet, but I wanted to get the thank you sent now.

[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.

[variant]

Is there going to be any reply from Nordic?

[Vidar Berg]

Sorry, I assumed the questions got answered by Dominik-NS  comments above. He is a Nordicer who is working on MCUBoot. Could you upload the configuration file (build/mcuboot/zephyr/.config) for your bootloader so I can have a look at the configuration?

[variant]

Thanks for the reply Vidar Berg . And I apologize Dominik-NS that I didn't realize you were replying as a Nordic rep. Your reply was very detailed, but I wasn't sure it was sanctioned by Nordic. 
Attached is the build/mcuboot/zephyr/.config file that Vidar suggested I post.

Thanks again.

.config_for_mcuboot.txt

[Dominik-NS]

I think we are mistaking binary with mcuboot image, these are different things:

the top one is binary, that is the thing build logs size form; the bottom one is image, that is uploaded to the device.
Once your image is signed there is additional information added to it, and build log does not show that info.
For experiment I have appended my binary with enough data to fill, after signing, entire slot - 2 * 4096 bytes, and that worked fine. But I have been using equal slot sizes, that is why I have to subtract on slot for move area and one for trailer rounded up to one slot.
In primary slot trailer may not be written in the same page as the swapped in image is.

In secondary slot trailer may be written to the same page as uploaded, because there is no "move" page between trailer and image.
The move page needs to be erased independently, so it can not be either part of image nor trailer.
But that image will be swapped to the primary slot, and at that point that slot has to be able to

It seems that you have CONFIG_BOOT_MAX_IMG_SECTORS=256, the nrf5340 has a 4096B page and 4B write block, 974848 primary slot.

The 974848 takes 238 slots, so 238 * 3 * 4 + 80 = 2936 ~= 4096
So primary slot can take max 974848  - 2 * 4096 = 966656

Please check your PM_MCUBOOT_SECONDARY_SIZE, because it seems that this is significantly shorter. The trailer equation will only work with the secondary slot, because here the trailer can touch the last page of binary, something it can not do in primary slot.