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>
Reason for use sw-interrupt as syscall interrupt:
The xtensa `syscall` instruction can cause SYSCALL interrupt.
But SYSCALL interrupt is same interrupt level with level-one
interrupt.
Nuttx swint can enter `enter_critical_section` and gerenate
interrupt.
Signed-off-by: zhuyanlin <zhuyanlin1@xiaomi.com>
For up_irq_disable, use XCHAL_EXCM_LEVEL
For up_irq_save, use XCHAL_IRQ_LEVEL.
Then we can use svcall in enter_crritical_section.
Signed-off-by: zhuyanlin <zhuyanlin1@xiaomi.com>
Reason: xtensa svcall only have level-1 interrupt level.
Sush do not generate interrupt when up_irq_save.
Software int can generate interrupt when up_irq_save.
Signed-off-by: zhuyanlin <zhuyanlin1@xiaomi.com>
