- Increased the TEE stack when secure boot is enabled
- Also, generate a build error when the generated TEE binary image size is
greater than the TEE partition size
- Also fixed an issue where NewLib ROM APIs, when called from TEE, were
using the syscall table located in the REE SRAM. This could be abused
as an attack vector to invoke illegal functions from the TEE.
To prevent this, the syscall table is now switched to the TEE-specific
copy during every M-U mode transition.
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
Currently, REE SPI flash HAL operations are routed as service calls to TEE,
but the TEE implementation incorrectly uses ROM APIs instead of HAL APIs.
This leads to issues and is not the recommended approach.
esp_stdio contains everything the old esp_vfs_console contained (the vfs stdio glue layer)
as well as other functionality related to stdio (previously referred to as console)
- Previously, only the U-mode interrupt threshold was raised in REE critical sections,
leaving M-mode at the lowest level.
- As a result, when a service call transitioned to M-mode, all interrupts were still
allowed to fire, including those that should have been masked.
- Remove GPTIMER and TIMG related definitions from soc_caps_full.h files
- Move timer peripheral definitions to appropriate HAL layer files
- Update references across components to use proper HAL abstractions
- Consolidate timer group and GPTIMER capabilities organization
- Ensure consistent timer configuration across all ESP32 variants
This refactoring improves the separation of concerns between SOC
capabilities and HAL implementations for timer-related functionality.
- Ensure bound checks correctly handle all scenarios, including
when a requested operation's (SPI0/1) range fully contains the
TEE-protected region.
- Disable delegation of INTWDT timeout and Cache error interrupts as they reset
the device after the panic handler
- Fix incorrect setting in the edge interrupt acknowledgement API
- Avoid executing the service call dispatcher in the U-mode ecall,
rather execute `mret` to jump it
- Avoid `t1` register corruption when processing `ecall`
- Switch back to the bootloader stack from TEE stack after the
execution of the entire TEE initialization routine
- Rename `tee_test_fw` app configs for better CI tracking
- Decrease the lower bound of TEE I/DRAM config options
- Trim the TEE test-apps build
- Improve the TEE/REE OTA pytest script with additional checks
- Fix build issues when `tee_sec_storage`/`tee_ota_ops` are a
a part of the project build but ESP-TEE is disabled
This commit refactors the esptool_py component to provide utility
functions for binary file generation targets instead of creating the
targets. Binary generation targets are now moved to the respective
projects.
The following changes were done in this commit:
- Added __idf_build_binary() function to esptool_py to create the binary
file generation target.
- Added __idf_build_secure_binary() as the secure boot equivalent of the
above function.
- Top level project build now creates its own binary targets in
idf_build_executable() in build.cmake.
- Bootloader and esp_tee subprojects create their binary file generation
targets in their respective CMakeLists.txt files.
- All post-build targets such as the app_size_check target are now
created by the respective projects and not esptool_py.
- General clean-up of the esptool_py cmake files.
harshal.patil
Mahavir Jain
Jiang Jiang Jian
Aditya Patwardhan
Laukik Hase
Xiao Xufeng
Ashish Sharma
Alexey Lapshin
Marius Vikhammer
morris
Peter Dragun
Marek Fiala
Sudeep Mohanty