Adds documentation entries to the tab5 board, mentioning the new
defconfigs and updates support features.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
Remove the manual mkimage step because CONFIG_UBOOT_UIMAGE=y already
generates a valid uImage. This brings the documentation up to date
with the uImage usage that was already standard in practice.
Restore the esp32c3-devkit:dropbear defconfig and its documentation, now that
the AES symbol collision between the Wi-Fi stack and crypto/aes.c is fixed in
the ESP HAL. netutils/dropbear depends on CRYPTO_CRYPTODEV_SOFTWARE_CRYPTO,
so the defconfig enables the cryptodev software backend and base64 codecs.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The 32 MHz TCXO that clocks the SX1276 is powered from PA12 and was never
driven, so the radio had no clock at all. The user button was copied from
the Nucleo L073RZ and left on PC13, which carries DIO3 of the radio on this
board; it is PB2.
Adds lorawan_tx and lorawan_beacon, with the radio defaults of a public
LoRaWAN network in the 915 MHz band, and fills in the board page.
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
- The frequency step was truncated to 61 Hz, while it is FXOSC/(2**19),
about 61.035 Hz. The error puts a 915 MHz channel more than 500 kHz away
from the requested frequency, outside its own bandwidth.
- The low or high frequency front end was left at its reset value, so a board
wired for 868 or 915 MHz neither transmitted nor received.
- sx127x_rx_watchdog() is only used by the FSK and OOK path but was compiled
whenever receive support was on, so a LoRa only configuration failed to
build with -Werror. nrf52840-dk:sx127x is such a configuration.
Adds the sync word, the default bandwidth and the default spreading factor as
configuration options, all defaulting to the previous behaviour, and a page
for the driver under components/drivers.
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Character driver for the Semtech SX1301, the baseband processor of a LoRaWAN
gateway, and the two SX125x radios it drives. Received packets come from
read(), downlinks go to write(), and the channel plan, the start and the stop
are ioctls.
The interface is device independent, in nuttx/wireless/lpwan/lora_gw.h with
the commands in the common WLIOC_GW_* space, so another concentrator driver
can implement it and the same application drive it.
Adds a lorawan_gw configuration for the Nucleo F746ZG with a shield of the
LRWAN_GS_HF1 family. Off by default (LPWAN_SX1301).
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Adds documentation to input and touchscreen controller files, regarding
support for ST7123 IC.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
The CMake build does not need the manual export/import/mkromfsimg
steps: applications and the ROMFS image are generated by the normal
build. Document the CMake invocation and how to run the image.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
mknxflat is built from tools/nxflat by the NuttX build itself, so the
toolchain section no longer sends the reader to buildroot for it; only
ldnxflat still comes from there. Bring the mknxflat usage text in line
with the tool, note that MKNXFLAT and LDNXFLAT are supplied by the ARM
Toolchain.defs, and correct the r10 references left in the PIC
descriptions.
Describe the module ABI marker, so that a user whose prebuilt module
starts failing exec() with ENOEXEC finds out that the loader refuses a
module whose import table does not name __nxflat_abi_v2, and that
rebuilding the module is the fix.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
ARM PIC has used r10 as the base register, but the tree has never been
consistent about it. Toolchain.defs gives CONFIG_BUILD_PIC
-mpic-register=r9 and CONFIG_PIC -mpic-register=r10, twenty-five lines
apart, and arm_initialstate.c sets REG_R9 from inline assembly under one
and REG_PIC under the other, with a comment reading "Set the PIC base
register (probably R10)". This settles it on r9 for all of PIC: NXFLAT,
ELF PIC and CONFIG_BUILD_PIC alike.
r9 is the right choice rather than an arbitrary one. It is the AAPCS
platform register, the "static base", and it is what GCC itself picks
for -msingle-pic-base on an EABI target; r10 is the non-EABI default.
It also removes a combination that cannot build today. Stack checking
adds -ffixed-r10 in armv7-m/Toolchain.defs and armv8-m/Toolchain.defs,
while CONFIG_PIC adds -mpic-register=r10, and GCC rejects the pair with
"unable to use 'r10' for PIC register". The comment above REG_PIC has
always said the register "can be R9 if stack checking is enabled", but
the definition was unconditionally REG_R10, so it would have named the
wrong register even had the build succeeded.
The thunk generator moves with the firmware. NXFLAT import stubs had
the register baked in as "add ip,ip,sl", so a module built for r9 would
load and then branch to a wild address on its first call out. The stubs
now come from NXFLAT_PIC_REG in the in-tree tool, which is built only
when CONFIG_NXFLAT is set, following the
CONFIG_BOARD_ETC_ROMFS_PASSWD_ENABLE precedent in tools/Unix.mk.
That leaves modules built before this change, and they are the reason
for the ABI marker. The NXFLAT header cannot carry a version: h_magic
is written by ldnxflat, which is GPL, derived from elf2flt, and stays
out of this repository, so it can never be changed in step with the
loader. The import table can, because both of its ends are in-tree --
mknxflat emits it and nxflat_bindimports() reads it -- and ldnxflat
passes it through untouched. So every module now imports
__nxflat_abi_v2, the base firmware defines it, and a module that does
not import it is refused.
Making the marker a real exported symbol rather than a name the loader
special-cases is what keeps it out of the build system's way: a board's
symbol table picks it up exactly as it picks up printf, so mksymtab.sh
and its equivalents need no change. It also gives the reverse direction
a diagnosis for free -- a module built against a newer ABI than its
firmware fails with "Exported symbol __nxflat_abi_v2 not found".
Most of the remaining churn is boards restating a default. ARCHPICFLAGS
is a "?=" default so that a board only speaks up when it differs, and
twenty-six were assigning the value the default already had. MKNXFLAT
gets the same treatment: thirteen boards named the same tool, and the
only thing that varies is ARM versus Thumb-2, which falls out of
CONFIG_ARM_THUMB. LDNXFLAT gains a default too -- it stays an
out-of-tree PATH lookup, but naming it centrally fixes boards that never
assigned it, where it expanded to nothing and handed make a recipe
beginning "-e", whose leading dash make ate as "ignore errors".
The non-ARM boards carrying -mpic-register=r10 lose it: it is an
ARM-only option, reachable only through CPICFLAGS, which is only used to
build NXFLAT modules, and no non-ARM board enables NXFLAT.
Boards keep nothing about PIC flags any more. ARCHPICFLAGS was set by
sixty-three of them and only ever fed CPICFLAGS, which is only used to
build NXFLAT modules; no board outside arch/arm enables NXFLAT, so every
non-ARM copy was setting a variable nothing read. Those are removed
rather than moved somewhere more central, which would only make dead
text look load-bearing. LDNXFLAT goes the same way as MKNXFLAT, for the
same reason: thirteen boards named the same tool that Toolchain.defs now
names once.
One of them was not merely redundant. am67/t3-gem-o1 asked for
"-mpic-register=r10 -ffixed-r10", which GCC refuses outright with
"unable to use 'r10' for PIC register" -- the very combination the
filter-out machinery in Toolchain.defs exists to prevent. It has
survived because that board does not build NXFLAT modules, so the flags
are never handed to a compiler. Renaming the register would have
carried the fault forward unchanged, so the line goes.
Tested on lm3s6965-ek:qemu-nxflat under QEMU, configured and built with
no overrides. The nxflat example runs the errno, hello and struct
modules with output identical to the same config built from master.
Built with the old out-of-tree thunk generator instead, the same
firmware refuses all three with ENOEXEC rather than locking up in a
HardFault, which is what this change is for. mps3-an547:picostest,
which is CONFIG_PIC without CONFIG_NXFLAT, builds clean and does not
build the thunk generator.
The .def files pick up two cosmetic changes here alongside the register:
a "Dyanamic" typo that codespell rejects, and a reworded comment in each
thunk_*.c. Neither appears in the emitted thunk -- both are in C
comments -- so the generated text is still what the upstream tool
produces, modulo the register itself.
BREAKING CHANGE: ARM PIC moves from r10 to r9. An NXFLAT module built
before this change has r10 baked into its import stubs and will not run
against a firmware carrying it; the two cannot be mixed. The module is
refused with ENOEXEC rather than branching to a wild address, by way of the
__nxflat_abi_v2 marker described below.
Quick fix: rebuild the module against this tree. Its source needs no
change. A board that reserved r10 by hand, or that assigned ARCHPICFLAGS
or MKNXFLAT to restate a default, should drop those assignments; nothing
else is affected, and CONFIG_PIC without CONFIG_NXFLAT needs no action.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The audio subsystem page listed the source files and the configuration
options, but nothing about the interface the upper half presents to
applications. PR #18348 added a device state machine, a second buffer
allocation mode, poll and mmap support and several new ioctls, none of
which were described anywhere, so the only way to learn the expected
call sequence was to read audio/audio.c.
Document what the upper half now guarantees:
- the device state machine, and the fact that AUDIOIOC_START is
rejected until AUDIOIOC_CONFIGURE has moved the device out of
AUDIO_STATE_OPEN;
- the normal open/configure/allocate/enqueue/start sequence;
- the two AUDIOIOC_ALLOCBUFFER modes selected by u.pbuffer, who owns
the buffers in each, and that a shared ring request may return zero
when the ring is already populated;
- that AUDIOIOC_GETBUFFERINFO also establishes the shared ring depth,
so a lower half which does not implement it disables that mode;
- the poll event semantics and how mmap() selects between a ring
buffer and the device status by requested length;
- all ioctls handled by the upper half, grouped by purpose;
- how per-open state is aggregated into the device state when several
applications share one device.
No functional change.
Signed-off-by: fangyibo <fangyibo@xiaomi.com>
The registration example showed the three argument form, which no longer
compiles, and fetch() as the only way samples are taken. Update it, add
a section on the two acquisition modes and the attach() a board provides
for the interrupt one, and state the 100 Hz sample rate.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Describe the shared library open semantics in the FLAT and PROTECTED
builds: dlopen() of a library that is already loaded returns a handle
to it and takes an additional reference, and the library is unloaded
only when the last handle is closed. Note the consequences that follow
from having a single instance: libraries are matched by basename, data
is shared by all users, and constructors and destructors run once.
Contrast this with insmod(), which still rejects a duplicate module
name, and note that dlopen() is not implemented in the KERNEL build.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The options that let a board trade memory for drawing speed were only
described in their Kconfig help, where someone bringing the game up on a
new board is unlikely to find them. Describe what each one does and
when it is worth enabling.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Runs NXDoom on the board's LCD, played with a USB HID keyboard and
reading the game data from the microSD card, so it exercises the LTDC
framebuffer, the OTG FS host and the SDMMC peripheral at once.
Three settings are needed that are not obvious:
CONFIG_FAT_FORCE_INDIRECT, because the FAT layer otherwise reads whole
sectors straight into the caller's buffer and the SDMMC IDMA cannot
reach the caller's buffer when it lives in external SDRAM. The
failure appears part way through startup, once the internal RAM has
filled and allocations start coming from SDRAM.
CONFIG_HIDKBD_NOGETREPORT, because the keyboard answers GET_REPORT on
the control pipe with an empty report and only delivers key data on
its interrupt endpoint. Without it the keyboard enumerates, reports
no error, and no key is ever seen.
CONFIG_STM32_LTDC_L1_L8 with the frame buffer colour map, because DOOM
is natively palettised: letting the display convert the palette while
it scans out removes the conversion from the blit and halves the
amount of data written per frame.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Document inode_checkperm / inode_checkpathperm, mountpoint traverse vs open
semantics, and the optional mountpt_operations.permission hook in
file_permission.rst.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
The lvglterm page still told the reader to pick the input source that
matches the hardware, which was the whole thing being removed: it has
one physical keyboard variant now, and reads whatever is registered.
The hidkbd page pointed at HIDKBD_ENCODED, which no longer exists. What
produces that byte stream now is INPUT_KEYBOARD_BYTESTREAM.
system/kbd had no page at all.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The terminal reads a keyboard device and does not care which one, so it
can be driven with no keyboard plugged in at all. Enable UINPUT_KEYBOARD
and system/kbd so that the configuration can do it out of the box, and
document how, including how to have the USB keyboard and the console feed
the terminal at the same time.
The terminal no longer has a USB specific input source either, so the
device path has to be spelled out: the USB HID driver names its devices
/dev/kbda onwards while the option defaults to /dev/kbd0.
INPUT_KEYBOARD_BYTESTREAM is not needed here. The terminal reads events
now, and this configuration has no other keyboard consumer.
UINPUT_KEYBOARD_BUFNUMBER is raised to 128. It counts events rather than
keys, so the default of eight holds four keystrokes, and a console hands
over a whole line at once. The upper half overwrites the oldest event
when the buffer is full, so a typed line arrived with its beginning
silently missing.
HIDKBD_NOGETREPORT is enabled as well. Sampling the keyboard over the
control pipe every 40 ms loses any key pressed and released between two
samples, which on this board meant most of them.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
On K3 SoCs the A53 cluster does not own device power, clocks, resets or
interrupt routing; these are managed by the DM/TIFS firmware and requested
over TISCI through the secure-proxy mailbox. Add:
- a TISCI client (secure-proxy transport plus device/clock/reset helpers)
- a GPIO driver for banks 0/1 with pad mux and TISCI power-on
- an OMAP-I2C driver for the main-domain I2C controllers
and wire them into the PocketBeagle2 and BeaglePlay bring-up.
Tested on PocketBeagle2 (SYSFW 11.2.5) with the TechLab cape attached:
nsh> i2c bus
nsh> i2c dev -b 0 0x03 0x77 # I2C0 detects onboard 0x20 and 0x50
nsh> gpio -o 1 /dev/gpio3 # drives a user LED; read back with:
nsh> gpio /dev/gpio3
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
The watchdog documentation includes the new functionality of the
driver's char device: When reading from it, it emits information
about the watchdog status including flags, timeout and timeleft
as milliseconds. An example has been included as well.
Signed-off-by: Javier Alonso <dev@javinator9889.com>
Allow pull requests targeting master to declare same- and
cross-repository dependencies. Parse declarations with a tested Python
helper, apply exact dependency commits before the existing build matrix,
and rerun heavy CI only when an edited description changes the dependency
state.
Keep fork builds read-only and use a trusted workflow_run to validate
artifacts and post per-build dependency results. Document the supported
declaration forms and operational limits.
Assisted-by: Kiro:gpt-5.6-sol
Signed-off-by: zhangning21 <zhangning21@xiaomi.com>
The keyboard driver documentation described the byte stream codec and
nothing else. It never mentioned keyboard_register(), keyboard_event()
or the event types, so somebody writing a driver had no way to find the
interface that every keyboard in the tree actually uses.
That omission has a cost that can be counted: six of the nine drivers
that register a keyboard report only the press and release types and
never the special ones, which means their arrow keys are silently
dropped by any application that follows the contract. The header they
would read to find out declares two of the four types.
Document the contract, why the event type is what tells an arrow key
from the character that shares its value, what to name the device, how
to get a matrix keyboard working without writing a driver at all, and
how to test the result with or without the hardware.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Wire the shared Ameba GPIO driver into the RTL8721F (amebagreen2) build and
add the EVB board glue:
- arch/arm/src/rtl8721f: build ameba_gpio.c (CMake/Make.defs), source the
common Ameba Kconfig, and add ameba_gpio_chip.h describing the chip's
three GPIO ports (A/B/C), their IRQs and the APBPeriph clock bit.
- arch/arm/src/common/ameba: teach the driver that amebagreen2's ROM
GPIO_Init does not call PAD_PullCtrl or GPIO_INTMode, so call both
explicitly after GPIO_Init; on RTL8721Dx (ram_common) these are harmless
redundant writes. Add the AMEBA_PORT_C / AMEBA_PC() helpers.
- boards/arm/rtl8721f/rtl8721f_evb: register output/input/interrupt demo
pins, add the bringup hook, and provide a minimal 'gpio' NSH defconfig.
- Documentation: add a GPIO section for the RTL8721F EVB and fix a
rising/falling typo in the PKE8721DAF page.
Hardware-verified on the RTL8721F EVB: output, input, and all interrupt
trigger/polarity combinations (rising/falling edge, level high/low).
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Add platform documentation for the Realtek RTL8721F: a chip overview
page and the rtl8721f_evb board page, modelled on the existing RTL8720F
/ RTL8721Dx docs. The platform index picks them up automatically via
its */index glob.
The pages cover the vendor-SDK/toolchain dependency, the make and CMake
build/flash flow, and the hardware-verified features: NSH over the
LOG-UART console, littlefs at /data on the on-chip NOR flash, Wi-Fi
station and SoftAP via the wapi tool, and the DHCP client/server.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Co-Authored-By: Claude <noreply@anthropic.com>
Document setreuid/setregid, getresuid/getresgid, and how inode_reserve
assigns owner and group for pseudo-filesystem objects.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
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>
