ECDSA based Secure Boot V2 is not functional for certain input vectors on
ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure
Boot V2 is the recommended scheme where the SoC supports it. This issue will be
fixed in a future hardware ECO revision; more details will be shared through the
hardware errata document.
A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected
mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure
Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by
default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App
signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no
RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default.
The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not
supported in their SoC capabilities instead of using the option above. As
ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on
it; ESP32-H21 retains RSA based Secure Boot V2.
The security documentation keeps the ECDSA Secure Boot V2 content visible and
adds a warning describing the limitation (including that ECDSA Secure Boot V2 on
ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure
Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
accordingly.
The otatool pytest calls dut.serial.close() and then immediately
launches otatool_example.py as a subprocess that re-opens the same
serial port via esptool. This fails intermittently because:
1. pytest-embedded's QueueFeederThread still holds a reference to
the serial port file descriptor when close() returns, causing
'argument must be an int, or have a fileno() method' error.
2. The OS has not fully released the serial port by the time the
subprocess tries to open it.
Add a delay after serial close and retry logic for the subprocess
to handle transient serial port contention.
Made-with: Cursor
- Modified test for storage data, reduced the size to 500 bytes,
less than IMAGE_HEADER_SIZE (1024), to check the workflow, if the
custom partition other than APP and BOOTLOADER less IMAGE_HEADER_SIZE
performed OTA
This commit also added config option to set default buffer size for OTA.
This testcase mainly checks if OTA resumption fails if data written is
not 16 byte aligned when Flash Encryption is enabled.
Problem:
1. In low-memory scenarios, the dynamic buffer feature can fail due to memory fragmentation.
2. It requires a contiguous 16KB heap chunk, but continuous allocation and deallocation of
the RX buffer can lead to fragmentation.
3. If another component allocates memory between these operations, it can break up the
available 16KB block, causing allocation failure.
Solution:
1. Introduce configurable strategy for using dynamic buffers in TLS connections.
2. For example, convert RX buffers to static after the TLS handshake.
3. Allow users to select the strategy via a new field in the esp_http_client_cfg_t structure.
4. The strategy can be controlled independently for each TLS session.
Due to ci/pytest-mark-formatter(branch) fix, while executing the main
function from the pytest, it gives error for the incorrect idf_path.
This commit ensure that, idf_path is fixed correctly.
This commit have updated check for max chip revision along with min chip revision.
Also added qemu based pytest to verify chip revision while performing OTA.
This commit enabled configurable OTA resumption feature in advanced ota example.
This resumes downloading OTA image from where it left off in case of
an error or reboot.
Closes https://github.com/espressif/esp-idf/issues/13127
1. Remove the pre_encrypted_ota example from the esp-idf as we have
moved this example idf-extra-components repository under esp_encrypted_img
component
2. Added the migration guide for 5.5 release
This commit added config option to enable session ticket support
while performing ota. This helps in optimizing latency while
downloading ota over multiple HTTP requests.
closes https://github.com/espressif/esp-idf/issues/14783
Currently, several example dependencies rely on the fact that all
registered components are added to the build, along with components
specified in common requirements. This results in longer build times
because even unused components must be built. Switch all examples to use
idf_minimal_build to compile only the components actually required by
the example.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, several examples do not explicitly state their component
dependencies, relying instead on the default behavior that includes all
registered components and commonly required ones in the build.
Explicitly adding component dependencies can reduce build time when
set(COMPONENTS main) is used.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Checked the support of OTA features for esp32c5, tested
examples and added the support in README.md file. Even
added the support in systems .build-test-rules.yml
Aditya Patwardhan
Jiang Jiang Jian
Konstantin Kondrashov
hrushikesh.bhosale
Fu Hanxi
Evgeny Torbin
Mahavir Jain
nilesh.kale
Zhang Wen Xu
Tan Yan Quan
Ashish Sharma
Chen Jichang
igor.udot
gaoxu
Marek Fiala
Konstantin Kondrashov
Frantisek Hrbata
zhanghaipeng
wanlei