Before:
The cache won't be disabled when XIP on psram. But during flash
erasing/programming, read data will be courrupt.
When XIP in psram is enabled, the image is not mapped to the cache so
usually there will be no flash access. The only way to read from flash
is via the driver or use mmap. The driver has protection during erasing,
while th mmap region not.
Now:
Mmap APIs provide a flag to make mmap->unmap region mutually exclusive
to flash erase/programming when XIP from psram. SPI Flash write APIs
will benefit from this. When the flag is used, no concurrent access to
mapped region will happen while writing; otherwise the cache will be
disable to avoid data corruption.
Most ESP-IDF APIs calls mmap with this flag. As for users calling
mmap-like APIs directly, they can choose whether to enable this by a
flag.
Closes https://github.com/espressif/esp-idf/issues/14897
ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
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.
Recovery bootloader support increased the ESP32-P4 bootloader image enough
that it no longer fits before 0xe000. Moving the partition table to 0x10000
restores slack for CI builds using secure boot and flash encryption together.
Co-authored-by: Cursor <cursoragent@cursor.com>
test(ci): re-enable ESP32-H4 in core system test apps
Closes IDF-15602, IDF-15604, IDF-15605, IDF-15606, and IDF-15612
See merge request espressif/esp-idf!48454
feat(esp_hw_support): support esp32s31 lowpower features
Closes IDF-5660, IDF-14643, IDF-14645, IDF-14647, IDF-14648, IDF-14784, PM-708, and PM-714
See merge request espressif/esp-idf!47216
fix(ulp/lp_core): fix LP UART data_bits validation and add full word-length test coverage
Closes PM-715, PM-660, IDFCI-10410, and IDFCI-10464
See merge request espressif/esp-idf!47432
Add LP SPI HAL LL layer for ESP32-S31 and ESP32-P4, enable the
peripheral in soc_caps, and port the HP-side and LP-core-side SPI
drivers to use the new LL abstraction.
Several LP core pytest files were either hardcoded to specific chip lists
or using a less-precise SOC capability filter:
- test_lp_core_multi_device: was locked to ['esp32c6'] pending a workaround
for LP I2C on esp32p4; all three active LP core chips now have
SOC_LP_I2C_SUPPORTED=1, so switch to soc_filtered_targets.
- test_lp_uart_wakeup_modes: was using SOC_LP_CORE_SUPPORTED which is
semantically wrong for a UART test; change to SOC_ULP_LP_UART_SUPPORTED.
- LP core example pytests (build_system, interrupt, gpio_intr_pulse_counter,
lp_timer_interrupt): replace hardcoded ['esp32c5', 'esp32c6', 'esp32p4']
with soc_filtered_targets('SOC_LP_CORE_SUPPORTED == 1') so that new
chips automatically get coverage when their SOC cap is enabled.
fix(otatool): fix flaky serial port handoff in otatool CI test
Closes IDFCI-3263, IDFCI-3302, IDFCI-3402, IDFCI-3410, IDFCI-4548, IDFCI-5191, IDFCI-6937, and IDFCI-7329
See merge request espressif/esp-idf!47318
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
