boot: bootutil: swap_scratch: Fix compressed image sector size check #2085
Conversation
Fixes an issue with compressed update support whereby it would wrong continue to check all sector sizes and error due to the sector sizes of the secondary slot being 0 until overflow Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
…tor size check Fixes an issue with compressed update support whereby it would wrong continue to check all sector sizes and error due to the sector sizes of the secondary slot being 0 until overflow Upstream PR: mcu-tools/mcuboot#2085 Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
|
Missed this in the log: |
…tor size check Fixes an issue with compressed update support whereby it would wrong continue to check all sector sizes and error due to the sector sizes of the secondary slot being 0 until overflow Upstream PR: mcu-tools/mcuboot#2085 Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
| size_t sector_size = boot_img_sector_size(state, BOOT_SECONDARY_SLOT, j); | ||
|
|
||
| #ifdef MCUBOOT_DECOMPRESS_IMAGES | ||
| if (sector_size == 0) { | ||
| /* Since this supports decompressed images, we can safely exit if slot1 is | ||
| * smaller than slot0. | ||
| */ | ||
| break; | ||
| } | ||
| #endif | ||
| sz1 += sector_size; |
There was a problem hiding this comment.
Should we even have a full run of the function boot_slots_compatible when decompression is enabled? It seems that we are going to ignore the difference anyway, so we could just skip the check at all.
There was a problem hiding this comment.
Slot 0 should still be larger than slot 1, plus it can be possibly enhanced in future if only some slots support compression
There was a problem hiding this comment.
OK.
Note for the future: for devices that have uniform erase block size and block sizes that equal for partitions, if the are placed on different devices, we should figure out compile time check for this.
Fixes an issue with compressed update support whereby it would wrong continue to check all sector sizes and error due to the sector sizes of the secondary slot being 0 until overflow