Adds both xipfs configurations to the board configuration list, and notes
that xipfs-nxflat needs the NXFLAT tools (mknxflat and ldnxflat), which a
standard toolchain installation does not provide.
Impact: documentation only.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Pages for the three applications that come with xipfs: the command that
compacts a volume and prints its block map, the test suite and what each of
its sections covers, and the demo that downloads an NXFLAT module into a
volume and runs two instances of it in place.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Describe the write-once usage model, the strict in-place mmap and what
MAP_XIP_STRICT is for, extent pinning, manual defragmentation and how to read
its result, the power-loss ordering, the on-media layout, and the
limitations.
The NXFLAT page said ROMFS was the only file system able to serve the XIP
mappings its loader needs. That is now one of two, so point at both, and at
what the writable one adds: a module can arrive at run time instead of being
baked into a host-built image.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
nxstyle checks one file per invocation. nxstyle_sweep.sh runs it over
the directories given, or the whole repository, and collects what it
reports.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Add a shared Ameba high-speed UART driver on top of the GPIO driver's
common/ameba/ infrastructure, exposing UART0/UART1 through the NuttX
serial upper half.
- arch/arm/src/common/ameba/ameba_uart.c/.h: serial lower-half driver
built on the SDK fwlib UART register layer (ROM symbol table). RX/TX
dispatch through NuttX-native interrupts; TERMIOS get/set supported.
The pins are muxed to the direction-specific UART crossbar function
codes (TXD/RXD per controller) required by the amebadplus pinmux, and
RX is pulled high through the SDK ROM.
- arch/arm/src/common/ameba/Kconfig: AMEBA_UART option (selects SERIAL
and ARCH_HAVE_SERIAL_TERMIOS) plus RX/TX buffer-size knobs.
- arch/arm/src/rtl8721dx: wire ameba_uart.c into the Make/CMake builds
and pull the fwlib ram_common UART table into the fwlib link set.
- boards/arm/rtl8721dx/pke8721daf: board UART port table registering
UART0 at /dev/ttyS1 (PB18/PB19, 115200), bring-up hook, and a uart
NSH config with the serialrx/serialblaster examples.
- Documentation: describe the driver and the uart board config.
Verified on hardware (PKE8721DAF): pinmux routing, TX/RX and interrupt
paths, and the TERMIOS ioctl path via loopback.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
The Pimoroni Pico Plus 2 W is a Pico form-factor board built around the
RP2350B, the 80-pin part with 48 GPIOs, carrying 16MB of flash, 8MB of PSRAM
and a Raspberry Pi RM2 module for 2.4GHz WiFi. The RM2 houses an Infineon
CYW43439, wired to the same pins the Raspberry Pi Pico W uses: GPIO 23 for
power enable, 24 for the shared gSPI data and interrupt line, 25 for chip
select and 29 for the clock.
Three configurations are provided: nsh and usbnsh without the wireless chip,
and wifi, which brings up wlan0 in station mode with WAPI, a DHCP client and
ping. The CYW43439 firmware and CLM blob are linked in from the pico-sdk at
build time, as on the Pico W; CONFIG_CYW43439_FIRMWARE_BIN_PATH selects the
file and the board documentation covers converting it out of the C header that
pico-sdk 2.x ships in place of the binary. rp23xx_firmware.c is placed in the
common source directory so that a future board with the same chip can reuse
it, and unlike rp2040 the blob is staged for the CMake build as well.
Two board details are worth calling out:
- The only LED is wired to GPIO 0 of the CYW43439 rather than to a pin of
the RP2350, so driving it means an iovar request over the gSPI bus. That
works for CONFIG_USERLED but not for CONFIG_ARCH_LEDS, whose
board_autoled_on() is called from interrupt handlers and from assertion
handling, so a build selecting CONFIG_ARCH_LEDS is rejected with an
explicit message. The LED also only responds once wlan0 has been brought
up, because that is when the chip's firmware is downloaded.
- The BOOT button is also wired to GPIO 45, so it can be read as an ordinary
user button once NuttX is running. Its internal pull-up is enabled
deliberately: erratum RP2350-E9 means a floating Bank 0 input on RP2350 A2
leaks enough current to settle around 2.2V, which the internal pull-down
cannot overcome.
Tested on the board with a Raspberry Pi Debug Probe: nsh and wifi boot on
UART0, wlan0 reports the MAC read from the chip, wapi scan lists access
points, and association to a WPA2 network followed by DHCP gives a working
route with ping succeeding to both a literal address and a resolved name.
The LED and the BOOT button were confirmed by hand.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Add boot commands.rst section describing its syntax and behavior,
including relative image path resolution against the NSH
current working directory, and boot command config.rst dependency-table entry
mapping CONFIG_BOARDCTL_BOOT_IMAGE and CONFIG_NSH_DISABLE_BOOT.
Signed-off-by: Junbo Zheng <zhengjunbo1@xiaomi.com>
The rp2350 holds 4096 rows of 24 bit one-time-programmable memory, which
the port did not expose at all. This adds a driver on the NuttX efuse
interface, registered by the common board bringup as /dev/efuse.
The driver uses the ECC interpretation of a row, in which 16 bits carry
data and the remaining 8 carry a Hamming code, so the OTP appears as a
flat space of 4096 * 16 bits for the efuse field descriptors to index: a
descriptor at bit offset N refers to bit N % 16 of row N / 16. That
matches the row numbers already listed in hardware/rp23xx_otp_data.h.
Reads come from the chip's ECC-translated window and have no side
effects. Rows are locked in pages of 64; a page locked against reads
would raise a bus fault, so the lock is checked first and reported as an
error instead.
Programming needs the separate RP23XX_OTP_WRITE option, which defaults to
off; without it a write returns EPERM and no programming code is built at
all. When enabled, a row is programmed as a whole through the bootrom,
since the ECC bits cover the whole row. For the same reason a row that
already holds data cannot be modified, and such a write is rejected
rather than left to corrupt the row's ECC.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Add a reference section for the NSH `du` command, covering the -h,
-s, -a, and -d N options, default-to-current-directory behavior,
and an example showing recursive directory output.
Options are rendered as an RST simple table to match the style of
other NSH command sections (ls, umount, uptime). Sizes are noted as
apparent sizes (st_size) and -h as integer-arithmetic, one-decimal
output that needs no float printf support.
Signed-off-by: Junbo Zheng <zhengjunbo1@xiaomi.com>
adc_shutdown() gates the ADC clock (RCU_APB2EN.ADCEN) when the device is
closed, but the one-shot adc_reset() that first enabled it only runs at
registration and adc_setup() never re-enabled it. A second open() then drove
a clock-gated peripheral whose conversions never completed, so a second run of
a reader such as the adc example hung after opening the device. adc_setup()
now re-enables the ADC clock; clock gating preserves the register
configuration, so nothing else has to be re-programmed.
Add an "adc" configuration that exercises the driver. It is the nsh base plus
the ADC driver, registered as /dev/adc0 and read by the adc example. ADC
channel 8 (ADC_IN8) is routed to PB0 on the J1 header so an analog voltage
applied there is sampled. The board bringup samples that channel when the pin
is routed, and PB0 is only claimed for the ADC when SPI is off (with SPI on it
belongs to the I2C0 fallback), so the periph configuration is unaffected.
The GD32VW55x ADC converts on demand rather than continuously, so the example
uses the software trigger (CONFIG_EXAMPLES_ADC_SWTRIG) and is bounded to 20
sample groups so it returns to the prompt.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Add an "sdcard" configuration that mounts an SD card over SPI0 with a FAT
filesystem. The board provides the SPI chip-select glue (gd32_spi0select,
gd32_spi0status and gd32_spi0register in a new gd32_spi.c) and gd32_bringup()
binds the slot with mmcsd_spislotinitialize() and mounts /dev/mmcsd0 on
/mnt/sd.
The card is wired to the J1 header: SCK PA2, MISO PA1, MOSI PA0, and a
software chip select on PA4. CONFIG_MMCSD_MMCSUPPORT is left off (its MMC
CMD1 probe upsets SD cards).
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Add a "pwm" configuration that exercises the PWM driver on TIMER1. It is the
nsh base plus the PWM driver, registered as /dev/pwm0 and driven by the pwm
example (100 Hz, 50 % duty by default).
TIMER1 channel 0 is routed to PA0 on the J1 header (AF1) so the waveform can
be probed there; the other channels stay unrouted.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The GD32VW55x I2C master (the STM32-style "v2" IP) never completed a real
transfer. Two bugs:
1. Wrong kernel clock. The protocol state machine is clocked by the I2C
kernel clock selected in RCU_CFG1.I2C0SEL, not by the APB1 bus clock that
only feeds the register interface. The driver left it at the APB1 default
and computed TIMING for PCLK1 (~80 MHz); the resulting prescaled period is
so short that the SDADEL/SCLDEL setup and hold times fall below the
analog-filter minimum of the IP, so the master latches START but never
drives SCL (STAT stuck with BUSY set). Route I2C0 to IRC16M (16 MHz) and
use it as clk_freq, and never let the prescaler drop below the value that
keeps the prescaled clock at/under 4 MHz (250 ns) so SDADEL/SCLDEL stay in
spec. This matches the vendor BSP (IRC16M, PSC=3).
2. Transfer timeout was zero. CONFIG_GD32VW55X_I2C_TIMEOTICKS has a Kconfig
default of 0 ("override when non-zero"), but the driver derived the timeout
with a plain #ifndef, which never triggers because the symbol is always
defined. The polled wait loop therefore ran a single iteration and gave
up. Address probes (NACK on the first pass) still worked and masked it;
only multi-byte transfers exercised the loop. Honour the "0 means derive
from seconds/milliseconds" contract.
Also make the interrupt wait immune to the ISR completing between startmsg()
and the wait (do not clobber a posted DONE), and drop a redundant cast.
To exercise this on hardware, add an "sht3x" configuration to the
gd32vw553k-start: the nsh base plus I2C0, the i2ctool and the Sensirion SHT3x
temperature/humidity driver, registered as /dev/i2c0 and /dev/temp0. I2C0 is
routed to PA2 (SCL) / PA3 (SDA) on AF4, the pins broken out on the J1 header
(datasheet Table 2-5); when SPI is enabled it claims PA2, so I2C0 falls back
to PB0/PB1, whose SDA pin is not broken out (the periph case).
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The RP2350 has no dedicated RTC block (the RP2040 one was removed). Use the
POWMAN always-on timer instead: a 64-bit millisecond counter clocked from the
low-power oscillator, so it keeps running across warm resets.
Enabling CONFIG_RP23XX_RTC selects CONFIG_RTC and builds the driver, which
implements the simple up_rtc_initialize()/up_rtc_time()/up_rtc_settime()
interface backing the system clock (seconds resolution). up_rtc_initialize()
sources the timer from the low-power oscillator at a 1 kHz tick and starts it,
preserving the value when the timer is already running. POWMAN register writes
carry the required 0x5afe password.
Document the RTC on the rp23xx platform page: an "RTC" section explaining how
the POWMAN always-on timer is used (LPOSC clocking, the 0x5afe password and the
four 16-bit time registers, stopping the counter to reload it), with reference
links to the RP2350 datasheet Power chapter and the pico-sdk hardware_powman /
pico_aon_timer implementation the driver mirrors. The same references are
noted in the driver header.
Assisted-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Adds a driver for the external QSPI PSRAM hanging off QMI chip select 1,
such as the 8 MiB APS6404 fitted on the Pimoroni Pico Plus 2.
rp23xx_psramconfig() assigns the CS1 pin, reads the device ID over the QMI
direct interface to confirm an APS6404-family part (KGD 0x5D), resets it
into quad mode and programs the QMI M1 timing/read/write formats so the
region at 0x11000000 becomes directly addressable and writable. Because
driving the QMI in direct mode stalls execute-in-place from the flash, the
detection and (re)configuration code runs from RAM (.time_critical) with
interrupts disabled; the command bytes are selected with immediates rather
than a .rodata table for the same reason. The register values follow the
Raspberry Pi Pico SDK setup_psram().
The detection routine only keeps the QMI DIRECT_CSR synchronization that is
strictly necessary. Each candidate busy-wait was removed one at a time and
re-verified on hardware: the post-enable "cooldown" waits, the READ_ID
TXEMPTY wait (redundant with the BUSY wait after it), and a fixed nop delay
proved unnecessary and are omitted. The three BUSY waits that remain -- after
the quad-mode nudge, after each READ_ID byte, and after each reset/quad-enable
command -- are required and carry a comment explaining that the frame must
finish shifting before the chip select is deasserted, and what breaks
otherwise (garbage ID reads, or the shared QMI bus wedging).
rp23xx_psram_restore() re-applies the M1 configuration and is meant to be
called from the flash write path, which goes through the bootrom and
reconfigures the shared QMI for chip select 0.
rp23xx_heaps.c is wired into the build and now uses the detected size, so
the PSRAM is exposed to the memory manager (added to the main heap, used as
a separate heap, or as the user heap) and is skipped cleanly when no PSRAM
is present.
Enabled by default on the pimoroni-pico-2-plus:nsh configuration, where it
adds the 8 MiB to the main heap. A documentation page for the Pimoroni Pico
Plus 2 is added alongside the other rp23xx boards, covering its serial
console, LED, the external PSRAM and how it is exposed to the heap, the
supported capabilities and the available configurations, with a photo of the
board.
Tested on Pimoroni Pico Plus 2 hardware: detection reports the 8 MiB
APS6404, the region is read/write across its whole range (ramtest word,
half-word and byte passes, marching/pattern/address-in-address), and the
heap reports the extra 8 MiB.
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The port could only run with a periodic ARM SysTick tick. Add an alarm/
oneshot lower-half backed by an RP2350 system timer block so the scheduler
can run tickless, waking the CPU only when a timer actually expires.
rp23xx_oneshot.c implements the ONESHOT_COUNT lower-half (mirroring the
RISC-V mtimer driver). A timer block is a free-running 64-bit microsecond
counter (clocked by the TICKS block, independent of the SysTick), which serves
directly as the monotonic time base returned by current(), so timekeeping is
exact to 1 us. The one adaptation versus a full 64-bit compare timer is that
the RP2350 ALARM registers match only the low 32 bits of the counter:
max_delay() is therefore capped below 2^32 counts (~71.5 minutes) so the
scheduler never asks for a longer interval, and any deadline that is already
due -- or that the counter reaches while the alarm is being armed -- is
raised immediately through the INTF force register instead of waiting a full
32-bit wrap for the compare to match again.
Enabled with CONFIG_RP23XX_SYSTIMER_TICKLESS (mutually exclusive with
RP23XX_SYSTIMER_SYSTICK), which selects ONESHOT, ONESHOT_COUNT and
ALARM_ARCH; up_timer_initialize() then hands the oneshot to
up_alarm_set_lowerhalf(). ARCH_CHIP_RP23XX now selects ARCH_HAVE_TICKLESS.
The block is selectable with CONFIG_RP23XX_SYSTIMER_TICKLESS_TIMER0 (default)
or _TIMER1; the chosen block is claimed exclusively by the scheduler and is
excluded from the /dev/timer driver (CONFIG_RP23XX_TIMER) in Kconfig, so the
tickless clock and a /dev/timer device can coexist on different blocks.
Tested on Pimoroni Pico Plus 2 (RP2350B) hardware with CONFIG_SCHED_TICKLESS
and CONFIG_SCHED_TICKLESS_ALARM: the image boots to nsh and keeps accurate
time -- "uptime" advances at real-time rate (17 s over a measured 17.4 s) and
"sleep 4" blocks for 4.25 s of wall time -- confirming the oneshot both drives
the scheduler and provides a correct 1 MHz monotonic clock.
Assisted-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The RP2350 has two system timer blocks (TIMER0, TIMER1), each a free-running
64-bit counter incremented once per microsecond by the TICKS block (set up in
rp23xx_clock.c). They are independent of the ARM SysTick that drives the OS
tick, so they are free for application use, but the port had no driver for
them.
Add rp23xx_timer.c, a NuttX timer lower-half that binds a block to a
/dev/timerN device. It uses ALARM0 of the block, which matches the low 32
bits of the microsecond counter, to implement single-shot and periodic
timeouts with 1 us resolution and a maximum interval of 2^32 - 1 us (~71.5
minutes). Periodic reloads are scheduled relative to the previous expiry to
avoid drift, but never behind the counter (an alarm set in the past would not
match until the 32-bit counter wraps).
Enable with CONFIG_RP23XX_TIMER (which selects CONFIG_TIMER), then turn on each
block independently: CONFIG_RP23XX_TIMER0 registers /dev/timer0 and
CONFIG_RP23XX_TIMER1 registers /dev/timer1. A block claimed by the tickless
oneshot (CONFIG_RP23XX_SYSTIMER_TICKLESS) is excluded from these choices in
Kconfig, so the two features can be enabled together without colliding on the
same block or its alarm IRQ.
Tested on Pimoroni Pico Plus 2 (RP2350B) hardware with examples/timer and a
CMSIS-DAP probe. The device registers as /dev/timer0; the ALARM0 interrupt
fires at the programmed period (verified over SWD at the configured 1 s
interval, not a busy loop), and the full path -- alarm match, the driver ISR,
the timer notification and delivery of the SIGNO to user space -- reaches the
example's signal handler and increments its counter.
Assisted-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The rp2350 executes in place from external QSPI flash, and a NuttX image
normally leaves most of that flash unused. This exposes the unused region
as an MTD device so it can carry a filesystem, mirroring what the rp2040
port already provides with rp2040_flash_mtd.c.
The region is given by RP23XX_FLASH_MTD_OFFSET and RP23XX_FLASH_MTD_SIZE,
both multiples of the 4096 byte erase sector. Initialization fails rather
than corrupting the running image if the region would overlap the NuttX
binary, checked against __flash_binary_end.
Erase and program use the bootrom flash routines. Those stall instruction
fetch from the same flash, so they run from SRAM with interrupts disabled
and, on SMP builds, the other core parked; afterwards the QSPI interface is
returned to execute-in-place mode. By default that restores the fast read
mode the bootrom configured at boot; RP23XX_FLASH_MTD_SAFE_XIP instead
always uses the bootrom flash_enter_cmd_xip routine, which is slower to
execute from but depends only on the documented bootrom entry point.
The driver answers BIOC_XIPBASE with the memory-mapped address of the
region, so a filesystem supporting execute in place can hand out real flash
pointers rather than copying into RAM.
The common board bringup registers the device as /dev/rpflash.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
FIOC_REFORMAT, FIOC_OPTIMIZE, FIOC_INTEGRITY and FIOC_DUMP act on a volume,
not on any one file, but the only route into a file system has been the
per-file ioctl method. A caller therefore has to open an unrelated file
just to name the volume it means.
For nxffs that is not merely awkward, it is a dead end. nxffs_ioctl()
refuses FIOC_REFORMAT while any file on the volume is open:
if (volume->ofiles)
{
ferr("ERROR: Open files\n");
ret = -EBUSY;
and every open file is on that list (nxffs_open.c). The descriptor used to
issue the command is itself such a file, so the check can never pass and
FIOC_REFORMAT is unreachable through the only interface that exposes it.
Add an optional ioctldir method to struct mountpt_operations, reached by
issuing the ioctl on a descriptor for the mountpoint directory:
fd = open("/mnt/nxffs", O_RDONLY | O_DIRECTORY);
ioctl(fd, FIOC_REFORMAT, 0);
It takes the same (mountpt, dir) pair as opendir/readdir/rewinddir, so it
reads as a member of the directory-operations family; the file system
recovers the volume from the mountpoint inode and may ignore dir. The
member is placed at the end of the structure rather than beside the other
directory operations on purpose: every file system initialises
mountpt_operations positionally, so a member inserted mid-structure would
force all of them to add a slot for a method they do not implement.
Appending keeps the change to one file system.
dir_ioctl() gives that method the first chance at every command when the
directory belongs to a mounted volume and the file system provides one, and
falls back to its own handling of FIOC_FILEPATH and BIOC_FLUSH when the file
system answers -ENOTTY. Trying the file system first is what lets a file
system override a command the VFS would otherwise answer generically; the
-ENOTTY fallback is what keeps the generic answers available to everyone
else. A file system that leaves the method NULL is unaffected: the VFS
answers exactly as before.
The existing per-file method could not simply be reused for this. It takes
a struct file, and every implementation that has an ioctl -- fat, romfs,
tmpfs, spiffs among them -- asserts on filep->f_priv and dereferences it,
so handing it a directory descriptor with no open file behind it would
fault. Making the entry point separate keeps that contract intact and
makes support explicit rather than assumed.
nxffs implements it, which is what makes its FIOC_REFORMAT reachable. The
per-file path is left in place and both share one implementation, so
nothing that works today stops working. spiffs, which has the same shape
of volume commands, can follow.
Measured on sim:nxffs, with one file written to the volume and then the
same sequence of ioctls issued on a file descriptor, on a descriptor for the
mountpoint directory, and on a descriptor for a pseudo file system directory.
Before:
FIOC_REFORMAT via file fd: ret=-1 errno=16 (EBUSY, as expected)
FIOC_REFORMAT via dir fd: ret=-1 errno=25
FIOC_FILEPATH via dir fd: ret=0 "/mnt/nxffs//"
BIOC_FLUSH via dir fd: ret=0
bogus cmd via dir fd: ret=-1 errno=25
FIOC_FILEPATH via /dev fd: ret=0 "/dev//"
bogus cmd via /dev fd: ret=-1 errno=25
name still in the raw MTD image afterwards: yes
After:
FIOC_REFORMAT via file fd: ret=-1 errno=16 (EBUSY, as expected)
FIOC_REFORMAT via dir fd: ret=0
FIOC_FILEPATH via dir fd: ret=0 "/mnt/nxffs//"
BIOC_FLUSH via dir fd: ret=0
bogus cmd via dir fd: ret=-1 errno=25
FIOC_FILEPATH via /dev fd: ret=0 "/dev//"
bogus cmd via /dev fd: ret=-1 errno=25
name still in the raw MTD image afterwards: no
Only the FIOC_REFORMAT line on the directory descriptor changes, and the raw
MTD image confirms the volume really was erased. FIOC_FILEPATH and
BIOC_FLUSH on a directory still answer even though nxffs is now consulted
ahead of them, an unrecognised command is still refused rather than
forwarded blindly, and a directory in the pseudo file system, which has no
ioctldir at all, is untouched.
Assisted-by: Claude Code:claude-opus-4-8
Assisted-by: Claude Code:claude-fable-5
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Add a driver for the rp2350 hardware true random number generator.
Enabling CONFIG_RP23XX_RNG selects ARCH_HAVE_RNG and builds the driver,
which registers /dev/random (and /dev/urandom when CONFIG_DEV_URANDOM
selects the architecture source, DEV_URANDOM_ARCH). Each read enables
the entropy source, waits for a valid 192-bit entropy holding register
(EHR) sample, reads the six 32-bit EHR words, and repeats until the
request is satisfied.
Document the TRNG on the rp23xx platform page.
Assisted-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The simulated UART driver currently opens the host path configured by
CONFIG_SIM_UARTx_NAME directly. This requires the host-side serial endpoint
to exist before NuttX opens the UART, so users and CI jobs need an external
setup step such as socat to create a PTY pair. It also means the host
endpoint path is effectively a build-time choice: changing the host device
path requires changing configuration and rebuilding, which is inconvenient
for tests that allocate a fresh PTY path on each run.
Add CONFIG_SIM_UART_PTY for Linux sim builds. When enabled, non-console
simulated UART ports allocate a host pseudoterminal from /dev/ptmx, put the
host master side in raw mode, and print the host slave path when the NuttX
UART is opened. The NuttX-side device name remains CONFIG_SIM_UARTx_NAME,
for example /dev/ttySIM0, so applications continue to use the normal NuttX
serial API.
Keep the option disabled by default so existing configurations still open
the configured host path directly. Console UART handling is also left on the
existing host-open path.
Also make host_uart_checkin() and host_uart_checkout() check the actual
POLLIN/POLLOUT bits returned by poll(). This avoids treating error-only or
unrelated poll events as readable or writable serial readiness.
The main benefit is simpler and more deterministic simulator integration: a
simulated UART can expose a real host-visible /dev/pts/N endpoint by itself,
without pre-creating a matching host device and without rebuilding NuttX
when the host PTY path changes. This is useful for host-side test scripts
and external protocol tools while keeping application code on the standard
NuttX UART interface.
Companion apps-side test branch:
https://github.com/LingaoM/nuttx-apps/tree/sim_uart_tester
Testing:
Host:
Ubuntu 22.04 x86_64
Board/config:
sim:nsh
Apps test code:
https://github.com/LingaoM/nuttx-apps/tree/sim_uart_tester
Common test configuration:
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_EXAMPLES_HELLO=y
CONFIG_SIM_UART_NUMBER=1
CONFIG_SIM_UART0_NAME="/dev/ttySIM0"
CONFIG_SIM_UART_PTY=y
DMA-mode build and test:
1. Configure sim:nsh with the companion apps tree:
./tools/configure.sh -a ../nuttx-apps sim:nsh
2. Enable the common test configuration above and keep DMA enabled:
CONFIG_SIM_UART_DMA=y
CONFIG_SERIAL_TXDMA=y
CONFIG_SERIAL_RXDMA=y
3. Build:
make clean
make -j16
4. Start NuttX:
./nuttx
5. In NSH, run the hello test app:
nsh> hello
/dev/ttySIM0 connected to pseudotty: /dev/pts/73
6. In another terminal, run the host-side tester from the companion apps
branch with the printed PTY path:
cd ../nuttx-apps
./examples/hello/test_sim_uart_pty.py /dev/pts/73
7. The host-side tester sends 32768 bytes from the host to NuttX and
receives 49152 bytes from NuttX to the host. The payload includes
non-text binary bytes. Both sides validate deterministic payload
contents and checksums, then exchange an ACK.
8. Observed host-side output:
HOST_OPEN: /dev/pts/73
HOST_TX: 32768 bytes checksum=0x1f9989f4
HOST_RX: 49152 bytes checksum=0x06a45c69
HOST_TX: ACK
TEST PASSED
9. Observed NuttX output:
sim_uart_pty_test: binary RX 32768 TX 49152 passed
Non-DMA build and test:
1. Disable DMA for the same sim:nsh configuration:
# CONFIG_SIM_UART_DMA is not set
# CONFIG_SERIAL_TXDMA is not set
# CONFIG_SERIAL_RXDMA is not set
2. Refresh the configuration and rebuild. On this host, the installed
Python olddefconfig shim is broken, so I refreshed Kconfig directly
with kconfig-conf and the same environment that the NuttX Makefile
passes to Kconfig:
APPSDIR=/mnt/ssd/code/code/nuttx-apps \
APPSBINDIR=/mnt/ssd/code/code/nuttx-apps \
BINDIR=/mnt/ssd/code/code/nuttx \
EXTERNALDIR=/mnt/ssd/code/code/nuttx/dummy \
kconfig-conf --olddefconfig Kconfig
make clean
make -j16
3. Repeated the same runtime steps as the DMA test:
./nuttx
nsh> hello
cd ../nuttx-apps
./examples/hello/test_sim_uart_pty.py /dev/pts/73
4. Observed the same successful binary transfer result:
HOST_TX: 32768 bytes checksum=0x1f9989f4
HOST_RX: 49152 bytes checksum=0x06a45c69
HOST_TX: ACK
TEST PASSED
sim_uart_pty_test: binary RX 32768 TX 49152 passed
After the non-DMA test, I restored the default DMA configuration, rebuilt,
and reran the same binary PTY test successfully so the final local build
state was back on CONFIG_SIM_UART_DMA=y.
Assisted-by: Claude:Claude-Fable-5
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Toolchain.defs adds --fixed-r10 to CFLAGS under CONFIG_PIC, but nearly
every board Make.defs includes that file and then assigns
CFLAGS := $(ARCHCFLAGS) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS) ...
with ':=', which discards it. 266 of the 269 ARM board files assign
CFLAGS that way; the remaining three delegate to a shared makefile that
does the same thing.
The flag is what keeps the base firmware from allocating r10, the
register a PIC module reaches its own data through. Losing it is silent
and the symptom is remote from the cause: the build succeeds, and only a
callback from base firmware into module code -- qsort() with a module
comparison function is the standard case -- misbehaves, reading its data
through a register the firmware has since felt free to reuse.
Adding it to ARCHCFLAGS puts it on the far side of that ':=', which
re-expands ARCHCFLAGS, so every board picks it up with no board changes
at all.
A module is the other side of the --fixed-r10 contract: it gets r10 via
-mpic-register=r10, and GCC rejects both on one command line with
"unable to use 'r10' for PIC register". Every ARM board carried the
same three lines to set that up:
ARCHPICFLAGS = -fpic -msingle-pic-base -mpic-register=r10
CPICFLAGS = $(ARCHPICFLAGS) $(CFLAGS)
CXXPICFLAGS = $(ARCHPICFLAGS) $(CXXFLAGS)
They move to arch/arm/src/common/Toolchain.defs, which also filters
--fixed-r10 back out of CPICFLAGS, CXXPICFLAGS, CELFFLAGS and
CXXELFFLAGS in one place instead of each board having to know about the
interaction. ARCHPICFLAGS uses '?=' and the derived flags use deferred
'=', so a board can still override or append after including the file,
and CFLAGS is whatever the board finally set it to.
Two boards keep a definition because they genuinely differ: am67 adds
-ffixed-r10 and tiva conditionally adds -mno-pic-data-is-text-relative.
tlsr82 previously appended -fpic to an unset variable, so only -fpic
ever reached its compiler; it now inherits the standard set, verified
against tc32-elf-gcc 4.5.1.tc32-elf-1.5 (Telink TC32 v2.0), whose
ARM-derived backend honors -msingle-pic-base and -mpic-register=r10.
The mps2, mps3, qemu-armv7a, qemu-armv7r, fvp and mcx-nxxx families
referenced ARCHPICFLAGS without ever defining it, so their CPICFLAGS
carried no PIC flags at all; they get the standard set too.
Also adds the missing space in
CXXELFFLAGS = $(CXXFLAGS)-fvisibility=hidden -mlong-calls
which ran the last token of CXXFLAGS into -fvisibility=hidden, yielding
a single malformed token such as -DNDEBUG-fvisibility=hidden.
Also exempts the pre-existing "*.siz" gsize comment in Toolchain.defs
from codespell, which reads "siz" as a misspelling and fires for any
patch touching the file, since checkpatch scans whole files rather than
changed lines.
Before, with CONFIG_PIC=y: CFLAGS has --fixed-r10: NO
After: CFLAGS has --fixed-r10: YES
CPICFLAGS/CELFFLAGS: filtered out
Assisted-by: Claude Code:claude-opus-4-8
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Add EHCI and OHCI USB host drivers for the Ingenic JZ4780 SoC, derived
from the existing sama5 implementation.
Additionally, introduce the display controller driver using code ported
from FreeBSD under its original license terms. Note that this driver
lacks EDID support and is currently hardcoded to 1360x768.
Update the linker script memory layout to utilize the full 256 MiB RAM,
excluding the 8 MiB reserved at the top of memory for the framebuffer.
Signed-off-by: Lwazi Dube <lwazeh@gmail.com>
Documents how to use the txmorse application and how it can be extended
to support other output devices besides the console and GPIO.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Includes documentation about how to include and use the Morsey library
for transmitting Morse code.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Document PBKDF2-HMAC-SHA256 ROMFS passwd generation and update board
Kconfig help text accordingly. Set the documented sim/login CI credential
in GitHub Actions.
Enable CONFIG_CODECS_BASE64 and CONFIG_NETUTILS_CODECS on sim:dropbear for
link compatibility with dropbear's bundled libtomcrypt.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Add a "curl" configuration for the linum-stm32h753bi board, based on the
netnsh configuration (ethernet + DHCP). It enables the system/curl HTTP
client command, SD card support (mounted manually, as in the sdcard
configuration) and a larger console line buffer (CONFIG_LINE_MAX=256) so
long URLs and JSON bodies are not truncated at the NSH prompt.
Also document the curl command: add a man page under
Documentation/applications/system/curl and a usage example (download,
POST JSON, multipart upload) to the board documentation.
Signed-off-by: Jorge Guzman <jorge.gzm@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>
Documents the configuration for the barometer dashboard example, and
explains how to set up a fake barometer to test it.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Documents how to use the baromonitor example, shows its visualization
and explains its default behaviour.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Drop the esp32c3-devkit:dropbear defconfig and its documentation.
The companion apps#3636 (Dropbear over /dev/crypto for this board)
is stuck on an unrelated Espressif CI dependency issue, and the
port is moving to different hardware.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Document the new stm32f746g-disco:dropbear configuration, mirroring
the existing esp32c3-devkit Dropbear documentation.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Introduce networking capabilities to the Creator CI20 board by leveraging
the pre-existing dm9000 ethernet driver.
To achieve this, the following changes were made:
- Integrated the jz4780 GPIO module to properly configure and enable the
interrupt pin required by the ethernet controller.
- Added `dm90x0.h` to export the dm9000 initialization function, allowing
the board-specific setup code to initialize the network interface.
Signed-off-by: Lwazi Dube <lwazeh@gmail.com>
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>
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>
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>
