boot_set_next BOOT_MAGIC_BAD case

[ofirshe]

Hi,

I have a question regarding the behavior of boot_set_next() when handling the BOOT_MAGIC_BAD case. Specifically, when MCUBOOT_BOOTUTIL_LIB_FOR_DIRECT_XIP is not defined, the function erases the entire slot by calling:
flash_area_erase(fa, 0, flash_area_get_size(fa));
I'm trying to understand whether a full erase is actually necessary at this point. Wouldn’t this condition later be detected by boot_validate_slot(), which would then invoke boot_scramble_slot() as part of the recovery logic?

If the erase is still required here, could we consider applying the same enhancement added in loader.c - using boot_scramble_slot() added by @de-nordic? This would help avoid the time and wear associated with full-slot erasure, preserving device endurance and improving boot-time latency.

Thanks,
Ofir.

[de-nordic]

Probably, when the BOOT_MAGIC_BAD is met then we do not really have to erase slot, we can just do nothing; as you have said, the boot_validate_slot will do the same thing. Although we should probably just leave he image and ignore it till something new is written over it.

The scramble function has been added, in MCUboot, to cover a case where MCUboot tries to remove data and will do that by write on devices without erase and by erase on devices that do have erase; so scramble will still do -1 to a device life, the difference is that it will do that only in limited range, but still the most worn down range determines life of a device in the end.

[ofirshe]

Thanks @de-nordic. I've created a PR that removes this erasure.