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
- Removed conditional definitions for various RCC_ATOMIC macros across
multiple files, replacing them with a unified PERIPH_RCC_ATOMIC() macro.
- Updated instances where specific RCC_ATOMIC macros were used to ensure
consistent usage of PERIPH_RCC_ATOMIC().
- Deleted unused uart_share_hw_ctrl.h file as its functionality is now
integrated into the new structure.
This commit reorganizes SPI flash header files to better reflect their
visibility and intended usage:
1. Rename `esp_flash_port/` to `esp_flash_chips/`:
- Better reflects that these headers are for chip driver implementations
- All chip driver headers moved to `esp_flash_chips/` directory
- Added README.md explaining semi-public nature of these headers
2. Move internal headers to `esp_private/`:
- `esp_flash_internal.h` -> `esp_private/esp_flash_internal.h`
- `memspi_host_driver.h` -> `esp_private/memspi_host_driver.h`
3. Move chip driver related headers to `esp_flash_chips/`:
- `esp_private/esp_flash_types.h` -> `esp_flash_chips/esp_flash_types.h`
- `spi_flash/spi_flash_defs.h` -> `esp_flash_chips/spi_flash_defs.h`
- `spi_flash_override.h` -> `esp_flash_chips/spi_flash_override.h`
- All `spi_flash_chip_*.h` headers moved to `esp_flash_chips/`
4. Code improvements:
- Remove unused includes (e.g., `spi_flash_override.h` from `cache_utils.c`)
- Use public API `esp_flash_get_size()` instead of direct member access
- Add `esp_flash_is_quad_mode` to linker.lf for IRAM placement
5. Documentation updates:
- Add README.md in `esp_flash_chips/` explaining semi-public headers
- Update programming guide with warnings about internal headers
- Update both English and Chinese documentation
6. Update all references across the codebase:
- Update includes in `spi_flash` component
- Update `bootloader_support`, `app_update`, `esp_tee`, `espcoredump`
- Update example projects
Breaking changes:
- Headers moved to new locations require include path updates
- `custom_flash_driver` example temporarily disabled until external
components are updated
This commit refactors the SPI flash component to improve encapsulation and
modularity by moving internal types and functions to private headers, and
reorganizing initialization code.
Key changes:
1. Move PSRAM frequency constraint macro from soc_caps.h to mspi_ll.h
- 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
2. Move internal types to private headers
- Move esp_flash_t structure to esp_private/esp_flash_types.h
- Move esp_flash_os_functions_t to esp_private/spi_flash_os.h
- Update all internal files to include private headers
- Keep forward declarations in public esp_flash.h
3. Move chip driver header to internal directory
- Move spi_flash_chip_driver.h to esp_flash_port/spi_flash_chip_driver.h
- Update all references to use new path
- Add esp_private/esp_flash_types.h include to the moved header
4. Refactor initialization functions
- Move init_flash from esp_system/startup_funcs.c to
spi_flash/esp_flash_spi_init.c
- Create new init_pm_flash_freq_limit function in startup_funcs.c
to call esp_pm_flash_freq_limit_init() conditionally
- Update system_init_fn.txt with new function locations
5. Improve API encapsulation
- Replace direct access to esp_flash_t->size in
esp_partition_register_external() with esp_flash_get_size() API
- Move esp_flash_is_quad_mode from inline function to regular function
in esp_flash_api.c
6. Update component dependencies
- Add esp_driver_gpio to spi_flash component PRIV_REQUIRES
- Remove unused includes and clean up header dependencies
These changes improve code organization by clearly separating public APIs
from internal implementation details, making the codebase more maintainable
and reducing the risk of breaking changes to internal structures.
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.
If LDO1 is used by spi flash, then we recommend to give the ownership to
the hardware. Software just read the parameters from the efuse and set
to PMU.
Common spi functionality for sharing the SPI bus between modules is moved from esp_driver_spi to
a more fitting location in esp_hw_support (shared HW resource control).
This also allows us to decouple the spi_flash driver from esp_driver_spi, removing
esp_driver_spi and esp_ringbuf from G1 builds.
