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>
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.
