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.
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>
In cmakev1, the executable target is named "${project}.elf". In cmakev2,
the executable is named "${project}" with .elf as the output suffix.
Strip the .elf suffix and look up the bare target name when the original
name doesn't exist.
Two compatibility fixes:
- idf_component_register: apply separate_arguments to REQUIRES and
PRIV_REQUIRES after cmake_parse_arguments. Some managed components
publish CMakeLists.txt with PRIV_REQUIRES "log esp_eth" as a single
quoted string (e.g. espressif__rtl8201).
- Add register_component() macro and idf_component_add_link_dependency()
shims for legacy ESP-IDF examples (ULP apps, BLE mesh) and managed
components (esp_flash_nor).
kconfgen runs while the component manager iterates to convergence.
Those passes operate on partial component sets and emit "unknown
kconfig symbol" warnings for symbols defined in not-yet-downloaded
components — idf-build-apps treats those as build failures.
Suppress kconfgen output on the intermediate passes; only the final
pass against the converged set emits warnings.
The cmakev2 compat layer's idf_component_register() was passing
${sources} quoted to add_library(), collapsing the semicolon-delimited
list into a single argument. Drop the quotes so each source becomes a
separate argument, matching cmakev1's idf_component_register().
The CMakeLists injects CONFIG_ESP_REV_MIN_FULL and CONFIG_XTAL_FREQ on
the command line because those symbols live in esp_common's Kconfig,
which is outside the G0 closure and is not loaded during a restricted
COMPONENTS build. When every discovered component's Kconfig is processed
(IDF_BUILD_V2) the symbols are already defined via their Kconfig
defaults, and the additional -D would conflict with the existing
definition.
Gate the injection so it only runs when the Kconfig is not processed.
g1_components forces VFS_SUPPORT_IO=n in sdkconfig.defaults to keep
vfs and its transitive deps out of the closure. When the restricted
COMPONENTS list does not load components/vfs/Kconfig, the symbol is
unknown at config time and kconfgen emits an "unknown kconfig symbol"
warning that idf-build-apps treats as a build failure.
Add an ignore pattern so the warning does not gate the build.
g1_components builds a minimal COMPONENTS list. When every component's
Kconfig is processed, components/vfs/Kconfig sets VFS_SUPPORT_IO=y by
default, and the conditional requires in esp_stdio and esp_libc pull
vfs, esp_driver_uart, and their transitive deps into the closure.
Add an sdkconfig.defaults that forces the symbol off so the dependency
graph stays restricted to the components actually under test.
expected_dep_violations only listed the edges visible when
idf_component_optional_requires was a no-op for the dependency graph.
Under build system v2's DEFERRED mode the call propagates the resolved
dependency back into PRIV_REQUIRES, and the graph also captures
esp_common -> {efuse, bootloader_support, app_update} and esp_system ->
esp_app_format.
Add those entries so the script does not flag them when IDF_BUILD_V2
is set.
