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.
Keep legacy ULP apps on the CMake v1 build path while buildv2 coverage
is limited to full_subproject ULP apps.
Also add the missing esp_driver_gpio dependency to the esp_pm test app
so buildv2 dependency checks see driver/rtc_io.h explicitly.
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
Correct "802.154" to "802.15.4" and change the EUI-64 derivation notation
from base_mac[0:3]/base_mac[3:6] to the inclusive base_mac[0:2]/base_mac[3:5]
in the esp32h2/esp32h21/esp32h4 Kconfig.mac help text and the EN/zh_CN
misc_system_api docs.
Co-authored-by: Cursor <cursoragent@cursor.com>
Add help text to the esp32h2/esp32h21/esp32h4 Kconfig.mac explaining
that these chips only consume one universally administered MAC address:
the IEEE 802.154 EUI-64 is derived from the base MAC and MAC_EXT, and
Bluetooth reuses the base MAC as-is (no BT offset, since there is no
Wi-Fi).
Add a matching 1-MAC derivation table and note to misc_system_api.rst
(EN and zh_CN) under a new `.. only:: esp32h2 or esp32h21 or esp32h4`
block, and exclude these targets from the generic 4/2 table.
Add an esp32s31-only note stating that the "Four" option may only be
used with a customer-provided custom base MAC range, since ESP32-S31
only provides two universally administered MAC addresses in eFuse.
Co-authored-by: Cursor <cursoragent@cursor.com>
ESP32-H2/H21/H4 only provide a single universally administered MAC
address in eFuse (MAC_FACTORY), so switch their UNIVERSAL_MAC_ADDRESSES
Kconfig from "Two" to "One" to match the hardware allocation.
This is a functional no-op for MAC generation: the BT offset is only
applied when SOC_WIFI_SUPPORTED, and these chips have no Wi-Fi, so
Bluetooth already reuses the base MAC as-is; the IEEE 802.154 EUI-64 is
derived from the base MAC and MAC_EXT regardless. The only change is
the (otherwise unused) ESP_MAC_UNIVERSAL_MAC_ADDRESSES int value going
from 2 to 1.
Co-authored-by: Cursor <cursoragent@cursor.com>
sibeibei
morris
Island
cjin
Ma Jing Jing
Jiang Jiang Jian
Wan Lei
Renz Christian Bagaporo
Alexey Lapshin
wuzhenghui
He Binglin
Renz Bagaporo
C.S.M
JackandCursor
yanzihan@espressif.com
Li Shuai