Wrap MWDT-related code under SOC_WDT_SUPPORTED so targets without a main
watchdog can compile.
Add SOC_RTC_WDT_SUPPORTED for RTC watchdog usage (bootloader, slow-clock
paths) and regenerate Kconfig.soc_caps.in. Bootloader RWDT setup stays
under SOC_RTC_WDT_SUPPORTED; MWDT flashboot teardown stays under
SOC_WDT_SUPPORTED.
ESP_INT_WDT, ESP_TASK_WDT_EN, and BOOTLOADER_WDT_ENABLE depend on
SOC_WDT_SUPPORTED where applicable. Build xt_wdt.c only when
SOC_XT_WDT_SUPPORTED. Provide no-op panic WDT helpers when
SOC_WDT_SUPPORTED is disabled.
When DMA keep writing the memory, some data may be corrupted after reset. For example, the stack of bootloader may be overwritten and failed to boot until a higher scope of reset (Core).
Also removed the DPORT_PERIP_RST_EN_REG alias on ESP32S2. Now it's the same as some following chips (EN0).
This change addresses a rare but critical issue observed on certain
ESP32-C3 and ESP32-S3 devices, where secure boot verification
intermittently fails due to improper cleanup of crypto peripherals
during a restart.
Background – Restart Behavior in IDF
------------------------------------
In ESP-IDF, when the device restarts (via `esp_restart()` or due to a
panic/exception), a partial peripheral reset is performed followed by a
CPU reset. However, until now, crypto-related peripherals were not
included in this selective reset sequence.
Problem Scenario
----------------
If a restart occurs while the application is in the middle of a bignum
operation (i.e., using the MPI/Bignum peripheral), the ROM code may
encounter an inconsistent peripheral state during the subsequent boot.
This leads to transient RSA-PSS secure boot verification failures.
Following such a failure, the ROM typically triggers a full-chip reset
via the watchdog timer (WDT). This full reset clears the crypto
peripheral state, allowing secure boot verification to succeed on the
next boot.
Risk with Aggressive Revocation
-------------------------------
If secure boot aggressive revocation is enabled (disabled by default in
IDF), this transient verification failure could mistakenly lead to
revocation of the secure boot digest.
If your product configuration has aggressive revocation enabled,
applying this fix is strongly recommended.
Frequency of Occurrence
-----------------------
The issue is rare and only occurs in corner cases involving
simultaneous use of the MPI peripheral and an immediate CPU reset.
Fix
---
This fix ensures that all crypto peripherals are explicitly reset prior
to any software-triggered restart (including panic scenarios),
guaranteeing a clean peripheral state for the next boot and preventing
incorrect secure boot behavior.
1. Remove RTC_CLOCK_BBPLL_POWER_ON_WITH_USB Kconfig option
During sleep, BBPLL clock always gets disabled
esp_restart does not disable BBPLL clock, so that first stage bootloader log can be printed
2. Add a new Kconfig option PM_NO_AUTO_LS_ON_USJ_CONNECTED
When this option is selected, IDF will constantly monitor USB CDC port connection status.
As long as it gets connected to a HOST, automatic light-sleep will not happen.
Closes https://github.com/espressif/esp-idf/issues/8507