Move the cache profile counter type definitions to hal/cache_types.h so
that
esp_cache_cnt.h can use them without depending on the public soc header
soc/cache_periph.h (which CI rejects as non-public).
The remaining cache_periph.h header and its per-target cache_periph.c
sources
are moved from the soc component into the hal component, with the
sources
organized per target directory as usual for the hal component.
Removes the soc/cache_periph.h dependency from esp_cache_cnt.h and
hal/cache_ll.h by using hal/cache_periph.h instead.
Move the following modules from the hal component into a new dedicated
esp_hal_debug_assist component, following the esp_hal_timg pattern:
- assist_debug (hal + target-specific LL headers)
- debug_probe (types + target-specific LL headers)
- riscv_trace (hal + types + source + target-specific LL headers)
- trace_ll (esp32/esp32s2/esp32s3 target-specific LL headers)
Update the following components to depend on esp_hal_debug_assist:
esp_system, riscv, bootloader_support, esp_hw_support, esp_riscv_trace
Remove riscv_trace_hal.c from the hal component.
Move soc_etm_retention_desc_t type definition and soc_etm_retention_info
data from hal component to esp_hw_support component, following the
pattern of other peripheral retention data (e.g. MWDT).
- Create esp_private/etm_retention.h with type and extern declaration
- Create port/<target>/etm_retention.c for each target with retention data
- Remove hal/<target>/etm_periph.c and hal/include/hal/etm_periph.h
- Update esp_etm.c to include the new header
- Update CMakeLists.txt in both components
Adds CONFIG_SPIRAM_ENC_EXEMPT, available on chips that support per-page
PSRAM encryption configuration (esp32c5, esp32c61, esp32p4). When
enabled, esp_psram carves CONFIG_SPIRAM_ENC_EXEMPT_SIZE off the top of
PSRAM and maps it via the new mmu_hal_map_region_no_enc() helper, which
writes MMU entries without the SENSITIVE bit. The region is registered
as a separate heap pool reachable only through the new
MALLOC_CAP_SPIRAM_NO_ENC capability bit, so default SPIRAM allocations
cannot accidentally land there.
PSRAM encryption imposes alignment constraints that some DMA engines
(e.g. 2D-DMA) cannot satisfy. This option lets such workloads place
their buffers in unencrypted PSRAM while keeping the rest of PSRAM
(and flash) encrypted. Default disabled; security implications are
documented in the Kconfig help text.
bugfix(wifi): fix incomplete phy initialization due to absence of bb clocks at...
Closes ESPCS-1007 and ESPCS-997
See merge request espressif/esp-idf!42511
