The I2C master driver support for the RTL8721Dx (pke8721daf) and RTL8721F
(rtl8721f_evb) boards was merged without the matching board documentation.
Add the missing I2C entry to each board's Features list and an "i2c"
configuration section describing the /dev/i2cN devices, the board pin
table, and the i2ctool usage, mirroring the existing gpio/uart sections.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Wire the RTL8720F to the shared Ameba I2C master driver
(arch/arm/src/common/ameba/ameba_i2c.c), reusing it unchanged.
Add the per-chip header arch/arm/src/rtl8720f/ameba_i2c_chip.h supplying
the chip's I2C wiring: two controllers (I2C0/I2C1) on their non-secure
register aliases (0x401c8000 / 0x401c9000), the APBPeriph function/clock
masks, the crossbar SCL/SDA pad-mux codes (59/60 and 61/62), and
AMEBA_I2C_HAS_DMA_FIELDS=1 (the chip's I2C_InitTypeDef carries the DMA
request-level fields).
Add the board glue: rtl8720f_i2c.c registers I2C0 at /dev/i2c0
(PA22/PA23) and I2C1 at /dev/i2c1 (PA24/PA25), plus the build wiring
(Make.defs / CMakeLists.txt / ameba_board.mk pull in the common driver
and the fwlib ram_common/ameba_i2c.c data-table source), the bringup
registration hook and the board header declaration.
Add the i2c defconfig (minimal NSH with the i2ctool) and document the
config in the board index.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Wire the shared common UART driver
(arch/arm/src/common/ameba/ameba_uart.c) into RTL8720F. Add an
ameba_uart_chip.h supplying the per-chip UART parameters: two
general-purpose controllers (UART0/UART1), their non-secure register
bases (0x401C3000 / 0x401C4000 -- the fwlib UART_DEV_TABLE points at
the non-secure alias), NVIC vectors, APBPeriph function/clock masks
and the crossbar TX/RX pad-mux function codes.
The fwlib ROM UART routines index data tables (UART_DEV_TABLE,
APBPeriph_UARTx) that live in fwlib ram_common/ameba_uart.c, so that
source is compiled in when CONFIG_AMEBA_UART is set. Wire
CONFIG_AMEBA_UART into Make.defs/CMakeLists/ameba_board.mk, add the
board port table (UART0 at /dev/ttyS1, PA22 TX / PA23 RX, 115200 8N1)
with bringup registration, a uart config and board documentation.
Hardware-verified on rtl8720f_evb: serialrx/serialblaster over a
PA22-to-PA23 TX/RX loopback transferred all 2600 bytes intact.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
RTL8720F drives all GPIO through a single 32-pin port A controller
served by one NVIC vector, unlike RTL8721Dx (ports A/B) or RTL8721F
(ports A/B/C). Add an ameba_gpio_chip.h that configures the shared
common GPIO driver (arch/arm/src/common/ameba/ameba_gpio.c) for a
single port: AMEBA_GPIO_NPORTS=1, AMEBA_GPIO_PORT_IRQS={GPIOA} and
the APBPeriph_GPIO gate bits.
GPIO_INTStatusGet/ClearEdge live in the RTL8720F ROM symbol table, so
no fwlib ram_common object needs compiling in. Wire CONFIG_AMEBA_GPIO
into Make.defs/CMakeLists/Kconfig, add the board pin table (PA22 out,
PA23 in, PA24 interrupt) with bringup registration and a gpio config.
Hardware-verified on rtl8720f_evb: output, input and (falling-edge)
interrupt all confirmed via a PA22-to-PA24 loopback.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
QEMU's b-l475e-iot01a machine models the STM32L4x5 core peripherals, but
not the QUADSPI controller or the on-board MX25R6435F flash. The nsh
configuration therefore panics during board bring-up, inside
stm32_qspi_initialize() -> mx25rxx_initialize() -> qspi_command(), before
the console has produced any output.
Add a qemu configuration that is nsh without CONFIG_B_L475E_IOT01A_MTD_FLASH
and the QSPI/MTD/SMARTFS chain that symbol selects. It boots to an NSH
prompt on USART1 under:
qemu-system-arm -M b-l475e-iot01a -nographic -kernel nuttx
Document the new configuration, including the fact that QEMU's STM32L4x5
USART model never calls qemu_chr_fe_accept_input() after the guest reads
RDR. Console input consequently stalls after the first byte or two when a
line is pasted or piped in, although typing at human speed works.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Add the board photo and replace the placeholder todo in the RTL8721F EVB
documentation index with a figure directive so the board page renders the
hardware image, matching the other Realtek board pages.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Expose the RTL8721F general-purpose UARTs through the shared Ameba serial
driver in arch/arm/src/common/ameba. Only the chip-specific glue is added:
a new ameba_uart_chip.h supplying the green2 register bases, IRQs, clock
masks and UART TX/RX pin-mux function codes, plus the build wiring and a
board port table registering UART0 at /dev/ttyS1. The common serial layer
is reused unchanged.
A new "uart" board config enables the driver with the serialrx and
serialblaster examples and runtime TERMIOS support.
Verified on RTL8721F EVB hardware with a PA24/PA25 loopback: single-message
echo, 2600-byte serialrx/serialblaster throughput with no loss, and TERMIOS
reconfiguration (CS7 data-bit truncation, parity and stop-bit ioctl
round-trip, and 9600 baud reprogramming) all pass.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
In a kernel build vfork() is reached through a system call, so the return
address and stack pointer the architecture's entry point can see for itself
are the kernel's, not the caller's. A child built from those resumes at a
kernel address, which is why x86_64 selected the fork family only for the
flat build.
x86_64_syscall() now publishes the caller's frame in xcp.sregs for the
duration of the stub call, and x86_64_fork() builds the child from it:
x86_64_fork_syscall() when xcp.sregs is non-NULL, so that the child
returns from the very same `syscall' instruction as
the parent, in user mode, on its own stack;
x86_64_fork_direct() otherwise, which is the flat build and any kernel
thread that calls the entry point as a plain
function.
The discriminator is xcp.sregs rather than TCB_FLAG_SYSCALL, which arm64 and
RISC-V use: that flag also defers signal actions, x86_64 has never raised it,
and its kernel-build signal path does not survive being made to -- a
pre-existing problem that does not belong to this work.
Two properties of SYSCALL/SYSRET shape the child's frame. The instruction
leaves the caller's RIP and RFLAGS in RCX and R11 rather than on a stack, so
they are moved into the RIP and RFLAGS slots of the interrupt frame the child
is resumed from; and the hardware never records the caller's CS and SS at all,
SYSRETQ reconstructing them from IA32_STAR, so the child's are filled in with
the user code and data selectors at RPL 3. The frame is therefore not copied
wholesale: the extended state and the general registers are inherited, while
the segment registers and the thread pointer stay as up_initial_state() left
them, the child's stack being a fresh allocation the parent's FS base does not
describe.
x86_64_fork_relocfp() is new and is not optional here. A function returns
with `leave', which feeds the frame pointer into the stack pointer, so
relocating only the RBP the child resumes with gets it exactly one frame:
the next return loads a saved RBP still pointing into the parent's stack.
With that in place ARCH_X86_64 can select ARCH_HAVE_VFORK unconditionally.
Build-verified on qemu-intel64:knsh_romfs and qemu-intel64:ostest. NuttX on
qemu-intel64 requires tsc-deadline and pcid, which TCG does not implement, so
it cannot be run on this host.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
In a kernel or protected build vfork() is reached through a system call, so
the return address and stack pointer that the entry point in
arm64_fork_func.S can snapshot for itself belong to the kernel-side stub, not
to the caller. A child built from that snapshot resumes at a kernel address
on a kernel stack. This is why arm64 selected the fork family only for the
flat build.
Record what the caller was actually doing instead. arm64_sync_exc passes the
exception frame to dispatch_syscall() in x7 -- x0-x6 carry the call number and
its six parameters, so x7 is free -- and dispatch_syscall() stores it in
xcp.sregs, mirroring what riscv_swint.c does.
arm64_fork() then chooses where the caller's registers live:
arm64_fork_syscall() when TCB_FLAG_SYSCALL is set, rebuilding the child
from xcp.sregs so that it returns from the very same
SVC as the parent;
arm64_fork_direct() otherwise, which is the flat build and any kernel
thread that calls the entry point as a plain function.
The stack copy and the relocation of pointers into it are shared by both
paths in arm64_fork_stack() and arm64_fork_reloc().
With that in place ARCH_ARM64 can select ARCH_HAVE_VFORK unconditionally.
Verified on qemu-armv8a:knsh (BUILD_KERNEL), qemu-armv8a:nsh (BUILD_FLAT) and
qemu-armv8a:citest_smp under qemu-system-aarch64: ostest's vfork_test passes
on all three, and it was absent from knsh before the change. The protected
configurations are build-verified only (fvp-armv8r:pnsh), there being no
emulator for them here.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
In a kernel build the cloning primitives are reached through a system call,
and armv7-a dispatches one by re-pointing the caller's own exception frame at
dispatch_syscall() and switching to the task's kernel stack. The snapshot the
entry point in fork.S takes for itself therefore describes the kernel-side
stub, and the frames below it are on a stack the child gets no copy of: a
child built from that snapshot resumes at a kernel address with a stack
pointer into its own user stack. It faulted with a prefetch abort at PC 0 on
qemu-armv7a:knsh, which is why the fork family had never been run there.
Record what the caller was actually doing instead. arm_syscall() stores the
exception frame of the outermost system call in xcp.sregs, mirroring
riscv_swint.c, and arm_fork() chooses where the caller's registers live:
arm_fork_syscall() when a user stack pointer is saved, rebuilding the child
from xcp.sregs so that it returns from the very same SVC
as the parent, in the same mode, on its own stack and
with no inherited system call nesting;
arm_fork_direct() otherwise -- the flat build, a kernel thread in any
build, and a build without a kernel stack, where the
call is dispatched on the caller's own stack so the
caller's frames are copied along with the kernel-side
ones.
Note that the discriminator is xcp.ustkptr rather than TCB_FLAG_SYSCALL. On
armv7-a the caller is the task that runs the kernel side of its own system
call, so being in a system call is not by itself a reason to distrust the
snapshot; the switch to the kernel stack is. Because arm_syscall() has
already re-pointed the frame by the time arm_fork() runs, the caller's PC,
CPSR and SP come from where arm_syscall() put them -- syscall[0].sysreturn,
syscall[0].cpsr and ustkptr -- and the rest from the frame itself.
Nothing selects the primitives on an ARM kernel build yet, so this commit
changes no configuration; it is what the next one needs to be correct.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Documentation/guides/fork_vfork_migration.rst is new. It says what changed
and why, gives the two primitives as a table, states plainly what breaks, and
answers "which replacement do I want?" from the reader's own reason for having
called fork() -- posix_spawn() or vfork() to run a program, pthread_create()
for a second flow of control that shares memory, fork() itself for an
independent copy. It also documents the two configuration symbols, what an
architecture has to implement to gain real fork(), and the one visible
consequence of moving the vfork() suspension into the kernel: a waitpid()
after a child that _exit()s can only report status where
CONFIG_SCHED_CHILD_STATUS is enabled.
reference/user/01_task_control.rst gains an entry for fork() and rewrites the
one for vfork(), which described NuttX's limitations rather than the
interface's contract. standards/posix.rst moves fork() from "No" to "Cond."
and vfork() from "Yes" to "Cond.", both being conditional on the configuration
now. implementation/memory_configurations.rst no longer lists fork() as
unimplementable in the presence of address environments, which was the whole
point of that section's wish list. Three long-standing typos in that file are
corrected while touching it, since codespell checks the whole of any file a
patch modifies.
BREAKING CHANGE: this commit carries no code; it is the migration guide for
the fork() withdrawal in the commit before it, and is marked so that every
commit in the series carries the marker CONTRIBUTING.md 1.13 requires. The
quick fixes are in Documentation/guides/fork_vfork_migration.rst.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Add a common upper-half character driver for digital potentiometers
with a generic set of ioctl commands (wiper set/get, terminal control,
device properties) that can be shared by chip-specific lower halves.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
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>
