Adds lowerhalf MIPI DSI driver for RISC-V Espressif devices,
including KConfig options for LDO and MIPI_DSI.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
The task and pthread entry points were entered with the stack pointer
left by the kernel side of the startup path, not aligned to the 16
bytes the ABI requires: applications calling a variadic function with
floating point arguments crashed with a general protection exception
on the first SSE store of the argument save area. Align the stack
pointer when returning to user space, where the value is known.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The disconnect handler only reconnects when the reported reason is
WIFI_REASON_ASSOC_LEAVE, so an AP-initiated deauth (beacon timeout, auth or
assoc expire) leaves the station down forever. Restore the intent flag the
driver used before 1f7c3a32e5 and 20ff68bd65, matching the ESP-IDF rule of
reconnecting unless the disconnection was requested locally.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
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
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
The HAL's wpa_supplicant defines aes_encrypt()/aes_decrypt(), which collide
at link time with the same symbols from crypto/aes.c whenever a Wi-Fi
configuration also enables CRYPTO_CRYPTODEV_SOFTWARE_CRYPTO. Bump the HAL to
the revision that prefixes them on NuttX (espressif/esp-hal-3rdparty#13).
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Initialize i2c_ll_hw_cmd_t in sendstart/startrecv so ack_exp/done are
not left with stack garbage that can NACK or skip the address byte.
Program i2c_hal_set_bus_timing() with the requested bus_freq instead of
the board default so msg frequency is applied.
Affects only Espressif devices.
Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
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>
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
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>
The CMake build referenced arm64_physpgaddr.c and arm64_virtpgaddr.c,
which no longer exist (consolidated into arm64_pgalloc.c, already
listed).
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The CMake build had no STARTUP_OBJS (crt0) target and no elf.cmake, so
applications were linked without crt0 and without '-e _start': the ELF
entry defaulted to main and applications crashed on exit returning to
a NULL address.
Add STARTUP_OBJS and elf.cmake with the LDELFFLAGS equivalents from
Toolchain.defs, following the other architectures.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
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>
CMAKE_LD was never set, so application link commands were invalid, and
CMAKE_STRIP defaulted to plain 'strip', which removes the symbol and
relocation tables required to load CONFIG_BINFMT_ELF_RELOCATABLE
binaries. Use the host linker and 'strip --strip-unneeded' as on the
other architectures.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
arch_interface exists only for CONFIG_BUILD_PROTECTED, but x86_64 and
arm64 referenced it for any non-flat build, breaking CMake
configuration of kernel builds. Use the CONFIG_BUILD_PROTECTED guard
as arm and risc-v do.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
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>
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>
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>
Several risc-v assembly labels are .global but untyped, so mkallsyms.py
(which only collects STT_FUNC symbols) silently drops them from the
ALLSYMS table, and backtraces/%pS print raw addresses instead of names.
Add .type <name>, function to the affected labels, matching existing
convention elsewhere in the tree.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Assisted-by: Claude Code:claude-sonnet-5
Two level errors corrupted kernel memory when a user process extended
its heap with sbrk:
- PGT_LAST was X86_MMU_PT_LEVELS (4), but valid levels are 0-3, so the
final level entry was written with an out-of-range index.
- x86_64_get_pgtable indexed the PD (level 2) with level 3, installing
newly allocated page tables into the wrong PD slot.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Adds LDO support for RISC-V Espressif devices. In general, should
only affect ESP32-P4 on a few boards.
ESP32-P4 has 4 channels of low-dropout voltage regulators, which
are programmable. Can be used to power external devices.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
- 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>
- 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>
- 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>
- 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>
USDHC_PROCTL selects whether the usdhc uses SDMA or ADMA. This driver
only uses the SDMA or no DMA at all, so select that option. There might be a
wrong register value left by ROM code or an earlier bootloader which uses
ADMA.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
chromakey is a uint32_t, so printing it with %d warns. The line is only
compiled when CONFIG_STM32_FB_CMAP is enabled, which is why it has gone
unnoticed.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
On K3 SoCs the A53 cluster does not own device power, clocks, resets or
interrupt routing; these are managed by the DM/TIFS firmware and requested
over TISCI through the secure-proxy mailbox. Add:
- a TISCI client (secure-proxy transport plus device/clock/reset helpers)
- a GPIO driver for banks 0/1 with pad mux and TISCI power-on
- an OMAP-I2C driver for the main-domain I2C controllers
and wire them into the PocketBeagle2 and BeaglePlay bring-up.
Tested on PocketBeagle2 (SYSFW 11.2.5) with the TechLab cape attached:
nsh> i2c bus
nsh> i2c dev -b 0 0x03 0x77 # I2C0 detects onboard 0x20 and 0x50
nsh> gpio -o 1 /dev/gpio3 # drives a user LED; read back with:
nsh> gpio /dev/gpio3
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
The X11 keyboard reported any keysym that its translation table did not
know as an ordinary key press carrying the raw keysym. An application
looking for a byte of text got 65307 for Escape and 65289 for Tab, and
the modifiers arrived as 65505 and friends.
That is not a character, so it cannot be a KEYBOARD_PRESS. NXDoom on
the simulator has therefore had no menu, no map and no fire, which is
most of the game.
Escape and Tab are control characters and are reported as such. The
eight modifiers get the keycodes that the codec now has for them. And a
keysym above the Latin-1 range that no table knows is not reported at
all, which closes the case rather than the three instances of it.
Verified by dumping the events while typing: Escape arrives as 27, Tab
as 9, the modifiers as keycodes 88 to 95, and the game plays.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Wire the shared Ameba GPIO driver into the RTL8721F (amebagreen2) build and
add the EVB board glue:
- arch/arm/src/rtl8721f: build ameba_gpio.c (CMake/Make.defs), source the
common Ameba Kconfig, and add ameba_gpio_chip.h describing the chip's
three GPIO ports (A/B/C), their IRQs and the APBPeriph clock bit.
- arch/arm/src/common/ameba: teach the driver that amebagreen2's ROM
GPIO_Init does not call PAD_PullCtrl or GPIO_INTMode, so call both
explicitly after GPIO_Init; on RTL8721Dx (ram_common) these are harmless
redundant writes. Add the AMEBA_PORT_C / AMEBA_PC() helpers.
- boards/arm/rtl8721f/rtl8721f_evb: register output/input/interrupt demo
pins, add the bringup hook, and provide a minimal 'gpio' NSH defconfig.
- Documentation: add a GPIO section for the RTL8721F EVB and fix a
rising/falling typo in the PKE8721DAF page.
Hardware-verified on the RTL8721F EVB: output, input, and all interrupt
trigger/polarity combinations (rising/falling edge, level high/low).
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
The shared port ISR clears interrupt status with GPIO_INTStatusClearEdge(),
which only clears edge latches. For a level-triggered pin the status stays
asserted as long as the level is active, so the ISR re-enters forever once
the level fires -- the system hangs before the application can even service
the event.
Remember at configure time whether a pin is level-triggered, and in the ISR
mask such a pin (GPIO_INTConfig DISABLE) before invoking the callback. The
application re-enables it via go_enable() after servicing. Edge pins are
left unmasked, so their behaviour is unchanged.
This fixes a hang reproducible on RTL8721Dx and RTL8721F when a
level-high/level-low interrupt pin is used.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
The fix was ported from the STM32G0 to all the STM32 platforms,
as the code is mostly the same hence presents the same failure
Signed-off-by: Javier Alonso <javieralonso@geotab.com>
When the interrupts get disabled, the callback(s) are still attached.
That structure is never cleared, causing several calls to attach/detach
to eventually fail as the callback queue gets full.
When the error occurs, the registration fails with error 12 (ENOMEM).
By detaching the IRQ and clearing the callbacks, this error doesn't
happen again
Signed-off-by: Javier Alonso <javieralonso@geotab.com>
Bring up the last two RTL8721F feature blocks and wire them into the
nsh board configuration:
- littlefs on the on-chip flash MTD region (P2).
- WHC/INIC WiFi with the on-chip IPC control plane, NuttX net stack,
DHCP client and the wapi command tool (P3).
Two porting fixes were required for the WiFi control plane:
- ameba_ipc.c: the AP IPC device base (IPCAP_DEV) was carried over
verbatim from the RTL8720F template (0x40804000). On this SoC IPC0
lives at 0x40815000; using the wrong base makes ipc_table_init()
program the RX-full mask in the wrong register block, so the NP->AP
interrupt never fires and WiFi bring-up hangs waiting for the device
to answer. Point IPCAP_DEV at the correct 0x40815000 base.
- ameba_board.mk: the EVB silicon is B-cut, so link against the
ameba_rom_symbol_bcut*.ld ROM symbol tables (the A-cut tables resolve
the WiFi ROM helpers to the wrong addresses and fault at run time).
Validated on hardware: NSH comes up, wapi scan lists real APs, a WPA2
connect succeeds, the DHCP client obtains a lease and ICMP to the
public internet round-trips.
The board defconfig keeps SSID/passphrase as placeholders; real
credentials are supplied at run time via the wapi commands.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Wire the RTL8721F km4tz core up to a working NuttShell:
- irq.h: renumber the KM4TZ external vector table to the RTL8721F
APIRQn map (UART_LOG=24, IPC=5, +GPIOB/C, TIMER7/8, ...).
- ameba_loguart.c: fix the LOG-UART base to 0x40810000. The former
0x401C6000 belongs to a different Ameba part; the wrong base bus-
faulted on the RX interrupt-enable write while TX still worked
(LOGUART_PutChar uses its own ROM-internal base).
- ameba_app_start.c: adjust the MPU read-only / RAM regions for the
RTL8721F memory map and seed the RTC on first power-on so the
SDM32K-clocked SYSTIMER comes up (mirrors the SDK app_rtc_init).
- ameba_ipc.c: move the km4tz<->km4ns IPC to APIRQn 5 (IPC_CPU0).
- ameba_board.mk: pull in fwlib ameba_rtc.c for the RTC_* symbols.
- defconfig: RTL8721F RAM map, enable TIMER/TIMER_ARCH/ARMV8M_SYSTICK
for a live system tick, and drop the WiFi/NET stack for now.
- scripts/Make.defs: use the RTL8721F_NOR flash profile.
Boots cleanly to nsh> on hardware; tick, RX and builtin apps verified.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Add a P0 skeleton port for the Realtek RTL8721F (SDK codename Green2 /
amebagreen2). Structurally the RTL8721F is a twin of the RTL8720F -- the
AP/host core is km4tz (ARMv8-M.main, TrustZone secure) and the WiFi MAC/PHY
runs on the km4ns network-processor core -- so this port is modelled on the
RTL8720F one and shares the IC-agnostic ameba glue in
arch/arm/src/common/ameba.
This is the "configures and links" skeleton (rtl8721f_evb:nsh builds an
image end to end). Four differences from the RTL8720F template were needed
to make the empty shell link against amebagreen2:
* km4tz has no FPU (cmsis_cpu.h defines __FPU_PRESENT 0), so the chip does
not select ARCH_HAVE_FPU and the image is built soft-float.
* ameba_app_start.c matches amebagreen2's ram_km4tz silicon init: the
nocache MPU map, the non-secure ROM BSS clear, OSC4M (not OSC2M)
calibration gated on EFUSE cut >= B and CHIP_TYPE_ASIC_POSTSIM.
* amebagreen2 ships no lib_rom.a, so the ROM archive whole-archive link is
dropped; the WiFi/OS/non-secure ROM symbols come from the SDK
ameba_rom_symbol_acut{,_wifi,_os}.ld maps appended to the image2 linker
script, exactly as green2's own image2 link does.
* the AP WiFi security lib is lib_wifi_common.a (was lib_wifi_com_sec.a).
The per-chip IRQ vector table (irq.h) and the RAM_START/RAM_SIZE layout
still carry RTL8720F values and are refined in the follow-up bring-up work.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
As analyzed, the NuttX initial keyboard API design uses event
type KBD_SPECPRESS/KBD_SPECREL to deliver special keys
and KBD_PRESS/KBD_RELEASE to deliver ASCII codes.
But it seems that this design choice has not been followed
in virtio-input, goldfish_events and sim_keyboard designs
and result is that external keyboard special keys events
are mapped to KEYCODE_xxx values which start from 0 and
overlaps with ASCII keys.
The issue is tracked under #19527 number.
This set of changes correct events reporting for mentioned
keyboards to report right event type for special keys.
The solution is only partial at this phase.
Virtual and more complex keyboards usually deliver
key pressures as scancodes (key position on keyboard)
and mapping to ASCII for keys which corresponds to letter
and other similar keys lacks mapping of national alphabets,
second row symbols and switch to capital letter according
to modifiers.
Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>
rp2040_update_buffer_control()/rp23xx_update_buffer_control() re-arm an
endpoint buffer by setting the AVAILABLE bit in the buffer-control word,
which lives in DPSRAM. When a buffer is re-armed from the completion
path (rp2040_usbintr_buffstat/rp23xx_usbintr_buffstat), that runs after
the handler has cleared the endpoint's bit in BUFF_STATUS, which lives in
the USB controller register block -- a different peripheral region.
The bus fabric may reorder those two stores. If the controller observes
the AVAILABLE re-arm before the BUFF_STATUS clear lands, it can transmit
the next IN packet and latch its completion in BUFF_STATUS before the
clear arrives; the late clear then wipes that just-set completion bit.
The lost completion edge stops all further buffer interrupts for the
endpoint, so the class driver's write-complete callback never runs and
TX wedges permanently.
This is most visible on RP2350 (Cortex-M33) under dense/bursty IN traffic
such as CDC-NCM with TCP write buffers. Add a UP_DMB() at the top of the
AVAILABLE re-arm so the preceding BUFF_STATUS clear is ordered ahead of
it. (Non-SMP builds reduce spin_lock_irqsave to a barrier-free
up_irq_save, so nothing else orders these two stores.)
Assisted-by: Claude (Anthropic Claude Code)
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
During the Toybox port to NuttX, Claude noticed that changes in the
menuconfig weren't taking affect. This issue exists for a long time on
NuttX, in fact BayLibre's presentation from 2017 make jokes about our
building system not been reliable:
https://www.youtube.com/watch?v=XUJK2htXxKw&t=320s
Stale archive members from $(AR)'s additive-only behavior can linger
after Kconfig toggles change which files provide a symbol, causing dead
weight or "multiple definition" link errors on incremental builds.
Fixed by splitting ARCHIVE into two macros: ARCHIVE keeps the original
additive behavior for apps/libapps.a, which many independent
subdirectories contribute to across a build, while the new
ARCHIVE_REBUILD deletes then archives for the far more common case
of a single Makefile building its own self-contained $(OBJS)
- all 39 such call sites now use it.
Assisted-By: Claude Sonnet 5
Signed-off-by: Alan C. Assis <acassis@gmail.com>
In a protected build arm_svcall.c treats the caller's CONTROL as part of
the saved system call state: it stores it in xcp.syscall[].ctrlreturn on
entry and restores it from there on SYS_syscall_return. All three
Cortex-M profiles do this -- armv6-m, armv7-m and armv8-m each define the
field in arch/arm/include/<arch>/irq.h and use it symmetrically.
arm_fork_direct() copied sysreturn and excreturn to the child but not
ctrlreturn. The child's TCB comes from kmm_zalloc(), so the field was
zero, and CONTROL == 0 is nPRIV clear: the child returned to user space
privileged while its parent returned unprivileged. The child ran out its
life with the MPU restrictions its parent is under silently lifted, which
is the isolation BUILD_PROTECTED exists to provide.
Nothing faults, and that is why this survived. CONTROL == 0 also selects
MSP, which sounds like it should crash immediately, but NuttX already
runs Cortex-M threads on MSP -- the parent's saved value is 0x1, nPRIV
set and SPSEL clear -- so the two differ only in the privilege bit and
there is no stack change to trip over. Privileged code then passes every
test unprivileged code passes, so ostest cannot see it either.
Measured on an RP2350 (Cortex-M33) in BUILD_PROTECTED, breaking at the
nxtask_start_fork() call in arm_fork_direct() during task_fork_test:
parent ctrlreturn 0x00000001, child ctrlreturn 0x00000000. With this
change both read 0x00000001.
BUILD_FLAT is unaffected: without CONFIG_LIB_SYSCALL, nsyscalls is 0 and
the whole block is skipped. armv7-a and armv7-r are unaffected too; they
carry cpsr instead, and that is already copied.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Two device-controller defects that break standard host error recovery,
found while root-causing why macOS never mounts a NuttX mass-storage
function (full analysis and host traces in apache/nuttx#19435):
1. epsubmit() aborted (-EBUSY) any IN request submitted while the
endpoint was halted. The mass storage class halts bulk-IN for a
failed device-to-host command (BOT-legal) and then submits the CSW;
the CSW was dropped on the floor, so after the host's Clear-Halt the
endpoint NAKed forever and the host timed out (macOS: 30 s, then a
Bulk-Only-reset/device-reset spiral until it disables the port).
This is exactly the race documented for years in the usbmsc_scsi.c
header (David Hewson's analysis); the USBMSC_STALL_RACEWAR sleep
workaround only survives hosts that clear the halt within 100 ms --
Linux does, macOS does not, which is why Linux testing never saw it.
Implement the stall-queueing contract instead: requests submitted
while an endpoint is halted are queued without arming the hardware
(arming rewrites the buffer control word and would silently clear
the STALL bit); a halt terminates any in-flight IN transfer (its
hardware buffer is disarmed by the STALL write and would never
complete); clearing the halt resets the data toggle and re-arms the
head of the queue; stale buffer completions latched for transfers
aborted by a halt are ignored. RP2040/RP23XX now select
ARCH_USBDEV_STALLQUEUE, which also retires the RACEWAR's two 100 ms
sleeps per failed command.
2. The USB_REQ_GETSTATUS handler in ep0setup() validated the request
but never queued the two-byte response, for all three recipients
(device/interface/endpoint), so EP0 NAKed the host's data stage
forever and every GET STATUS timed out. macOS issues GetPipeStatus
= GET STATUS(endpoint) on a halted pipe before running Bulk-Only
reset recovery and hit this on every probe; lsusb -v's device-status
query hangs on it as well. Send the response: endpoint recipient
reports the halt bit, device recipient reports self-powered,
interface reports zeros; the status stage is armed by handle_zlp()
exactly as for class-dispatched IN transfers.
Validated on RP2350 silicon (Raspberry Pi Pico 2 W, composite
CDC-ACM + CDC-NCM + USBMSC): pre-fix, a raw-usbfs replay of macOS's
sequence and timing reproduced both defects deterministically (CSW read
ETIMEDOUT after a delayed clear-halt; all GET STATUS variants
ETIMEDOUT). Post-fix: the CSW survives the halt and is delivered after
Clear-Halt with correct tag/status/residue across a post-stall delay
sweep of 0-1000 ms; all GET STATUS variants answer immediately with
correct halt reporting; no regressions in the exact-length SCSI suite,
Bulk-Only reset, FAT mount and full reads, CDC-NCM/ACM, or warm
reboots; and macOS now mounts the volume (together with the companion
usbmsc fixes). The rp2040 driver shares the code and receives the
identical fix (build-tested).
Assisted-by: Claude (Anthropic Claude Code)
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
arch/x86 set CROSSDEV only under Cygwin, so everywhere else the build used
the bare tool names and got the host compiler. On Linux that is a native
gcc which can produce i486 ELF objects, which is what the board README
assumes. On macOS it is Apple clang, and on Apple Silicon that cannot
target i386 in any form -- so there is no configuration in which the default
works and a cross toolchain is not optional.
Default it to i686-elf-, which Homebrew packages and which accepts the
-march=i486 -mtune=i486 already in ARCHCPUFLAGS. arch/x86_64 has had
exactly this stanza for its own toolchain all along; this is the same shape.
The Cygwin assignment becomes ?= to match, so that a CROSSDEV passed in from
the environment or the command line is honoured rather than overridden.
Note for anyone tempted by the toolchain they already have: a 64-bit x86
compiler with -m32 is not a substitute unless it was built with multilib.
Homebrew's x86_64-elf-gcc compiles 32-bit objects perfectly happily and has
no 32-bit libgcc to link them against, so the entire build succeeds and only
the final link fails, on __udivdi3, __divdi3, __moddi3 and __udivmoddi4.
`x86_64-elf-gcc -print-multi-lib' prints just `.;', which is the toolchain
saying so up front.
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Registering /dev/rtc0 from up_rtc_initialize() creates the pseudofs inode before clock_inittime() synchronizes CLOCK_REALTIME. Its timestamp is consequently zero and omitted by ls -l.
Keep lower-half setup in early RTC initialization, but defer character-device registration to up_initialize(), which runs after clock initialization.
Fixes#19504
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
sim_head.c is linked separately from libarch, so it was omitted from the
source and dependency lists. Track its source independently so
configuration and header changes rebuild sim_head.o while preserving its
link behavior.
Assisted-by: Codex:gpt-5.6 Sol
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
intel64_timer_start_absolute() computed "expected - current_us" unsigned. A
watchdog started with a delay of zero asks for a deadline that is already
current, the subtraction wraps to nearly 2^64, and the comparator is set so
far ahead that the timer never fires. The CONFIG_INTEL64_HPET_MIN_DELAY
clamp in intel64_oneshot_start() cannot help: the wrapped value is enormous,
not small.
Ask for the shortest delay the hardware can take instead of wrapping, and let
that existing minimum-delay logic pick it.
It presents as ostest hanging in wdog_test with no output and no fault.
apps/testing/ostest/wdog.c:281 calls wdtest_once(&test_wdog, param, 0), and
NSEC2TICK() takes the next few delays (1ns, 10ns, ...) to zero ticks as well;
wdtest_once() then spins forever in its "wait until the callback is triggered
exactly once" loop.
Impact: runtime, ARCH_INTEL64_HPET_ALARM only.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
copy_kernel_mappings() copies exactly one PDPT entry, the 1GB linear window
that maps physical 0-1GB at 4GB-5GB. The boot identity mapping of the low
4GB, which lives in PDPT entries 0-3 of g_pdpt_low (intel64_head.S:756, one
page directory per 1GB) and is where every MMIO register is reached, is not
carried over.
A kernel thread never gets an address environment of its own and
addrenv_switch() leaves the last one in place for it, so as soon as any
process exists, kernel code touching MMIO faults. The HPET at 0xfed00000
finds it immediately -- CR2=fed000f0, in intel64_hpet_getreg() under
clock_systime_ticks() on the lpwork thread -- and any MMIO driver would.
Inherit the four boot PDPT entries. They point at the boot page directories
rather than at copies, so anything intel64_map_region() adds later is
inherited too, and they carry no X86_PAGE_USER, so user code still cannot
reach them.
Impact: runtime, CONFIG_ARCH_ADDRENV builds only. User-space access is
unchanged; the entries added are supervisor-only.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
mm_pginitialize() documents heap_start as "the physical address of the start
of memory region", and every x86_64 consumer of mm_pgalloc() agrees:
create_spgtables(), x86_64_get_pgtable() and up_addrenv_create() all put the
result through x86_64_pgvaddr() before touching it. x86_64_pgvaddr() in turn
range-checks against CONFIG_ARCH_PGPOOL_PBASE (arch/x86_64/src/common/
pgalloc.h:67). arm64's equivalent passes CONFIG_ARCH_PGPOOL_PBASE.
up_allocate_pgheap() passed CONFIG_ARCH_PGPOOL_VBASE instead, and in the
other branch X86_64_PGPOOL_BASE + X86_64_LOAD_OFFSET, which is the same
mistake spelled out. Every page handed out was therefore a virtual address
that fell outside the pool's physical window, x86_64_pgvaddr() returned 0,
and the first x86_64_pgwipe() memset NULL.
It presents as a page fault in memset() under create_spgtables() the first
time a process address environment is created, which is loading the init
program. qemu-intel64:knsh_romfs sets PGPOOL_PBASE=0x00c000000 and
PGPOOL_VBASE=0x10c000000, so the value passed was off by the 4GB load
offset.
Impact: runtime, CONFIG_ARCH_ADDRENV builds only (CONFIG_MM_PGALLOC).
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
