During the serial reconfiguration from bootloader to the
NuttX a trash character "?" (Unicode replacement U+FFFD)
was printed in the screen.
This fix was discovered by Sylvio Alves from Espressif!
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.
Considering that the future fb needs to achieve dynamic resolution, the address and size of fbmem will be redistributed on the bottom driver side, so remove fbmem, fblen, and bpp cached in fb_chardev_s, and change it to call getplaneinfo every time to re-acquire panel info from the bottom driver. Avoid cache coherency problems.
Signed-off-by: pengyiqiang <pengyiqiang@xiaomi.com>
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setcancelstate.html
The pthread_setcancelstate() function may fail if:
[EINVAL]
The specified state is not PTHREAD_CANCEL_ENABLE or PTHREAD_CANCEL_DISABLE.
The pthread_setcanceltype() function may fail if:
[EINVAL]
The specified type is not PTHREAD_CANCEL_DEFERRED or PTHREAD_CANCEL_ASYNCHRONOUS.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_once.html
If an implementation detects that the value specified by the once_control
argument to pthread_once() does not refer to a pthread_once_t object
initialized by PTHREAD_ONCE_INIT, it is recommended that the function
should fail and report an [EINVAL] error.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_detach.html
If an implementation detects that the value specified by the thread argument
to pthread_detach() does not refer to a joinable thread, it is recommended
that the function should fail and report an [EINVAL] error.
If an implementation detects use of a thread ID after the end of its lifetime,
it is recommended that the function should fail and report an [ESRCH] error.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
ld: warning: arch_setjmp_x86_64.o: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
/usr/bin/ld: warning: nuttx.rel: requires executable stack (because the .note.GNU-stack section is executable)
The linker is instructed to make the stack non-executable with the
switch: `-z noexecstack`.
More information can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136
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`
Commit 4d6a8663fa made pipes and
named pipes block when opening for O_WRONLY or O_RDONLY. Local
sockets, however, require `local_open_client_tx` to be non-blocking
to enable the server side to prevent the server side from blocking.
If set otherwise, it would deadly block. This commit sets the FIFO
as non-blocking temporarily, open the TX side and, if originally
blocking - restores it to that state.
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>
added IPV6_RECVHOPLIMIT support so that fd of SOCK_RAW ICMPV6 can obtain ttl
information, some network related tools use this feature.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
utils/net_cmsg.c: In function 'cmsg_append':
utils/net_cmsg.c:82:23: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith]
82 | msg->msg_control += cmsgspace;
| ^~
cc1: all warnings being treated as errors
Using void pointers in arithmetic operations is a GCC extension, it is
not supported by the standard. Because what is the size of a void ?
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>
RESTORE_FACTORY used to reset the device
FACTORY_INQUIRY used to reset the device but need user confirmed.
Signed-off-by: minjian.tang <minjian.tang@aqara.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.
