Add USB DFU and OTG console SOC capability flags for esp32s2, esp32s3, and esp32p4.
Use these caps in Kconfig, documentation conditionals, and idf.py DFU actions so USB support
is derived from SOC capabilities instead of hardcoded target names.
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
The idf_test component was previously cleaned up but accidentally
reintroduced when adding esp32s31 support. It only contained an empty
header file (idf_performance_target.h) with no references anywhere
in the codebase.
Also removes the corresponding entry from astyle-rules.yml.
- esp_tls_mbedtls: require cert when PSA-backed server/client key is set
- esp_tls_mbedtls: drop redundant pk_init/x509_crt_init (calloc handles it)
- psa SE driver: copy callbacks/opaque_key by value (no lifetime coupling)
- psa SE driver: replace atomic CAS with simple null check on register
- psa SE driver: use sig_len from sign callback with bounds validation
- psa SE driver: validate pubkey_len returned by export_pubkey callback
- psa SE driver: check hash sub-alg in RSA PKCS1V15 branch of validate_request
- psa SE driver: align secure_element_register_callbacks doc with value-copy impl
- esp_https_server: initialize server_key in HTTPD_SSL_CONFIG_DEFAULT
- mbedtls: move SECURE_ELEMENT_DRIVER_ENABLED to esp_config.h for parity
with ESP_ECDSA_DRIVER_ENABLED; drop target_compile_definitions
- docs: fix esp_tls_cfg_t -> esp_http_client_config_t cross-reference
- docs: check psa_import_key() status in ESP-TLS PSA example
- hints/error_output: point at CONFIG_MBEDTLS_SECURE_ELEMENT_DRIVER_ENABLED
(cherry picked from commit 08b567ef3b)
Add ESP_KEY_SOURCE_BUFFER and ESP_KEY_SOURCE_PSA key sources so all
hardware backends (DS, ECDSA, secure element) are accessed via PSA
key IDs through a single esp_tls_cfg_t.client_key field.
(cherry picked from commit 36090b7161)
main/{esp32s2,esp32c3,esp32s3}/test_panic.c uses WDT registers from
esp_hal_wdt. Declare it explicitly so the build works under cmakev2's
strict component isolation.
The spiram-xip IROM/DROM alignment tests assumed the XIP region always
leaves an alignment gap before the next MMU page: they executed into the
gap and expected an instruction access fault followed by a register dump.
When the section ends exactly on an MMU page boundary there is no gap - the
device prints "<IROM/DROM> alignment gap not added into heap" and returns,
the framework restarts cleanly (esp_restart_noos, no panic), and the test
timed out waiting for a register dump.
When an app sets __COMPONENT_REQUIRES_COMMON before project(), the
explicit value used to bypass the default branch that includes
${idf_target_arch}, dropping the arch component from the build.
IDF_TARGET_ARCH isn't known pre-project(), so apps shouldn't have to
hand-roll a target -> arch map. Append it after the explicit list during
common-component initialization; empty on linux means no append.
Read sdkconfig.cmake's CONFIG_* values and re-publish them on the
build-properties target so component CMakeLists.txt code that queries
Kconfig via idf_build_get_property(var CONFIG_FOO) returns the expected
value.
Add a COMMAND check on esptool_py_flash_target before invoking it in
__init_project_flash_targets. Apps that restrict the build set without
esptool_py would otherwise hit "Unknown CMake command".
Move managed-dependency injection and recursive inclusion to BEFORE the
component's add_subdirectory() call, so its CMakeLists.txt can resolve
managed-dep targets at register time. Inside idf_component_register,
union the manager-injected REQUIRES/PRIV_REQUIRES with what the
component author wrote instead of overwriting them.
Under __V1_COMPAT_SHIM, populate EXECUTABLE, EXECUTABLE_NAME, and
BUILD_COMPONENTS build properties in __project_default(), and propagate
project_elf to the caller scope. Relax the BUILD_COMPONENTS query gate
in build.cmake so component code that uses
idf_build_get_property(... BUILD_COMPONENTS) keeps working.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Replicate Build system v1 behavior where the 'main' component implicitly
depends on the discovered components (or the app-restricted
__SHIM_COMPONENTS list) when no explicit REQUIRES/PRIV_REQUIRES is set.
Gated on __V1_COMPAT_SHIM so native Build system v2 projects retain
their explicit dependency contract.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
When IDF_BUILD_V2 evaluates to a CMake-truthy value, project.cmake
delegates to Build system v2 (cmakev2). The shim wraps project(),
forwards the app-declared COMPONENTS list via __SHIM_COMPONENTS, and
publishes __V1_COMPAT_SHIM so Build system v2 internals can gate Build
system v1 compatibility behavior. Existing app CMakeLists.txt files
build unchanged.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Replace argparse with rich-click and use esp_pylib.logger for
standardized console output and fatal error handling.
(cherry picked from commit 3a7896f2c5)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
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.
Move the OpenCode companion guide into the ble_uart_service example.
Add English and Chinese Markdown guides with image assets.
Keep ESP-BLE-UART naming consistent across the example and bridge tooling.
(cherry picked from commit 926111e721)
Co-authored-by: Zhou Xiao <zhouxiao@espressif.com>
When esp-idf-kconfig >= 3.9.0 is installed, we can use the optimized
menuconfig target without the need to preprocess the sdkconfig file by
kconfgen (removing deprecated options - menuconfig - readding deprecated
options).
Also removed unused {menuconfig_depends} from the new target.
Co-authored-by: Cursor <cursoragent@cursor.com>
