Commit graph

16647 commits

Author SHA1 Message Date
raiden00pl
2ef5db01f0 arch/arm/stm32: use common SYSTICK_HCLKd8 symbol
The SysTick timer logic of stm32h5, stm32h7, stm32l4, stm32l5, stm32u5
and stm32wl5 tests a family specific SYSTICK_HCLKd8 symbol, while
common/stm32 and stm32wb already test CONFIG_STM32_SYSTICK_HCLKd8.  Use
the common name everywhere.

No Kconfig defines the symbol and the timer logic undefines it
unconditionally, so this does not change the generated code.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
raiden00pl
968005810c arch/arm/stm32wb: use common Kconfig symbols
The flash header documents CONFIG_STM32WB_FLASH_CONFIG_x and the RCC
tests CONFIG_STM32WB_AES1/AES2, which no Kconfig defines.  Use the
common CONFIG_STM32_* names.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
raiden00pl
0ee1608bf0 arch/arm/stm32wl5: use common Kconfig symbols
CONFIG_STM32WL5_FLASHEN is not defined by any Kconfig, so the FLASH clock
enable is dead code.  Use CONFIG_STM32_FLASH.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
raiden00pl
8c23508510 arch/arm/stm32u5: use common Kconfig symbols
CONFIG_STM32U5_I2C3EN, SDMMC1EN, SDMMC2EN, the STM32U5xxXX family names
and STM32U5A5ZJT are not defined by any Kconfig, so the RCC clock enables
and the STM32U5A5ZJT block in chip.h are dead code.  Use the common
CONFIG_STM32_* symbols and CONFIG_ARCH_CHIP_STM32U5A5ZJT.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
raiden00pl
e68f9a7c85 arch/arm/stm32l5: use common Kconfig symbols
CONFIG_STM32L5_FLASHEN, OTFDEC1EN, PKAEN, SDMMC1EN, WWDGEN and GTZCEN
are not defined by any Kconfig, so the RCC clock enables are dead code.
Use the common CONFIG_STM32_* peripheral symbols.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
raiden00pl
b1df5ddfb8 arch/arm/stm32l4: use common Kconfig symbols
CONFIG_STM32L4_OTGFS_SOFOUTPUT is not defined by any Kconfig, so the SOF
output pin is never enabled.  Use CONFIG_STM32_OTG_SOFOUTPUT.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
raiden00pl
0de50ad42e arch/arm/stm32h7: use common Kconfig symbols
CONFIG_STM32H7_LCD_BACKLIGHT is not defined by any Kconfig, so the LTDC
backlight control is dead code.  Use CONFIG_STM32_LTDC_BACKLIGHT.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
raiden00pl
f15d609069 arch/arm/stm32h5: use common Kconfig symbols
The headers test CONFIG_STM32H5_* names that no Kconfig defines (the
STM32H5xXXX families, FLASHEN, OTFDEC1EN, DCACHE, STM32H2X/H3X/H7X), so
those branches are dead code.  Use the common CONFIG_STM32_* symbols.

Fix what this exposes: derive the SRAM2/SRAM3 bases from the family SRAM
sizes, since the boot ECC init would otherwise write past the end of RAM
on smaller parts, correct the H52x/H53x SPI count to SPI1-4 and drop the
STM32_STM32H5X3XX select, which names no symbol.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
raiden00pl
20f15ba2e3 arch/arm/stm32f7: use common Kconfig symbols
CONFIG_STM32F7_LCD_BACKLIGHT is not defined by any Kconfig, so the LTDC
backlight control is dead code.  CONFIG_STM32F7_PLLSAI and
CONFIG_STM32F7_PLLI2S are defined by the board.h files, and the common
SPI test helper names its mode macros CONFIG_STM32F7_SPIx_TEST_MODE.
Use the common CONFIG_STM32_* names everywhere.

Also drop the misspelled CONFIG_STM32F7_STM33F75XX from the DMA chip
check, which already tests CONFIG_STM32_STM32F75XX.

The CAN section of the STM32F7 documentation names the options
CONFIG_STM32F7F7_CANx, which has a duplicated family prefix and never
existed.  Use the common names there too.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-18 09:34:58 +08:00
dechao_gong
eaaba5e0a1 arch/arm/rtl8721f: add PWM master driver support
Wire the shared Ameba PWM driver (arch/arm/src/common/ameba/ameba_pwm.c)
to RTL8721F (amebagreen2).  The chip spreads PWM across four four-channel
timers (TIM4..TIM7); this port drives TIM4 as the single time base with
four compare channels, matching the shared driver's model.  A new
ameba_pwm_chip.h supplies the RTL8721F specifics taken from the SDK
fwlib headers: TIM4 at the non-secure base 0x41000000, 40 MHz input
clock, IRQ 11 (TIMER4_IRQ), crossbar pad-mux codes 111..114
(PINMUX_FUNCTION_TIM4_PWM0..3) and the distinct function/clock enable
bits (APBPeriph_PWM0 / APBPeriph_PWM0_CLOCK).

The board registers one timer at /dev/pwm0 with channel 1 on PB18 and
channel 2 on PB19 for the pwm example; edit the table to match a board's
wiring.  The common driver is not touched.

Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
2026-08-17 09:34:22 -03:00
dechao_gong
2546802911 arch/arm/rtl8720f: add PWM master driver support
Wire the shared Ameba PWM driver (arch/arm/src/common/ameba/ameba_pwm.c)
to RTL8720F.  The chip spreads PWM across several four-channel timers
(TIM4/TIM5); this port drives TIM4 as the single time base with four
compare channels, matching the shared driver's model.  A new
ameba_pwm_chip.h supplies the RTL8720F specifics taken from the SDK
fwlib headers: TIM4 at the non-secure base 0x401c7000, 40 MHz input
clock, IRQ 9 (TIMER4_IRQ), crossbar pad-mux codes 45..48
(PINMUX_FUNCTION_TIM4_PWM0..3) and the distinct function/clock enable
bits (APBPeriph_PWM0 / APBPeriph_PWM0_CLOCK).

The board registers one timer at /dev/pwm0 with channel 1 on PB18 and
channel 2 on PB19 for the pwm example; edit the table to match a board's
wiring.  The common driver is not touched.

Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
2026-08-17 09:34:22 -03:00
dechao_gong
6f2e17c113 arch/arm/rtl8721dx: add shared Ameba PWM driver
Add a shared NuttX PWM lower-half for the Realtek Ameba PWM timer in
arch/arm/src/common/ameba, driven through the SDK fwlib.  TIM8 provides a
single time base feeding eight compare channels (CCR0..CCR7) that share one
frequency while each carries its own duty, so a single /dev/pwm0 exposes the
multichannel output via CONFIG_PWM_NCHANNELS.  The fwlib PWM routines are
split ROM/RAM: the time-base calls resolve from on-chip ROM, while the
capture/compare calls live in fwlib ram_common/ameba_tim.c, which the build
pulls into AMEBA_FWLIB_SRCS when CONFIG_AMEBA_PWM is set.

Per-chip wiring (timer index, channel count, register base, input clock,
IRQ, clock masks and the crossbar pad-mux code table) lives in
arch/arm/src/rtl8721dx/ameba_pwm_chip.h so a port to another Ameba chip only
supplies a same-named header; the pad-mux codes are a per-channel table
(AMEBA_PWM_PINMUX_FIDS) rather than a computed base, so chips with a single
shared code or codes grouped per timer are expressed by the header alone.

The timer registers as /dev/pwm0 from pke8721daf bring-up through the stock
PWM character driver; a dedicated `pwm` defconfig drives examples/pwm for
validation.

Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
2026-08-17 09:34:22 -03:00
Liam Howatt
b245cc1762 arch/arm/stm32h5: Add EXTI GPIO support.
Copy the stm32u5 implementation,
add necessary port configuration for the MUXs.

Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Co-authored-by: Nathan Best <nathanbest@geotab.com>
Co-authored-by: Randy Rossi <randyrossi@geotab.com>
2026-08-17 10:45:14 +02:00
raiden00pl
440be49862 arch/arm/src/common/stm32: read UID with 32-bit accesses
STM32H5 stores the UID in flash memory that supports only 16-bit or
32-bit read accesses. The 8-bit reads introduced with the stm32_uid
unification generate an AHB bus error and hard fault the chip when
the Ethernet driver reads the MAC address.

Read the UID as three 32-bit words into an aligned buffer and copy it
to the caller's buffer. On little-endian ARM the resulting byte order
is identical to byte reads, so behavior is unchanged for the other
STM32 families.

Fixes: https://github.com/apache/nuttx/issues/19771

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-16 08:42:20 -03:00
dechao_gong
36a971567a arch/arm/rtl8721f: add SPI master driver support
Some checks failed
MemBrowse Memory Report / changes-filter (push) Waiting to run
MemBrowse Memory Report / load-targets (push) Waiting to run
MemBrowse Memory Report / identical (push) Blocked by required conditions
MemBrowse Memory Report / analyze (push) Blocked by required conditions
Build Documentation / build-html (push) Has been cancelled
Wire the shared Ameba SPI (DesignWare SSI) driver
(arch/arm/src/common/ameba/ameba_spi.c) into the RTL8721F (amebagreen2)
build and expose the SPI0/SPI1 masters at /dev/spiN.

Add the per-chip ameba_spi_chip.h with the amebagreen2 controller bases
(0x40121000 / 0x40122000, non-secure aliases), the group-0 SPI clock masks
(bit14/bit15), and the per-signal crossbar pad-mux codes (SPI0 75/76/77/78,
SPI1 79/80/81/82).  The SSI ip_clk is the PERI_HCLK-domain clock, which the
amebagreen2 fwlib exposes directly through HPERI_ClkGet(), so AMEBA_SPI_IPCLK()
is a single ROM call rather than the register poking the other ICs need.

Compile the common driver and the SDK fwlib SSI RAM source under
CONFIG_AMEBA_SPI, register the bus in the board bring-up, and add an "spi"
board configuration exercising the system/spi spitool.

Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
2026-08-14 11:36:37 -03:00
dechao_gong
214d02f417 arch/arm/rtl8720f: add SPI master driver support
Wire the shared Ameba SPI (DesignWare SSI) driver
(arch/arm/src/common/ameba/ameba_spi.c) into the RTL8720F build and expose
the SPI0/SPI1 masters at /dev/spiN.

Add the per-chip ameba_spi_chip.h with the RTL8720F controller bases
(0x401C1000 / 0x401C2000, non-secure aliases), the group-0 SPI clock masks,
the per-signal crossbar pad-mux codes (RTL8720F has no generic
PINMUX_FUNCTION_SPI), and the SYS_PLL-based ip_clk computation
(REG_LSYS_CKD_SYS_PLL_GRP0 HPERI divider).  The chip header declares the
SYS_PLL_ClkGet() query its AMEBA_SPI_IPCLK() uses, since RTL8720F has no
PLL_ClkGet().

Compile the common driver and the SDK fwlib SSI RAM source under
CONFIG_AMEBA_SPI, register the bus in the board bring-up, and add an "spi"
board configuration exercising the system/spi spitool.

Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
2026-08-14 11:36:37 -03:00
dechao_gong
7dbf782e5b arch/arm/rtl8721dx: add shared Ameba SPI driver
Add a shared NuttX SPI master lower-half for the Realtek Ameba SPI
controllers (SPI0/SPI1) in arch/arm/src/common/ameba, driven through the
SDK fwlib in polling mode with full-duplex exchange and a software chip
select.  Per-chip wiring (controller count, register bases, clock masks,
crossbar pad-mux codes and the fwlib SSI_InitTypeDef layout) lives in
arch/arm/src/rtl8721dx/ameba_spi_chip.h so a port to the other Ameba
chips only supplies a same-named header.

Each controller registers as /dev/spiN from pke8721daf bring-up through
the stock SPI character driver; a dedicated `spi` defconfig drives the
spitool for validation.

Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
2026-08-14 11:36:37 -03:00
raiden00pl
45657b976b arch/nrf53: fix HFXO trim field extraction
fix HFXO trim field extraction

Signed-off-by: raiden00pl <raiden00@railab.me>
2026-08-13 21:52:30 +08:00
Javier Alonso
f8cf5f9d4e arch/s32k3xx: initializers clobbering rx_pin instead of enable_high
The `rx_pin` configuration when `CONFIG_S32K3XX_FLEXCAN2` is defined is
overwritten if `PIN_CAN2_ENABLE` is defined, breaking the flexcan config
for S32K3 MCU.

Signed-off-by: Javier Alonso <javieralonso@geotab.com>
2026-08-13 12:29:11 +02:00
Javier Alonso
2a777381d6 arch/kinetis: initializers clobbering rx_pin instead of enable_high
The `rx_pin` configuration when `CONFIG_KINETIS_FLEXCAN2` is defined is
overwritten if `PIN_CAN2_ENABLE` is defined, breaking the flexcan config
for Kinetis MCU. Additionally, the `.enable_high` configuration points to
a non-defined constant/macro (looks like a legacy from the first driver
definition). Based on regularly maintained drivers (such as s32k3), this
was changed to `CAN2_ENABLE_OUT`

Signed-off-by: Javier Alonso <javieralonso@geotab.com>
2026-08-13 12:29:11 +02:00
Javier Alonso
8730a75687 arch/s32k1xx: initializers clobbering rx_pin instead of enable_high
The `rx_pin` configuration when `CONFIG_S32K1XX_FLEXCAN2` is defined is
overwritten if `PIN_CAN2_ENABLE` is defined, breaking the flexcan config
for S32K1 MCU. Additionally, the `.enable_high` configuration points to
a non-defined constant/macro (looks like a legacy from the first driver
definition). Based on regularly maintained drivers (such as s32k3), this
was changed to `CAN2_ENABLE_OUT`

Signed-off-by: Javier Alonso <javieralonso@geotab.com>
2026-08-13 12:29:11 +02:00
dechao_gong
af49db4483 arch/arm/rtl8720f: add I2C master driver support
Wire the RTL8720F to the shared Ameba I2C master driver
(arch/arm/src/common/ameba/ameba_i2c.c), reusing it unchanged.

Add the per-chip header arch/arm/src/rtl8720f/ameba_i2c_chip.h supplying
the chip's I2C wiring: two controllers (I2C0/I2C1) on their non-secure
register aliases (0x401c8000 / 0x401c9000), the APBPeriph function/clock
masks, the crossbar SCL/SDA pad-mux codes (59/60 and 61/62), and
AMEBA_I2C_HAS_DMA_FIELDS=1 (the chip's I2C_InitTypeDef carries the DMA
request-level fields).

Add the board glue: rtl8720f_i2c.c registers I2C0 at /dev/i2c0
(PA22/PA23) and I2C1 at /dev/i2c1 (PA24/PA25), plus the build wiring
(Make.defs / CMakeLists.txt / ameba_board.mk pull in the common driver
and the fwlib ram_common/ameba_i2c.c data-table source), the bringup
registration hook and the board header declaration.

Add the i2c defconfig (minimal NSH with the i2ctool) and document the
config in the board index.

Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
2026-08-12 08:46:16 -03:00
dechao_gong
18d2ae253c arch/arm/rtl8720f: add UART master driver support
Wire the shared common UART driver
(arch/arm/src/common/ameba/ameba_uart.c) into RTL8720F.  Add an
ameba_uart_chip.h supplying the per-chip UART parameters: two
general-purpose controllers (UART0/UART1), their non-secure register
bases (0x401C3000 / 0x401C4000 -- the fwlib UART_DEV_TABLE points at
the non-secure alias), NVIC vectors, APBPeriph function/clock masks
and the crossbar TX/RX pad-mux function codes.

The fwlib ROM UART routines index data tables (UART_DEV_TABLE,
APBPeriph_UARTx) that live in fwlib ram_common/ameba_uart.c, so that
source is compiled in when CONFIG_AMEBA_UART is set.  Wire
CONFIG_AMEBA_UART into Make.defs/CMakeLists/ameba_board.mk, add the
board port table (UART0 at /dev/ttyS1, PA22 TX / PA23 RX, 115200 8N1)
with bringup registration, a uart config and board documentation.

Hardware-verified on rtl8720f_evb: serialrx/serialblaster over a
PA22-to-PA23 TX/RX loopback transferred all 2600 bytes intact.

Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
2026-08-12 08:46:16 -03:00
dechao_gong
3197472ad4 arch/arm/rtl8720f: add single-port GPIO support
RTL8720F drives all GPIO through a single 32-pin port A controller
served by one NVIC vector, unlike RTL8721Dx (ports A/B) or RTL8721F
(ports A/B/C).  Add an ameba_gpio_chip.h that configures the shared
common GPIO driver (arch/arm/src/common/ameba/ameba_gpio.c) for a
single port: AMEBA_GPIO_NPORTS=1, AMEBA_GPIO_PORT_IRQS={GPIOA} and
the APBPeriph_GPIO gate bits.

GPIO_INTStatusGet/ClearEdge live in the RTL8720F ROM symbol table, so
no fwlib ram_common object needs compiling in.  Wire CONFIG_AMEBA_GPIO
into Make.defs/CMakeLists/Kconfig, add the board pin table (PA22 out,
PA23 in, PA24 interrupt) with bringup registration and a gpio config.

Hardware-verified on rtl8720f_evb: output, input and (falling-edge)
interrupt all confirmed via a PA22-to-PA24 loopback.

Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
2026-08-12 08:46:16 -03:00
Luka Filipović
62b41ad9b4 arch/arm/src/common/stm32: Bound SDIO command response wait by time.
Some checks are pending
MemBrowse Memory Report / changes-filter (push) Waiting to run
MemBrowse Memory Report / load-targets (push) Waiting to run
MemBrowse Memory Report / identical (push) Blocked by required conditions
MemBrowse Memory Report / analyze (push) Blocked by required conditions
stm32_waitresponse() polls SDIO_STA bounded only by an iteration
counter, set to 0x7fffffff for all R1/R1B/R2/R4/R5/R6 commands.  The
hardware CTIMEOUT flag is the intended exit for a missing response,
but it is only generated while the card clock is running and the CPSM
has reached its Wait state.  If the card clock stops or the peripheral
fails, SDIO_STA never updates and the loop spins for INT32_MAX
iterations while holding the FAT filesystem lock, at the caller's
priority-inheritance boosted priority if higher priority tasks block
on the filesystem.  Since the mmcsd layer retries failed commands,
the driver's recovery paths are never reached and the system never
recovers.

Bound the wait by time instead: 250 ms for response-bearing commands
(the largest timeout the SD specification allows for any operation)
and 10 ms for the no-response/R3/R7 cases.  CTIMEOUT remains the
normal error exit within microseconds; the software bound only fires
when the peripheral itself is dead, converting an unbounded spin into
-ETIMEDOUT so the existing mmcsd retry logic can run.

Signed-off-by: Luka Filipović <filipovicluka3@gmail.com>
Assisted-by: Claude Code:claude-fable-5
2026-08-12 15:41:32 +08:00
dechao_gong
30cbb23e6b arch/arm/rtl8721f: add I2C master driver support
Wire the shared Ameba I2C master lower-half (arch/arm/src/common/
ameba/ameba_i2c.c) into the RTL8721F (amebagreen2) build through a
per-chip header (ameba_i2c_chip.h), and register the RTL8721F EVB
buses at /dev/i2cN.

Per-chip differences from the other Ameba SoCs (non-secure register
bases, crossbar pinmux codes, APB clock masks and the fwlib
I2C_InitTypeDef layout) are isolated in ameba_i2c_chip.h; no change to
the shared driver is needed.

Verified end-to-end on hardware against a second Ameba board acting
as an I2C slave: address ACK, register write and read-back over
repeated-START, and bus scan all pass on I2C0 (PA22/PA23).

Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
2026-08-12 14:22:00 +08:00
dechao_gong
dfc55c9bbe arch/arm/rtl8721dx: add shared Ameba I2C driver
Add a shared NuttX I2C master lower-half for the Realtek Ameba I2C
controllers (I2C0/I2C1) in arch/arm/src/common/ameba, driven through
the SDK fwlib in polling mode.  Per-chip wiring (controller count,
register bases, clock masks, crossbar pad-mux codes and the fwlib
I2C_InitTypeDef layout) lives in arch/arm/src/rtl8721dx/ameba_i2c_chip.h
so a port to the other Ameba chips only supplies a same-named header.

Each controller registers as /dev/i2cN from pke8721daf bring-up through
the stock I2C character driver; a dedicated `i2c` defconfig drives the
i2ctool for validation.

Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
2026-08-12 14:22:00 +08:00
Darryl Ring
894a08e35f arch/arm/stm32h5: Fix handling of GPIO port I
Correct the number of GPIO ports (STM32_NPORTS) from 8 to 9 and include
GPIOI in the g_gpiobase array. Also fix the comparison that would
prevent the GPIOI clock from being enabled (this is really a no-op,
though).

Signed-off-by: Darryl Ring <darryl@bluerobotics.com>
2026-08-11 10:51:46 +08:00
dechao_gong
b5ec07b19b arch/arm/rtl8721f: add UART character driver support
Expose the RTL8721F general-purpose UARTs through the shared Ameba serial
driver in arch/arm/src/common/ameba.  Only the chip-specific glue is added:
a new ameba_uart_chip.h supplying the green2 register bases, IRQs, clock
masks and UART TX/RX pin-mux function codes, plus the build wiring and a
board port table registering UART0 at /dev/ttyS1.  The common serial layer
is reused unchanged.

A new "uart" board config enables the driver with the serialrx and
serialblaster examples and runtime TERMIOS support.

Verified on RTL8721F EVB hardware with a PA24/PA25 loopback: single-message
echo, 2600-byte serialrx/serialblaster throughput with no loss, and TERMIOS
reconfiguration (CS7 data-bit truncation, parity and stop-bit ioctl
round-trip, and 9600 baud reprogramming) all pass.

Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
2026-08-10 09:51:02 -03:00
Marco Casaroli
608d1e269a arch/arm: Build fork() children from the caller's syscall frame on armv7-a.
In a kernel build the cloning primitives are reached through a system call,
and armv7-a dispatches one by re-pointing the caller's own exception frame at
dispatch_syscall() and switching to the task's kernel stack.  The snapshot the
entry point in fork.S takes for itself therefore describes the kernel-side
stub, and the frames below it are on a stack the child gets no copy of:  a
child built from that snapshot resumes at a kernel address with a stack
pointer into its own user stack.  It faulted with a prefetch abort at PC 0 on
qemu-armv7a:knsh, which is why the fork family had never been run there.

Record what the caller was actually doing instead.  arm_syscall() stores the
exception frame of the outermost system call in xcp.sregs, mirroring
riscv_swint.c, and arm_fork() chooses where the caller's registers live:

  arm_fork_syscall()  when a user stack pointer is saved, rebuilding the child
                      from xcp.sregs so that it returns from the very same SVC
                      as the parent, in the same mode, on its own stack and
                      with no inherited system call nesting;
  arm_fork_direct()   otherwise -- the flat build, a kernel thread in any
                      build, and a build without a kernel stack, where the
                      call is dispatched on the caller's own stack so the
                      caller's frames are copied along with the kernel-side
                      ones.

Note that the discriminator is xcp.ustkptr rather than TCB_FLAG_SYSCALL.  On
armv7-a the caller is the task that runs the kernel side of its own system
call, so being in a system call is not by itself a reason to distrust the
snapshot; the switch to the kernel stack is.  Because arm_syscall() has
already re-pointed the frame by the time arm_fork() runs, the caller's PC,
CPSR and SP come from where arm_syscall() put them -- syscall[0].sysreturn,
syscall[0].cpsr and ustkptr -- and the rest from the frame itself.

Nothing selects the primitives on an ARM kernel build yet, so this commit
changes no configuration; it is what the next one needs to be correct.

Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-10 08:57:30 -03:00
Marco Casaroli
70c2ef5911 !sched/arch/libc: Give fork() and vfork() their real, separate semantics.
NuttX implemented fork() and vfork() as the same function.  Both were libc
wrappers around a single up_fork() syscall; vfork() differed only by a
trailing waitpid().  Underneath, the child joined the parent's address
environment -- the same addrenv_join() that pthread_create() uses -- and got
a private copy of the stack.  So the child shared .data, .bss and the heap
with its parent and ran concurrently with it.

That is not fork().  It is vfork()-with-a-private-stack under fork()'s name,
and the history says so: today's fork() is NuttX's old vfork(), renamed in
c33d1c9c97 (2023) without any change of behaviour.  The failure was silent --
a program written against POSIX fork() compiled, ran, and had its child's
writes land in the parent's variables.

Separate them into two primitives, chosen by which function the caller
called rather than by what the hardware happens to be:

  fork()   child gets its own copy of the parent's memory at the same
           virtual addresses; runs concurrently.  Only where an address
           environment can be duplicated -- elsewhere it is not declared at
           all, so calling it is a build error naming the function.
  vfork()  child shares the parent's memory; parent suspended until the
           child _exit()s or exec()s.  Implementable everywhere.

Below libc there is still one syscall.  up_fork() gains a bool saying which
primitive the caller used, since the per-architecture register snapshot is
the same for both, and passes it to nxtask_setup_fork(), which is the single
place the memory semantics are decided.  The argument arrives in the first
argument register and is never touched:  each architecture's snapshot takes
some other call-clobbered register for its scratch, so the flag is simply
still there when the C worker is called.

The vfork() parent suspension moves out of libc into nxtask_start_fork(),
released from nxsched_release_tcb() by nxtask_resume_vfork().  Two things
follow: the parent is resumed at exec(), since exec_swap() has already handed
the child's pid to the loaded program by the time the vfork stub exits, and
vfork() no longer depends on CONFIG_SCHED_WAITPID.

Releasing there requires one fix in nxtask_exit().  It raises rtcb->lockcount
directly rather than through sched_lock() while it tears the TCB down, so the
nxsem_post() that wakes the vfork() parent leaves it queued where a blocked
task collects while pre-emption is off -- g_pendingtasks, or g_readytorun on
SMP -- and the matching raw lockcount-- does not publish it the way
sched_unlock() would, leaving the parent stranded with nothing to move it on.
The fix mirrors sched_unlock() for each case:  nxsched_merge_pending(), or
nxsched_deliver_task() under CONFIG_SMP.  Both are no-ops while pre-emption is
still disabled, and up_exit() re-reads this_task() afterwards, so a change of
the ready-to-run head is honoured.  Without it vfork() deadlocks wherever no
other task happens to call sched_unlock() afterwards -- rv-virt:nsh64 and
rv-virt:pnsh64, where NSH is blocked in waitpid() holding the lock, and
qemu-armv8a:citest_smp, which hangs the moment the vfork() test runs.

fork() is built on a new addrenv_fork(), backed by an up_addrenv_fork() hook
that duplicates an address environment into freshly allocated pages mapped at
the same virtual addresses -- unlike up_addrenv_clone(), which copies only
the representation and leaves both pointing at the same page tables.  The
child then adopts the parent's stack geometry rather than being given a
relocated copy: a pointer to a stack local taken before fork() must name the
same object in the child that it named in the parent, and the parent's stack
is already in the duplicate, with its contents, at the parent's address.

No architecture implements up_addrenv_fork() yet, so this commit leaves
fork() unavailable everywhere.  That is the intended state.  It withdraws
fork() from ARCH_ARM, flat ARCH_ARM64, ARCH_RISCV, ARCH_SIM and ARCH_X86_64,
where until now it named the sharing primitive; per-architecture patches
restore it, with POSIX semantics, as up_addrenv_fork() lands.  In the
meantime the sharing primitive is still there under the name that describes
it: vfork() for a child that runs a program, pthread_create() for a second
flow of control that shares memory, posix_spawn() for both at once.

Kconfig: ARCH_HAVE_VFORK inherits ARCH_HAVE_FORK's select lines, conditions
included, so no configuration gains machinery; ARCH_HAVE_FORK is redefined to
mean "can provide POSIX fork() semantics" and now depends on ARCH_ADDRENV.

There is one deliberate departure from "verbatim".  ARCH_ARM selected the
fork family unconditionally, BUILD_KERNEL included, and that has never
worked:  on a kernel build the architecture's fork entry point sees the
kernel's return address and stack pointer rather than the caller's, so the
child resumes at a kernel address.  On qemu-armv7a:knsh master faults in
ostest's fork case with "Child did not run" and then a data abort; without
the condition this change faults the same way through vfork().  ARCH_ARM64
and ARCH_X86_64 already carried "if !BUILD_KERNEL" for exactly this reason --
ARM was the outlier.  Conditioning it turns a runtime fault into an honest
absence, which is the whole point of the change; arch/arm takes the condition
off again in the patch that adds its saved-syscall-frame path.  Only the
MMU-capable ARM ports are affected, since Cortex-M cannot build BUILD_KERNEL
at all.

Also fixes two latent syntax errors found on the way: a missing comma in
riscv_fork.c and mips_fork.c, both in *_FRAMEPOINTER && !SAVE_GP branches
that are never compiled today.

BREAKING CHANGE: fork() is withdrawn from every architecture.  It is no
longer declared in unistd.h, so code that calls it fails to build with an error
naming the function, and the sharing behaviour it used to have is gone rather
than renamed.  CONFIG_ARCH_HAVE_FORK no longer means "fork() exists"; it means
"this configuration can provide POSIX fork() semantics", and no architecture
selects it yet.

Quick fix, chosen by why the call was made:

  to run a program                vfork() + exec*(), or better posix_spawn()
  a second flow of control that   pthread_create()
  shares the caller's memory
  a genuinely independent copy    keep fork(), and wait for the per-arch patch
  of the process                  that implements up_addrenv_fork() and selects
                                  CONFIG_ARCH_HAVE_FORK

Out-of-tree code that tests CONFIG_ARCH_HAVE_FORK to decide whether a
fork-then-exec path is available wants CONFIG_ARCH_HAVE_VFORK instead, which is
selected in exactly the places CONFIG_ARCH_HAVE_FORK used to be.  The full
migration guide is Documentation/guides/fork_vfork_migration.rst.

Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-10 08:57:30 -03:00
Alan Carvalho de Assis
87260499e1 cmake: Use NUTTX(_DIR/_BIN_DIR) instead CMAKE(_SRC_DIR/_BIN_DIR)
Some checks are pending
MemBrowse Memory Report / changes-filter (push) Waiting to run
MemBrowse Memory Report / load-targets (push) Waiting to run
MemBrowse Memory Report / identical (push) Blocked by required conditions
MemBrowse Memory Report / analyze (push) Blocked by required conditions
This change fixes NuttX’s CMake support when NuttX is embedded
in another project via add_subdirectory(). CMake’s CMAKE_SOURCE_DIR
and CMAKE_BINARY_DIR refer to the outermost project, causing NuttX
to access its .config, generated files, host tools, and build artifacts
in the parent project’s directories. The fix introduces NUTTX_DIR and
NUTTX_BINARY_DIR, based on CMAKE_CURRENT_SOURCE_DIR and
CMAKE_CURRENT_BINARY_DIR, and consistently uses them for NuttX
self-references while preserving existing standalone builds. It fixes
the Kconfig initialization failure reported in #19697 and allows an
embedded sim:nsh build to configure, build, and boot successfully.
The change affects only the CMake build system (not Make or Kconfig
defaults), requires the corresponding nuttx-apps change, and does not
extend add_subdirectory() support to cross-compiled non-sim boards due
to CMake’s toolchain-file limitation.

Fixes #19697.

Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Alan Carvalho de Assis <acassis@gmail.com>
2026-08-09 11:13:08 -03:00
raiden00pl
0b3848ef6b arch/nrf52: add SAADC continuous sampling mode
Add CONFIG_NRF52_SAADC_CONTINUOUS for gapless timer-triggered sampling
with double-buffered EasyDMA. The SAADC is auto-restarted directly from
the END event through a PPI channel (no CPU in the loop) and each
completed buffer is delivered to the ADC upper half via the batch
interface. Enables high-rate single-channel streaming.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-08 14:56:52 -03:00
raiden00pl
24a50121f2 arch/nrf53: add HFCLK XTAL oscillator support
add HFCLK XTAL oscillator support

Signed-off-by: raiden00pl <raiden00@railab.me>
2026-08-08 14:43:09 -03:00
raiden00pl
903f393546 arch/nrf53: add DCDC regulator support
add DCDC regulator support

Signed-off-by: raiden00pl <raiden00@railab.me>
2026-08-08 14:42:32 -03:00
raiden00pl
f1565aa5a0 arch/nrf53/nrf53_i2c.c: fix I2C3 base
Some checks are pending
Build Documentation / build-html (push) Waiting to run
MemBrowse Memory Report / changes-filter (push) Waiting to run
MemBrowse Memory Report / load-targets (push) Waiting to run
MemBrowse Memory Report / identical (push) Blocked by required conditions
MemBrowse Memory Report / analyze (push) Blocked by required conditions
fix I2C3 base

Signed-off-by: raiden00pl <raiden00@railab.me>
2026-08-08 13:26:18 +02:00
raiden00pl
b0182d3c0e arch/nrf5x: fix USBD data OUT packet loss when no read request is queued
A packet received while the request queue was empty was silently dropped
and the transfer deadlocked. Hold it in the endpoint buffer until the
class driver submits a read request.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-07 18:50:36 +08:00
raiden00pl
5eeb0ae939 arch/nrf5x: fix USBD data IN back-to-back packet loss
A data IN endpoint has a single hardware buffer, but the driver armed
the next packet before the host had read the previous one, silently
overwriting it and dropping data under sustained bulk IN traffic. Track
an armed-packet-in-flight state per endpoint (epinflight) and defer
re-arming until the host read completes (EPDATASTATUS), sending the next
packet from nrf52_epdatainterrupt(). Also release the DMA lock right
after the busy-wait for ENDEPIN on data endpoints so other endpoints do
not stall on an interrupt round-trip.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-07 18:50:36 +08:00
Jorge Guzman
790a197ed0 arch/arm/stm32l0: declare SYSCFG so the EXTI port mapping is written
STM32_STM32L0 does not select STM32_HAVE_SYSCFG, so STM32_SYSCFG does not
exist for this family and the clock of the peripheral is never enabled.  The
mapping of a pin to an EXTI line lives in SYSCFG_EXTICR, so every write to it
was dropped and a GPIO interrupt on any port other than port A never fired.

STM32_SYSCFG is default y, so no configuration changes.

Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
2026-08-06 13:01:39 -03:00
raiden00pl
461e3fd362 arch/nrf52/nrf53/nrf91: allow zero-length I2C transfers
Some checks are pending
Build Documentation / build-html (push) Waiting to run
MemBrowse Memory Report / changes-filter (push) Waiting to run
MemBrowse Memory Report / load-targets (push) Waiting to run
MemBrowse Memory Report / identical (push) Blocked by required conditions
MemBrowse Memory Report / analyze (push) Blocked by required conditions
Allow zero-length I2C transfers when DEBUGASSERT is enabled.

Zero-length transfers (used for I2C bus scanning) never access the
transfer buffer, so any EasyDMA pointer is valid.

Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
2026-08-06 20:33:59 +08:00
Jacob Dahl
659f47a824 arch/arm/stm32h7/i2c: use per-instance RCC registers for clock and reset
stm32_i2c_init() and stm32_i2c_deinit() hardcoded APB1LENR/APB1LRSTR
while taking the enable and reset bits from the per-instance config.
That is correct for I2C1-3, but I2C4 is on APB4: its clk_bit and
reset_bit are RCC_APB4ENR_I2C4EN and RCC_APB4RSTR_I2C4RST, both bit 7,
and bit 7 of APB1LENR/APB1LRSTR is TIM13.

So for I2C4 the driver enabled and pulsed the reset of TIM13 instead,
and never reset the I2C4 peripheral at all.  I2C4 still works because
rcc_enableapb4() enables I2C4EN at boot, but the peripheral reset that
stm32_i2c_reset() (CONFIG_I2C_RESET) relies on to clear a wedged I2C
state machine never happens, and deinit gates TIM13 while leaving the
I2C4 clock running.

Store the clock enable and reset register addresses in
struct stm32_i2c_config_s next to the bits, and use them in
stm32_i2c_init() and stm32_i2c_deinit().

Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
2026-08-06 08:49:20 -03:00
Joao Mario Lago
bfad05b9fa arch/arm/stm32h5/serial: fix UART8 buffer guard typo
Some checks are pending
Build Documentation / build-html (push) Waiting to run
MemBrowse Memory Report / changes-filter (push) Waiting to run
MemBrowse Memory Report / load-targets (push) Waiting to run
MemBrowse Memory Report / identical (push) Blocked by required conditions
MemBrowse Memory Report / analyze (push) Blocked by required conditions
Use CONFIG_STM32_UART8_SERIALDRIVER so g_uart8rxbuffer and
g_uart8txbuffer are compiled when UART8 is enabled.

Signed-off-by: Joao Mario Lago <joao.mario.lago@hotmail.com>
2026-08-05 17:43:14 -03:00
Marco Casaroli
abbe0df26d !arch/arm: Use r9 as the PIC base register.
ARM PIC has used r10 as the base register, but the tree has never been
consistent about it.  Toolchain.defs gives CONFIG_BUILD_PIC
-mpic-register=r9 and CONFIG_PIC -mpic-register=r10, twenty-five lines
apart, and arm_initialstate.c sets REG_R9 from inline assembly under one
and REG_PIC under the other, with a comment reading "Set the PIC base
register (probably R10)".  This settles it on r9 for all of PIC: NXFLAT,
ELF PIC and CONFIG_BUILD_PIC alike.

r9 is the right choice rather than an arbitrary one.  It is the AAPCS
platform register, the "static base", and it is what GCC itself picks
for -msingle-pic-base on an EABI target; r10 is the non-EABI default.

It also removes a combination that cannot build today.  Stack checking
adds -ffixed-r10 in armv7-m/Toolchain.defs and armv8-m/Toolchain.defs,
while CONFIG_PIC adds -mpic-register=r10, and GCC rejects the pair with
"unable to use 'r10' for PIC register".  The comment above REG_PIC has
always said the register "can be R9 if stack checking is enabled", but
the definition was unconditionally REG_R10, so it would have named the
wrong register even had the build succeeded.

The thunk generator moves with the firmware.  NXFLAT import stubs had
the register baked in as "add ip,ip,sl", so a module built for r9 would
load and then branch to a wild address on its first call out.  The stubs
now come from NXFLAT_PIC_REG in the in-tree tool, which is built only
when CONFIG_NXFLAT is set, following the
CONFIG_BOARD_ETC_ROMFS_PASSWD_ENABLE precedent in tools/Unix.mk.

That leaves modules built before this change, and they are the reason
for the ABI marker.  The NXFLAT header cannot carry a version: h_magic
is written by ldnxflat, which is GPL, derived from elf2flt, and stays
out of this repository, so it can never be changed in step with the
loader.  The import table can, because both of its ends are in-tree --
mknxflat emits it and nxflat_bindimports() reads it -- and ldnxflat
passes it through untouched.  So every module now imports
__nxflat_abi_v2, the base firmware defines it, and a module that does
not import it is refused.

Making the marker a real exported symbol rather than a name the loader
special-cases is what keeps it out of the build system's way: a board's
symbol table picks it up exactly as it picks up printf, so mksymtab.sh
and its equivalents need no change.  It also gives the reverse direction
a diagnosis for free -- a module built against a newer ABI than its
firmware fails with "Exported symbol __nxflat_abi_v2 not found".

Most of the remaining churn is boards restating a default.  ARCHPICFLAGS
is a "?=" default so that a board only speaks up when it differs, and
twenty-six were assigning the value the default already had.  MKNXFLAT
gets the same treatment: thirteen boards named the same tool, and the
only thing that varies is ARM versus Thumb-2, which falls out of
CONFIG_ARM_THUMB.  LDNXFLAT gains a default too -- it stays an
out-of-tree PATH lookup, but naming it centrally fixes boards that never
assigned it, where it expanded to nothing and handed make a recipe
beginning "-e", whose leading dash make ate as "ignore errors".

The non-ARM boards carrying -mpic-register=r10 lose it: it is an
ARM-only option, reachable only through CPICFLAGS, which is only used to
build NXFLAT modules, and no non-ARM board enables NXFLAT.

Boards keep nothing about PIC flags any more.  ARCHPICFLAGS was set by
sixty-three of them and only ever fed CPICFLAGS, which is only used to
build NXFLAT modules; no board outside arch/arm enables NXFLAT, so every
non-ARM copy was setting a variable nothing read.  Those are removed
rather than moved somewhere more central, which would only make dead
text look load-bearing.  LDNXFLAT goes the same way as MKNXFLAT, for the
same reason: thirteen boards named the same tool that Toolchain.defs now
names once.

One of them was not merely redundant.  am67/t3-gem-o1 asked for
"-mpic-register=r10 -ffixed-r10", which GCC refuses outright with
"unable to use 'r10' for PIC register" -- the very combination the
filter-out machinery in Toolchain.defs exists to prevent.  It has
survived because that board does not build NXFLAT modules, so the flags
are never handed to a compiler.  Renaming the register would have
carried the fault forward unchanged, so the line goes.

Tested on lm3s6965-ek:qemu-nxflat under QEMU, configured and built with
no overrides.  The nxflat example runs the errno, hello and struct
modules with output identical to the same config built from master.
Built with the old out-of-tree thunk generator instead, the same
firmware refuses all three with ENOEXEC rather than locking up in a
HardFault, which is what this change is for.  mps3-an547:picostest,
which is CONFIG_PIC without CONFIG_NXFLAT, builds clean and does not
build the thunk generator.

The .def files pick up two cosmetic changes here alongside the register:
a "Dyanamic" typo that codespell rejects, and a reworded comment in each
thunk_*.c.  Neither appears in the emitted thunk -- both are in C
comments -- so the generated text is still what the upstream tool
produces, modulo the register itself.

BREAKING CHANGE: ARM PIC moves from r10 to r9.  An NXFLAT module built
before this change has r10 baked into its import stubs and will not run
against a firmware carrying it; the two cannot be mixed.  The module is
refused with ENOEXEC rather than branching to a wild address, by way of the
__nxflat_abi_v2 marker described below.

Quick fix: rebuild the module against this tree.  Its source needs no
change.  A board that reserved r10 by hand, or that assigned ARCHPICFLAGS
or MKNXFLAT to restate a default, should drop those assignments; nothing
else is affected, and CONFIG_PIC without CONFIG_NXFLAT needs no action.

Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-06 01:38:23 +08:00
Joao Mario Lago
df8538608e arch/arm/stm32: allow UART7/8 serial driver on H5
Include STM32_HAVE_USART_H5 in the UART7/UART8 driver choice
depends so CONFIG_STM32_UART*_SERIALDRIVER can be selected on
STM32H5.

Signed-off-by: Joao Mario Lago <joao.mario.lago@hotmail.com>
2026-08-06 01:38:00 +08:00
Jiri Vlasak
3b8f9bc698 kinetis/rtc: Enable global lock for all
Some checks failed
MemBrowse Memory Report / changes-filter (push) Waiting to run
MemBrowse Memory Report / load-targets (push) Waiting to run
MemBrowse Memory Report / identical (push) Blocked by required conditions
MemBrowse Memory Report / analyze (push) Blocked by required conditions
Docker-Linux / push (push) Has been cancelled
g_rtc_lock is used by the up_rtc_settime, a base RTC function.
Therefore, it should be available even for this procedure, not just when
CONFIG_RTC_HIRES.

Signed-off-by: Jiri Vlasak <jvlasak@elektroline.cz>
2026-08-05 21:55:48 +08:00
Takashi Furuya
b3a280e3b0 s32k3xx/flexcan: Initialize union and allow BRS control
- Zero initialize union in s32k3xx_transmit()
- Allow setting BRS from frame flags

Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-04 22:47:08 +08:00
Takashi Furuya
94f4b9e92f s32k1xx/flexcan: Initialize union and allow BRS control
- Zero initialize union in s32k1xx_transmit()
- Allow setting BRS from frame flags

Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-04 22:47:08 +08:00
Takashi Furuya
c4010cb205 kinetis/flexcan: Initialize union and allow BRS control
- Zero initialize union in kinetis_transmit()
- Allow setting BRS from frame flags

Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-04 22:47:08 +08:00
Takashi Furuya
a117a55b44 imx9/flexcan: Initialize union and allow BRS control
- Zero initialize union in imx9_transmit()
- Allow setting BRS from frame flags

Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-04 22:47:08 +08:00
Takashi Furuya
5f8a3ea68d imxrt/flexcan: Initialize union and allow BRS control
- Zero initialize union in imxrt_transmit()
- Allow setting BRS from

Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
2026-08-04 22:47:08 +08:00