Under CONFIG_AUDIO_MULTI_SESSION, audio_pause() and audio_resume() take a
session argument, but two internal call sites still passed only the file
pointer:
audio.c:612 audio_start() forwarding a resume of a paused device
audio.c:694 audio_stop() forwarding a pause
Neither compiles, so the option cannot be selected at all -- which is
presumably why nobody has noticed.
Guarded the way the rest of the file guards the same pair.
Tested on sim:nsh with AUDIO, AUDIO_MULTI_SESSION and AUDIO_NULL. Before
the change, audio.c does not compile. After the change, the build passes.
A local test app on the null audio device runs both changed paths:
AUDIOIOC_START on a paused device resumes it, and AUDIOIOC_STOP while
another open is paused pauses the device. Both return 0.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Whitespace only. Add a blank line after two declarations. The errors
are older than the next commit, but checkpatch checks the whole file.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
An unprivileged task that touched memory it does not own took the whole
system down. The MMU refused the access, as it should, and then
x86_64_fault_panic_isr() panicked -- so a contained application bug
became a system-wide outage. x86_64 had no user-fault recovery at all,
while arm64, RISC-V and esp32s3 each have one, and ISR13 and ISR14 here
went straight to a handler whose own comment says "Don't even brother
to recover, just dump the regs and PANIC."
The decision has to be made in the handler. The user-task check in
_assert() looks like it already covers this, but a fault arrives as an
exception, so up_interrupt_context() is already true by the time it is
reached and the panic branch is taken no matter who faulted.
The CPL in the saved CS is the whole test, and on this architecture it
is exact: everything that runs on behalf of a user task inside the
kernel -- a system call body, an interrupt handler, a kernel thread --
runs in ring 0, so a fault there is correctly refused recovery. That is
what RISC-V reads out of STATUS_PPP and arm64 out of SPSR_MODE_EL0T.
x86_64 cannot use TCB_FLAG_SYSCALL the way those two do: it has never
set it, and making it do so is a separate change with its own hazards
(see the note in x86_64_syscall()). The task type is checked as well,
as RISC-V does, so that a frame that cannot be trusted -- an early-boot
fault, before any user task exists -- cannot talk its way in with a
stale selector.
Recovery is the same shape as the other architectures -- RIP to _exit,
first argument SIGSEGV, TCB_FLAG_FORCED_CANCEL raised -- plus the three
x86_64 specifics:
* CS and SS move to the kernel selectors together with RIP. The frame
being rewritten is the one x86_64_fullcontextrestore() is about to
iretq from, and iretq takes the target privilege level from the CS
it pops; in long mode it pops SS with it even when the level does
not change.
* RSP moves to the top of the task's own kernel stack. _exit() must
not run on the user stack the fault came from, because the address
environment that stack belongs to is torn down while _exit() is
still running. The kernel stack is free -- the fault was taken in
user mode, so no system call of this task is in flight. The -8
reproduces the offset a call would have left, which is what the SysV
ABI states its 16-byte rule against and what up_initial_state() sets
up for the same reason.
* RFLAGS is reset to the value up_initial_state() gives a new thread
rather than carried over. The faulting task's flags are its own to
set, and DF in particular must be clear on entry to any C function.
ISR6 is routed through the same handler. An invalid opcode is
attributable to the instruction that raised it, so a user task running
garbage should die on its own rather than take the system with it --
the same conclusion esp32s3 reached for EXCCAUSE_ILLEGAL. ISR8 keeps
panicking unconditionally: a double fault says an exception could not be
delivered at all, and there is nothing left to trust.
The message gives the fault address (CR2) only for a page fault, because
the other exceptions do not set CR2.
X86_GDT_PL_MASK and X86_GDT_RPL_USER now live in intel64/arch.h beside
the selectors they mask; x86_64_fork.c had a private copy of the latter.
Verified on qemu-intel64:knsh_romfs under QEMU TCG with
apps/examples/sandbox. The probe targets kernel .text at _stext
(0x100909000). This config sets CONFIG_RAM_START to 0x0, a Kconfig
default, so the address is given on the command line. The "x" probes
call the address; that mode was added to the sandbox locally for the
test.
sandbox r 0x100909000 -> Exception 14, error code 5, 2816
sandbox w 0x100909000 -> Exception 14, error code 7, 2816
sandbox x 0x100909000 -> Exception 14 at RIP=100909000, 2816
sandbox r 0x8000000000000000 -> Exception 13 (non-canonical), 2816
sandbox x 0x80000000d -> Exception 6 at RIP=80000000d, 2816
All five probes run in one boot and report CONTAINED. The offender
dies with SIGSEGV, the parent survives, a canary thread keeps running,
and the memory and descriptors of the offender come back. The shell
answers after the last probe. Without this change each probe panics
the system.
ostest exits with status 0 on knsh_romfs, fork and vfork included. It
also exits with status 0 on the flat qemu-intel64:nsh with
CONFIG_SCHED_THREAD_LOCAL disabled. With it enabled, ostest faults in
sched_thread_local_test() with and without this change.
Each vector is reached deliberately. A non-canonical address is a #GP
rather than a #PF, which the read and call probes never produce on their
own. The #UD needs no corrupt binary either: the crt0 stub this
architecture links into every user ELF already ends in a ud2 at
_stext+0xd, and with CONFIG_ARCH_TEXT_VBASE at 0x800000000 the call
probe can simply be aimed at it, executing an invalid opcode in ring 3
out of the process's own text.
The negative direction was checked too, on the flat build, where the
same non-canonical read is taken at CPL 0: it reaches
x86_64_fault_panic_isr() exactly as before and panics with a full
register dump reporting CPL 0.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Two problems in the same path make a contained user fault look like a
kernel failure.
arm64_el1_undef() dumps the words around ELR. For an exception taken
from EL0, ELR is a user address, and the words around it can be in a
page that is not mapped. Then the memcpy faults inside the fatal
handler. That nested exception trips the DEBUGASSERT in
arm64_fatal_handler(), and the fault that the user took is not reported.
The ESR that tells what happened is lost. Skip the dump when the
exception came from EL0. At EL1 the address is kernel code that was
just fetched, so keep the dump there.
arm64_fatal_handler() then reports the fault that it recovers from as
"PANIC: Unhandled user exception", followed by a full register dump.
But there is no panic: it sets TCB_FLAG_FORCED_CANCEL, changes ELR to
_exit(SIGSEGV), and the system continues without the offending task.
Print "Segmentation fault in <process> (PID n: <thread>)" instead, the
same message as risc-v, and keep the register dump for the
PANIC_WITH_REGS() path, which is fatal.
Tested on QEMU qemu-armv8a:knsh with examples/sandbox and ostest. A
user read or write of kernel memory (0x40000000) now prints:
arm64_exception_handler: ESR_ELn: 0x9200000e
arm64_fatal_handler: Segmentation fault in sandbox (PID 10: sandbox)
arm64_fatal_handler: Reason: DABT (lower EL) - Data Abort from a ...
sandbox: the offender exited with status 2816
Before this change it printed "PANIC: Unhandled user exception" and a
register dump for the same recovered fault. An undefined instruction
at EL0 now prints "Undefined instruction at <ELR>" without the dump,
then the same segmentation fault message. The shell survives in all
cases, and ostest exits with status 0 before and after this change.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
nxstyle reports "Bad right brace alignment" for the closing brace of the
switch in arm64_el1_exception_handler(). Indent it like the switch,
because CI checks every file that a change touches.
No functional change. The change is whitespace only.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
In CONFIG_BUILD_PROTECTED, a user task that touches memory it does not
own must be terminated on its own. The rest of the system must keep
running. riscv_fault_handler() already does this: it checks for a fault
taken from U-mode, sets TCB_FLAG_FORCED_CANCEL and changes the exception
return to _exit(SIGSEGV) in privileged mode. But the whole block was
inside #ifdef CONFIG_ARCH_KERNEL_STACK. Configurations that do not
select that symbol, such as rv-virt:pnsh and rv-virt:pnsh64, fell
through to PANIC_WITH_REGS(). A contained user-space bug stopped the
whole system.
Only the last line of the block needs a kernel stack:
running_regs()[REG_SP] = tcb->xcp.ktopstk;
because xcp.ktopstk exists only with one. Narrow the guard to that
assignment, so the rest compiles in all configurations. arm64 already
does the same in arm64_fatal_handler().
It is correct to leave REG_SP unchanged. In riscv_exception_common.S
the switch to the kernel stack at exception entry is also inside
#ifdef CONFIG_ARCH_KERNEL_STACK. Without a kernel stack, the exception
frame goes on the user stack and REG_SP holds the user SP.
dispatch_syscall() already runs on that stack, so the kernel runs all
system calls of this task there, exit() included. Running _exit on it
after a fault is the same case and adds no new exposure. The stack also
stays mapped until the scheduler switches away, because a build without
a kernel stack cannot select CONFIG_ARCH_ADDRENV
(riscv_exception_common.S has an #error for that combination).
No behaviour change in other builds. The recovery runs only when the
saved STATUS_PPP is clear, that is, when the fault came from U-mode. In
CONFIG_BUILD_FLAT, tasks run at kernel privilege (M-mode, or S-mode on
the nsbi configurations), so STATUS_PPP is set and the panic path stays
the same. CONFIG_BUILD_KERNEL configurations select ARCH_KERNEL_STACK
through ARCH_ADDRENV, so their code does not change.
Tested on QEMU with examples/sandbox and ostest. On rv-virt:pnsh and
rv-virt:pnsh64 a forbidden read or write of kernel memory now kills
only the offending task, with status 2816 (SIGSEGV). The shell and an
unrelated thread keep running. Before this change the same access
caused a PANIC. ostest exits with status 0 on both, before and after
this change. rv-virt:knsh still builds, and its riscv_exception.o
differs only in the __LINE__ value of the PANIC call.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
nuttx_tasking.rst lists g_waitingforsemaphore, g_waitingformqnotempty and
g_waitingformqnotfull as task lists. They no longer exist: a task that
waits for a semaphore, an event or a message queue is on a prioritized
wait list in that object. Describe that, and remove the three lists.
Also spell "preempted" as codespell wants, because CI checks every file
that a change touches.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Three comments say that the caller of inode_search() and
_inode_linktarget() holds the g_inode_sem semaphore. That semaphore no
longer exists. The caller holds the inode tree lock, from inode_lock()
or inode_rlock(). No code change.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Three comments say that g_waitingforsemaphore must be prioritized, and the
message queue code says that its waiters are in g_waitingformqnotempty and
g_waitingformqnotfull. These lists do not exist. A task that waits for a
semaphore, an event or a message queue is on a prioritized wait list in
that object, which g_tasklisttable finds through TLIST_ATTR_OFFSET.
Say that in the comments. No code change.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
nxstyle reports "Bad left brace alignment" for the block that sets up
the heaps in nx_start(). Indent the block like the code around it,
because CI checks every file that a change touches.
No functional change. The change is whitespace only.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Add a Features bullet and an "i2c" configuration section to the
RTL8730E EVB board page describing I2C0-2 as /dev/i2c0-2, the pads the
board table registers and the i2ctool scan command, following the
pke8721daf board format.
Note the two pad constraints that are specific to this chip: a pad
reaches exactly one I2C controller (unlike the GPIO and UART
crossbars), and the pads inside the analogue audio ranges are driven by
the codec and cannot carry I2C.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Expose the RTL8730E I2C controllers through the shared Ameba I2C driver
(arch/arm/src/common/ameba/ameba_i2c.c) by adding the chip-specific
glue, build wiring and a board bus table. The change is gated by
CONFIG_AMEBA_I2C (default disabled).
Chip glue (ameba_i2c_chip.h) supplies the three controller register
bases, the APB function/clock masks -- amebasmart encodes these in
bit 25/26/27 with the group selector bit30=0, unlike the (bit30 |
bit10/11) layout of the KM4-based parts -- and the pad-mux code.
amebasmart has a single generic PINMUX_FUNCTION_I2C shared by every I2C
pad instead of per-signal SCL/SDA crossbar codes, and its
I2C_InitTypeDef omits the DMA request-level fields, so
AMEBA_I2C_HAS_DMA_FIELDS stays undefined. The whole I2C fwlib lives in
ram_common/ameba_i2c.c rather than lib_rom.a, so it is compiled into
libameba_fwlib.a when I2C is enabled.
The shared driver gains an optional per-controller IP-clock hook,
AMEBA_I2C_IPCLK_FN(bus). amebasmart needs it because its
I2C_StructInit() fills in a 10 MHz placeholder rather than the real
reference clock (the other Ameba parts fill in a correct XTAL_ClkGet()
/ PLL_GetHBUSClk() / HPERI_ClkGet()), which makes I2C_SetSpeed()
miscompute the SCL counts. The hook resolves the rate at run time: the
two HS controllers sit on HS_AHB, i.e. NP_PLL divided by
REG_LSYS_CKD_GRP0.CKD_HBUS, so it is a PLL/board setting and not a
constant -- an EVB measured CKD_HBUS=8 (div9, 88.9 MHz) while the SDK's
own I2CCLK_TABLE claims a flat 100 MHz and the register reset value
would imply 80 MHz. The LP-domain I2C0 keeps its fixed 20 MHz. Chips
that leave the macro undefined use the fwlib default and are
unaffected; regression-tested on pke8721daf:i2c.
All three controllers are registered: /dev/i2c0 on PA9/PA10, /dev/i2c1
on PA3/PA4 and /dev/i2c2 on PB10/PB11. Pad choice is constrained on
this chip -- a pad reaches exactly one controller (SDA fixed per
controller, SCL the next pad up), and the pads inside the analogue
audio ranges (PA20-PA29, PA30-PB2, PB3-PB6) are driven by the codec and
leave the bus stuck idle. Both rules are noted in the table's
comment.
Also add a weak DiagVprintf stub: the I2C fwlib logs through RTK_LOGx()
-> rtk_log_write(), and unlike DiagPrintf that symbol is not in the AP
ROM symbol table. It is weak so the strong definition in
rtl8730e_wifi_stubs.c still wins when WiFi is enabled; both route to
vprintf.
Hardware-verified on an RTL8730E EVB against a second board running an
I2C slave: register read, write, write/read round-trip, multi-byte dump
and a full address scan, on all three buses at 100 kHz.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
OpenAMP libmetal calls up_addrenv_pa_to_va() and up_addrenv_va_to_pa(),
and every virtio driver uses libmetal. With CONFIG_DEV_SIMPLE_ADDRENV,
drivers/misc/addrenv.c provides both. Without it, arm64 provides only
up_addrenv_va_to_pa(), in arm64_physpgaddr.c. So an arm64 build with
an MMU and any virtio driver does not link, flat or kernel:
undefined reference to `up_addrenv_pa_to_va'
The flat qemu-armv8a virtio configurations set CONFIG_DEV_SIMPLE_ADDRENV.
That does not fit a kernel build: its table gives the same address back
for a user address of the process.
Add up_addrenv_pa_to_va() next to up_addrenv_va_to_pa(). It translates
the page pool and the kernel RAM with arm64_pgvaddr(), and any other
address to itself. up_addrenv_va_to_pa() must then give back the same
physical address, otherwise the function returns NULL, as
include/nuttx/arch.h specifies.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
With CONFIG_EXECFUNCS_SYSTEM_SYMTAB, the make build generates
exec_symtab.c from libc.csv, libm.csv and syscall.csv with the host
tool mksymtab. CONFIG_LIBC_ELF_SYSTEM_SYMTAB does the same for
elf_sys_symtab.c. The CMake build did neither, so a CMake configuration
with one of these options did not link:
binfmt_execsymtab.c: undefined reference to `g_symtab'
Do the same in libs/libc/CMakeLists.txt: build mksymtab as a host tool,
sort the three lists by name, generate the table with the configured
array and count names, and add it to the C library. mksymtab runs in
the build directory with relative names, so the output is the same as
from the make build.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Documentation/os/binfmt/fdpic.rst covers what an FDPIC module is and what
it adds over the position independent ELF support already in the tree, how
the loader places one, where shared libraries come from and how they are
found, which entry points resolve a function descriptor and the rules for
adding another, and how to build a module and a library. A comparison
table places it against NXFLAT and PIC ELF, and the reference section
records the object layout and the relocations.
pimoroni-pico-2-plus:xipfs-fdpic is the configuration the series was tested
on: xipfs on the board's QSPI flash, the ELF loader with CONFIG_FDPIC, and
apps/examples/fdpicxip with apps/testing/fs/xipfs.
CONFIG_DEFAULT_TASK_STACKSIZE is 4096 there rather than the rp23xx default
of 2048. Both sides of the loader need it: a module that calls into the
firmware's printf family overflows 2048, and with no MPU that is a lockup
rather than a diagnostic. CONFIG_ELF_STACKSIZE follows it, and
apps/testing/fs/xipfs sizes its own task from it.
CONFIG_HAVE_CXXINITIALIZE is set because crt0 runs the constructors of a
module only with it, and the xipfs suite checks that they ran.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The linker scripts of the board name the bounds of .init_array the way the
Pico SDK does, __init_array_start and __init_array_end, and do not
define _sinit and _einit. lib_cxx_initialize() walks _sinit to _einit,
so a configuration with CONFIG_HAVE_CXXINITIALIZE does not link:
"undefined reference to `_sinit'".
Define _sinit and _einit at the same places in the three scripts.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
With CONFIG_ARCH_HIPRI_INTERRUPT enabled, arm_doirq() dispatches PendSV
for deferred processing. The STM32H7 debug handler unconditionally panics
on that valid interrupt, preventing normal operation with debug enabled.
Guard the panic with CONFIG_ARCH_HIPRI_INTERRUPT, allowing the common
interrupt path to finish signal delivery and context switching. Preserve
the diagnostic when high-priority interrupts are disabled.
Assisted-by: Codex:GPT-6
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
GPIO_EDGE_RISING was (12 << GPIO_CN_SHIFT), which sets bits 10 and 11
(GPIO_PULLDOWN | GPIO_EDGE_DETECT) instead of the edge type bit 12 that
its comment describes. A pin configured for rising edges therefore also
got the pull-down, and a falling-edge pin with GPIO_PULLDOWN was taken
as a rising-edge pin. Use bit 12.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
The RX byte count and the EMAC1MAXF limit both include the 4-byte FCS,
but the driver did not account for it:
- RXBUFSZ was programmed with CONFIG_NET_ETH_PKTSIZE, rounded down to
16 bytes (1504 for 1514), so longer frames were split into fragments
and dropped.
- EMAC1MAXF was set to CONFIG_NET_ETH_PKTSIZE, so the MAC rejected
frames longer than CONFIG_NET_ETH_PKTSIZE - 4.
- d_len included the FCS.
Make room for the FCS in the buffers, program RXBUFSZ with the aligned
buffer size and EMAC1MAXF with CONFIG_NET_ETH_PKTSIZE + 4, and remove
the FCS from d_len. The largest ping that got an answer was 1458
bytes; it is now 1472, the full 1500-byte MTU.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
VIRT_ADDR() converted the DMA buffer addresses to KSEG1, while the
buffers come from g_buffers, which is linked in KSEG0 when the data
memory is cached. Buffers then ended up in the free list under both
aliases. Use the segment g_buffers is linked in instead.
A buffer handed to an RX descriptor may still have dirty D-Cache lines,
at least the free list link written into it. If such a line is evicted
while the DMA writes the frame, it overwrites part of the frame.
Discard the buffer from the D-Cache before giving it to the DMA.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
After starting an MII management command, the driver executed 16 NOPs
before waiting for the busy flag to clear. The flag is set a few clock
cycles after the command, and when the code runs from the I-Cache the
NOPs end before that: the wait returned at once and phyread() returned
the previous read data. With the L1 cache enabled the PHY was not found
(ID1 read as 0x3000) and the interface never came up.
Poll until the busy flag is set, bounded in case the command has
already completed, before waiting for it to clear. A management frame
lasts 64 MDC cycles, so the flag cannot be missed.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
pic32mz_bufferinit() appended every buffer to pd_freebuffers without
emptying the list first. On the first ifup the list is empty (the
driver structure was cleared), but on later ones it still holds the
buffers that were free at ifdown. Appending them again truncates the
list and loses buffers, depending on which ones were free. With too few
buffers left the driver could no longer transmit or replace RX buffers,
so after ifdown/ifup the interface stayed up without answering (not
even ARP) until the next ifdown/ifup.
Reproduced with ifdown/ifup from NSH while pinging the board every
10 ms: 3 of 10 cycles left the interface dead before the fix, none
after it. This also happens on cable reconnection with
CONFIG_NETINIT_MONITOR, which takes the interface down and up.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
The driver had no d_ioctl, so CONFIG_NETDEV_PHY_IOCTL had no effect.
Implement SIOCGMIIPHY, SIOCGMIIREG and SIOCSMIIREG and, with
CONFIG_ARCH_PHY_INTERRUPT, SIOCMIINOTIFY. SIOCMIINOTIFY subscribes
through phy_notify_subscribe() (the board provides arch_phy_irq()) and
enables the PHY link down and auto-negotiation complete interrupts.
This is what CONFIG_NETINIT_MONITOR needs.
The PHY interrupt is implemented for the LAN8720 and LAN8740; add their
interrupt source/mask register bits to mii.h.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
After a successful auto-negotiation, pic32mz_phyinit() called
pic32mz_phymode() with the negotiated speed and duplex. That function
clears MII_MCR_ANENABLE, so the PHY stayed in a forced mode. The link
keeps working until the cable is removed, but on reconnection the PHY
no longer negotiates and, against an auto-negotiating partner, the link
stays down (seen with a LAN8720A: MCR 0x2100, MSR without link status).
Only force the mode when CONFIG_PIC32MZ_PHY_AUTONEG is not selected.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
- Close the TX descriptor ring on the last TX descriptor. It used
CONFIG_PIC32MZ_ETH_NRXDESC, so with more RX than TX descriptors the
DMA ran past the TX ring and stopped transmitting after two packets.
- Decrement ETHSTAT.BUFCNT (ETHCON1.BUFCDEC) for each received
descriptor that is processed.
- Drop a received packet instead of asserting when no buffer is free to
replace the one in the RX descriptor.
- Program EMAC1SA0-2 with the MAC address assigned to the device, if
any. The driver only read these registers, which are preloaded with a
factory address on PIC32MZ EC/EF but reset to zero on PIC32MZ-W1.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Fix the indentation of a wd_cancel() call and add braces to an empty
while loop, so that the file passes checkpatch.sh. No functional change.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
The kernel mode section shows the QEMU command but does not say why
-semihosting is there. Without it the guest traps in smh_call and stops in
AppBringUp, which reads as a kernel defect and is not one. It cost me a
session once.
Also state that a kernel build is the only mode on this board with POSIX
fork(), and that vfork() is available in every mode.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Duplicate an address environment into freshly allocated pages mapped at the
same virtual addresses, which is what POSIX fork() is built on. It lives in
arm64_addrenv_mmu.c: an MPU address environment is a set of protection
regions over one physical address space, not a mapping that can be duplicated
at the same virtual addresses. So ARCH_ARM64 selects ARCH_HAVE_FORK only
in a kernel build with ARCH_ADDRENV. The condition repeats the
ARCH_ADDRENV dependency, because a select bypasses depends on.
arm64_fork_stack() then lets the child run at the parent's stack addresses. A
pointer to a stack local taken before fork() must name the same object in the
child that it named in the parent, so the child adopts the parent's stack
geometry rather than being given a relocated copy; the parent's stack is
already in the duplicate, at the parent's address, with its contents. With a
zero offset arm64_fork_reloc() is then the identity, so the register context
needs no further special casing.
Verified on qemu-armv8a:knsh under qemu-system-aarch64: ostest's fork_test
reports "Parent and child had independent memory", and vfork_test passes.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
jz4780_decodeirq() saves the interrupted context into
g_running_tasks[this_cpu()]->xcp.regs on entry, but nothing updates
g_running_tasks[] after a context switch: every interrupt saves the
context into the Idle task's TCB, and once a task exits (up_exit() sets
the entry to NULL) no context is saved at all and the next context
switch restores stale registers.
Set g_running_tasks[this_cpu()] to this_task() before returning, as
pic32mz_decodeirq() does. This is the same bug that crashed the
PIC32MZ-W1 when the netinit thread exited.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
pic32mx_decodeirq() saves the interrupted context into
g_running_tasks[this_cpu()]->xcp.regs on entry, but nothing updates
g_running_tasks[] after a context switch: every interrupt saves the
context into the Idle task's TCB, and once a task exits (up_exit() sets
the entry to NULL) no context is saved at all and the next context
switch restores stale registers.
Set g_running_tasks[this_cpu()] to this_task() before returning, as
pic32mz_decodeirq() does. This is the same bug that crashed the
PIC32MZ-W1 when the netinit thread exited.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
pic32mz_decodeirq() saves the interrupted context to the TCB in
g_running_tasks[], but never updated g_running_tasks[] after a context
switch. It kept pointing at the Idle task from nx_start(), so every
interrupt overwrote the Idle task's saved registers, and after up_exit()
set it to NULL no context was saved at all. The next context switch
then restored stale registers; on PIC32MZ-W1 the system crashed as soon
as the netinit thread exited.
Set g_running_tasks[] to this_task() before returning, as the other
architectures do.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Change the imxrt1180-evk M7 NSH configuration to use the SoC memories
more efficiently:
- Place .data, .bss, idle stack and primary heap into DTCM
- Allocate available OCRAM as a secondary heap
- Add a separate .dmamemory section in OCRAM for USB device DMA
allocations
- Place .ramfunc into ITCM, together with hand-picked "hot" functions.
The section is copied to ITCM at boot by the ramfunc copy.
The eDMA accesses DTCM through the SoC's dedicated bus window.
This configuration acts as an example of performance optimization for
imxrt1180 based boards.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Cortex-M7 core's DTCM is available for other peripherals via a
dedicated address space. If transfers are done to or from the DTCM,
translate addresses to work on this shadow memory region instead, via
which the eDMA can access the DTCM.
This allows using the existing imxrt peripherals, which use DMA, to work
directly even if .data/.bss are located in DTCM.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add support for Cortex-M33 code to initialize the M7 TCM memories before
releasing it to run. The TCM has ECC, which needs to be initialized before
the memory is usable for M7.
Specifically, the TCM needs to be initialized sequentially in 64-bit writes.
Use eDMA4 for this; this is the same mechanism which the NXP MCUXpresso SDK
code does.
Split imxrt118x_release_cm7() into imxrt118x_prepare_cm7() and
imxrt118x_start_cm7(). The TCM ECC initialization is done in
imxrt118x_prepare_cm7(), after the M7 has been released from reset and
before the M7 is started. Also reset M7_CFG[TCM_SIZE] to the default
256 KiB ITCM / 256 KiB DTCM layout.
Co-Authored-By: Jukka Laitinen <jukka.laitinen@tii.ae>
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Move the imxrt118x SRC register defintions to an own file. They differ
from the other imxrt chips, and were also scattered between blockctrl
and a common imxrt_src headers.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
telnet_putchar() dropped every CR from the user buffer. RFC 854
requires a CR to be followed by LF or NUL, so send it and add a NUL
if the next character is not LF.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: raiden00pl <raiden00@railab.me>
telnet_putchar() appended the carriage return after the line feed, so
every output line ended with LF CR. RFC 854 defines the telnet end of
line as CR LF.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: raiden00pl <raiden00@railab.me>
Indent the switch cases in telnet_ioctl() and factory_ioctl(), align a
closing brace and wrap a long comment line. No functional change.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: raiden00pl <raiden00@railab.me>
virtio_9p_create() copies the tag from "tag=" to the next comma, and the
length it computes includes the comma. So a tag that is not the last
option never matches the mount tag of the device:
nsh> mount -t v9fs -o tag=host,trans=virtio /mnt
nsh: mount: mount failed: 19
Copy only the characters of the tag. The allocation is zeroed, so one
more byte terminates it.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
v9fs_client_init() steps over each option with "options += length + 1",
to skip the comma after it. The last option has no comma, so the step
goes past the terminating NUL, and the loop parses the memory after the
string as more options. If that memory has a "trans=" or "uname=", it
replaces the option given.
For example, NSH keeps the next argument after the options:
nsh> mount -t v9fs -o trans=virtio,tag=host trans=x /mnt
nsh: mount: mount failed: 2
The parser reads "trans=x", and there is no transport "x". The same
thing happens to options in .rodata, as CONFIG_INIT_MOUNT_DATA is.
Skip the comma only when there is one.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
nxstyle reports "Missing blank line after declarations" in three places.
Add the blank lines, because CI checks every file that a change touches.
No functional change. The change is whitespace only.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Loop devif_poll() until it reports nothing more
to send, matching the batch-drain behaviour of the upper-half CAN
drivers, so a transfer completes on one notification.
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
RP23XX_FLASH_MTD_OFFSET and RP23XX_FLASH_MTD_SIZE come from Kconfig.
If the region ends past the end of the flash, the flash wraps the
address around, and an erase or program hits the start of the flash,
where the NuttX image is. For example, a 4M region at 1M does not
fit on the 4M flash of a Raspberry Pi Pico 2.
Read the JEDEC ID at initialization, in QMI direct mode as the Pico
SDK flash_do_cmd() does, and refuse a region that does not fit. The
capacity byte is log2 of the size in bytes. If the ID does not look
valid, warn and do not check.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
While the bootrom erases or programs the flash, the QMI is in direct
mode, and an access to the XIP space (flash or PSRAM) gives a bus
fault. The flash MTD driver accessed it in two cases:
- The data to program was in flash or PSRAM. flash_range_program()
read it during the operation. Now the driver copies each such page
to an SRAM buffer first.
- The caller's stack was in PSRAM. This is the normal case with
RP23XX_PSRAM_HEAP_USER, and possible with RP23XX_PSRAM_HEAP_SINGLE.
The operation pushed to that stack. Now the driver switches to a
small SRAM stack for the operation if the stack is in the XIP space.
The operation data is static (SRAM) since the previous commit.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The flash MTD driver disabled interrupts for a whole request. A
multi-block erase or a large write kept them off for seconds.
Erase one 64K block (or one 4K sector where the range is not block
aligned) and program one 256 byte page per step. Enable interrupts and
release the other core between steps. A single block erase is still
long, but that is the limit of the flash.
Also, on SMP:
- Do not send the pause call to the CPU that does the operation.
nxsched_smp_call_single_async() runs it at once on that CPU.
- Keep the isolation data in a static, not on the stack. The other
CPU spins on it while the flash is busy.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
After a flash operation the driver called flash_select_xip_read_mode()
with a fixed EBh quad mode and clock divisor 4, and called
flash_enter_cmd_xip() if it "failed". But that ROM function returns
void, so the check read a random r0. The fixed mode and divisor can
also be different from the ones the bootrom found at boot.
The datasheet (5.2.7, 5.4.8.10) and the Pico SDK use a different
method: after a flash boot the bootrom leaves an XIP setup function in
the first 256 bytes of boot RAM. It restores the read mode and clock
divisor found at boot. Boot RAM is not executable, so copy the
function to SRAM once at initialization, and call the copy.
If boot RAM is empty (no flash boot), use flash_enter_cmd_xip(), as
RP23XX_FLASH_MTD_SAFE_XIP does.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The bootrom flash functions reset the QMI window 1 (chip select 1)
registers and the QSPI pads. flash_flush_cache() also discards dirty
XIP cache lines. The flash MTD driver did not save anything, so after
the first erase or program the PSRAM on chip select 1 read garbage,
and PSRAM writes still in the cache were lost.
Do what the Pico SDK hardware_flash library does:
- Clean the XIP cache before the operation. Clean by set/way through
the top of the maintenance window, to avoid erratum RP2350-E11.
- Save the QSPI pads and the five QMI M1 registers before, and write
them back after XIP is restored. Also keep XIP_CTRL.WRITABLE_M1.
rp23xx_psram_restore() was the earlier fix for this, but nothing called
it. Remove it.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
