MCUBoot image trailer and padding conflict in swap-move mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCUBoot image trailer and padding conflict in swap-move mode

Jump to solution
332 Views
jslota13245
Contributor II

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:

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

  2. If I set padding to 0, it works — but am I violating the swap-move requirements?

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

0 Kudos
Reply
1 Solution
287 Views
Sam_Gao
NXP Employee
NXP Employee

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

View solution in original post

0 Kudos
Reply
1 Reply
288 Views
Sam_Gao
NXP Employee
NXP Employee

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

0 Kudos
Reply