Use the full rodata page range when converting flash physical addresses back to cache addresses for XIP PSRAM. RISC-V extram stack coredump tests are temporarily skipped in CI until coredump supports PSRAM task stacks (IDF-15623).
Before:
The cache won't be disabled when XIP on psram. But during flash
erasing/programming, read data will be courrupt.
When XIP in psram is enabled, the image is not mapped to the cache so
usually there will be no flash access. The only way to read from flash
is via the driver or use mmap. The driver has protection during erasing,
while th mmap region not.
Now:
Mmap APIs provide a flag to make mmap->unmap region mutually exclusive
to flash erase/programming when XIP from psram. SPI Flash write APIs
will benefit from this. When the flag is used, no concurrent access to
mapped region will happen while writing; otherwise the cache will be
disable to avoid data corruption.
Most ESP-IDF APIs calls mmap with this flag. As for users calling
mmap-like APIs directly, they can choose whether to enable this by a
flag.
Closes https://github.com/espressif/esp-idf/issues/14897
Guard external-cache suspend for pure-ram apps where esp_cache_utils is
not linked, and move esp32p4-only xip_psram sdkconfig options into a
target-specific file to avoid unknown-kconfig failures on other chips.
Currently, s_mxic_set_required_regs() lacks checking for
CONFIG_SPI_FLASH_SUPPORT_MXIC_OPI_CHIP. And this causes a defined but not
used warning when MXIC flash driver is disabled in project config. So add
a #if check for this to supress warning.
Signed-off-by: Shengyu Qu <wiagn@4d2.org>
(cherry picked from commit 062c948c18)
ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
- Rename SOC_SPI_MEM_PSRAM_FREQ_AXI_CONSTRAINED to
MSPI_TIMING_LL_PSRAM_FREQ_AXI_CONSTRAINED
- Move macro definition to chip-specific mspi_ll.h files (C5, C61, H4, P4, S31)
- Update usage in clk_utils.c and esp_flash_spi_init.c
- Remove old macro from all soc_caps.h files
This commit implements a workaround that allows ESP32-C5 to run at 240MHz CPU frequency
normally, while automatically reducing CPU frequency during encrypted flash writes to
ensure correct operation. The frequency limit is chip revision dependent:
- v1.2 and above: limited to 160MHz during encrypted writes
- v1.0 and below: limited to 80MHz during encrypted writes
Key implementation details:
- Frequency limiting is triggered automatically when esp_flash_write_encrypted() is called
- Uses start() flags (ESP_FLASH_START_FLAG_LIMIT_CPU_FREQ) to integrate with OS layer
- Works with both PM enabled and disabled configurations
- Frequency is automatically restored after encrypted write completes
- For ESP32-C5 with 120MHz flash, Flash clock and timing registers are adjusted when
CPU frequency is reduced to 80MHz
- SPI1 timing registers are configured during frequency switching since encrypted writes
use SPI1 and must work correctly at reduced CPU frequencies
Code improvements:
- Use SOC_MSPI_FREQ_AXI_CONSTRAINED capability macro instead of hardcoded chip checks
- Control workaround via Kconfig (CONFIG_PM_WORKAROUND_FREQ_LIMIT_ENABLED) instead of
hardcoded macros
- Add comprehensive test cases covering various PM configurations and edge cases
This workaround enables ESP32-C5 applications to benefit from 240MHz CPU performance
while maintaining reliable encrypted flash write functionality.
Guillaume Souchere
Jiang Jiang Jian
wuzhenghui
Ashish Sharma
wanckl
morris
Chen Chen
Sudeep Mohanty
Michael.B
Armando (Dou Yiwen)
C.S.M
Shengyu Qu
harshal.patil
Song Ruo Jing
Konstantin Kondrashov
Fu Hanxi
Mahavir Jain
Shen Meng Jing