Many places in the ESP_SYSTEM are using CONFIG_FREERTOS_UNICORE instead of CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE (GitHub PR)
Closes IDFGH-11333
See merge request espressif/esp-idf!27435
This commit deprecates the "freertos/xtensa_context.h" and "xtensa/xtensa_context.h"
include paths. Users should use "xtensa_context.h" instead.
- Replace legacy include paths
- Removed some unnecessary includes of "xtensa_api.h"
- Add warning to compatibility header
This commit deprecates the "freertos/xtensa_api.h" and "xtensa/xtensa_api.h"
include paths. Users should use "xtensa_api.h" instead.
- Replace legacy include paths
- Removed some unnecessary includes of "xtensa_api.h"
- Replaced some calls with "esp_cpu_..." equivalents
- Add warning to compatibility header
Similar to how the secondary init functions were already registered
via ESP_SYSTEM_INIT_FN, do the same for the core init functions.
This MR doesn't actually move the init functions into respective
components yet. This has to be carefully done in follow-up MRs.
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.
This commit deprecates xTaskGetAffinity(), xTaskGetCurrentTaskHandleForCPU()
and xTaskGetIdleTaskHandleForCPU() APIs for IDF-FreeRTOS kernel.
Instead, users are directed to use alternatives. All other
components in IDF using these functions have been updated accordingly.
1st bootloader won't help to initialize the MSPI & cache properly as it
usually do when loading from flash. And the ram app doesn't have valid
headers.
Since there is no enough space in 2nd bootloader, we replace the
`bootloader_init_spi_flash` in the ram_app (!pure_ram_app), with an
customized alternative of it for the ram_app.
This alternative helps to initialize the MSPI & cache properly, without
the help of 1st bootloader or image headers.
This commit mainly targets the ESP32-P4. It adds supports for coprocessors on
RISC-V based targets. The coprocessor save area, describing the used coprocessors
is stored at the end of the stack of each task (highest address) whereas each
coprocessor save area is allocated at the beginning of the task (lowest address).
The context of each coprocessor is saved lazily, by the task that want to use it.
