Expose the bundled LAME and libmad headers to the sim:alsa arch target and include LAME through its installed public header name. This lets the CMake build compile sim_offload.c without relying on host codec development packages.
Assisted-by: Zed:GPT-5.6 Terra
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
SPI_VIA_IOMUX used SPI2 IOMUX pin macros that are undefined when SPI2
is disabled or on chips without IOMUX SPI pins (e.g. ESP32-P4), so the
driver took the IOMUX path and never routed SPI3 via the GPIO matrix.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
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>
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>
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>
Change the arch/mips/src/Makefile to build nuttx with CONFIG_ALLSYMS
enabled in MIPS architecture. This enables symbol name showing in
system, such as 'dumpstack 3' shows both functions name and addresses.
This change is referred to arch/tricore/src/Makefile and updated to
work well with MIPS. And it works with and without CONFIG_ALLSYMS enabled.
Fixes apache#19728
Signed-off-by: wangtao <twangpicasso@gmail.com>
Replace the iLLD helpers IfxCpu_resetAndStartCounters() and
IfxCpu_getClockCounter() in the performance-counter path with direct
CSR accesses via tricore_mtcr()/tricore_mfcr().
tricore_reset_ccnt() disables the CPU cycle counter (CPU_CCTRL), clears
CPU_CCNT, then re-enables it; up_perf_gettime() reads CPU_CCNT directly.
This removes the arch/tricore perf path's dependency on the Infineon
iLLD layer. No behavior change.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
Replace the iLLD register structures (Ifx_CPU_PCON0/1/2, Ifx_CPU_DCON0/1/2)
and the IfxCpu_cfg.h cache-size/line-size macros in the cache path with
direct CSR accesses via tricore_mtcr()/tricore_mfcr() and locally defined
PCON/DCON bit masks. Also switch __isync()/__dsync() to the UP_ISB()/
UP_DSB() barrier wrappers.
This removes the arch/tricore cache path's dependency on the Infineon
iLLD layer. No behavior change.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
Add tricore_mtcr()/tricore_mfcr() inline-assembly wrappers for the
MTCR/MFCR (move to/from Core Special Function Register) instructions.
These let arch/tricore code access CSRs directly without relying on the
Infineon iLLD intrinsics, and are used by the following iLLD-removal
change in the performance-counter path.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
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>
The signal frame was built inside the 128 byte red zone of the
interrupted user code and inherited its stack alignment, so a leaf
function could lose live data to the siginfo copy and the handler
could fault on an SSE access. Build the frame below the red zone,
16 byte aligned; the naked trampoline calls the handler itself and
its call provides the return address slot.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
For a thread interrupted in user mode the trampoline ran on the user
stack, where the signal handler then grows over its frame. Run it on
the thread kernel stack, unused while the thread is in user mode. The
stack cannot be selected from the saved CS: up_initial_state() records
the caller CS, a kernel selector even for user threads.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
SYS_signal_handler_return restored RSP from saved_rsp, which is not
written when a task signals itself: synchronous dispatch skips
up_schedule_sigaction(), so the kernel stack pointer was set to zero
and the next push faulted. Save the kernel stack pointer at dispatch
in xcp.kstkptr, as risc-v does, and restore that.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
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>
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>
Replace the divergent board conventions for the timer input clock
frequency with a single uniform convention provided by every board:
- STM32_APBx_TIMn_CLKIN and BOARD_TIMn_FREQUENCY -> STM32_TIMn_CLKIN
- STM32_APBx_LPTIMn_CLKIN, BOARD_LPTIMn_FREQUENCY and
STM32_LPTIMn_FREQUENCY -> STM32_LPTIMn_CLKIN
- STM32_APB1_THRTIM1_CLKIN and BOARD_HRTIM1_FREQUENCY ->
STM32_HRTIM1_CLKIN
All STM32 consumers (tim/lptim/pwm/adc/dac/capture/sdadc/dfsdm/
pulsecount) updated to match; the timer input clock is now bus-agnostic
in the drivers.
Boards that carried the same timer clock in more than one convention now
define STM32_TIMn_CLKIN exactly once, derived from the APB bus clock
(PCLKx with the x2 doubler when the APB prescaler is greater than 1),
instead of redefining it with a second, sometimes different, value.
BREAKING CHANGE: The timer input-clock board macros STM32_APBx_TIMn_CLKIN,
BOARD_TIMn_FREQUENCY, STM32_APBx_LPTIMn_CLKIN, BOARD_LPTIMn_FREQUENCY,
STM32_LPTIMn_FREQUENCY, STM32_APB1_THRTIM1_CLKIN and
BOARD_HRTIM1_FREQUENCY are removed in favor of STM32_TIMn_CLKIN,
STM32_LPTIMn_CLKIN and STM32_HRTIM1_CLKIN. Out-of-tree boards must
define the new macros (drop the APB bus from the name, keep the value),
and out-of-tree drivers referencing the old names must be updated.
Signed-off-by: raiden00pl <raiden00@railab.me>
STM32_ETHMAC selects NETDEVICES, but NETDEVICES depends on NET. Enabling
ETHMAC without NET produced an invalid Kconfig
Signed-off-by: raiden00pl <raiden00@railab.me>
Enabling STM32_FOC without MOTOR_FOC failed to build with
"unknown type name 'foc_current_t'". Add the dependency on MOTOR_FOC.
Signed-off-by: raiden00pl <raiden00@railab.me>
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>
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
The STM32H7, STM32F7, STM32L4 and common STM32 SDIO/SDMMC drivers failed
to program the WIDBUS bits when switching MMC/eMMC cards to 4-bit mode,
and the MMC transfer clock presets were hardwired to 1-bit bus width.
Add CLOCK_MMC_TRANSFER_4BIT to the common SDIO clock enum, add 4-bit
MMC clock presets, and update stm32_widebus() to use modifyreg32/
sdmmc_modifyreg32 to set the host controller bus width.
Signed-off-by: DuoYuWang <thirteenking.wang@gmail.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>
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>
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>
usbdev_register() calls CLASS_BIND, which ends with DEV_CONNECT
(composite_bind/cdcacm_bind) and sets SIE_CTRL.PULLUP_EN, and then
performs a wholesale putreg32 of SIE_CTRL to set EP0_INT_1BUF --
clobbering the pull-up microseconds after it was asserted.
Enumeration only ever succeeded because the host happened to latch the
microsecond pull-up blip and issued a bus reset, whose handler
(CLASS_DISCONNECT -> DEV_CONNECT) re-arms the pull-up. A warm host
port catches the blip; a cold-plugged port is still in attach debounce,
misses it, and never resets -- PULLUP_EN stays 0 forever and the device
is totally silent on the bus while NuttX runs normally underneath.
This presented as an intermittent, image-dependent "cold boot brick"
(boot timing shifts the blip in or out of the host's blind window).
Fix: set EP0_INT_1BUF with setbits_reg32 so PULLUP_EN survives.
Validated on RP2350 silicon (Raspberry Pi Pico 2 W): an image that
failed 0/10 cold plugs enumerated 10/10 with the fix; a second board
that had never enumerated at all was recovered by it. The rp2040
driver has the identical code and receives the identical fix
(build-tested; the RP2350 validation exercised the shared logic).
Fixesapache/nuttx#19434
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
rp23xx_usbdev.c is a line-for-line copy of the rp2040 USB device driver
and shares all three endpoint-handling defects fixed in the preceding
commits:
- bulk OUT reads armed with the full request length, overflowing the
10-bit buffer-control LEN field for large reads (e.g. cdcncm);
- endpoint requests resubmitted from their own completion callback
being armed twice, corrupting the data PID;
- the buffer AVAILABLE bit written together with length/PID instead of
afterwards.
Port the identical fixes to the RP2350 driver. The affected functions
are byte-identical to their rp2040 counterparts, so the changes match
verbatim. These were validated on RP2040 hardware; RP2350 shares the
same USB controller IP and driver, but was not re-tested on silicon.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
Per the RP2040 datasheet section 4.1.2.5.1, when handing a buffer to the
USB controller the AVAILABLE bit must be written after the rest of the
buffer-control register (length and data PID) and after a short delay,
because buffer control crosses from the system clock domain into the USB
clock domain. Writing everything in a single store risks the controller
acting on a stale length or PID. rp2040_update_buffer_control() wrote
the whole word, AVAILABLE included, in one access.
Follow the sequence the datasheet (and the Pico SDK) use: write the
control word with AVAILABLE cleared, wait ~12 CPU cycles, then set
AVAILABLE. The delay covers system clocks up to 12x the 48 MHz USB
clock.
Validated on raspberrypi-pico (RP2040) as part of bringing up cdcncm;
no regression on cdcacm/usbmsc.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
rp2040_txcomplete() and rp2040_rxcomplete() unconditionally called
rp2040_wrrequest()/rp2040_rdrequest() to start the next transfer after
invoking a request's completion callback. When that callback resubmits
a request on the same, now-idle endpoint -- which cdcncm and rndis do
from their interrupt/notify completion handlers -- rp2040_epsubmit()
already arms the hardware buffer for it. The unconditional re-arm in the
completion path then arms the same buffer a second time, toggling the
DATA0/DATA1 PID twice. The host sees a stale PID and silently discards
the packet as a retransmission, so e.g. the cdcncm NETWORK_CONNECTION /
SPEED_CHANGE notifications never reach the host and the interface stays
NO-CARRIER.
Track whether a request's hardware buffer has already been armed with a
per-request flag (set in rp2040_wrrequest/rp2040_rdrequest, cleared in
rp2040_epsubmit) and skip the redundant re-arm when the completion
callback has already resubmitted. The in-progress multi-packet case
(transfer not yet complete) still continues normally.
Validated on raspberrypi-pico (RP2040): the cdcncm interrupt-IN
notification is now delivered (confirmed with usbmon) and the host
brings the link up; previously it never was. This is also the likely
cause of the long-standing rndis control-response timeout on this
controller.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
rp2040_epread() armed the DPSRAM buffer-control register with the full
usbdev request length. That length is only correct for requests no
larger than the buffer-control LEN field, which is 10 bits wide (max
1023 bytes). Class drivers that post larger read requests -- e.g.
cdcncm allocates a 16 KiB NTB read buffer -- overflow LEN: 16384 & 0x3ff
is 0, and the high bits corrupt the neighbouring control flags. The
controller then sees a zero-length available buffer and completes the
transfer immediately with zero bytes, over and over, so no OUT data is
ever received (cdcncm floods "Wrong NTH SIGN, skblen 0").
The receive path already accumulates a request across multiple packets:
rp2040_rxcomplete() copies each packet, advances xfrd and re-arms via
rp2040_rdrequest() until the request is satisfied or a short packet
arrives. So the buffer only ever needs to be armed for a single
maximum-size packet. Clamp nbytes accordingly. This matches the
transmit path, which already chunks to ep.maxpacket in rp2040_wrrequest.
Bulk classes with small reads (cdcacm, usbmsc) were unaffected because
their request lengths already fit in LEN, which is why the defect only
showed up on cdcncm.
Validated on raspberrypi-pico (RP2040): a CONFIG_NET_CDCNCM device that
previously received nothing now passes traffic in both directions with
0% packet loss.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW
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>
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>
794c325947 ("arch/x64:Syscall support is enabled by default", 2025-05-27)
changed nine guards from CONFIG_LIB_SYSCALL to CONFIG_ARCH_HAVE_SYSCALL but
never added the Kconfig symbol. Only ARCH_HAVE_SYSCALL_HOOKS exists in tree;
ARCH_HAVE_SYSCALL itself is defined nowhere, so it is always unset and since
that commit x86_64 has had no x86_64_syscall_entry(), no x86_64_syscall(), no
IA32_LSTAR/IA32_STAR programming and no syscall stub layer in any
configuration:
arch/x86_64/src/common/Make.defs:37 x86_64_syscall.c not compiled
arch/x86_64/src/common/CMakeLists.txt:41 likewise
arch/x86_64/include/irq.h:86
arch/x86_64/src/intel64/intel64_cpu.c:247, :386
arch/x86_64/src/intel64/intel64_head.S:83, :351, :538
arch/x86_64/src/intel64/intel64_saveusercontext.S:108
qemu-intel64:knsh_romfs and qemu-intel64:knsh_romfs_pci are the two
CONFIG_BUILD_KERNEL configurations in tree, and neither can have worked in
that time. They still link -- nothing references the missing pieces, so
libstubs.a is simply never pulled in -- and then die the first time user code
executes SYSCALL.
Define the symbol with the condition the code had before that commit, which
is LIB_SYSCALL: every protected and every kernel build needs the interface,
and a flat build is left exactly as it is today.
Impact: restores the system call interface for CONFIG_BUILD_KERNEL and
CONFIG_BUILD_PROTECTED on x86_64. CONFIG_BUILD_FLAT is unaffected --
qemu-intel64:nsh still builds with ARCH_HAVE_SYSCALL unset.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
g_x86_64_timer_freq is assigned only under ARCH_INTEL64_TSC_DEADLINE or
ARCH_INTEL64_TSC, and is read only by the two intel64_tsc_*.c files those
options build. With the HPET as the system clock it stays 0, which is
correct and harmless -- but x86_64_timer_calibrate_freq() panics on 0
unconditionally, so the board dies during x86_64_lowsetup().
Require a frequency only where something needs one, which is
ARCH_INTEL64_HAVE_TSC.
The failure mode is worth recording, because it gives nothing to work from:
the PANIC() happens before x86_64_earlyserialinit(), and the panic handler
itself then triple-faults, because _assert() reads up_interrupt_context() --
a %gs-relative load -- and the GS base is not programmed until
x86_64_cpu_priv_set(). The console stays completely empty and the machine
resets.
Impact: runtime, ARCH_INTEL64_HPET_ALARM only. Configurations with a TSC
are unchanged -- the PANIC() is still compiled for them.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
ARCH_INTEL64_HPET_ALARM is one of the three members of the "System Timer
Source" choice, but selecting it does not build. Taking qemu-intel64:nsh on
master and moving the choice off ARCH_INTEL64_TSC_DEADLINE onto it:
intel64/intel64_hpet_alarm.c:41:24: error:
'CONFIG_ARCH_INTEL64_HPET_ALARM_CHAN' undeclared
ARCH_INTEL64_HPET_ALARM_CHAN lives inside "if INTEL64_HPET" and nothing
selects INTEL64_HPET. Enabling that by hand moves the failure to link time,
because intel64_oneshot_lower.c is built only when INTEL64_ONESHOT is set:
undefined reference to `oneshot_initialize'
Enabling INTEL64_ONESHOT as well finally reaches the real problem.
intel64_oneshot_lower.c implements the counter flavour of struct
oneshot_operations_s, which exists only with ONESHOT_COUNT:
intel64_oneshot_lower.c: error: 'const struct oneshot_operations_s' has no
member named 'start_absolute'
intel64_oneshot_lower.c: error: implicit declaration of function
'oneshot_count_init'
intel64_oneshot_lower.c: error: initialization of
'int (*)(struct oneshot_lowerhalf_s *, const struct timespec *)' from
incompatible pointer type ... (four more of these)
ONESHOT, ONESHOT_COUNT and ONESHOT_FAST_DIVISION were selected by
ARCH_INTEL64_TSC_DEADLINE and by nothing else, so the other members of the
same choice could never be built.
Select the four from ARCH_INTEL64_HPET_ALARM as well. INTEL64_ONESHOT
selects INTEL64_HPET in turn, which is what brings
ARCH_INTEL64_HPET_ALARM_CHAN into existence, so one added select closes all
three stages.
Impact: build only, and only for a configuration that could not be built
before. No existing defconfig selects ARCH_INTEL64_HPET_ALARM.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.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>
on_hci() ran the host upcall with g_sdc_dev.lock held. On nrf53 this
deadlocks the BLE link: the upcall waits for the app core,
which cannot answer while bt_hci_send() blocks on the same lock.
nrf52 modified for consistency, deadlock is not possible there.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The rp23xx hardware headers define a register address macro for every
register, then a block of register bit definitions. In three headers a bit
definition reuses the name of a register address macro, so the register
address is silently redefined as a bit mask:
RP23XX_POWMAN_BADPASSWD address 0x40100000 -> (1 << 0)
RP23XX_POWMAN_BOD_CTRL address 0x40100018 -> (1 << 12)
RP23XX_POWMAN_DBG_PWRCFG address 0x401000a4 -> (1 << 0)
RP23XX_BUSCTRL_BUS_PRIORITY_ACK address 0x40068004 -> (1 << 0)
RP23XX_BUSCTRL_PERFCTR_EN address 0x40068008 -> (1 << 0)
RP23XX_PADS_QSPI_VOLTAGE_SELECT address 0x40040000 -> (1 << 0)
None of these headers has an in-tree user yet, which is why this has gone
unnoticed; each clash appears as a "macro redefined" warning as soon as a
driver includes the header. Code that included one of them and used the
register by name would have dereferenced 1 or 0x1000 instead of the register.
Two of the POWMAN clashes were plain duplicates. Per the RP2350 datasheet
BOD_CTRL bit 12 is ISOLATE and DBG_PWRCFG bit 0 is IGNORE, and the correctly
named RP23XX_POWMAN_BOD_CTRL_ISOLATE and RP23XX_POWMAN_DBG_PWRCFG_IGNORE were
already defined with the same values on the following lines, so the bare names
are simply removed. The blank line separating the VREG_LP_EXIT and BOD_CTRL
groups is restored at the same time; its absence is what let the duplicate
hide inside the preceding group.
The other four are single field registers whose field carries no separate name
(the datasheet and the SDK describe each as a one bit register), so their bit
definitions are renamed to <REGISTER>_MASK, following the _MASK spelling these
headers already use for a field extent, and written in hex like their peers.
The rp23xx-rv copies of the three headers are identical to the arm ones and
carry the same clashes, so they get the same change and stay in sync.
No functional change: none of the six names has any user in the tree.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
