Whenever a SPI flash operation is going to take place, it's
necessary to disable both the instruction and data cache. In order
to avoid the other CPU (if SMP is enabled) to retrieve data from
the SPI flash, it needs to be paused until the current SPI flash
operation finishes. All the code that "pauses" the other CPU (in
fact, the CPU spins until `up_cpu_resume` is called) needs to run
from the instruction RAM.
This config also prevents crashes due to the commit 6be363f, which
fix a race condition in multi-threaded write/read of the serial
driver, but increases stack size.
Instead of using Espressif's emulated NVS to save Wi-Fi data, use
`wapi`s wireless configure initialization mechanism for saving
Wi-Fi data. It 1) avoids creating a specific storage partition
just to save Wi-Fi data (ESP32-S3's storage partition is used
instead); 2) avoids initialization problems of the emulated NVS
when SMP is enabled (the Wi-Fi driver tries to initialize it before
the actual partition is initialized); and 3) enables reconnecting
using `wapi reconnect` command and connect the device automatically
on bringup if `CONFIG_NETUTILS_NETINIT` is selected.
While using NVS-like storage of the Wi-Fi driver, an error was
thrown while trying to access a file whose name was longer than
the mounted SPIFFS `CONFIG_SPIFFS_NAME_MAX`.
1) Wi-Fi driver libs from Espressif ESP-IDF release/v5.0;
2) Station mode only;
3) WPA2-PSK and WPA3-SAE enabled;
Not yet supported (WIP):
- SoftAP mode;
- 802.11k, 802.11v and 802.11R;
- Power Save mode;
- BLE Coexistance;
MCUboot support is no longer behind EXPERIMENTAL for the following
chips:
- ESP32
- ESP32-S2
- ESP32-S3
- ESP32-C3
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
In order to turn longjmp context-switch safe, it's necessary
to disable interrupts before modifying windowbase and windowstart.
Otherwise, after a context switch, windowstart and windowbase
would be different, leading to a wrongly set windowstart bit due to
longjmp writing it based on the windowbase before the context switch.
This corrupts the registers at the next window overflow reaching
that wrongly set bit.
*Background:*
This PR is related to an issue first observed on ESP-IDF
https://github.com/espressif/esp-idf/issues/5229 and it was, then,
checked on NuttX using a test application.
*The test application:*
To check if the problem affects ESP32, ESP32-S2 and ESP32-S3 on
NuttX, it was created an application based on:
https://en.cppreference.com/w/c/program/longjmp
The application creates 16 tasks (`#define NUMBER_OF_TASKS 16`)
that implements the following daemon:
```
static int setjmp_longjmp_daemon(int argc, char *argv[])
{
for (int i = 0; i < NUMBER_OF_TASKS * 2; i++)
{
jmp_buf env;
volatile int count = 0;
if (setjmp(env) != UINT16_MAX)
{
foo(&env, ++count);
}
}
sem_post(&g_sem);
return EXIT_SUCCESS;
}
```
The main function also initializes a semaphore to avoid application
exiting before tasks return successfully:
```
sem_init(&g_sem, 0, -NUMBER_OF_TASKS);
```
Finally, the round-robin interval was lowered to 1ms to raise the
chances of the longjmp being interrupted by a context switch
(`CONFIG_RR_INTERVAL=1).
This setup was able to reproduce the problem prior to this patch
being applied.
This change syncs the NuttX application image IRAM upper limit to the
start of the IRAM region used by the IDF 2nd stage bootloader.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
