Summary:
- Temporarily disables ARCH_HAVE_FORK for arm64 to address a crash issue,
as detailed in https://github.com/apache/nuttx/pull/9755.
- This is a precautionary measure until a more permanent solution is implemented.
Impact:
- Temporarily limits certain functionalities on arm64,
but necessary to ensure system stability.
Testing:
- Successfully tested on QEMU-8.1.2.
- Note: please apply the changes from https://github.com/apache/nuttx-apps/pull/1962.
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
1. If CONFIG_ESP32S3_PHY_INIT_DATA_IN_PARTITION and CONFIG_ESP32S3_SUPPORT_MULTIPLE_PHY_INIT_DATA are enabled,
PHY initialization data (PHY initialization data is used for RF calibration) will be loaded from a partition.
2. The corresponding PHY init data type can be automatically switched according to the country code,
China's PHY init data bin is used by default, country code can be modified through the wapi command: wapi country <ifname> <country code>.
Signed-off-by: chenwen@espressif.com <chenwen@espressif.com>
If using flow control with a high CTS the thread may be
blocked forever on the second transmit attempt due to waiting
on the txdma semaphore. The calling thread can then never
make progress and release any resources it has taken, thus
may cause a deadlock in other parts of the system.
The implementation differs in behavior from interrupt-driven
TX. It should not implicitly wait on a taken semaphore but
return immediately and let the upper layers decide on what to
do next.
If using flow control with a high CTS the thread may be
blocked forever on the second transmit attempt due to waiting
on the txdma semaphore. The calling thread can then never
make progress and release any resources it has taken, thus
may cause a deadlock in other parts of the system.
The implementation differs in behavior from interrupt-driven
TX. It should not implicitly wait on a taken semaphore but
return immediately and let the upper layers decide on what to
do next.
If using flow control with a high CTS the thread may be
blocked forever on the second transmit attempt due to waiting
on the txdma semaphore. The calling thread can then never
make progress and release any resources it has taken, thus
may cause a deadlock in other parts of the system.
The implementation differs in behavior from interrupt-driven
TX. It should not implicitly wait on a taken semaphore but
return immediately and let the upper layers decide on what to
do next.
This commit sets the BLE's interrupt as a IRAM-enabled interrupt,
which enables it to run during a SPI flash operation. This enables
us to create a cache to off-load semaphores and message queues
operations and treat them when the SPI flash operation is finished.
By doing that, we avoid packet losses during a SPI flash operation.
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`.
Whenever we enter/leave a critical section, the interrupt status is
saved and, then, restored. However, for the ESP32's BLE adapter,
entering/leaving a critical section is done on separate functions
that need to be registered as a callback.
The status flag was being saved as a global variable. However,
calling nested enter_critical_section would overwrite this global
variable that was storing the previous flag and, when leaving the
last critical section, the restored status would be different from
the one expected. The proposed solution for this issue is to create
a global array to store the interrupt status flags for nested calls.
If using flow control with a high CTS the thread may be blocked forever
on the second transmit attempt due to waiting on the txdma semaphore.
The calling thread can then never make progress and release any
resources it has taken, thus may cause a deadlock in other parts of the
system.
The implementation differs in behavior from interrupt-driven TX and the
STM32F7 TXDMA . It should not implicitly wait on a taken semaphore but
return immediately and let the upper layers decide on what to do next.
Some APIs are implemented both in common code and CHIP-specific code,
and the link needs to be based on the implementation in CHIP, so move
NUTTX_CHIP_ABS_DIR before common src.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Because there is no pre-encoding length of the ssid, the ssid including
the Chinese characters whose length is less than 32 after encoding
cann't be translated.
For example, the ssid name is `word人`. After encoding it is `world\xe4\xba\xba` and will not be decoded.
Signed-off-by: liqinhui <liqinhui@xiaomi.com>
These flags are not used in the code.
SERIAL_HAVE_RXDMA and SERIAL_HAVE_TXDMA flags are used instead.
STM32_UART_TXDMA flag is not even defined in Kconfig
Connecting the static page tables to each other was done with the page
table virtual address (riscv_pgvaddr) when the page table physical address
is needed.
I can never remember whether the static page table list contains the
table's physical or kernel virtual address.. Add the fact as a comment
there.
Also add the limitations that come from this static page table approach
for Sv32.
The SSID can be configured with special symbols suach as single
quotations, double quotations and backslashes, which need to be escaped.
Signed-off-by: liqinhui <liqinhui@xiaomi.com>
