The QEMU virt machine has a PL031 RTC at 0x09010000 (SPI 2), which QEMU
sets from the host clock. qemu-armv8a did not register it, so the
system time started at CONFIG_START_YEAR, and files on a host share
(v9fs, hostfs) had times years in the future.
With CONFIG_RTC_PL031, up_rtc_initialize() now registers the PL031 as
the RTC, so the system time starts at the host's time.
The new option QEMU_RTC_PL031_SYNC makes the boot wait (up to a second)
for the RTC second to change. The PL031 counts whole seconds, so
without the wait the time starts up to a second behind the host.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
arch_setjmp.S stores d8-d15 only under CONFIG_ARCH_FPU, but it did not
include nuttx/config.h. So setjmp() never saved these registers and
longjmp() never restored them. They are callee-saved (AAPCS64), so a
function that kept a value in one of them could see it change after a
longjmp().
Include nuttx/config.h. The assembly then stores d8-d15, eight bytes
each, at offsets 112 to 176. struct setjmp_buf_s declared them as
eight 4-byte floats, 32 bytes short, so declare them as uint64_t too.
jmp_buf is now 176 bytes with the FPU, and its layout matches the
assembly.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
pgalloc() grows a process heap for sbrk(). It extended the address
environment of the running task (addrenv_own). While exec() sets up a
new process, the caller selects the new address environment and
allocates the new process's stack from its heap. When that stack does
not fit in the initial heap, the heap must grow, but the running task is
the caller. For the kernel thread that starts init this was an
assertion; for a user task it would have grown the caller's heap.
Use the selected address environment (addrenv_curr). For a normal sbrk()
it is the same as addrenv_own.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
This allows using >25MHz bus speeds by adding a configration option
to set SDIO_CAPS_SD_HS_MODE capability.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Add the missing clock gating macros for imxrt118x
- Change sw_cd_gpio from int32_t to gpio_pinset_t (64-bits on 118x)
- Invalidate cache again after the data has been received. Cache might
be refilled by a prefetch or, in theory, by cpu read touching the same
cache line - even though the latter should not happen.
- Map any DMA accesses to/from DTCM to the shadow address window, which
gives the uSDHC DMA access to the DTCM.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
With CONFIG_NET_PROMISCUOUS, also enable the multicast and "not me"
unicast receive filters (ETHRXFC MCEN and NOTMEEN), so that the MAC
accepts every frame on the link, as the option's help text describes.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
CPP is also used to preprocess init.rc into the /etc ROMFS. Without -P
it emits GNU linemarkers, which nxinit's parser rejects.
Assisted-by: OpenCode:claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
A JRCR reset only flushes and halts the job ring; a second reset, once
JRINT reports the halt done, completes it, as Linux's caam_reset_hw_jr()
does. With the single write the ring stayed halted, so the RNG
instantiate job never completed and every boot logged "job ring did not
answer" before the settle loop's second ring init finished the reset.
Signed-off-by: Royyan Zahir <royzah@gmail.com>
Add the PIC32MZ-W1 family, used in Microchip's WFI32E01 Wi-Fi modules.
W1 shares the MIPS32 M-Class core and much of the peripheral IP with
PIC32MZ EC/EF, but its SFR map, IRQ vectors, PPS registers and
configuration words are laid out differently, so these are new files
selected by CONFIG_ARCH_CHIP_PIC32MZW1:
- hardware/pic32mzw1_*.h, irq_pic32mzw1.h: memory map, PPS, IRQ vectors
and configuration words, from the PIC32MZ-W_DFP (Apache-2.0).
- pic32mz_wfi32_pwrclk.c: W1 does not set up its PLLs from the
configuration words. Software starts the 40 MHz crystal oscillator,
runs SYSCLK at 200 MHz from the system PLL, starts the Ethernet/Wi-Fi
PLL and switches the regulator from MLDO to buck mode using the
factory trim values (on B0 silicon). Facts not found in the
data sheet or DFP are marked [EX] in comments; they come from
Microchip's WFI32 Ethernet/Wi-Fi bridge example firmware.
- pic32mz_head.S, pic32mz_config.h: emit the W1 configuration words
(DEVCFG0/1/2/4, FBCFG0, FCPN0, FSIGN0).
- W1 differences in shared code: PREFEN only accepts 0/1, PB6DIV clocks
the CPU and is left alone, UART1/2, SPI1/2 and I2C2 are clocked from
PBCLK3 and the timers from PBCLK1 (data sheet Table 11-1), I2C1 and
I2C2 are not contiguous in the SFR map, UART1 and SPI1 can use their
dedicated (non-PPS) pins.
New Kconfig options: PIC32MZ_W1_PMU_MLDO (keep the regulator in its
power-on MLDO mode), PIC32MZ_W1_FLASH_WAITSTATES (default 5, the value
used by Microchip's example at 200 MHz) and PIC32MZ_W1_BOOTTRACE (polled
early boot trace on UART1, a bring-up aid).
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
mmu_write_ttbr0() writes TTBR0_EL1 and then invalidates the TLB. A write
to TTBR0_EL1 takes effect only at the next context synchronization event,
so until the ISB at the end of the invalidation, a table walk can still
use the old table. The instruction fetches of the invalidation sequence
itself do such walks. An entry that they cache after the TLBI completes
stays valid: walk cache entries are not tagged with the table base, and
the kernel and every process use ASID 0.
A kernel build then translates a user address of the new process through
a level 0 entry of the old table, and gets a level 1 translation fault.
Under QEMU with HVF on Apple silicon this happens on every boot of
qemu-armv8a:knsh: up_addrenv_va_to_pa() fails for the first user buffer,
and virtio gets a descriptor with address 0. TCG has no walk caches, so
it does not show the problem.
Add an ISB after the write, as the Arm ARM sequence for a TTBR change
without an ASID change requires: write, ISB, TLBI, DSB, ISB.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The completion handler did:
dmach->callback(...);
dmach->callback = NULL; /* after the call */
so a callback that registers itself again -- which is the only way for a
driver to keep a channel running continuously -- has that registration
wiped the moment it returns. The channel transfers one more block and
then goes deaf, with no error raised anywhere and nothing in the
registers to say why. A PWM audio driver hit this and worked around it
by restarting from a thread instead, which put a millisecond of silence
into every buffer boundary.
Lift the callback and its argument out first and clear them before the
call. One-shot behaviour is unchanged for every existing user, since
none of them re-register from inside the call; the difference is only
that one which does now survives.
Tested on a Pimoroni Pico Plus 2 W (pimoroni-pico-plus-2-w:nsh) with a
local test: a memory-to-memory transfer whose callback starts the next
one, 100 times. Master gives 1 completion of 100; this change gives 100.
The existing users (SPI, I2S, CYW43439, WS2812) do not start a transfer
from inside the callback, so they do not change.
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
rp23xx_dmachannel(). Add the blank line, 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>
Select STM32_HAVE_IP_USART_M33_V3 and drop the family serial, USART
header, and low-level console sources. Provide the USART clock and RCC
gate definitions for all thirteen ports in stm32_rcc_m33.h and the RX
DMA request numbers in the family DMA signal map. Include the family
DMA header from stm32.h so the common driver reaches the DMA API.
Extend the common Cortex-M33 v3 USART support with the STM32H5
features: USART6, UART7-9, USART10-11, and UART12 ports, the LPUART
prescaler for low baud rates, RX DMA through the family-provided
request number, wakeup-from-stop CR3 definitions, and per-port
descriptors gated by the family peripheral options.
Enable the USART FIFO for every Cortex-M33 family. The low-level
console uses the per-port kernel clock and RCC gate, which corrects
the UART9 and UART12 enable register. The RX DMA callback delivers
data only while reception is enabled.
The non-BSD break ioctl now uses the send-break request register
instead of a CR1 bit this USART IP does not have. Correct the UART12
gates and the RXDMA and console undef lists in the USART driver
header. Raise STM32_NUSART to six on the H56x and H57x parts so UART12
fits the device table, add the missing UART9 buffers, write LPUART CR1
only on the USART path, and build device names with snprintf so minors
above nine are valid.
Keep the termios flow control fields writable so TCSETS compiles with
input flow control, let up_putc emit a bare newline since syslog adds
the carriage return, and make the unconfigure-on-close options
available to every Cortex-M33 family.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Select STM32_HAVE_IP_GPIO_M33_V1 and STM32_HAVE_IP_EXTI_M33_V1 and
drop the family GPIO and EXTI sources and headers in favor of the
common Cortex-M33 v1 implementation. Add the RM0481 line count for the
H56x and H57x parts to the common EXTI line inventory.
Add GPIO_PORTI to the common Cortex-M33 pin encoding for the parts
with a ninth GPIO port.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Enable STM32_COMMON_M33 for STM32H5 and drop the family reset, NVIC,
SysTick, and idle sources in favor of the common Cortex-M33 v1
implementation. The common heap allocator replaces the generic ARM one
through a STM32_PRIMARY_SRAM_SIZE spanning the contiguous SRAM banks
and skips the SRAM2 region when the primary heap already covers it.
Rename the family RCC header to stm32_rcc_m33.h for the common RCC
dispatch.
Add the SRAM3 parity initialization block and the CONFIG_STM32_ICACHE
enable call to the common reset handler, taken from the STM32H5 start
logic. Without CONFIG_STM32_ICACHE the reset handler disables an
ICACHE left enabled by a bootloader on STM32_HAVE_ICACHE families.
Move the flat-build MPU initialization to stm32_mpuinit_m33_v1.c in
common/stm32, built for every Cortex-M33 family with ARM_MPU, and
declare stm32_mpuinitialize for ARM_MPU as well as protected builds.
Declare stm32_board_initialize in the common start header.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
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>
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_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>
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>
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>
The always-on timer has an alarm comparator, but the RTC driver did not
use it: rp23xx_rtc.c implemented only up_rtc_initialize(),
up_rtc_time() and up_rtc_settime().
Add the alarm and an RTC lower half for /dev/rtc0:
- rp23xx_rtc_setalarm(), rp23xx_rtc_cancelalarm() and
rp23xx_rtc_rdalarm() on the ALARM_TIME registers and the POWMAN
timer interrupt.
- An RTC lower half with rdtime, settime, setalarm, setrelative,
cancelalarm and rdalarm, registered by the common board bringup.
The comparator asserts while the time is past the alarm time, not on
a transition. So the interrupt handler disables the alarm before it
does anything else; clearing only the status makes the interrupt
repeat. The arming sequence is the one of
powman_timer_enable_alarm_at_ms() in the Pico SDK.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
setup_period() printed the uint8_t slice number with %d, and the
uint32_t frequency, the uint16_t top and the uint32_t divisor with %lu.
Use %u for the two small fields and PRIu32 for the two uint32_t fields.
No build warns about this today, because GCC does not check syslog
format strings. It shows with CONFIG_DEBUG_PWM_INFO only.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
