OTA update used to fail if `firmware_size == partition_size`, because the code was trying to
erase one additional sector beyond the space reserved for the firmware partition.
This commit fixes the problem and OTA update can work if the firmware
size exactly matches the allocated partition size.
Closes https://github.com/espressif/esp-idf/pull/12460
Added an API to verify the bootloader and app image before revoking the key in Secure Boot V2.
This will help in preventing the device to be bricked if the bootloader/application cannot be
verified by any other keys in efuse
All the partition handling API functions and data-types were moved from the 'spi_flash' component to the new one named 'esp_partition'. See Storage 5.x migration guide for more details
The following two functions in bootloader_support are private now:
* esp_secure_boot_verify_sbv2_signature_block()
* esp_secure_boot_verify_rsa_signature_block()
They have been moved into private header files
inside bootloader_private/
* Removed bootloader_reset_reason.h and
bootloader_common_get_reset_reason() completely.
Alternative in ROM component is available.
* made esp_efuse.h independent of target-specific rom header
This patch modifies the OTA implementation to incremental erase flash sectors
as they are written, rather than bulk erasing them all at once when OTA begins.
This solves several problems:
- The bulk flash erase can take so long that it triggers the watchdog timer.
Disabling the watchdog is an undesirable risk.
- The bulk erase interferes with the responsiveness of the system to user input.
- Incremental erasing eliminates the need to pass the firmware image size to
esp_ota_begin to avoid erasing more flash sectors than required.
- When installing an OTA received via HTTP, the size of the firmware image is
known when the content-length header is received. Calling esp_ota_begin at that
time causes a long delay to do the bulk erase which causes the TCP transfer
speed to be measurably slowed when the transfer resumes after the erase.
Incremental erasing eliminates this TCP slowdown.
Update:
Rework so erase optimization is only applied when image_size is set to
OTA_WITH_SEQUENTIAL_WRITES #5246
Merges https://github.com/espressif/esp-idf/pull/5246
Using xxx_periph.h in whole IDF instead of xxx_reg.h, xxx_struct.h, xxx_channel.h ... .
Cleaned up header files from unnecessary headers (releated to soc/... headers).
1. separate rom include files and linkscript to esp_rom
2. modefiy "include rom/xxx.h" to "include esp32/rom/xxx.h"
3. Forward compatible
4. update mqtt
Added:
* set a secure version in app/bootloader.
* description anti-rollback to ota part
* emulate the secure_version write and read operations
* efuse_em partition.
* a description about a rollback for native_ota_example.
Closes: TW26335
On enabling flash encryption, OTA fails with magic byte error in the second chunk
if the http data is split into two or more chunks and first chunk is less than 16.
Added a new structure esp_app_desc_t. It has info about firmware:
version, secure_version, project_name, time/date build and IDF version.
Added the ability to add a custom structure with a description of the firmware.
The esp_app_desc_t is located in fixed place in start of ROM secotor. It is located after structures esp_image_header_t and esp_image_segment_header_t.
app_version is filed from PROJECT_VER variable (if set in custom make file) or PROJECT_PATH/version.txt or git repo (git describe).
Add API to get app_desc from partition.
Routine `spi_flash_cache2phys` sometimes return incorrect value,
resulting in failure in getting currently running ota partition.
This in turn aborts firmware update process.This issue was more
prominent with SPIRAM enabled cases.
Fix ensures proper cache guards during `spi_flash_cache2phys`, and
also for few other similar APIs.
In addition, `esp_ota_get_running_partition` has also been optimized
to save currently running partition for subsequent invocations.
Fixes https://github.com/espressif/esp-idf/issues/2451
Allows OTA updates to be secured via signature checks, without requiring the overhead or complexity
of a full secure boot implementation.
Uses same signing mechanisms (build system and/or espsecure.py as Secure Boot).
Requires:
* [ ] More testing
* [ ] Documentation
