-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bootutil: Add support for devices without erase #2114
base: main
Are you sure you want to change the base?
Conversation
cf8def0
to
03ac085
Compare
03ac085
to
b96fe4a
Compare
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 */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-I+i, *always
boot/bootutil/src/loader.c
Outdated
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, header and slot trailer are verified separately.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
include footer
boot/bootutil/src/bootutil_public.c
Outdated
#if !defined(CONFIG_MCUBOOT) && defined(__ZEPHYR__) | ||
flash_area_flatten(fa, 0, flash_area_get_size(fa)); | ||
#else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
b96fe4a
to
269f9e2
Compare
Converting to draft; after significant changes I need to re-test this on devices. |
75494c5
to
5a405e7
Compare
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 <[email protected]>
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 <[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]>
By default enable all other systems to work with devices that require erase prior to write. Signed-off-by: Dominik Ermel <[email protected]>
Getter for sector size stored in flash_sector object. Signed-off-by: Dominik Ermel <[email protected]>
cec59f0
to
8b23727
Compare
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_sectors
is no longer used, I have left it there because it may be used in the future.I have left a Note around
swap_status_init
function, 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_sectors
fulfilling hardware requirement for preparing device for write; the problem is thatswap_status_init
initializes 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_init
required to mitigate this, as in some paths the whole "init" may just mean removal of everything except information thatswap_status_init
would 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.