Unconditional erase of trailer sector in serial recovery

[jomigo96]

With MCUBoot in serial recovery, and with MCUBOOT_ERASE_PROGRESSIVELY, it seems that the last flash sector is unconditionally erased after the full image is received, causing the slot to be invalid if there was image data in that sector.

In this section from boot_serial.c

            /* Assure that sector for image trailer was erased. */
            /* Check whether it was erased during previous upload. */
            off_t start = flash_sector_get_off(&status_sector);

            if (erase_range(fap, start, start) < 0) {
                rc = MGMT_ERR_EUNKNOWN;
                goto out;
            }

The comment appears to indicate that it should check if the sector was already erased, but no such check is done.

Is this unintended, or does this mean that the last sector cannot have image data? I'm using a swap with scratch configuration.

[thedjnK]

This is expected, the MCUboot swap status goes there. An MCUboot image should be your whole image i.e. the hex/bin file, which then goes through imgtool to add the MCUboot header and footer, at this point that is the final image that cannot be changed, you cannot append data to the end of it. If you want to do that, you need to edit the hex/bin file before it is passed to imgtool

[jomigo96]

By image data I did not mean any modifications to the binary after imgtool, just the normal binary.

Let's say the image slot is 896 KiB with flash sectors of 128KiB. I observe that if the signed binary is larger than 768KiB, after upload this last sector is erased. Since it would have data/tlvs, the image is invalid. The same binary is working fine if flashed via debugger or uploaded without MCUBOOT_ERASE_PROGRESSIVELY.

[nordicjm]

Let's say the image slot is 896 KiB with flash sectors of 128KiB. I observe that if the signed binary is larger than 768KiB, after upload this last sector is erased. Since it would have data/tlvs, the image is invalid. The same binary is working fine if flashed via debugger or uploaded without MCUBOOT_ERASE_PROGRESSIVELY.

This is incorrect, there is the TLVs which are part of the image, they do not go in a new sector. There is a new sector(s) which is/are used for the swap status, this should be visible on https://docs.mcuboot.com/design.html but the website is down at present for some reason

[jomigo96]

there is the TLVs which are part of the image, they do not go in a new sector

Not a new sector, but in the last sector of the slot due to the size of the binary requiring it.

There is a new sector(s) which is/are used for the swap status

But is it exclusively for swap status? The design page only mentions

Note: Be aware that the image trailers make the ending area of the image slot unavailable for carrying the image data. In particular, the swap status size could be huge. For example, for 128 slot sectors with a 4-byte alignment, it would become 1536 B.

I was under the impression that it needs space for swap information, but this is controlled by MCUBOOT_MAX_IMG_SECTORS and the remaining space could be image data.

[nordicjm]

That Kconfig is the maximum number of sectors that will be searched and are supported (i.e. controls how large the swap field size will be), the size is limited by the partition size, so you can set that Kconfig to 5000 but with a 4KiB sector size and only 20 sectors in the partition, the 5000 value will just waste flash space, it will never go beyond 80KiB.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.