ESP32-S31 uses the same trace encoder IP as ESP32-P4. Of the E-Trace v2.0
parameters the two targets report, only privilege_width_p differs (1 on P4,
2 on S31), and it affects both the sync packet layout and the filter's
privilege selector.
- Add the SOC_RISCV_TRACE_* caps for ESP32-S31 along with the esp32s31 LL, and
declare TRACE0/TRACE1 in the target's trace_struct.h.
- Carry privilege_width_p as SOC_RISCV_TRACE_PRIV_WIDTH so the sync packet
decoder can locate the address field, which starts one bit later on targets
that implement supervisor mode.
- Use the RISC-V architectural privilege encoding (0 user, 1 supervisor,
3 machine) in the public filter enum so the values do not change per target,
and let each LL narrow them to its own register field.
- Add riscv_trace_ll_priv_is_supported() per target, so a privilege level the
selector cannot represent is rejected with ESP_ERR_NOT_SUPPORTED rather than
being silently narrowed to a different level. It lives next to the narrowing
code so the two cannot drift apart.
- Fix trace buffer allocation on targets whose internal RAM is not reached
through a cache. esp_cache_get_alignment() reports 0 there, which underflowed
the size check and failed every allocation. Align base and size to the larger
of the reported cache line and the encoder's 4-byte write granularity.
Expose RC_FAST as a shared MCPWM group clock source for timers,
capture timers, and carriers on ESP32-C5, ESP32-C6, ESP32-H2,
and ESP32-P4. Fix the ESP32-S31 MCPWM clock selector mapping.
Add a hardware runtime test that verifies MCPWM Timer counting
resolution for every supported clock source.
Rename the internal ULP child-build marker to __ULP_BUILDV2 so component CMake files make the build-system scope explicit.
Document that the marker is currently set only by the IDF_BUILD_V2 ULP child path.
Add SOC_DEBUG_HAVE_OCD_STUB_BINS for esp32c5, esp32c61, esp32h4,
esp32h21, esp32p4, and esp32s31. Update TEE linker scripts with
correct esp_tee_app_config offsets for the 0x3000 stub reservation
Configure the shared LCDCAM core clock through guarded LCD and CAM LL APIs,
and unify LCD functional clock LL calls around group IDs across supported targets.
Co-authored-by: Cursor <cursoragent@cursor.com>
The Key Manager hardware peripheral in its current form needs further
design changes before it can be offered as a production feature.
Until a revised peripheral design is available, withdraw ESP-IDF
support for it on all Key Manager capable targets.
Sub-projects like ULP are built as external CMake projects via
externalproject_add() and may use toolchains that are completely
different from the IDF target toolchain. For example, the ULP RISC-V
co-processor on an xtensa target (ESP32-S2/S3) uses
riscv32-esp-elf-gcc while the main project uses xtensa-esp-elf-gcc.
This causes problems in cmakev2:
1. __init_toolchain() in idf.cmake validates that CMAKE_TOOLCHAIN_FILE
matches IDF_TARGET and then overrides it. For sub-projects with
custom toolchains (passed via -DCMAKE_TOOLCHAIN_FILE from the
parent), this validation fails because the toolchain doesn't follow
the IDF naming convention (toolchain-<target>.cmake).
2. Several component project_include.cmake files use functions from
the IDF toolchain response file machinery (idf_toolchain_add_flags,
idf_toolchain_remove_flags, idf_toolchain_rerun_abi_detection) that
are not available in sub-projects with custom toolchains, or perform
validation that assumes the IDF target toolchain is in use.
Introduce IDF_CUSTOM_TOOLCHAIN, a CMake variable passed via -D from
the parent build to indicate that the toolchain was provided externally
and should not be resolved or validated by the IDF build system.
When IDF_CUSTOM_TOOLCHAIN is set:
- __init_toolchain() records the pre-set CMAKE_TOOLCHAIN_FILE and
skips IDF_TARGET-based resolution and validation.
- Component project_include.cmake files that manipulate IDF toolchain
flags (xtensa, esp_libc, esp_psram, soc) return early, as those
operations are not applicable to custom toolchains.
This is a generic mechanism usable by any sub-project that provides
its own toolchain (ULP, or any future sub-project with a non-IDF
toolchain).
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
