By default, submodules are cloned with `--depth=1`. This continues
to be true if `DISABLE_GIT_DEPTH` environment variable is not
defined (and it is not defined by default). But, if defined the
submodules will be fully cloned (without the `--depth` parameter).
This commits replicates some changes on files that were originally
written for other Espressif SoCs and inspired new implementations.
Eventually, these new implementations were improved and this commit
replicates these changes on the original sources.
It seems like a wrong copy-and-paste from esp32c3.
Actually, internal memory mapping varies among processors.
esp32s3: lightly tested with wamr aot
esp32s2: not tested (i have no hardware access)
1. Adjust code to avoid PM wakelock->count less than or equal to 0.
2. Fix some document format issues.
Signed-off-by: chenwen@espressif.com <chenwen@espressif.com>
Most of the functions used to describe the SoCs capabilities are
available for all Espressif's chips. This commit uses this set of
common functions and remove outdated functions that perform the
same operations in a chip level.
1. pm configuration demonstrates the use of power management present on the ESP32-S3.
2. You can use the pmconfig command to test the power management, for details look at
``Documentation/platforms/xtensa/esp32s3/boards/esp32s3-devkit/index.rst``
Signed-off-by: chenwen@espressif.com <chenwen@espressif.com>
The Simple Boot feature for Espressif chips is a method of booting
that doesn't depend on a 2nd stage bootloader. Its not the
intention to replace a 2nd stage bootloader such as MCUboot and
ESP-IDF bootloader, but to have a minimal and straight-forward way
of booting, and also simplify the building.
This commit also removes deprecated code and makes this bootloader
configuration as default for esp32s3 targets and removes the need
for running 'make bootloader' command for it.
Other related fix, but not directly to Simple Boot:
- Instrumentation is required to run from IRAM to support it during
initialization. `is_eco0` function also needs to run from IRAM.
- `rtc.data` section placement was fixed.
- Provide arch-defined interfaces for efuses, in order to decouple
board config level from arch-defined values.
Signed-off-by: Almir Okato <almir.okato@espressif.com>
This commit implements the common RMT driver (already available for
the other Espressif's xtensa-based devices) for ESP32.
This allows us to have a proper separation between the lower and
upper-half drivers and use the 'ws2812' example to drive WS2812 RGB
LEDs.
This commit just rearranges the order of the types, data and
functions without modifying them. This is done to make it look more
similar with ESP32's ble adapter and ease maintanence.
Most of the functions used to set the peripherals are available for
all Espressif's chips. This commit uses this set of functions and
remove outdated functions that perform the same operations in a
chip level.
This commit updates the Wi-Fi and the BLE driver of ESP32. Most of
the changes rely on using the common sources and header files for
xtensa-based Espressif's SoCs.
The new Wi-Fi driver supports WPA3-SAE for both Station and SoftAP
mode. BLE's coexistence mode was enhanced according to the latest
libraries.
Please note that other sources required minor changes in order to
be compatible with the common sources.
Whenever a SPI flash operation will take place, it's necessary to
disable the cache and run no code from the flash. This includes
pausing the other CPU (when `CONFIG_SMP=y`). This commit prevents
an error to occur when the CPU core is evaluated before the task
is increased to the max priority.
Whenever a SPI flash operation will take place, it's necessary to
disable the cache and run no code from the flash. This includes
pausing the other CPU (when `CONFIG_SMP=y`). This commit prevents
an error to occur when the CPU core is evaluated before the task
is increased to the max priority.
Avoid using static mutex and recursive mutex as the resource to be
acquired/release. Instead, create a specific lock for each call if
it does not exist.
Avoid using static mutex and recursive mutex as the resource to be
acquired/release. Instead, create a specific lock for each call if
it does not exist.
Avoid using static mutex and recursive mutex as the resource to be
acquired/release. Instead, create a specific lock for each call if
it does not exist.
