Why is MCUboot scratch algorithm disabled on Thingy:91?

Question

The original firmware for Thingy:91 in version 2019-11-29_d3130d77 and earlier, included MCUboot configured to use the scratch partition for swapping the firmware images. 
 Since version 2020-04-29_bc7ade8b, the default MCUboot version no longer does this, instead using the generic "move" algorithm - even though a 120KiB scratch partition is still reserved in the static partition layout. 
 Is it by design, or is this a bug? When distributing e.g. open source projects intended to run on the Thingy:91, it creates a problem - the published application shouldn't require an external debug probe to work, and if FOTA functionality is desired, then one would need to make sure that the application doesn't fill up the entire partition, so that the "move" algorithm can work. And in either case, without modifying the partition layout (which I believe is discouraged for the Thingy), the 120 KiB of the flash memory just go to waste and are not used for either MCUboot, the app image, or storage space. 
 Of course I can build my own version of MCUboot that uses the scratch algorithm, but that won't be usable by people who don't have access to an external debug probe. 
 Is there something that I'm missing? Could you comment on this issue?

Sigurd Hellesvik · Accepted Answer

kFYatek said: ..so I cannot be sure about what's going on - but the PR also doesn't seem to address the fact that the mcuboot_scratch partition is there defined in nrf/boards/arm/thingy91_nrf9160/thingy91_pm_static.yml , yet it is not used for anything - unless I'm missing something. It seems to me that it would make sense to either use the "scratch" algorithm, after all, or reallocate this space for other purposes. 
 Ah, I missed that part of the question. 
 It is not clear in our bootloader docs, so I have both given internal feedback to add this there, and created a PR to give users a warning. But from our partition manager docs : 
 "However, if you have a deployed product that consists of multiple images, where only a subset of the included images can be upgraded through a firmware update mechanism, the upgradable images must be statically configured." 
 To translate this, it means that if you use only MCUboot, you can not change partitioning between updates, as this may break DFU for future updates. This is because when the device is first flashed, MCUboot knows only the old partitioning and assumes that this is where all future partitions will be swapped from/to. So if the application then tries to write updates to other places in memory, things may break. 
 If I were to guess, this is the reason for the static partitioning: So that the updates will be valid for both old and new versions of the thingy. 
 If you want to update the partitioning, you must program the Thingy:91 with an external debugger (or DK). 
 Regards, Sigurd Hellesvik

Sigurd Hellesvik · Answer

The move algorithm has less flash wear than the skratch algorithm. 
 See https://www.youtube.com/watch?v=KFgK3TRDNR4 
 Regards, Sigurd Hellesvik

Sigurd Hellesvik · Answer

kFYatek said: commercially available Thingy:91 units are generally expected to be flashed with the latest firmware available at the time of manufacturing, is that right? 
 Generally, but there may be some lag here. 
 kFYatek said: So I cannot assume that MCUboot on any unit straight from the factory will use either the "move" or "scratch" algorithm? 
 Correct. I guess this is also a bonus when the partitioning is the same, as you can treat both the same. 
 kFYatek said: I can't say that I'm particularly happy that the 120 KiB originally reserved for a scratch partition are now basically unusable without repartitioning the device, but if that's intentional, then I guess it is what it is. 
 I understand that. 
 If it is to some consolidation, you can use our nRF9160DK or nRF5340DK to program the Thingy91, which lets you repartition. 
 Regards, Sigurd Hellesvik

Why is MCUboot scratch algorithm disabled on Thingy:91?

Top Replies