This commit adds "bare metal stubs" xtensa_rtos.h glue layer to mimic a bare
metal OS port. The bare metal stubs don't access any components outside of the
G0 group.
The previous commit moved the OS agnostic files from the IDF FreeRTOS port to
the xtensa component, thus can be accessed by both IDF and Amazon SMP FreeRTOS.
This commit removes the redudant copies in the Amazon SMP FreeRTOS port.
When porting an RTOS to the Xtensa architecture, there are a few files that
are common to all Xtensa RTOS ports. These files form the Xtensa RTOS porting
layer (e.g., "xtensa_vectors.S", "xtensa_context.S"). An Xtensa RTOS port is
expected to provide an RTOS specific "xtensa_rtos.h" header to interface with
the Xtensa RTOS porting layer.
Previously, the Xtensa RTOS porting layer files were placed in the FreeRTOS
component. This commit does the following:
1. Moves the Xtensa RTOS porting layer files from the `freertos` component to
the `xtensa` component. The following files were moved:
- xtensa_asm_utils.h
- xtensa_context.S
- xtensa_loadstore_handler.S
- xtensa_vectors.S
2. Refactored xtensa component include paths to separate Xtensa RTOS porting
layer headers.
- Xtensa HAL headers included via `#include <xtensa/...h>`
- Xtensa RTOS porting layer headers included via `#include <...h>`
Note: The xtensa files in the Amazon SMP FreeRTOS port are not moved/deleted in
this commit to ensure the moved files retain a clean diff history.
esp_hw_support: Update the memory ptr location/property checks to include the unused DCACHE added to DRAM
Closes IDF-7103
See merge request espressif/esp-idf!22904
- While updating to mbedtls release/v3.4.0, building mbedtls/library/psa_crypto.c,
clang produced an unreachable-code warning, so added `-Wno-unreachable-code` compile option for clang.
- In `mbedtls/v3.4.0`, the ECDSA restartable sign and verify functions (`ecdsa.c`) were made public.
- But the `mbedtls_ecdsa_sign_det_restartable` function prototype was declared in the file `ecdsa.h`,
only when `MBEDTLS_ECDSA_SIGN_ALT` was not defined.
- added a patch in mbedtls library to fix it.
- As per the memory block diagram for ESP32-S3, the
internal memory address ranges as follows:
DRAM: 0x3FC88000 (== SOC_MEM_INTERNAL_LOW) <-> 0x3FCF0000
IRAM: 0x40378000 <-> 0x403E0000 (== SOC_MEM_INTERNAL_HIGH)
- to acknowledge the unused DCACHE added to DRAM for ESP32-S3
- For ESP32-S3, when the DCACHE size is set to 16 kB, the unused 48 kB is added to
the heap in 2 blocks of 32 kB (from 0x3FCF0000) and 16 kB (from 0x3C000000).
- But, if we try allocating memory from the 16 kB block and run an `esp_ptr_internal`
check on that memory pointer, it fails as the address block from 0x3C000000
corresponds to the external memory symbols SOC_DROM_LOW and SOC_EXTRAM_DATA_LOW.
(E.g. freertos - If the IDLE task stack buffer gets allocated from this region,
the firmware will abort due to this failure).
- Thus, the checks `esp_ptr_internal`, `esp_ptr_in_drom` and `esp_ptr_byte_accessible`
have been updated to acknowledge this memory as a part of the DRAM.
Co-authored-by: Mahavir Jain <mahavir@espressif.com>
CI: created job and script for creating MR to esp-dockerfiles, added script execution to CI pipeline
Closes IDFCI-1445
See merge request espressif/esp-idf!21348
