bootutil: Add support for devices without erase #2114
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
14 times, most recently
from
bedea40
to
cf8def0
Compare
The commit adds two MCUboot configuration options: - MCUBOOT_DEV_WITHOUT_ERASE_THEN_NO_ERASE - MCUBOOT_MINIMAL_SCRAMBLE The first one should be enabled to support devices that do not require erase. When such devices are used in system then MCUboot will avoid erasing such device, which is not needed by hardware, and will just write data to it. This allows to both improve device lifetime and reduce time of operations like swap. The second option allows to reduce amount of removed data. When enabled, MCUboot will remove enough of data, depending on the purpose of the removal, to just fulfill the purpose; for example if removal of data is done to make image unrecognizable for MCUboot, with this option, it will only remove header. Signed-off-by: Dominik Ermel <[email protected]>
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
from
cf8def0
to
03ac085
Compare
Add Kconfig options:
- CONFIG_MCUBOOT_STORAGE_NO_UNNEEDED_ERASE that enables MCUboot
configuration MCUBOOT_DEV_WITHOUT_ERASE_THEN_NO_ERASE
- CONFIG_MCUBOOT_STORAGE_MINIMAL_SCRAMBLE that enables MCUboot
configuration MCUBOOT_MINIMAL_SCRAMBLE
Adds implementation of flash_area_erase_required, which is required when
MCUBOOT_DEV_WITHOUT_ERASE_THEN_NO_ERASE is enabled.
Signed-off-by: Dominik Ermel <[email protected]>
The intention of bs_custom_storage_erase is to remove data from device; to support devices that do not require erase, without calling erase, so that devices that do not implement such functions could work, the flash_area_erase has been replaced with flash_area_flatten. Signed-off-by: Dominik Ermel <[email protected]>
Switch from using flash_area_erase to flash_area_flatten. The later function uses write on devices that do not have erase by design, to scramble data. Signed-off-by: Dominik Ermel <[email protected]>
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
from
03ac085
to
b96fe4a
Compare
nordicjm
reviewed
Nov 18, 2024
| int boot_erase_region(const struct flash_area *fap, uint32_t off, uint32_t sz); | ||
| /* SImilar to boot_erase_region but will alwasy remove data */ |
Comment on lines
+1228
to
+1239
| uint8_t buf[BOOT_MAX_ALIGN]; | ||
| size_t size_done = 0; | ||
|
|
||
| memset(buf, flash_area_erased_val(fa), sizeof(buf)); | ||
|
|
||
| while (size_done < size) { | ||
| ret = flash_area_write(fa, size_done + off, buf, sizeof(buf)); | ||
| if (ret != 0) { | ||
| break; | ||
| } | ||
| size_done += sizeof(buf); | ||
| } |
There was a problem hiding this comment.
this just assumes max align will not overflow the size but makes no checks to ensure that, it should reduces buffer on final write to ensure it does not overflow
There was a problem hiding this comment.
Yes, that was intentional as I have assumes that MCUboot should write at BOOT_MAX_ALIGN pace anyway, but maybe that should be fixed.
| } else { | ||
| size = MAX(sizeof(((struct image_header *)0)->ih_magic), | ||
| BOOT_MAX_ALIGN); | ||
| size = (size + BOOT_MAX_ALIGN - 1) & ~(BOOT_MAX_ALIGN - 1); |
There was a problem hiding this comment.
This should do the same for footer data because it might contain swap status or mcuboot flags for swapping images and those should always be cleared
There was a problem hiding this comment.
Ah right, header and slot trailer are verified separately.
Comment on lines
+856
to
+858
| The same can be achieved with just removal of header, leaving the | ||
| rest of image untouched, as without header MCUboot will not be able | ||
| to recognize image in slot as bootable. |
Comment on lines
+551
to
+553
| #if !defined(CONFIG_MCUBOOT) && defined(__ZEPHYR__) | ||
| flash_area_flatten(fa, 0, flash_area_get_size(fa)); | ||
| #else |
There was a problem hiding this comment.
think it was mentioned in a previous PR that OS specific code should not be present in here
There was a problem hiding this comment.
I can fix that although MCUboot has significant problem where we are coupled with Flash Map API which means that this has to be replaced with a function that is implemented for every supported system. I will figure way around.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Commits:
The first MCUboot option allows to improve life time of devices for which erase is emulated by write, and is not really required by the device design and the second MCUboot option allows to just remove enough of data, where needed, by either reduced range of erase or reduced write; for example by scrambling only image header, rather than removing the entire image.
Tested on nrf52840dk and nrf54l15. In case of nrf54l it reduces swap time by half, in comparison to code using erase.