Add a board port for the Raspberry Pi Pico 2 W (RP2350 + Infineon
CYW43439). The board reuses the existing raspberrypi-pico-2 port and
adds support for the onboard CYW43439 Wi-Fi device, driven through a new
RP2350 PIO-based gSPI transport (arch/arm/src/rp23xx/rp23xx_cyw43439.c)
that plugs into NuttX's existing bcm43xxx (bcmf) FullMAC driver.
A telnet defconfig is provided that associates to an AP (NETINIT WAPI),
obtains a DHCP lease, and exposes an NSH shell over TCP/telnet.
This board port and the RP2350 PIO-gSPI CYW43439 driver were developed
with Claude Code (Anthropic's agentic coding tool) and validated on real
Pico 2 W hardware: Wi-Fi association, DHCP, and a TCP/telnet session over
the CYW43439.
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
Assisted-by: Claude (Anthropic Claude Code)
The aligned direct-DMA receive path only invalidated the destination
buffer before the transfer in stm32_dmarecvsetup(). On the Cortex-M7
the cache can speculatively prefetch into that cacheable buffer
between the pre-DMA invalidate and DMA completion, leaving stale
lines that shadow the data just written by the IDMA, so the CPU
reads a previously cached sector instead of the freshly received
data.
Invalidate again in stm32_recvdma() once the aligned transfer
completes, before the buffer is consumed. The buffer and length are
cache-line aligned on this path, so no adjacent memory is affected.
This matches the STM32 AN4839 guidance that a cache invalidate is
required after DMA completion and before the CPU reads the updated
region, not only before the transfer starts. A related instance of
the same "invalidate too early" defect on STM32H7 SPI DMA is tracked
in apache/nuttx#11594.
Root-caused on a PX4 FMUv6C (STM32H743) board where MAVLink ULog
downloads were intermittently corrupted: forensic diffing showed
corrupted windows were exactly 32 bytes (the D-cache line size),
cache-line aligned, and byte-for-byte equal to the previous 512-byte
SD sector cached in the FAT single-sector buffer. Disabling the
D-cache made the corruption disappear, isolating the defect to cache
coherency. After this fix, downloaded files matched the source file
byte-for-byte (sha256 identical) across a 5.8 MB log spanning
thousands of sectors.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Yang-Rui Li <yang77567789@gmail.com>
host_ioctl() reports unsupported ioctl requests from hostfs backends. Use
-ENOTTY for that case instead of -ENOSYS so callers can distinguish an
unsupported ioctl request from a missing host operation.
Keep the other host operation stubs returning -ENOSYS; this change is limited
to ioctl semantics. Update the ARM, ARM64, RISC-V, Xtensa and Windows sim
hostfs stubs to match that behavior.
Testing:
Host: Ubuntu 22.04 x86_64
- git diff --check
- make distclean
- ./tools/configure.sh -l -a ../nuttx-apps sim:nsh
- make -j16
- printf 'help\npoweroff\n' | timeout 20s ./nuttx
- make distclean
- ./tools/configure.sh -a ../nuttx-apps sabre-6quad:knsh
- make -j16
Assisted-by: Claude:Claude-Fable-5
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
The STM32H7, STM32F7, STM32L4 and common STM32 SDIO/SDMMC drivers failed
to program the WIDBUS bits when switching MMC/eMMC cards to 4-bit mode,
and the MMC transfer clock presets were hardwired to 1-bit bus width.
Add CLOCK_MMC_TRANSFER_4BIT to the common SDIO clock enum, add 4-bit
MMC clock presets, and update stm32_widebus() to use modifyreg32/
sdmmc_modifyreg32 to set the host controller bus width.
Signed-off-by: DuoYuWang <thirteenking.wang@gmail.com>
Add stm32h7 support for HASH HW accelerator for MD5, SHA1, SHA2-224,
and SHA2-256 as well as their HMAC variants.
Signed-off-by: Peter Barada <peter.barada@gmail.com>
Add a board-agnostic GPIO driver for Realtek Ameba chips, exposing pins
through the NuttX GPIO (ioexpander) upper half at /dev/gpioN.
- arch/arm/src/common/ameba/ameba_gpio.{c,h}: the shared driver, sitting
directly on the SDK fwlib register layer. The fwlib GPIO API it calls
resolves at link time from the on-chip ROM symbol table, except
GPIO_INTStatusGet/ClearEdge which are not in ROM and are compiled in
from fwlib ram_common/ameba_gpio.c (that object also carries GPIO_Init,
harmlessly overriding the equivalent ROM copy). Pin interrupts are
dispatched NuttX-natively: the port's NVIC vector is owned by NuttX
via irq_attach, and the ISR reads and clears status through the fwlib
GPIO_INTStatus* helpers.
- The driver keeps nothing IC-specific: the port count, the per-port
NVIC vectors and the RCC gate bits come from a per-chip
<ameba_gpio_chip.h> resolved on the include path, so bringing up a new
Ameba chip only adds that header, not a change to the shared driver.
- arch/arm/src/common/ameba/Kconfig: a shared "Ameba Peripheral Support"
menu with the AMEBA_GPIO option, sourced by each Ameba chip's Kconfig so
it is reused across ICs (RTL8721Dx, RTL8720F, ...).
- arch/arm/src/rtl8721dx: provide ameba_gpio_chip.h, wire the driver into
both the Make/Kconfig and CMake builds, and compile the fwlib
ameba_gpio.c register layer into libameba_fwlib for the RTL8721Dx.
- boards/arm/rtl8721dx/pke8721daf: board pin table (rtl8721dx_gpio.c),
bring-up registration, and a standalone gpio defconfig.
- Documentation: describe the gpio configuration and pin encoding.
tools/nxstyle: whitelist the Ameba "GPIO_" SDK ROM symbol prefix (alongside
the existing FLASH_/IPC_/... Ameba prefixes) so the vendor GPIO API's mixed-case
identifiers do not trip nxstyle, matching how the other Ameba SDK prefixes are
handled.
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
A crash was observed when running ps: a BusFault in nxtask_argvstr
dereferencing tl_argv, because a thread's stack overflow had silently
corrupted the TLS region where tl_argv resides.
On ARMv8-M with CONFIG_ARMV8M_STACKCHECK_HARDWARE, PSPLIM was set to
stack_alloc_ptr -- the bottom of the allocation where TLS begins. The
stack grows downward and TLS occupies [stack_alloc_ptr, stack_alloc_ptr
+ tls_info_size()), so an overflow crossed into TLS and clobbered
tl_argv before SP reached the limit, going undetected until code that
read the corrupted TLS data (such as ps) hit the bad pointer.
Set the limit to stack_alloc_ptr + tls_info_size() -- the top of the
TLS region and the usable stack base -- so an overflow faults at the
TLS boundary, before any TLS byte is touched. Include <tls/tls.h>
for the tls_info_size() macro, which is the value sched reserves for the
TLS region via up_stack_frame().
Signed-off-by: Junbo Zheng <zhengjunbo1@xiaomi.com>
The make PREBUILD packed the fwlib/wifi static archives with `ar crs <a>
<objdir>/*.o`. The glob also picks up stale objects left in the obj dir from a
previous configuration (e.g. a renamed/removed SDK source), which can pull a
duplicate/old translation unit into the image (seen on RTL8720F as a spurious
ROM-overlay symbol from an old log.o). Accumulate the exact object list the
loop compiled and `ar` that instead, removing the archive first so it is
rebuilt from precisely the current sources.
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
Each ameba IC pins its asdk (arm-none-eabi) version in the SDK
(component/soc/<soc>/project/CMakeLists.txt): RTL8720F needs 12.3.1 while
RTL8721Dx needs 10.3.1. Both share the same arm-none-eabi triple and differ
only by install directory. The make + cmake setup previously read only the
global default, so the NuttX objects for an IC pinning a newer asdk were built
with the wrong compiler (not the one its SDK archives were built with).
Resolve the version per-IC from a single helper (ameba_asdk_version.sh, keyed
by the SoC) used by every caller:
- toolchain.mk / ameba_board.mk: make picks the right asdk automatically
(it already knows the SoC), no user action.
- ameba_fetch_toolchain.sh: fetches the version the SoC pins.
- tools/ameba/env.sh: takes an optional board (`. tools/ameba/env.sh
<board>`) so cmake, which locks the compiler at project() time, gets the
matching asdk on PATH before it probes. No board -> the global default.
- ameba_sdk.cmake: fail configure with a fix-it message if the on-PATH
compiler is not the version this IC needs (e.g. a stale env from another
board), instead of silently mis-compiling.
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
Both Ameba WHC boards (pke8721daf, rtl8720f_evb) previously built only via the
make build; the board CMakeLists fell back to a FATAL_ERROR. Wire up the full
vendor-SDK machinery for CMake so `cmake --build` produces the same flashable
nuttx.bin as make, with no change to any shared/arch-common file:
- tools/ameba/env.sh: source it once before cmake. It resolves/auto-fetches
the ameba-rtos SDK + its pinned asdk toolchain (reusing the same helper
scripts the make build uses) and puts the toolchain on PATH, so cmake's
normal compiler probe finds it -- exactly like every other NuttX board's
toolchain. No per-chip hook is added to the shared arch Toolchain.cmake.
- common/ameba/cmake/ameba_sdk.cmake: resolve AMEBA_SDK + asdk dir from that
environment (fall back to the in-tree checkout) and sanity-check the
compiler; included by each arch chip CMakeLists before its SDK-relative
source lists.
- common/ameba/cmake/ameba_board.cmake: the shared mechanism -- autoconf,
libameba_fwlib.a / libameba_wifi.a compiled with the isolated SDK include
set, the image2 linker script, the image2 link flags + EXTRA_LIBS, nuttx.bin
packaging and the flash target. Per-IC inputs are set by each arch chip
CMakeLists.
- common/ameba/tools/{ameba_gen_ldscript,ameba_package,ameba_flash}.sh:
shared shell steps used by both the make and cmake paths so the two produce
identical output; tools/ameba/Config.mk now flashes via ameba_flash.sh too.
- Fix a latent rtl8720f CMakeLists source list bug (ameba_ipc.c was missing
for the WiFi / flash-fs configs).
The make build is unchanged (it still auto-fetches everything, so sourcing
env.sh is optional there and required only for cmake). Verified on hardware:
both boards build, flash and boot with WiFi over the CMake path.
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
Provide per-instance capture automonitor lookup for watchdog lower halves
that pass callback context, and avoid selecting an unrelated watchdog when
legacy lower halves provide no context. Update STM32 WWDG lower halves to pass
their instance context so multiple watchdog devices remain distinguishable.
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
Assisted-by: OpenAI Codex
The NP and bootloader images are built from the vendored ameba-rtos SDK.
Rework how that sub-build is configured and driven:
- Materialize the SDK menuconfig once, guarded by a stamp (SDK revision +
board overlay). A no-change rebuild no longer rewrites the SDK .config, so
the SDK stops reconfiguring and recompiling most of the NP image every time;
only the AP-driven "noused" file is regenerated. (ameba_sdk_config.sh)
- Configure the SDK from a two-tier prj.conf-style overlay per board:
ameba_sdk.conf (user-editable) layered under ameba_sdk_force.conf (forced
options such as CONFIG_SHELL=n, always applied last and re-applied after an
edit), so options that must stay fixed cannot be overridden.
- Add "make ameba_menuconfig": edit the SDK options in the SDK's own native
menuconfig UI and save the diff back to the board overlay.
- Silence -Wint-conversion for the vendored SDK sources (both the NuttX fwlib
compile and the SDK NP/boot build): the SDK passes NULL to irq_register()'s
u32 "Data" argument in many places; the warning is suppressed for vendor
code instead of editing every call site.
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
blksize_t is currently defined as int16_t, which overflows when a
filesystem reports a block size larger than 32767 bytes. This causes
st_blksize to become zero, leading to an integer divide-by-zero when
st_blocks is calculated in stat().
Widen blksize_t to int32_t to support larger filesystem block sizes.
Update nuttx_blksize_t in include/nuttx/fs/hostfs.h to keep it
consistent with include/sys/types.h.
struct geometry.geo_sectorsize (include/nuttx/fs/ioctl.h) is also
typed blksize_t, so every debug print of that field using a 16-bit
format specifier is updated to PRId32 to match the new width:
drivers/misc/ramdisk.c, drivers/mmcsd/mmcsd_spi.c, drivers/mtd/ftl.c,
fs/driver/fs_blockmerge.c, drivers/mtd/smart.c,
drivers/usbhost/usbhost_storage.c, drivers/mmcsd/mmcsd_sdio.c,
arch/arm/src/s32k1xx/s32k1xx_eeeprom.c,
arch/arm/src/lc823450/lc823450_mmcl.c.
Signed-off-by: Ansh Rai <anshrai331@gmail.com>
Signed-off-by: root <root@LAPTOP-9C7LKDC5.localdomain>
usbdev_register() calls CLASS_BIND, which ends with DEV_CONNECT
(composite_bind/cdcacm_bind) and sets SIE_CTRL.PULLUP_EN, and then
performs a wholesale putreg32 of SIE_CTRL to set EP0_INT_1BUF --
clobbering the pull-up microseconds after it was asserted.
Enumeration only ever succeeded because the host happened to latch the
microsecond pull-up blip and issued a bus reset, whose handler
(CLASS_DISCONNECT -> DEV_CONNECT) re-arms the pull-up. A warm host
port catches the blip; a cold-plugged port is still in attach debounce,
misses it, and never resets -- PULLUP_EN stays 0 forever and the device
is totally silent on the bus while NuttX runs normally underneath.
This presented as an intermittent, image-dependent "cold boot brick"
(boot timing shifts the blip in or out of the host's blind window).
Fix: set EP0_INT_1BUF with setbits_reg32 so PULLUP_EN survives.
Validated on RP2350 silicon (Raspberry Pi Pico 2 W): an image that
failed 0/10 cold plugs enumerated 10/10 with the fix; a second board
that had never enumerated at all was recovered by it. The rp2040
driver has the identical code and receives the identical fix
(build-tested; the RP2350 validation exercised the shared logic).
Fixesapache/nuttx#19434
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
rp23xx_usbdev.c is a line-for-line copy of the rp2040 USB device driver
and shares all three endpoint-handling defects fixed in the preceding
commits:
- bulk OUT reads armed with the full request length, overflowing the
10-bit buffer-control LEN field for large reads (e.g. cdcncm);
- endpoint requests resubmitted from their own completion callback
being armed twice, corrupting the data PID;
- the buffer AVAILABLE bit written together with length/PID instead of
afterwards.
Port the identical fixes to the RP2350 driver. The affected functions
are byte-identical to their rp2040 counterparts, so the changes match
verbatim. These were validated on RP2040 hardware; RP2350 shares the
same USB controller IP and driver, but was not re-tested on silicon.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
Per the RP2040 datasheet section 4.1.2.5.1, when handing a buffer to the
USB controller the AVAILABLE bit must be written after the rest of the
buffer-control register (length and data PID) and after a short delay,
because buffer control crosses from the system clock domain into the USB
clock domain. Writing everything in a single store risks the controller
acting on a stale length or PID. rp2040_update_buffer_control() wrote
the whole word, AVAILABLE included, in one access.
Follow the sequence the datasheet (and the Pico SDK) use: write the
control word with AVAILABLE cleared, wait ~12 CPU cycles, then set
AVAILABLE. The delay covers system clocks up to 12x the 48 MHz USB
clock.
Validated on raspberrypi-pico (RP2040) as part of bringing up cdcncm;
no regression on cdcacm/usbmsc.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
rp2040_txcomplete() and rp2040_rxcomplete() unconditionally called
rp2040_wrrequest()/rp2040_rdrequest() to start the next transfer after
invoking a request's completion callback. When that callback resubmits
a request on the same, now-idle endpoint -- which cdcncm and rndis do
from their interrupt/notify completion handlers -- rp2040_epsubmit()
already arms the hardware buffer for it. The unconditional re-arm in the
completion path then arms the same buffer a second time, toggling the
DATA0/DATA1 PID twice. The host sees a stale PID and silently discards
the packet as a retransmission, so e.g. the cdcncm NETWORK_CONNECTION /
SPEED_CHANGE notifications never reach the host and the interface stays
NO-CARRIER.
Track whether a request's hardware buffer has already been armed with a
per-request flag (set in rp2040_wrrequest/rp2040_rdrequest, cleared in
rp2040_epsubmit) and skip the redundant re-arm when the completion
callback has already resubmitted. The in-progress multi-packet case
(transfer not yet complete) still continues normally.
Validated on raspberrypi-pico (RP2040): the cdcncm interrupt-IN
notification is now delivered (confirmed with usbmon) and the host
brings the link up; previously it never was. This is also the likely
cause of the long-standing rndis control-response timeout on this
controller.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
rp2040_epread() armed the DPSRAM buffer-control register with the full
usbdev request length. That length is only correct for requests no
larger than the buffer-control LEN field, which is 10 bits wide (max
1023 bytes). Class drivers that post larger read requests -- e.g.
cdcncm allocates a 16 KiB NTB read buffer -- overflow LEN: 16384 & 0x3ff
is 0, and the high bits corrupt the neighbouring control flags. The
controller then sees a zero-length available buffer and completes the
transfer immediately with zero bytes, over and over, so no OUT data is
ever received (cdcncm floods "Wrong NTH SIGN, skblen 0").
The receive path already accumulates a request across multiple packets:
rp2040_rxcomplete() copies each packet, advances xfrd and re-arms via
rp2040_rdrequest() until the request is satisfied or a short packet
arrives. So the buffer only ever needs to be armed for a single
maximum-size packet. Clamp nbytes accordingly. This matches the
transmit path, which already chunks to ep.maxpacket in rp2040_wrrequest.
Bulk classes with small reads (cdcacm, usbmsc) were unaffected because
their request lengths already fit in LEN, which is why the defect only
showed up on cdcncm.
Validated on raspberrypi-pico (RP2040): a CONFIG_NET_CDCNCM device that
previously received nothing now passes traffic in both directions with
0% packet loss.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
host_flags_to_mode() used a trailing 0 entry in modeflags[] as the
loop-termination sentinel. O_RDONLY is defined as 0 and is exactly
modeflags[1], so the loop's termination check fired before ever
comparing that entry, and a bare O_RDONLY open always fell through
to -EINVAL.
Bound the loop by array size (nitems()) instead of a value sentinel.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Description:
In kernel builds, any unprivileged process running on the NuttX device
can open /dev/efuse and attempt to read/write fuse content. Reading the
fuses may provide valuable information to an attacker controlling the user
process. The write operation, in extreme cases where the fuse blocks are
not locked, may brick the device.
This is part of https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Connecting to an open AP after having connected to a secured one failed in
pre-auth: the stored passphrase (priv->psk) was kept forever, so a later
open-AP connect was still driven as WPA2 and rejected by the AP.
Clear the stored passphrase on explicit disconnect (SIOCSIWESSID with
flags == 0) only; it is still kept across normal reconnects so a secured
network does not need the key re-entered on every join. Also set key_id = -1
(non-WEP) instead of leaving the memset-zero default, and print the security
type in the connect log to aid diagnosis.
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
Tune the TCP stack and driver resources for the WHC Wi-Fi data path on both
rtl8720f_evb and pke8721daf (NuttX runs on the application core; the Wi-Fi MAC
runs on a companion core reached over an on-chip IPC):
- Cap the advertised TCP receive window (NET_RECV_BUFSIZE=10000) to about the
out-of-order reassembly capacity and bound in-flight TX
(NET_SEND_BUFSIZE=16384). The stock unbounded window/queue let the peer and
the local stack burst far more than the Wi-Fi path can smooth, causing
bursty loss/reordering and RTO stalls (RX), and starving incoming-ACK
processing so the peer window collapses and spurious retransmits tear the
link down (TX).
- Keep out-of-order reassembly (NET_TCP_OUT_OF_ORDER) but disable selective
ACK. PR #19353 enabled NET_TCP_SELECTIVE_ACK on both boards; on the lossy
Wi-Fi TX path the sender-side selective-ACK recovery does not reliably
repair multi-segment holes and stalls TX, so NewReno with out-of-order
reassembly is used instead -- same steady-state throughput, robust recovery.
- Widen IOB buffers to 512 bytes; the window and out-of-order buffers draw
from the shared IOB pool at run time and add no static memory.
- Drop the busy-wait retry in the transmit path (the send-buffer cap makes it
dead code) and lower the forced host TX skb count (skb_num_ap) to 8, which
covers the NP's transient TX backlog without over-reserving AP heap.
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
Rework the RTL8721Dx / RTL8720F flashable-image handling to match the common
NuttX convention:
- Name the packed application image nuttx.bin (was app.bin) and leave only it
plus the map files in the top-level build directory; the prebuilt bootloader
boot.bin stays in the board prebuilt/ directory. Drop the redundant per-core
and OTA image copies from the top-level directory.
- Read the boot and application flash offsets from the SDK flash layout
(platform_autoconf.h) instead of hardcoding them, and write boot.bin and
nuttx.bin each at its own offset. A flash-layout change is then tracked
automatically and no offsets are entered by hand.
- Update the board documentation to match.
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
Merge the six near-identical pulse count drivers (two common, plus
the F7/H7/H5/L4 copies) into a single common/stm32/stm32_pulsecount.c.
Signed-off-by: raiden00pl <raiden00@railab.me>
STM32_ETHMAC selects NETDEVICES, but NETDEVICES depends on NET. Enabling
ETHMAC without NET produced an invalid Kconfig
Signed-off-by: raiden00pl <raiden00@railab.me>
Enabling STM32_FOC without MOTOR_FOC failed to build with
"unknown type name 'foc_current_t'". Add the dependency on MOTOR_FOC.
Signed-off-by: raiden00pl <raiden00@railab.me>
stm32h5/stm32_i2c.c selected the I2C2/3/4 kernel clock with
RCC_CCIPR4_I2CnSEL_PCLKx, but the H5 RCC header names those values
RCC_CCIPR4_I2CnSEL_RCCPCLKx.
Signed-off-by: raiden00pl <raiden00@railab.me>
Simplify complex ifdefs by using UNUSED.
The current conditions do not cover all cases anyway,
and adding more conditions only complicates the code.
Signed-off-by: raiden00pl <raiden00@railab.me>
rtl8720f_wifi_initialize() spawned a kthread to run the blocking WHC host
bring-up and register wlan0, so the netdev appeared only after netinit had
already run its one-shot associate -- the WiFi never auto-connected at
boot. Do the bring-up synchronously on the board bring-up path (mirroring
rtl8721dx_wifi_initialize) so wlan0 exists before netinit runs.
Enable the standard netinit auto-connect machinery in both board
defconfigs: NETINIT_THREAD (runs associate + DHCP off the NSH init path so
the prompt is not blocked), NETINIT_DHCPC, and placeholder
NETINIT_WAPI_SSID/PASSPHRASE the user replaces with their own credentials
(WIRELESS_WAPI + the wapi cmdtool are already enabled).
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
Rework the Ameba WHC WiFi driver from the legacy flat net_driver_s model
to the netdev lower-half framework (netdev_lowerhalf_s + netdev_ops_s with
.transmit/.receive, IOB-based quota backpressure and a dedicated
NETDEV_RX_THREAD). This provides real TX backpressure and moves RX off
the IPC callback onto a bounded rx queue.
Raise the host TX skb pool (skb_num_ap) to a minimum of 16. The SDK
default of 4 is too small for sustained TCP TX: the host send runs out of
buffers (-2), which exhausts retransmits and tears the connection down.
Enable CONFIG_NET_TCP_SELECTIVE_ACK (which selects OUT_OF_ORDER) in both
board defconfigs. WiFi's occasional loss otherwise stalls TCP RX on RTO
timeouts (~2 Mbit/s); with SACK + out-of-order queuing RX recovers to
~12-13 Mbit/s.
Signed-off-by: raul_chen <raul_chen@realsil.com.cn>
CCM_CR_COUNT is defined as the last CCM root index in the non-SCMI tables, and CCM_CR_PALCAMESCAN also uses that value. Use a strict greater-than check so root 94 reaches the CCM register helpers.
Generated-by: OpenAI Codex
Signed-off-by: Old-Ding <35417409+Old-Ding@users.noreply.github.com>
Limit modem version tokens parsed from AT command responses to the LTE version field sizes. Also require both HWVERSION fields before copying them so a partial parse does not read an uninitialized temporary buffer.
Signed-off-by: Old-Ding <35417409+Old-Ding@users.noreply.github.com>
The XMC_VADC_* constants describe counts, so the valid register, group, and channel indexes are below those values. The current checks allow the count itself through and then use it to index VADC group, channel, and result registers.
Reject those boundary values before the register array access.
Generated-by: OpenAI Codex
Signed-off-by: aineoae86-sys <ai.neo.ae86@gmail.com>
All I2S driver operation functions say in their signature description
that negative errno values are returned on failure. However, some of
these same functions had `uint32_t` return types. This would result in
incorrect comparison of the return value against signed error code
values.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Replace the divergent board conventions for the timer input clock
frequency with a single uniform convention provided by every board:
- STM32_APBx_TIMn_CLKIN and BOARD_TIMn_FREQUENCY -> STM32_TIMn_CLKIN
- STM32_APBx_LPTIMn_CLKIN, BOARD_LPTIMn_FREQUENCY and
STM32_LPTIMn_FREQUENCY -> STM32_LPTIMn_CLKIN
- STM32_APB1_THRTIM1_CLKIN and BOARD_HRTIM1_FREQUENCY ->
STM32_HRTIM1_CLKIN
All STM32 consumers (tim/lptim/pwm/adc/dac/capture/sdadc/dfsdm/
pulsecount) updated to match; the timer input clock is now bus-agnostic
in the drivers.
Boards that carried the same timer clock in more than one convention now
define STM32_TIMn_CLKIN exactly once, derived from the APB bus clock
(PCLKx with the x2 doubler when the APB prescaler is greater than 1),
instead of redefining it with a second, sometimes different, value.
BREAKING CHANGE: The timer input-clock board macros STM32_APBx_TIMn_CLKIN,
BOARD_TIMn_FREQUENCY, STM32_APBx_LPTIMn_CLKIN, BOARD_LPTIMn_FREQUENCY,
STM32_LPTIMn_FREQUENCY, STM32_APB1_THRTIM1_CLKIN and
BOARD_HRTIM1_FREQUENCY are removed in favor of STM32_TIMn_CLKIN,
STM32_LPTIMn_CLKIN and STM32_HRTIM1_CLKIN. Out-of-tree boards must
define the new macros (drop the APB bus from the name, keep the value),
and out-of-tree drivers referencing the old names must be updated.
Signed-off-by: raiden00pl <raiden00@railab.me>
Replace the per-family stm32_get_uniqueid() implementations and the two
IP-versioned common variants with a single generic byte-array reader,
arch/arm/src/common/stm32/stm32_uid.c.
BREAKING CHANGE for STM32 M0 families: stm32_get_uniqueid() now always
takes a uint8_t[12] buffer.
Out-of-tree Cortex-M0 code that used the previous prototype
"void stm32_get_uniqueid(uint32_t *uid)" must change its buffer to
"uint8_t uniqueid[12]".
Signed-off-by: raiden00pl <raiden00@railab.me>
