DRAFT: ESP32-XX hardware flash encryption issue when updating images - "bootutil layer" solution #2321
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.
bootutil: add MCUBOOT_FLASH_HAS_HW_ENCRYPTION config-condition
MCUboot's state machine relies on erased valued data (e.g. 0xFF) readed from this erased region that could be not written before, however if the flash device has hardware flash encryption and its flash read operation always decrypts what is being read from flash, thus a region that was erased would not be read as what MCUboot expected (after erasing, the region physically contains 0xFF, but once reading it, flash controller decrypts 0xFF to something else).
So this configuration force the erased value into the region after the erasing the trailer regions, and also make an erase operation before writing trailers.
NOTE that for other ports, this configuration needs to be added, and flash implementation of
flash_area_erase
must be able to erase unaligned regions (could be through software algorithm).Use Zephyr branch from this PR:
zephyrproject-rtos/zephyr#90442
Use hal_espressif branch from this PR:
zephyrproject-rtos/hal_espressif#446
Prepare and enable Flash Encryption on ESP32-S3 (the conf files are already modified on the used branches):
Building the sample application on Zephyr:
west build -b esp32s3_devkitm/esp32s3/procpu -p -- -DEXTRA_CONF_FILE="overlay-bt.conf"
build/zephyr/zephyr.signed.confirmed.bin
) can be used for testing the scenario in which an image is already confirmedBuilding and flashing MCUboot:
(MCUBOOT_DIR should be the directory from Zephyr environment:
<ZEPHYRPROJECT_DIR>/bootloader/mcuboot
)