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-C3'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.
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'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.
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.
Devices connected to the same USB bus should have unique function addresses.
This was not true for root hubs with multiple ports. After this change,
enumeration is more reliable on the sama5d3-xplained board when both root hub
ports are used.
This change amounts to using one usbhost_devaddr_s object per root hub
instead of one per root hub port. For the majority of boards only one
root hub port is available so no change in behavior should be expected.
Currently only Port UART0 is supported for Allwinner A64. This PR adds support for all UART Ports: UART1 to UART4. (Except R-UART, which is a special low-power UART)
This is required for the upcoming LTE Modem Driver (Quectel EG25-G) for PINE64 PinePhone, which uses UART3. [(Details here)](https://lupyuen.github.io/articles/lte2)
The code was adapted from the NuttX UART Driver for Allwinner A1X: [`a1x_serial.c`](https://github.com/apache/nuttx/blob/master/arch/arm/src/a1x/a1x_serial.c)
`arch/arm64/src/a64/a64_serial.c`: Added ports UART1 to UART4, based on [`a1x_serial.c`](https://github.com/apache/nuttx/blob/master/arch/arm/src/a1x/a1x_serial.c)
`arch/arm64/src/a64/a64_serial.h`: Added IRQs for UART1 to UART4. Moved UART Base Addresses to `a64_memorymap.h`
`arch/arm64/src/a64/hardware/a64_memorymap.h`: Added UART Base Addresses for UART0 to UART4
`arch/arm64/src/a64/Kconfig`: Added UART1 to UART4 to Allwinner A64 Peripheral Selection menu
`boards/arm64/a64/pinephone/configs/lcd/defconfig`, `lvgl/defconfig`, `nsh/defconfig`, `sensor/defconfig`: Fixed `UART1_SERIAL_CONSOLE` to `UART0_SERIAL_CONSOLE`
This commit aims to enable the use of ROM functions on ESP32-S2.
This is done by creating the required syscall stubs table and adding the missing symbols to the linker script.
This commit aims to enable the use of ROM functions on ESP32.
This is done by creating the required syscall stubs table and adding the missing symbols to the linker script.
These series have the following GPIO ports:
- STM32F03X: A to D, and F
- STM32F05/07/09X: A to F
- STM32G0X: A to F
- STM32L0X: A to E, and H
Signed-off-by: Takumi Ando <t-ando@advaly.co.jp>
compile error log:
common/arm64_arch_timer.c: In function 'arm64_tick_max_delay':
common/arm64_arch_timer.c:178:12: error: conversion from 'long unsigned int' to 'clock_t' {aka 'unsigned int'} changes value from '18446744073709551615' to '4294967295' [-Werror=overflow]
178 | *ticks = UINT64_MAX;
| ^~~~~~~~~~
Signed-off-by: hujun5 <hujun5@xiaomi.com>
At present, the serial drivers qemu_serial.c and serial_pl011.c on the fvp-v8r and qemu platforms in arm64 are duplicated
and need to be merged. The plan is to place them under the drivers\serial directory to create a common code module,
so that both fvp-v8r and qemu can use the same code.
In the future, if new platforms use pl011 serial ports, they can also be directly reused
Signed-off-by: hujun5 <hujun5@xiaomi.com>
If the CONFIG_MMCSD_SDIOWAIT_WRCOMPLETE is enabled and the
card is found to be ready in the waitenable call. Then
we do not need a Watchdog nor to configure the pin for
IRQ to detect ready.
This was reported as an error, and it is not, it simply means
we do not have to wait.
Summary:
Keeping this option out of depend on any common serial.
Using the option, need to implement xxx_lowputc.S/c.
You can also logging the booting message through rewriting
fake arm64_lowputc with other debug method (eg semihosting,
ARM debug channel etc).
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
1. arm64/makefile: preprocess link script to make configure more flexibly
2. arm64/EXTRA_LIBS: link all staging library
Signed-off-by: chao an <anchao@xiaomi.com>
The following message is printed continuously and the nsh
shell is unusable on sama5d3-xplained.
"OHCI ERROR: Unhandled interrupts pending: 000001". This
happens when a keyboard is removed and reinserted on
port3 (lower port) while a bluetooth dongle is in port2.
- putreg32() is used the wrong way around (reg, val) instead of (val, reg)
- MPFS_SPI_FRAMESIZE is not a register, FSIZE is the name
- Clear all interrupts _before_ writing the FIFO, this prevents a race
condition where a short transmission completes before the interrupt is
enabled.
in SMP, signal processing cannot be nested, we use xcp.sigdeliver to identify whether there is currently a signal being processed, but this state does not match the actual situation
One possible scenario is that signal processing has already been completed, but an interrupt occurs, resulting in xcp.sigdeliver not being correctly set to NULL,
At this point, a new signal arrives, which can only be placed in the queue and cannot be processed immediately
Our solution is that signal processing and signal complete status are set in the same critical section, which can ensure status synchronization
Signed-off-by: hujun5 <hujun5@xiaomi.com>
In the interrupt context, we should first save the interrupt context and modify the interrupt register
to execute the signal processing program immediately after exiting the current interrupt
Signed-off-by: hujun5 <hujun5@xiaomi.com>
