When porting external projects to NuttX using uncrustify could help
to convert "alien code" (maybe we are the aliens) to NuttX coding
style.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Assisted-by: Hermes Agent using Deepseek-4-pro
Program names containing '-' (for example, renaming hello to
hello-world via PROGNAME) previously generated an invalid identifier
<NAME>_main when constructing the main= compiler definition and the
APP_MAIN target property used during builtin list generation. This
caused the CMake build to fail because '-' is not a valid character in
a C identifier.
This mirrors the Make-based fix (Application.mk's PROGSYM) for the
traditional build.
Introduce NAME_SYM, a sanitized copy of NAME with '-' replaced by '_',
and use it only where an internal C identifier is required: the
main= COMPILE_DEFINITIONS property and the APP_MAIN target property.
Leave NAME unchanged everywhere else, including CMake target/output
names and the APP_NAME property, where hyphens are valid.
The standalone/loadable executable path (MODULE/DYNLIB/kernel build)
does not rename main() and therefore requires no sanitization because
each executable is linked independently rather than merged into a
shared builtin image.
Testing (WSL2 Ubuntu, x86_64):
- BOARD_CONFIG=sim/nsh, CONFIG_EXAMPLES_HELLO_PROGNAME="hello-world":
clean CMake configure/build; 'hello-world' runs and prints
'Hello, World!!'
- Reverted to CONFIG_EXAMPLES_HELLO_PROGNAME="hello": reconfigured
and rebuilt; 'hello' runs and prints 'Hello, World!!' (no
regression)
Fixes#19447
Signed-off-by: Ansh Rai <anshrai331@gmail.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>
Without SCHED_WAITPID, NSH cannot waitpid() on a spawned builtin application,
so every foreground builtin (e.g. wapi) is run in the background and NSH echoes
"<cmd> [pid:priority]" instead of blocking until it finishes. Enable
CONFIG_SCHED_WAITPID (the setting used by the large majority of nsh defconfigs)
so foreground builtins run synchronously with a correct exit status and no
spurious [pid:priority] echo.
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>
CI builds with -Werror and the board's build carried thousands of
warnings, all rooted in the vendor SDK integration:
- The NMSIS riscv_encoding.h redefines 32 CSR macros that NuttX's
<arch/csr.h> (pulled in through <nuttx/irq.h>) already defines with
its own encodings. No -Wno flag covers macro redefinitions, so the
SDK patch now undefines those names right before the NMSIS
definitions. Same treatment for COMPILE_TIME_ASSERT in
wifi_management.h.
- The vendor sources are not NuttX-warning-clean (undefined macros in
#if, %d for uint32_t, shadowed locals, K&R prototypes, ...); add the
matching -Wno suppressions scoped to this chip's build.
- Fix the port's own warnings properly: gd32vw55x_eclic.h redefined
CSR_MINTSTATUS with the Nuclei address (0x346) over the standard
CLIC one in csr.h (renamed to CSR_NUCLEI_MINTSTATUS), an unused
variable in gdwifi_transmit() and a dead function in
wrapper_nuttx.c.
All seven configurations now build with "-Wno-cpp -Werror" (the CI
flags). Smoke-validated on hardware: Wi-Fi WPA2 association and ping,
BLE advertising, connect and GATT write.
Assisted-by: Claude Opus 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
A connection stops the legacy advertising set and the vendor stack
leaves it stopped, so after the first central connected (or aborted
the attempt) the device was never discoverable again until a reset.
Register a connection callback and restart the advertising set with
ble_adv_restart() on every disconnection event. This covers both the
clean disconnect and the aborted-connection case: an incomplete
connection holds the (single) link until the supervision timeout, and
its disconnection event then restarts the advertising the same way.
Validated on hardware (GD32VW553K-START): repeated
scan/connect/write/disconnect cycles from a Linux central all find the
device advertising again after the previous cycle, where it previously
required a reset after the first connection.
Assisted-by: Claude Opus 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Associating to a WPA3 (SAE) network faulted inside the prebuilt vendor
supplicant (load access fault in the elliptic-curve math of the SAE
handshake, wifi_mgmt task). The port is WPA2-only, so refuse what the
supplicant cannot complete:
- Undefine CONFIG_WPA3_SAE in the build_config.h shim. This activates
the vendor's own fallback in wifi_netlink.c: the SAE/OWE AKMs are
stripped from the connection config and the SAE auth algorithm is
never selected, so a WPA3-transition AP (WPA2/WPA3 mixed) now
associates through WPA2-PSK. The flag only gates code, not struct
layout, so the prebuilt libraries are unaffected.
- Refuse an SAE/OWE/802.1X-only network up front in the connect path
with ENOTSUP and a console message naming the unsupported AKM bitmap,
instead of an obscure association failure.
Validated on hardware (GD32VW553K-START), all three cases: a WPA2
network still associates (four-way handshake, DHCP, ping); a
WPA2/WPA3 transition hotspot ([RSN:WPA-PSK,SAE CCMP/CCMP][MFP])
associates through WPA2-PSK, gets a lease and pings the gateway
(it crashed before this change); and a WPA3-only hotspot is now
refused with
gdwifi: 'wpa3test' offers no supported AKM (bitmap 0x200): WPA3/SAE,
OWE and 802.1X are not supported, WPA2-PSK only
where it previously crashed.
Assisted-by: Claude Opus 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Explain how drivertest applications are selected and run, list the current test categories, and document the watchdog reset and notifier test behavior.
Assisted-by: OpenAI Codex
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
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>
New RISC-V chip port for the GigaDevice GD32VW55x (Nuclei N307, Wi-Fi 6
and BLE 5.3 combo), with the GD32VW553K-START board.
Core:
- ECLIC interrupt controller, clock tree (160 MHz / 40 MHz HXTAL),
64-bit machine timer, serial (USART0/UART1/UART2) and RTC.
- The instruction cache must be enabled in head.S or the UART drops
characters under load; the mask ROM uses the first 0x200 bytes of SRAM
so the image is linked at 0x20000200; the RTC needs PMU_CTL0.BKPWEN or
the register writes are silently discarded.
- The ECLIC only auto-clears the interrupt pending bit in hardware-vectored
mode, so the trap dispatch clears it for edge-triggered sources or they
re-fire forever (level-triggered peripherals clear their own).
Peripherals: DMA (8 channels), GPIO + EXTI, SPI (optional DMA), I2C0/I2C1
(the new STM32-v2-style IP, not the GD32F4 one), ADC, PWM and input
capture on the timers, both watchdogs, PROGMEM, TRNG and CRC. All use
the standard NuttX lower-half interfaces and direct register access, not
the vendor SPL. Three user LEDs (GPIOC), and a software reset through the
Nuclei SysTimer.
Internal flash: it is a system-in-package NOR die behind the real-time
decryption block, so it is not programmed through the FMC registers -- the
driver goes through the mask ROM API (rom_flash_*), the same way the
vendor code does. PROGMEM can be mounted as LittleFS; the region sits
below the Wi-Fi NVDS and must not overlap it.
Wi-Fi (wlan0), station and softAP:
- The MAC/PHY, RF and WPA supplicant are linked as prebuilt BSD-3
libraries. They are RTOS-agnostic, so the OS binding is a sys_* facade
on NuttX primitives (gdwifi/wrapper_nuttx.c). Critical sections mask by
ECLIC priority threshold, not by disabling every interrupt, or the MAC
misses its microsecond deadlines.
- The lwIP stack of the SDK is not used: the interface is a
netdev_lowerhalf driver driven by the standard tools (wapi, ifup, renew,
ping, dhcpd). EAPOL is handed to the supplicant instead of the IP
stack. The lowerhalf "priority" field is the work-queue id (HPWORK/
LPWORK), not a task priority -- a wrong value makes receive() never run
and every packet is dropped.
- The vendor gives the radio 32 KB of shared SRAM as an extra heap; this
needs CONFIG_MM_REGIONS >= 2 or the kernel silently drops the region.
- The DHCP client needs CONFIG_NETUTILS_DHCPC_BOOTP_FLAGS=0x8000 so the
server answers the OFFER by broadcast.
- softAP (wapi master mode -> wifi_management_ap_start): the single-VIF
firmware does station or AP at a time. Use WPA2, not WPA3: the SAE
handshake is deep on the stack and overflows the elliptic-curve crypto
with the default task stacks, so the Wi-Fi configs raise
CONFIG_INIT_STACKSIZE/DEFAULT_TASK_STACKSIZE.
Vendor SDK: cloned by the build at "context" time, pinned to a validated
commit and patched in place -- so CI can build with nothing preinstalled,
the same pattern as esp-hal-3rdparty. The prebuilt libraries are built
for the hard-float ilp32f ABI.
BLE 5.3, marked EXPERIMENTAL and off by default: the prebuilt libble is an
all-in-one controller plus RivieraWaves host (GAP/GATT/SMP inside the blob)
with no HCI transport, so the port drives the vendor host directly
(ble_adp_*, ble_adv_*, ble_gap_*) instead of registering a bt_driver_s.
The SDK's radio interrupt handlers must be attached to the NuttX IRQ table
(they are reached through the ECLIC hardware vector table in the vendor
build); attaching also keeps --gc-sections from dropping them. It ships
with no configuration; enabling it advertises as "NuttX", connectable.
Boards: gd32vw553k-start with nsh, wapi, sta_softap, periph and littlefs
configurations, and the board added to the CI build list.
Tested on hardware (GD32VW553K-START): NSH, the peripheral drivers
(TRNG entropy and the LEDs exercised), LittleFS (write, read, survives a
reboot), the full Wi-Fi station path (scan, WPA2, DHCP, ping to the
internet), the softAP (a client associates with WPA2, gets an address
from the board's DHCP server, and pings the board), and BLE (advertises as
"NuttX"; a central connects and enumerates the GATT database).
Assisted-by: Claude Opus 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Summary
Permissions (Part 3)
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.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
Impact
See https://github.com/apache/nuttx/issues/19410
Testing
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Three defects that together prevented macOS from ever mounting a
composite USBMSC function (Linux was mostly unaffected because its
probe sequence and recovery timing never exercised these paths):
1. usbmsc_setup() compared the class-request wIndex against the
compile-time constant USBMSC_INTERFACEID (= CONFIG_USBMSC_IFNOBASE,
i.e. 0) instead of the composite-assigned priv->devinfo.ifnobase.
In composite mode the MSC interface number is nonzero, so
GET MAX LUN, Bulk-Only Mass Storage Reset, and GET/SET INTERFACE
all failed the index check and stalled EP0. Standalone MSC is
unaffected (ifnobase == 0), which is why this went unnoticed.
2. usbmsc_deferredresponse() has its entire body inside
#ifndef CONFIG_USBMSC_COMPOSITE, so the deferred EP0 status stage
for MSRESET/SETINTERFACE was never sent in composite mode and the
host's Bulk-Only reset timed out. (Unreachable before fix 1 --
MSRESET used to stall at the wrong-interface check.) Compile the
body in composite mode too, but suppress the worker's deferred
response for SETCONFIGURATION there: the composite driver answers
that request itself, and a duplicate zero-length packet corrupts
the EP0 state.
3. usbmsc_cmdfinishstate() stalled the bulk IN endpoint whenever a
device-to-host command left a residue, even when the response had
already been sent and terminated by a short packet (or ZLP). The
stall is BOT-legal (USB MSC BOT 6.7.2) but gratuitous: the short
packet already ended the data phase and the residue is reported in
dCSWDataResidue. Hosts such as macOS answer any bulk-IN halt during
device probing with a full Bulk-Only reset sequence, which costs
seconds per command or aborts the probe entirely (macOS probes
MODE SENSE(6) with allocation lengths that exceed the response;
Linux's probe does not). Only halt the endpoint when nothing
terminated the data phase.
Root-cause analysis and host traces in apache/nuttx#19435.
Validated on RP2350 silicon (Raspberry Pi Pico 2 W, composite
CDC-ACM + CDC-NCM + USBMSC): GET MAX LUN answers 1 LUN (previously
EP0 stall and a garbage LUN count on macOS), MSRESET completes 10/10
(previously ETIMEDOUT), MODE SENSE(6) alloc=0xC0 returns short data
plus a CSW with dCSWDataResidue and zero bulk-IN stalls across the
exact-length suite, and macOS now mounts the volume (together with the
companion DCD fixes).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
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>
The existing CRYPTO_AES_CTR is the RFC 3686 profile: the last 4 bytes of
the key are a nonce, the IV is 8 bytes and only the low 32 bits of the
counter block are incremented. SSH aes128/192/256-ctr (RFC 4344) instead
uses the key as-is (no embedded nonce) and treats the whole 16-byte IV as
the initial counter block, incremented as a 128-bit big-endian integer,
with the first keystream block being E(IV).
Add CRYPTO_AES_CTR_SSH as a new enc_xform mirroring the CRYPTO_CHACHA20_DJB
addition. It reuses struct aes_ctr_ctx and the AES block; only setkey (full
key, no nonce), reinit (full 16-byte counter) and crypt (encrypt-then-
increment over all 16 bytes) differ from the RFC 3686 variant.
Keystream validated against `openssl enc -aes-128-ctr`, including a counter
that carries across byte boundaries and a non-block-aligned tail.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
sys_callN() wraps a bare ecall and calls no other function, so the
compiler treats it as a leaf function: with frame pointers enabled,
it only needs to spill the caller's s0, which it places in what
up_backtrace()'s fp-chain walk assumes is ra's stack slot, while the
real ra slot is never written. sched_backtrace() then misreads that
slot as the return address for this frame, either resolving to a
bogus symbol or, if the adjacent garbage happens to look
out-of-range, terminating the backtrace early.
Add "ra" to the ecall clobber list so the compiler spills/reloads ra
around the ecall like a normal call site, keeping ra and the saved
s0 in their expected slots. Gate this on
CONFIG_FRAME_POINTER && CONFIG_SCHED_BACKTRACE, the only combination
where up_backtrace()'s fp-chain walk is both valid (FRAME_POINTER)
and actually exercised (SCHED_BACKTRACE); other configurations keep
the original "memory"-only clobber and pay no extra cost.
This only fixes the syscall boundary. Leaf functions that do not
cross a syscall (e.g. up_idle()) can still lose their ra slot the
same way and are not addressed here.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
up_backtrace() on a different tcb dereferences that task's own stack
to walk its frame pointer chain, but never selected that task's
address environment first. Under CONFIG_ARCH_ADDRENV each task's
stack lives behind its own page tables mapped at the same fixed
virtual range, so reading tcb->stack_base_ptr without first switching
to that task's addrenv reads whatever physical page the caller's own
mapping of that virtual range happens to point to, not the target
task's real stack. A cross-tid dumpstack of a task running in a
different address environment therefore returns garbage or an
all-zero backtrace instead of failing cleanly or resolving the real
call chain.
Add an addrenv parameter to backtrace() and select the target tcb's
addrenv_own only around the two dereferences that read the target's
saved ra/fp (ra = *(fp - 1), next_fp = *(fp - 2)), then restore the
caller's own addrenv before writing the result into buffer. buffer
belongs to the caller, not the target tcb, so it must always be
written back in the caller's own address environment; writing it
while the target's addrenv is still selected would corrupt the
access instead of fixing it.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
xcp.ustkptr is only assigned once in up_initial_state() when a task is
created and, since the syscall fast path was optimized in
e6973c764c, is never updated afterwards. up_backtrace() used
"ustkptr != NULL" to decide whether a task is currently blocked
inside a syscall, and *(ustkptr + 1) as the frame pointer to resume
tracing from. Since ustkptr is now a dead value fixed at task
creation time, the check is always true and the "frame pointer" it
derives points at stale data near the initial stack top, unrelated
to where the task is actually blocked.
Use rtcb->flags & TCB_FLAG_SYSCALL together with xcp.sregs, which
dispatch_syscall() maintains precisely across the entire syscall
execution window (including any nested context switches caused by
blocking), to locate the frame pointer/return address saved at
syscall entry instead.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
The ihm07m1_b16 (FOC motor control) configuration overflows the
STM32F302R8 64 KiB flash region by ~470 bytes, so it no longer links.
Enable GNU Full LTO (CONFIG_LTO_FULL=y); cross-module dead-code
elimination brings the image back under the limit (flash drops from
~66.0 KiB to ~57.7 KiB, 88%).
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Added docs to explain how to use the RTTL audio player, the currently
supported audio sinks and how to add more audio sink support.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
posix_spawnattr_init() no longer pre-fills attr->stacksize and
attr->priority (it leaves them zero, as memset already does). When a
caller does not set them, the binary loader supplies them from the
loaded ELF (binp->stacksize / binp->priority, parsed from the nx_*
symbols), and nxtask_spawn_exec() falls back to the parent priority and
CONFIG_POSIX_SPAWN_DEFAULT_STACKSIZE for the posix_spawn() function-task
path.
This lets an application's stack size and priority embedded as ELF
symbols actually drive the spawned task, instead of being overridden by
the spawnattr defaults.
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Parse application attributes (stacksize, priority, and uid/gid/mode under
CONFIG_SCHED_USER_IDENTITY) from absolute symbols (nx_stacksize,
nx_priority, nx_uid, nx_gid, nx_mode) embedded in the ELF at link time,
falling back to defaults when the symbols are absent.
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Add libelf_findsymbol() to locate a symbol in the ELF symbol table by
name, reusing the existing libelf_findsymtab/libelf_readsym/libelf_symname
helpers, and expose its prototype in include/nuttx/lib/elf.h.
Signed-off-by: anjiahao <anjiahao@xiaomi.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>
This commit introduces a rudimentary architecture and board port for the
MIPS Creator CI20, featuring the dual core Ingenic JZ4780 SoC (MIPS32).
Included in this initial implementation:
- Basic architectural initialization and startup code for the JZ4780 Core 0.
- Minimal configuration required to execute from RAM.
- Early UART/serial console support for basic debugging and NSH output.
- Minimal board-specific configuration for the CI20 target.
- Console output is routed via UART0 on the expansion header.
This establishes basic support for running NuttX on the MIPS CI20.
Further peripherals, optimization, and extended documentation are left for
future iterations or community contributions.
Build and Runtime Deployment Info:
----------------------------------
The baseline can be configured, compiled using the MIPS MTI toolchain,
and loaded via U-Boot using the following commands (replace
<tftp_dir> with your local TFTP root directory).
./tools/configure.sh -l ci20/nsh
make CROSSDEV=mips-mti-elf-
mkimage -A mips -O linux -T kernel -C none -a 0x80000180 -e 0x800004ac \
-n "nx" -d nuttx.bin <tftp_dir>/nuttx.umg
Note: U-Boot must be properly configured for networking (e.g., valid ipaddr,
serverip, and ethaddr environment variables) to fetch the image over TFTP.
Run this from U-Boot prompt:
tftp nuttx.umg && bootm $fileaddr
Signed-off-by: Lwazi Dube <lwazeh@gmail.com>
Permissions (Part 2)
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.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
See https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
The group address in the IGMP header is declared as uint16_t grpaddr[2],
so it decays to a pointer. Comparing it against INADDR_ANY compares the
address of a struct member against 0, which is always false. The General
Query branch is therefore unreachable and GCC discards it entirely.
Commit 09bb292fa2 ("net/igmp: fix build warning on GCC 12.2.0") replaced
the original
if (igmp->grpaddr == 0)
with
if (net_ipv4addr_cmp(igmp->grpaddr, INADDR_ANY) != 0)
but net_ipv4addr_cmp(a, b) expands to (a == b) and INADDR_ANY expands to
((in_addr_t)0), so the emitted comparison is unchanged. The -Waddress
diagnostic disappeared only because the comparison now originates inside
a macro expanded from a header included via -isystem, and GCC suppresses
warnings from system-header macros. The defect was hidden, not fixed.
That commit also rewrote the unicast query test from group->grpaddr != 0,
which was well-formed, into the same pointer comparison, making it
unconditionally true.
Convert the header field with net_ip4addr_conv32() once, and compare the
resulting in_addr_t. The conversion was already being done in the
group-specific branch, so this only hoists it and reuses it.
Impact: a General Query (destination 224.0.0.1, group address 0) is the
periodic query every IGMP querier sends. It currently falls through to
the group-specific branch, where igmp_grpallocfind() allocates a group
for 0.0.0.0 and schedules a report for it, while joined groups never have
their report timers restarted. The querier then ages out the membership
and multicast delivery to the device stops.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.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>
Fixed MemBrowse report action to detect DOC only changes based on
comparing the forked point in the master with the PR, and not the
current master.
Signed-off-by: Michael Rogov Papernov <michael@membrowse.com>
The board-common stm32_reset.c and stm32_romfs_initialize.c are already
provided by boards/arm/common/stm32. Remove the redundant local copies
from boards
Signed-off-by: raiden00pl <raiden00@railab.me>
Adds a configuration that allows NXDoom to be played on the Raspberry
Pi 4B, with the WAD file loaded from the SD card and the graphics over
HDMI.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Propagate the solution for SD card bugs to the nxinit configuration,
which also uses the nxinit configuration.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Updated the documentation to reflect the fix of buggy SD card behaviour
at the sacrifice of slower performance.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
I document the issues encountered with multi-block transfers, namely the
block count failing to be set correctly. Even though I did test with
that issue corrected, it required modifications to the upper-half MMCSD
driver which I am not prepared to test. It also did not fix the time-out
on multi-block transfers, likely because the method of verifying FIFOs
have space to write is finicky. For now, limiting the block count of
transfers resolves the bug!
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Cache must be invalidated before the buffer is read since the
VideoCore's write will not invalidate the cache.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
