I'm working on integrating MCUBoot with an application that uses MCUBOOT_SWAP_USING_MOVE (i.e., swap without a scratch sector). I'm running into confusion with how the image trailer and flash padding are handled.
My question resolves around value of padding:
https://github.com/nxp-mcuxpresso/mcux-sdk-examples/blob/main/evkmimxrt1170/ota_examples/ota_mcuboot...
In my setup:
The primary slot is at 0x30100000, and the secondary is at 0x30200000.
Each slot is exactly 1 MiB (0x100000), sector-aligned (I store M7 core at first 500KiB and M4 at second 500KiB).
BOOT_FLASH_PADDING_SIZE was originally set to 4096 to reserve a sector for swap-move, but I had to set it to 0 to make things work.
The problem:
MCUBoot expects the image trailer (magic, image_ok, copy_done, etc.) at the end of the slot, which should be the last bytes of the configured flash area.
But when I subtract BOOT_FLASH_PADDING_SIZE from the slot size (as often seen in examples), it seems the trailer ends up outside the defined flash area, and the bootloader can't find the magic.
At the same time, the MCUBoot documentation says the padding (extra sector) is needed for the swap-move process.
I'm using imgtool to sign images, and it pads them up to the full slot size, including the trailer.
Questions:
If I set padding to 4096, the xmodem transfer fails (as expected - binary is larger than area size due to padding subtraction). Similarly even if i flash the binary the bootloader will still fail to find it because binary would be trimmed by padding sector.
If I set padding to 0, it works — but am I violating the swap-move requirements?
How should I correctly define the flash area and padding in this mode so that both:
the bootloader sees the trailer in the right spot,
and the swap-move algorithm has the extra sector it needs?
Is it safe to keep padding at 0 and simply assume that both primary and secondary slots are equal size and let the swap use space inside the primary slot?
Thanks in advance — this seems like a common area of confusion and I want to ensure I’m not missing something subtle that will break updates later.
Solved! Go to Solution.
Hi @jslota13245
This is a historical macro BOOT_FLASH_PADDING_SIZE, which has been removed from other chips. Please set it to 0, it should be workable.
B.R,
Sam
Hi @jslota13245
This is a historical macro BOOT_FLASH_PADDING_SIZE, which has been removed from other chips. Please set it to 0, it should be workable.
B.R,
Sam