This companion change updates the nuttx-apps CMake build to use
NuttX’s NUTTX_DIR and NUTTX_BINARY_DIR instead of CMAKE_SOURCE_DIR
and CMAKE_BINARY_DIR, which incorrectly refer to the outermost project
when NuttX is embedded via add_subdirectory(). Since apps/ is itself
included from NuttX’s top-level CMakeLists.txt, these variables were
effectively being used as references to NuttX’s root and inherited
the same bug fixed in the matching NuttX change for #19697. All
self-referencing uses are replaced while intentionally preserving
standalone projects and unrelated custom variables or hardcoded paths.
The change affects only the CMake build system, preserves normal
standalone behavior, and was tested with sim:nsh both standalone and
embedded, with apps such as hello and ostest successfully built and
available in NSH.
Fixes#19697.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Alan Carvalho de Assis <acassis@gmail.com>
The link line for applications in a kernel build is libmm, libc and the
proxies. libnx is never named, though the export has been shipping it
all along. So every application built on NX or NXFONTS fails to link,
the nx examples and fbcon alike, with undefined references to the font
and geometry routines.
Name it, ahead of libc since it calls into it, and only when CONFIG_NX
is set so that configurations without graphics are unaffected.
Tested on an EIC7700 EVB in a kernel build: with this, an application
built on NXFONTS links and runs; without it the same application fails
at link time.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
fbcon asked the registry of built-in applications for the stack size and
priority to spawn its shell with. A kernel build has no such registry:
its programs are ELF files in a filesystem, which is exactly what the
posix_spawn() below already handles, PATH search and all. The lookup
therefore fails to compile there.
Ask the registry only where there is one, and take the numbers from this
example's own configuration otherwise.
Tested on an EIC7700 EVB in a kernel build: fbcon renders its console on
a 1080p HDMI framebuffer and spawns a shell whose prompt appears on the
monitor.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The terminal spawned "nsh" by a name compiled in, which finds nothing
on a system that installs NSH under another name, as a kernel build
does when NSH is the system's init: the program is /system/bin/init
and no "nsh" exists at all. The terminal came up,
took keystrokes, and had no shell behind it.
The name is now configurable and still defaults to "nsh", so a bare
name is looked up on PATH as before and a path is taken as given.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A bare `boot` (no argument, argc == 1) passes argv[1] == NULL.
nsh_getfullpath(NULL) returns strdup(g_home) == "/" instead of NULL,
which turned the default-boot path (NULL -> board default image)
into "/". board_boot_image("/") then failed with -EINVAL (-22),
preventing the board from booting.
Guard the nsh_getfullpath() call so NULL passes through unchanged,
restoring the original default-boot behavior while still resolving
relative paths when an argument is given.
This fixes the regression introduced by the relative-path support
```
commit fabafbc361 (origin/master, origin/HEAD)
Author: Junbo Zheng <zhengjunbo1@xiaomi.com>
Date: Fri Jul 24 23:47:44 2026 +0800
nshlib: add relative image path support in boot command
cmd_boot passed the image path straight to boardctl(), which resolves
it in a context that does not inherit the NSH shell cwd, so relative
paths failed and only absolute paths worked. Use nsh_getfullpath() to
resolve relative paths against the cwd before calling boardctl().
Signed-off-by: Junbo Zheng <zhengjunbo1@xiaomi.com>
```
Signed-off-by: Junbo Zheng <zhengjunbo1@xiaomi.com>
Both the demo and the test asserted that each running instance of a module
gets its own copy of a library named in DT_NEEDED: two instances adding
their own seed each saw a total of seed*3.
That was true of the loader that walked DT_NEEDED itself. The loader now
hands the work to dlopen(), which returns the object already in the module
registry rather than loading a second copy of it, so there is one library
and one set of its globals, shared by every module that names it. The
module's own data stays private per instance, because exec() loads the
module afresh each time.
What an instance can still assert on its own is that every add it made
landed in the library, so that is what it checks; the totals interleave and
the final one counts both. The test additionally checks the consequences:
the library is pinned once rather than once per instance, and its
destructor runs once, at the last close, holding what both instances built
up.
USER_FAIL_PRIVATE becomes USER_FAIL_SHARED rather than gaining a
companion. The bit is a private protocol between cxxuser.cpp, which sets
it, and testing/fs/xipfs, which reads it; nothing else names it, and the
property it used to report no longer exists.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The two helper scripts this Makefile names gained a file extension when
tools/fdpic came into the nuttx tree: checkpatch rejects an executable file
that is not .sh, .py or .bat.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Forward the packets received by a LoRa concentrator to a LoRaWAN network
server with the Semtech UDP protocol version 2, and turn the downlink
requests of the server into transmissions. The server may be given as a name
and is resolved with getaddrinfo(). No floating point is used anywhere.
The same program provides the "lora" command, which mirrors the AT command
set of the vendor gateway firmwares, plus tx, which sends a single packet and
so brings a gateway up against any LoRa receiver without a network server.
Nothing here names a chip: the types and the commands are the device
independent gateway ones of the nuttx repository,
nuttx/wireless/lpwan/lora_gw.h. The application depends on LPWAN_LORA_GW,
the symbol such a driver selects, so until one is merged nothing here is
compiled.
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.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. Keep the apps workflow
consistent with the implementation already merged in apache/nuttx.
Assisted-by: Kiro:gpt-5.6-sol
Signed-off-by: zhangning21 <zhangning21@xiaomi.com>
The CMake build passed no STACKSIZE, so kernel-mode ELF loading fell
back to CONFIG_ELF_STACKSIZE, which may exceed the initial user heap.
Use CONFIG_DEFAULT_TASK_STACKSIZE as the Makefile does.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Verify that a mutex remains reusable after its last waiter times out
and that ownership is transferred when another waiter remains queued.
Signed-off-by: Martin Krasula <mkrasula@elektroline.cz>
Six statements assign a variable to itself, which clang rejects:
src/doom/f_finale.c:637:16: error: explicitly assigning value of
variable of type 'const char *' to itself [-Werror,-Wself-assign]
637 | lumpname = (lumpname);
Chocolate DOOM wraps those strings in DEH_String() so that a dehacked
patch can substitute them. The port has no dehacked support, and the
macro went away with it, leaving the parentheses behind. Two comments
that only described the substitution go as well.
Nothing changes at run time. GCC does not warn about this, so the
configurations built so far never noticed; the ones built with clang
do, and they fail because the CI treats warnings as errors.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
dlopen() of an already loaded library used to fail, so nothing exercised
what happens when two callers hold the same object.
Open the library a second time, check the same handle comes back, close
one of the two and check the library is still usable through the other.
Needs the counterpart change in nuttx; without it the second dlopen()
returns NULL and this reports it.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Neither of these wants fork() semantics. Both reach for fork() only to put
work in the background, and each has a NuttX-native way to do that, so
neither needs a fork primitive at all -- which matters once apache/nuttx#19562
makes ARCH_HAVE_FORK conditional on the architecture implementing POSIX
fork().
netutils/dropbear: the port already routes every fork-then-exec through
vfork(), because sysoptions.h selects DROPBEAR_VFORK when HAVE_FORK is
undefined and the port leaves it undefined. spawn_command() in dbutil.c and
both call sites in scp.c follow that switch. The one exception is the
daemon() fallback that compat.c compiles under #ifndef HAVE_DAEMON, which
calls fork() directly and bypasses it. NuttX provides daemon() in
libs/libc/unistd/lib_daemon.c and declares it in unistd.h, so the fallback is
redundant; define HAVE_DAEMON alongside the HAVE_STRLCAT and HAVE_STRLCPY
entries that are there for exactly the same reason. The code was unreachable
in any case -- the port hands svr_getopts() an argv containing -F, so
svr_opts.forkbg is always zero and dropbear never calls daemon() at all.
testing/drivers/nand_sim: forked so that the parent could return to the shell
while the child registered the MTD device and slept forever. Nothing from
before the fork is used after it, so the child is a self-contained entry
point, and task_create() expresses that directly. The emulator body moves
into nand_sim_daemon() unchanged. TESTING_NAND_SIM therefore needs no fork
dependency, and the two sim configurations that enable it keep working
whatever ARCH_HAVE_FORK is set to.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Two places call fork() from code that is compiled unconditionally, which is
fine only for as long as every architecture provides it. NuttX is splitting
fork() into three primitives -- see apache/nuttx#19562 -- after which
ARCH_HAVE_FORK announces POSIX fork() specifically, and is off until an
architecture implements it. Both then fail to link. Each is dropped only
where ARCH_HAVE_FORK is unset, so builds that have fork() are unaffected.
system/libuv: test-fork.c and test-pipe-close-stdout-read-stdin.c are
filtered out of the test-*.c glob. Nothing is lost even where they are
dropped: every test they define is already excluded from the task list on
NuttX by 0001-libuv-port-for-nuttx.patch, which extends the _WIN32 guards
around them to __NuttX__ -- all nine fork_* entries and
pipe_close_stdout_read_stdin. They are compiled today but never run.
testing/ltp: the open_posix_testsuite is filtered through LTP's existing
BLACKWORDS mechanism, which already drops tests for absent features and is
already conditioned on configuration symbols. The pattern spares vfork()
and task_fork(). Where fork() is absent this drops 278 of 1943 test files;
those tests exercise fork() and cannot link without it, and they return per
architecture as fork() lands.
Against today's master this is a no-op: ARCH_HAVE_FORK is set everywhere, so
neither filter drops anything. It is part of what lets the NuttX side build
against apps master.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Both read a keyboard as a stream of characters: NSH uses a USB HID
keyboard for stdin, and the raw mode of the Microwindows keyboard driver
decodes the stream with the codec. That stream now comes from
INPUT_KEYBOARD_BYTESTREAM rather than from the USB HID driver itself.
Say so, so that Kconfig refuses a combination that cannot work instead of
letting the application read events and treat them as text. No in-tree
configuration selects either option.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The example gated its decoding on HIDKBD_ENCODED, which no longer
exists: the USB HID keyboard driver reports through the keyboard upper
half now, and what produces the byte stream is
INPUT_KEYBOARD_BYTESTREAM.
Left as it was, the option could never be satisfied and the example
would quietly stop decoding special keys.
Reaching the option again brings hidkbd_decode() back into the build
after a spell of being unreachable, and it uses isprint() without
including ctype.h. That is an error rather than a warning under the
-Werror the CI builds with, in the nine configurations that enable
EXAMPLES_HIDKBD, so add the include here rather than in a later commit.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Somebody porting a board has to work on the application side before the
keyboard driver exists, and somebody reviewing that work often does not
have the board at hand at all.
With -i the tool goes the other way and writes into a uinput keyboard,
either what it reads from its own stdin or every key of another keyboard.
So an application reading /dev/ukeyboard is driven from the serial
console, or from whatever is on the far end of it, and a real keyboard
and an injected one can drive it at the same time, which neither can do
on its own since an application opens a single device.
Nothing in the application changes: it is reading a keyboard like any
other, which is the point.
Validated on a Linum STM32H753BI, forwarding a USB HID keyboard and the
serial console into the same virtual keyboard, with the LVGL terminal
reading it. 24 press and release pairs survived the crossing with no
duplicate, no orphan and three keys held at once.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The terminal had three input sources to choose from, and its own help
text explained why: the physical keyboard options "differ in the data
the keyboard device delivers on read(), so pick the one that matches the
hardware". That is the abstraction leaking. A user had to know that
the keyboard was USB rather than a matrix in order to compile the
terminal, and swapping one for the other meant rebuilding.
There are two sources now, touch and physical, and the physical one
reads any keyboard registered with keyboard_register(). Which format
arrives is decided by INPUT_KEYBOARD_BYTESTREAM, a property of the build
rather than of the hardware, so the terminal no longer asks.
Cursor keys reported as special events scroll the terminal, which is
what a driver following the current contract sends. The out of band
codes that the M5Stack Cardputer reports as ordinary presses are still
honoured, so that board keeps working until its driver is converted.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
i_get_event() handled KEYBOARD_PRESS and KEYBOARD_RELEASE and dropped
everything else, so every key reported as KEYBOARD_SPECPRESS went
nowhere. On the simulator that is already every arrow key, since
sim_keyboard reports them that way: the game is unplayable and says
nothing about why.
Handle all four types. A special key carries a value from enum
kbd_keycode_e rather than a character, so it gets its own translation
into doomkeys.h and contributes no printable character to the event.
The map covers what the game binds by default, which now includes Ctrl,
Shift and Alt. Fire, run and strafe are on the modifiers, so a keyboard
that reports them is the difference between playing and walking around.
Enter needed folding onto KEY_ENTER as well. A driver reports it as the
character that it produces, which is the line feed, so it never arrived
as KEYCODE_ENTER and never matched the carriage return that the game
binds the menu to. Confirmed on hardware with a USB keyboard.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The hidkbd and keyboard examples do the same thing for one kind of
keyboard each: hidkbd reads a USB HID keyboard as a byte stream, and
keyboard reads an upper half keyboard as events. Neither works with the
other, so bringing up a new keyboard means picking the right example
first, and there is no answer for somebody whose keyboard is neither.
Every keyboard registered with keyboard_register() is read the same way,
so one tool covers them all: USB HID, matrix, simulator, virtio, VNC.
The payload follows INPUT_KEYBOARD_BYTESTREAM rather than a switch of
its own. An application has no business knowing what hardware is behind
the device, and a build cannot mix the two formats anyway.
The two examples stay for now. They are what the in-tree configurations
still name, and removing them has to wait until those configurations
have been moved over.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The bundled encoder was checked out from lame's trunk with no revision, so
every build took whatever trunk happened to be at that moment. lame's trunk
grows vector tiers over time, and each one adds sources that the two build
files have to name: r6655 offered AVX2 to the vector routines on 2026-07-25,
and r6718 and r6720 added an AVX-512 tier on 2026-07-30. The AVX-512 sources
were never listed, so sim:alsa stopped linking on x86 hosts:
takehiro.c:332: undefined reference to `quantize_lines_xrpow_avx512'
takehiro.c:533: undefined reference to `ix_max_avx512'
takehiro.c:569: undefined reference to `count_bit_esc_avx512'
vbrquantize.c:261: undefined reference to `calc_sfb_noise_x34_avx512'
Pin the checkout to r6720 through a LAME_VERSION variable, as the rest of
apps/ pins its third-party sources, and list the three AVX-512 files that
revision provides. The pin is what keeps the two in step: the source list is
maintained by hand, so it can only be correct for a known revision.
The checkout is also only performed when lame/configure is absent and is never
updated afterwards, so before this an unpinned tree was frozen at whatever
trunk was on the day it was first built. Anyone who checked out before
2026-07-30 still links and cannot reproduce the failure, which is why this
surfaced only in CI.
Makefile named just vector/xmm_quantize_sub.c and none of the other vector
sources, so a Make build on an x86 host fails the same way with a longer list
of symbols, from SSE2 upwards. CI builds sim:alsa through CMake only, so that
half was latent rather than visible. Both files now list the same nine
sources under the same host condition.
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds two sections to the xipfs suite, guarded by CONFIG_FDPIC so a build
without the loader is unaffected. They belong here rather than in their own
test because what they exercise is modules loaded *out of the filesystem* --
the pin, the in-place mapping and the loader are one path.
'fdpic' asserts on the loader properties that otherwise fail *quietly*: a
loader that skips DT_INIT_ARRAY runs a C++ module happily with every global
left zero, one that skips DT_JMPREL loads a module that hard-faults only
once it calls out, and one that mis-sizes the descriptor pool corrupts the
heap. None of those announce themselves. The module exit status is the
channel -- each module checks its own invariants and reports a bitmask. It
also covers shared libraries across concurrent instances, per-instance data,
the leaf-library GOT fallback, the R_ARM_FUNCDESC descriptor pool, and every
firmware entry point that has to resolve a module callback, including
mq_notify and timer_create with SIGEV_THREAD.
'reject' mutates a known-good module byte by byte and asserts the loader
refuses it rather than loading something broken: a missing import, and more
DT_NEEDED entries than the walk will follow.
The modules are embedded as headers, for the same reason as in
examples/fdpicxip, and built for cortex-m3 for the same reason: one set of
blobs then runs on both the v7-M and v8-M targets. Their sources and the
makefile that regenerates these headers live in
apps/examples/fdpicxip/modules, so the copies the two apps carry are built
from the same sources in the same way.
Verified on a Pimoroni Pico Plus 2: fdpic 33/33, reject 7/7, and the whole
suite 130/130 with them included. The same three numbers on mps2-an500 under
QEMU, which is a Cortex-M7 rather than the RP2350's Cortex-M33.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The FDPIC counterpart of examples/nxflatxip, kept separate from it: that
example is about NXFLAT, and mixing the two module formats into one program
would leave neither demonstrating anything clearly.
Four subcommands, each showing one property of the loader. 'qsort' is the
simplest case it has -- one self-contained module, two concurrent instances,
one shared copy of the text in flash and a private copy of the data each,
with the pin count showing the extent held in place while they run and
released after. 'solib' adds a shared library, so two objects are mapped
and each instance still gets its own copy of both objects' data. 'cxx' is
the same in C++, which additionally requires global constructors to have run
in dependency order before main. 'jmprel' is a module whose imports are all
in DT_JMPREL rather than DT_REL.
The modules are embedded as headers rather than built as part of the app:
linking one needs arm-uclinuxfdpiceabi binutils, which the tree does not
require, so the headers are committed and both this example and
testing/fs/xipfs build with a plain toolchain.
Their sources are in modules/, with a makefile that rebuilds every header
from them on an explicit 'make regen NUTTX_DIR=...' and is never invoked by
the application build. It drives nuttx/tools/fdpic and writes the headers
this example needs alongside the ones testing/fs/xipfs needs, so one source
tree serves both and the two cannot drift apart. CPU is cortex-m3 there
deliberately: a v7-M module runs on the v8-M targets too, so one set of blobs
serves both the RP2350 and mps2-an500, while a cortex-m33 build produces
blobs the Cortex-M7 cannot execute at all.
This demonstrates; it does not assert. The assertions are in the fdpic and
reject sections of apps/testing/fs/xipfs.
Verified on a Pimoroni Pico Plus 2: all four subcommands, and nxflatxip
unaffected alongside them. Also verified on mps2-an500 under QEMU, which is
a Cortex-M7 -- a different core generation from the RP2350's Cortex-M33.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
In flashtool_main.c, the 'default:' label in a switch statement was
followed directly by '}', which is invalid in C.
This commit adds a 'break;' statement after the default label to
resolve the error.
Signed-off-by: tuansuper <tunainnet@tutanota.com>
perf_gettime() and perf_getfreq() are kernel functions, defined in
sched/clock/clock_perf.c. Neither appears in syscall.csv, and libc supplies
only perf_gettime(), under CONFIG_ARCH_HAVE_PERF_EVENTS_USER_ACCESS. So a
protected or kernel build cannot resolve either of them from user space:
ostest/perf_gettime.c:91: undefined reference to `perf_gettime'
ostest/perf_gettime.c:184: undefined reference to `perf_getfreq'
make[1]: *** [nuttx_user.elf] Error 1
The call in user_main() is guarded by CONFIG_ARCH_PERF_EVENTS &&
!CONFIG_ARCH_PERF_EVENTS_USER_ACCESS -- which is exactly the case where the
symbols are kernel-only -- so every such configuration fails to link.
mps3-an547:knsh is one: it sets CONFIG_SCHED_IRQMONITOR, which makes
ARCH_PERF_EVENTS default y. mps2-an521:knsh escapes only because it sets
neither monitor, leaving ARCH_PERF_EVENTS off, so the call compiles out and
the archive member is never pulled in.
Require CONFIG_BUILD_FLAT, where ostest links against the kernel's own copy.
No configuration that runs the test today stops running it.
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
CONFIG_NETUTILS_MDNS_STACKSIZE defaulted to DEFAULT_TASK_STACKSIZE,
which resolves to as little as 2KiB on some targets. The bundled
mjansson responder uses a deeper stack than that (DNS record parsing
with name decompression, plus the send/receive buffers) and overflows
on startup, taking the board down with a hardfault before it answers a
single query.
Default to 8KiB, the value that reliably runs the responder, and
correct the help text, which previously claimed a 4KiB default that did
not match DEFAULT_TASK_STACKSIZE.
Assisted-by: Claude (Anthropic Claude Code)
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
Require a cryptodev backend for FSUTILS_PASSWD and tie NSH console/telnet
login to ROMFS passwd generation when ETC_ROMFS is enabled.
Fixes#19573
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Install a minimal passwd file at CONFIG_LIBC_PASSWD_FILEPATH before
getpwnam() checks so sim:ostest does not require a pre-built /etc/passwd.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Add getresuid/setreuid coverage plus ownership and permission checks
for message queues, named semaphores, shared memory, and FIFOs.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Use getresuid() and getresgid() for Linux-style id output with name
resolution and a groups= list based on the effective GID.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
The blit assumed a 32-bit frame buffer: it wrote a uint32_t per pixel
and converted the palette with ARGBTO32 as it went, so the image came
out wrong anywhere else. It also drew at the origin, leaving the image
in a corner of a display it does not fill, and indexed the source by the
output column, which costs a division for every pixel of every frame.
Convert the palette once per palette change into the format the frame
buffer actually uses, map output columns to source columns through a
table built at startup, and centre the result. Output rows that come
from the same source row are copied rather than converted again.
Four options are added, all off by default, so that a board can trade
memory for speed where it pays:
GAMES_NXDOOM_FB_CMAP blits palette indices and lets a frame buffer
that has a colour map do the conversion in hardware.
GAMES_NXDOOM_FILLSCREEN stretches the image over the whole display
rather than scaling it by a whole number.
GAMES_NXDOOM_ROWSTAGE builds each row in a staging buffer so that the
frame buffer only sees burst-friendly copies.
GAMES_NXDOOM_STATIC_SCRNBUF places the render target in .bss, which
keeps it out of external memory on a board whose heap is mostly that.
On an STM32H753 driving a 1024x600 panel from SDRAM, the last two are
worth 2.7x together.
Also open the frame buffer with O_CLOEXEC.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Without this Make variable, Objects.rules does not add font_fnt.o
to the build, causing undefined reference to fnt_createfont at link time.
Signed-off-by: Acfboy <AcfboyU@outlook.com>
The point of a writable execute-in-place file system is that a module can
arrive after the firmware was built and still run without being copied into
RAM. This demonstrates exactly that, end to end: it writes an NXFLAT module
into xipfs the way a download would, declaring the size up front so the
extent is exact, checks the file system can hand out a real flash pointer
for it, and runs two instances concurrently.
Both instances report the address of their own text and of their stack. The
text address is the same in both and is inside the flash window -- it is the
address the file occupies on the media -- while the stacks differ. While
they run, the extent carries one pin per instance, which is what stops the
defragmenter relocating code that is executing.
Two subcommands cover the file system rather than the module. bench times a
bulk read out of the mapped flash before and after a write, which on the
RP2350 is the cost of whichever path the driver used to restore XIP. defrag
fills the volume, deletes every other file until an allocation genuinely
cannot be satisfied, compacts, retries the same allocation, then verifies
every relocated file byte for byte and again after a remount, printing a
block map at each step.
The module has neither static data nor string constants, and reports through
a callback into the firmware instead of formatting its own output. That is
not stylistic: the ldnxflat in circulation resolves the GOT entries for .bss
objects into the import table, and drops the addend when it resolves the
PC-relative references to .rodata, so a module using either quietly computes
wrong addresses. The comment in module/xipmod.c records both. The callback
also exercises the other direction of the interface, firmware code entered
with the module's data base still live in r10.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Twelve sections, selected by name on the command line because the power loss
sweeps run for minutes while everything else runs in seconds.
The routine part covers the VFS paths, the write-once rules (reopen for
write, append, seek during write, truncate of a written file are all refused)
and both mmap variants: that a plain mapping lands inside the media window
with no heap growth, that MAP_XIP_STRICT fails with ENXIO rather than
copying, and that N mappings of one file produce N pins on one extent.
The rest is aimed at the two properties that are easy to get wrong and quiet
when they are:
Pin release. A pin taken by one task and a task that dies with a mapping
still live both have to end with the extent movable again -- the second
without the task ever calling munmap, since a module that faults never will.
Both are checked by asking the defragmenter to move the extent afterwards.
Power-loss atomicity. With CONFIG_FS_XIPFS_FAULT_INJECT the suite fails the
Nth flash operation, remounts, and checks the volume is consistent and every
file that had been committed is byte-for-byte intact. It sweeps N across
create, unlink and defragmentation, and repeats the sweep with the failing
write torn -- a partial program rather than a clean refusal -- which is what
a real power loss mid-program leaves behind.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
xipfs has a defragmentation ioctl and no way to reach it from a shell. The
only caller was a demo in examples/nxflatxip, which built its own block map
to show what compaction had done.
xipfs [-n] [-t <ms>] [<mountpoint>]
-n surveys and reports without moving anything: where each file sits, a map
of the volume, and how much of the free space a single allocation can reach.
That last number is the one a caller facing -ENOSPC actually wants; at 0%
the largest possible file already fits however scattered the map looks.
The compaction is asked for through a descriptor for the mountpoint
directory, so no file inside the volume is open while it runs and a single
pass can reach every extent.
The walk descends into the directories xipfs synthesises from names, and
reports each file by its path relative to the mount, so a volume that uses
them is described in full rather than down to its first level.
Block totals come from statfs rather than XIPFSIOC_EXTENTINFO, because that
one does name a file and an empty volume has none, yet its geometry is still
worth reporting.
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
This ports mwdemo.c from Microwindows as a standalone NuttX example
application. mwdemo is the primary Win32 API demo in the Microwindows
project, featuring 3D graphics, window controls, timer-driven
animation, and bitmap image rendering.
The demo runs on both qemu-intel64:mw and sim:mw configurations.
Signed-off-by: Acfboy <AcfboyU@outlook.com>
examples/microwindows: address review, clean up mwdemo.
- Replace minimal copyright notice with full Apache 2.0 license header
- Use angle brackets for system and microwindows includes
- Remove OS-specific dead code (DOS_TURBOC, RTEMS, EMSCRIPTEN/MULTIAPP)
- Drop unused demo-mode macros and their corresponding dead code paths
(IMAGE, CLIENT3D, CLIPDEMO, ARCDEMO). Keep a fixed GRAPH3D+CONTROLS
configuration as the single NuttX demo.
- Add g_ prefix to global variable (image -> g_image)
- Move demoWndData typedef from mid-file to Private Types section
- Merge WinMain body into main() and remove the WinMain indirection
- Removed unused images.
Signed-off-by: Acfboy <AcfboyU@outlook.com>
This commit integrates the Microwindows core into the NuttX apps
build system:
- Downloads a pinned upstream commit during build and compiles the
engine, drivers and precompiled bitmap fonts via Microwindows'
Objects.rules files.
- Adds Kconfig options for framebuffer path, keyboard driver
selection (event-mode, raw byte-stream, none, custom), and
mouse/touchscreen driver selection (relative, touchscreen, none,
custom).
- Uses the MWCONFIG_FILE mechanism to inject NuttX-specific
configuration (mwconfig.nuttx) without modifying upstream headers.
- The NuttX screen, keyboard, mouse and touchscreen drivers are
pulled from upstream Microwindows. Driver selection is controlled
via ARCH=NUTTX and Kconfig-driven KEYBOARD/MOUSE variables in
the Makefile.
- Depends on VIDEO_FB for the framebuffer device.
- Builds the mwin library (Win32 API layer) when MICROWINDOWS_MWIN
is enabled.
Co-authored-by: Pavel Pisa <ppisa@pikron.com>
Signed-off-by: Pavel Pisa <ppisa@pikron.com>
Signed-off-by: Acfboy <AcfboyU@outlook.com>
Add a -p option to select the pattern to draw. The existing expanding
rectangles animation remains the default, and a new "smpte" pattern
fills the display with seven equal vertical bars (white, yellow, cyan,
green, magenta, red and blue), which is useful to verify color ordering
and channel wiring of a framebuffer display.
To support more than one palette, the draw_rect() helpers now receive
the color value to write instead of an index into the per-format color
tables. Monochrome displays pick black or white per bar using a BT.601
luma threshold.
The FBIO_UPDATE ioctl is moved out of draw_rect() into a new
present_area() helper, so the SMPTE pattern can draw every bar and
then update the display only once.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
This fixes all the warnings in the i_pcsound module caused when enabling
the sound feature Kconfig option. This warnings would prevent CI from
passing.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
