This commit provides an interface to register ISRs that run from
IRAM and keeps track of the non-IRAM interrupts. It enables, for
instance, to avoid disabling all the interrupts during a SPI flash
operation: IRAM-enabled ISRs are, then, able to run during these
operations.
It also makes the code look more similar to the ESP32-S3 SPI flash
implementation by creating a common `esp32_spiflash_init` that is
responsible to create the SPI flash operation tasks. The function
intended to initialize the SPI flash partions was, then, renamed to
`board_spiflash_init`.
This commit provides an interface to register ISRs that run from
IRAM and keeps track of the non-IRAM interrupts. It enables, for
instance, to avoid disabling all the interrupts during a SPI flash
operation: IRAM-enabled ISRs are, then, able to run during these
operations.
The low-level Wi-Fi driver registers two peripheral interrupts to
the same CPU interrupt. Although the registered ISR is the same for
both peripherals interrupt, it's needed to call `up_enable_irq` to
ensure that the interrupt matrix is being set accordingly.
Please note that the current implementation of the ESP32-S3's IRQ
driver - although allow us to set a callback for each IRQ, which
represents the peripherals interrupt - doesn't allow us to call
both callbacks when these IRQs refers to a same CPU interrupt.
`g_cpu0_intmap` (or `g_cpu1_intmap`) associates each CPU interrupt
to a single IRQ/peripheral and, then, when a CPU interrupt is
triggered, only the last registered IRQ's callback will be called.
This isn't a problem here because 1) the registered callback is the
same for both IRQ's (in fact, it considers the CPU interrupt) and
2) we know in advance which peripheral interrupts will be attached
to which CPU interrupt and, then, we can set them directly.
- Fix macro values from `arch/xtensa/include/esp32s3/irq.h`
- Remove references to unexisting edge-triggered CPU interrupts
- Add `esp32s3_getirq` to get IRQ based on core and the `cpuint`
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;
Summary:
- It is applicable to esp32 products and uses the himem part
of 8M psram by creating character devices.
Impact:
- None
Testing:
- Use esp32-wrover series products for more than 1000 functional verifications.
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.
1 move fpu register to XCP_REGS
2 move save & restore fpu register to context_save/restore
Consistency with other archs.
Signed-off-by: zhuyanlin <zhuyanlin1@xiaomi.com>
This is required to avoid the interface header (syscall.h) depending on
the xtensa_swi.h header from the implementation
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Also fix an inconsistenct regarding the ESP32S3_NGPIOS macro. Although
correctly defining the number of available GPIOs in ESP32-S3, it was
erroneously being used for verifying the pin range.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Yanfeng Liu