Files
esp-idf/components/soc
Aditya Patwardhan 94be07050f change(secure_boot): mark ECDSA based Secure Boot V2 as insecure on affected SoCs
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.
2026-06-10 18:06:48 +05:30
..

The SoC component

The soc component provides register-level descriptions for targets supported by ESP-IDF.

File Description
xxx_reg.h/xx_struct.h Defines registers layout of a specific module. These files are automated, and should not be updated manually.
Please note the register names and layout are subject to change between different chip series.
xxx_pins.h Defines the unchangeable GPIOs used by a specific module.
e.g. if a high speed signal is routed through IO MUX, its corresponding GPIO is not selectable.
soc_caps.h Describes the differences in capabilities between different chips.
The macros here can also affect cmake build system, Kconfig system, docs system, pytest and CI environment.
Changes to this file requires extra caution as they are part of the public API.
xxx_periph.h This is the portal for each peripheral module at the SoC layer,
containing all relevant register header files and organizing other key information, such as interrupt sources, hardware signal IDs, etc.
xxx.peripherals.ld This is the linker script that defines each module's memory address.

The SoC Capabilities

soc_caps.h file describes the SoC capabilities. To used the soc capability macros, you should use the macro functions offered by soc/soc_caps_eval.h.

Macro function Description Example
SOC_IS Checks if the current SoC is a specific one. SOC_IS(ESP32)
SOC_HAS Checks if the current SoC has a specific module. SOC_HAS(DAC)
SOC_MODULE_ATTR Get the attribute of a specific module. SOC_MODULE_ATTR(GPTIMER, TIMERS_TOTAL)
SOC_MODULE_SUPPORT Checks if the current SoC supports a specific feature. SOC_MODULE_SUPPORT(GPTIMER, ETM)