Enable FTM Responder mode for ESP32C6. Update wifi libs with below -
1. Break FTM State Machine code into separate functions
2. Use dynamic allocation for FTM session to save memory
3. Add API to get FTM report instead of event based mechanism
4. Add FTM Request retry and comeback support
"Enable USB when phy init" Kconfig option would call esp_phy function
`phy_bbpll_en_usb()` that is not implemented for all targets.
Selecting this option for unsupported target results in linking error.
The necessity of this workaround is now defined soc_caps.h rather than
in the Kconfig.
Closes https://github.com/espressif/esp-idf/issues/12185
This commit updates the "*_struct.h" files for the USB OTG peripheral:
- Added/removed some missing/non-existing register fields
- Added "reserved" place holders for registers that are missing due to IP
configuration.
- Added "usb_dwc_cfg.h" listing the USB OTG IP configuration for each target.
- Updated LL/HAL according to register field updates. Also tidied up the include
directives in those headers.
For C6/H2/P4/C5, there is no SoC specific debug range. Instead the same
address range is part of CPU Subsystem range which contains debug mode
specific code and interrupt config registers (CLINT, PLIC etc.).
For now the PMP entry is provided with RWX permission for both machine
and user mode but we can save this entry and allow the access to only
machine mode for this range.
For P4/C5 case, this PMP entry can have RW permission as the debug mode
specific code is not present in this memory range.
Previously the DROM_HIGH_ADDR for esp32s3 was 0x3D000000, which
convers only 16 MB of address range. But esp32s3 supports 32 MB
external memory. So this address should be 0x3E000000
This commit refactors SOC_USB_PERIPH_NUM as follows:
- Renamed to SOC_USB_OTG_PERIPH_NUM to avoid confusion with USB Serial JTAG
- Updated to unsigned integer "1U"
- Updated some build rules to depend on SOC_USB_OTG_SUPPORTED instead
In ESP32-H2, the ECDSA peripheral by default uses the TRNG (hardware)
generated k value but it can be overridden to software supplied k.
This can happen through by overriding the `ECDSA_SOFTWARE_SET_K` bit
in the configuration register. Even though the HAL API is not exposed
for this but still it could be achieved by direct register
programming. And for this scenario, if sufficiently random k is not
supplied by the software then it could posses a security risk.
In this change, we are unconditionally programming the efuse
`ESP_EFUSE_ECDSA_FORCE_USE_HARDWARE_K` bit during startup security
checks itself. Additionally, same is ensured in the `esp_efuse_write_key`
API as well. This always enforces the hardware k mode in the ECDSA
peripheral and ensures strongest possible security.
