Commit Graph

17 Commits

Author SHA1 Message Date
wuzhenghui
5436d1f0c4 fix(esp_system): force enable uart0 sclk in esp_restart 2025-06-27 20:04:13 +08:00
Konstantin Kondrashov
ff0408c087 feat(esp_system): Adds Kconfigs to place code in IRAM 2025-06-23 13:23:33 +03:00
Song Ruo Jing
6d293c8582 feat(clk): Add basic clock support for esp32h21 2025-06-16 15:05:32 +08:00
harshal.patil
e08189f37b fix(system_internal): Avoid the sec clock reset caused due to resetting all crypto peripherals 2025-05-22 16:01:02 +05:30
armando
0c6aeecde4 feat(cache): supported cache panic driver on h21 2025-05-14 11:37:30 +08:00
armando
acda9a7a7e feat(cache): supported cache driver on h21 2025-05-14 11:37:30 +08:00
Marius Vikhammer
298da837fd feat(system): updated reset reasons for H21 2025-04-27 16:11:24 +08:00
Mahavir Jain
55a2ad3df3 fix(esp_system): reset crypto peripherals before device restart
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.
2025-04-15 19:06:26 +05:30
wuzhenghui
b3911c7c89 fix(esp_hw_support): fix unused OSC source deinit breaks XTAL32K configuration 2025-04-10 20:56:53 +08:00
wuzhenghui
c84757d35e fix(esp_hw_support): fix current leakage if ext32k slow clock source not exists 2025-04-08 20:07:47 +08:00
Li Shuai
350e3c3d06 fix(esp_system): update clk code for esp32h21 2025-03-17 11:24:39 +08:00
Li Shuai
8103ea67c7 change(esp_hw_support): pmu driver, hal and ll layer support for esp32h21 2025-03-17 11:24:39 +08:00
C.S.M
5e4fd8ee52 refactor(bod): Move brownout handling file from esp_system to esp_hw_support 2025-01-08 14:41:37 +08:00
gaoxu
25731d0c1e feat(esp32h21): finnal introduce hello world support 2024-12-30 20:14:40 +08:00
gaoxu
3e30d2e928 feat(esp32h21): ci enable public header check (stage7) 2024-12-24 16:44:08 +08:00
gaoxu
b240defc75 feat(esp32h21): support esp_system, esp_timer and freertos (stage5) 2024-12-20 22:43:10 +08:00
gaoxu
64bbb53b8f feat(esp32h21): introduce target esp32h21(stage 1) 2024-11-12 15:42:27 +08:00