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
15 times, most recently
from
cf8def0 to
03ac085
Compare
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
from
03ac085 to
b96fe4a
Compare
nordicjm
reviewed
Nov 18, 2024
boot/bootutil/src/bootutil_priv.h
Outdated
| 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 */ |
boot/bootutil/src/loader.c
Outdated
Comment on lines
1228
to
1235
| 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.
boot/bootutil/src/loader.c
Outdated
| } 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
+873
| 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. |
boot/bootutil/src/bootutil_public.c
Outdated
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.
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
from
b96fe4a to
269f9e2
Compare
de-nordic
requested review from
almir-okato,
romanjoe and
d3zd3z
as code owners
|
Converting to draft; after significant changes I need to re-test this on devices. |
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
4 times, most recently
from
75494c5 to
5a405e7
Compare
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
7 times, most recently
from
d2fecc0 to
693327f
Compare
The commit adds two MCUboot configuration options: - MCUBOOT_SUPPORT_DEV_WITHOUT_ERASE - MCUBOOT_SUPPORT_DEV_WITH_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 is just bringing a configuration option for already existing support for deviceses with erase. The third 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 <dominik.ermel@nordicsemi.no>
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
from
693327f to
cec59f0
Compare
Add Kconfig options:
- CONFIG_MCUBOOT_STORAGE_WITHOUT_ERASE that enables MCUboot
configuration MCUBOOT_SUPPORT_DEV_WITHOUT_ERASE
- CONFIG_MCUBOOT_STORAGE_WITH_ERASE that enables MCUboot
configuration MCUBOOT_SUPPORT_DEV_WITH_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_STORAGE_DEV_WITHOUT_ERASE is enabled.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
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 <dominik.ermel@nordicsemi.no>
By default enable all other systems to work with devices that require erase prior to write. Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
Getter for sector size stored in flash_sector object. Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
de-nordic
force-pushed
the
improve-no-erase-device-time
branch
from
cec59f0 to
8b23727
Compare
de-nordic
added
area: zephyr
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:
- Zephyr: switch to boot_set_next, from flash_area_erase, for Zephyr builds of bootutil_public.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.
Note: Even though, finally,
swap_erase_trailer_sectorsis no longer used, I have left it there because it may be used in the future.I have left a Note around
swap_status_initfunction, that partially corresponds to this; it seems that in many places call toswap_scramble_trailer_sectors, whee followed byswap_status_init, should in reality beswap_erase_trailer_sectorsfulfilling hardware requirement for preparing device for write; the problem is thatswap_status_initinitializes only part of swap information, which means that if the region of entire swap info is not scrambled first, leftovers may lead to improper behaviour, for example test will not revert.There is re-design of
swap_status_initrequired to mitigate this, as in some paths the whole "init" may just mean removal of everything except information thatswap_status_initwould put there anyway, or combined init operation that would first remove no longer needed information than overwrite what should be re-initialized - but this requires further analysis.So far this PR works fine on devices that do not require erase as well as these that require erase before write.