In release/v5.x, esp_fault.h resides in the esp_hw_support (G1)
component, so the G0 components (hal, esp_rom) must not depend on it.
Copy its contents to esp_common as esp_fault_internal.h, keep
esp_fault.h as a compatibility wrapper around it, and switch the hal
and esp_rom ECDSA/ECC code to the internal header.
The addend in `emac_hal_ptp_start()` was derived from the floating-point
`config->ptp_req_accuracy_ns` instead of the integer `base_increment`
register that actually drives the sub-second update. The cast to
`uint8_t` loses the fractional part, so the un-corrected addend leaves
the PTP clock running off-rate.
Example: with a 40 MHz XTAL and the default `req_accuracy_ns = 40`,
`base_increment` rounds 85.899 up to 86, leaving the clock +1170 ppm
fast — well outside the IEEE 802.1AS neighborRateRatio limit (~±200
ppm), so strict-1AS bridges refuse asCapable.
Compute the addend from the stored `base_increment` for both rollover
modes: `addend = 2^32 * clk_period_ns / increment_ns`.
Measured on ESP32-P4: neighborRateRatio drops from +1147.5 ppm to
+4.2 ppm, and asCapable is granted.
Co-authored-by: Ondrej Kosta <panzer412@gmail.com>
Introduced in 8818157e42
The workaround in the commit routes the signal to LP GPIO matrix first.
When uses LP IOMUX pin as UART RX, the signal did not bypass the matrix,
which caused the issue.
This commit adds rtc_gpio_iomux_input and rtc_gpio_iomux_output APIs
to align with existing GPIO driver APIs.
This allows rtc_gpio_deinit to always switch the pad back to GPIO,
regardless of lp io clock enabled or not, so that gpio_config can
always switch the IO back to GPIO use after wakeup from deep sleep.
The key_mgr_ll_set_xts_aes_key_len() function was incorrectly using
REG_SET_FIELD() with the key_len enum value directly. Since
KEYMNG_FLASH_KEY_LEN is a 1-bit register field (0=128-bit, 1=256-bit),
writing ESP_KEY_MGR_XTS_AES_LEN_128 (value 3) resulted in the LSB (1)
being stored, incorrectly configuring 256-bit mode.
Fixed by using a switch statement to properly map:
- ESP_KEY_MGR_XTS_AES_LEN_128 → REG_CLR_BIT (0)
- ESP_KEY_MGR_XTS_AES_LEN_256 → REG_SET_BIT (1)
Thus, matching the correct ESP32-C5 implementation.
- Update the Key Manager key types to be generic
- Define a new enum to determine the length of the keys
- Refactor the Key Manager driver support generic key types and key lengths
- Also store key deployment mode in the key recovery info
On ESP32-P4 rev < 3.0, Key Manager is software-disabled, but the public
esp_key_mgr.h APIs had no runtime check.
Calls using HMAC/DS/PSRAM key types fell through to
HAL_ASSERT("Unsupported ...") paths in key_mgr_ll.h. Gate
each public API with key_mgr_ll_is_supported() and return
ESP_ERR_NOT_SUPPORTED cleanly instead.
