Switch every qemu-armv8a defconfig whose init entry point was nsh_main
(20 configs) to nxinit (init_main). nsh now runs as a "console sh"
service started by init.rc instead of being the top-level init task.
Each switched defconfig only gains the nxinit-essential keys (minimal
delta):
- CONFIG_INIT_ENTRYPOINT="init_main"
- CONFIG_SYSTEM_NXINIT=y plus its Kconfig deps not already set:
CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS
(depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_ETC_ROMFS=y / CONFIG_FS_ROMFS=y to ship init.rc via ROMFS
No stack-size overrides: INIT_STACKSIZE/SYSTEM_NSH_STACKSIZE keep their
Kconfig defaults (DEFAULT_TASK_STACKSIZE, already 8192 on this board).
Add boards/arm64/qemu/qemu-armv8a/src/etc/init.d/init.rc, shipped via
ROMFS in the Make build (RCSRCS) and CMake (nuttx_add_romfs()), gated on
CONFIG_ETC_ROMFS && CONFIG_SYSTEM_NXINIT. Omitting this ROMFS plumbing
causes a link-time "undefined reference to romfs_img".
Testing: qemu-armv8a:nsh (and nsh_smp with -smp 4) boot into nxinit with
nsh spawned as its service (init task = init_main, sh = its child),
confirmed via qemu-system-aarch64 in an earlier run of this series. The
removed explicit 8192 stack sizes equal this board's DEFAULT_TASK_STACKSIZE,
so runtime behavior is unchanged. Note: current apache/master fails to
build locally this round (empty -Wstack-usage=, missing libfdt.h)
independent of this change.
Assisted-by: opencode-agent/claude-opus-4-8
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch every sim/sim/sim defconfig whose init entry point was nsh_main
(81 configs) to nxinit (init_main). nsh now runs as a "console sh"
service started by init.rc instead of being the top-level init task.
Each switched defconfig only gains the nxinit-essential keys (minimal
delta, regenerated so no unrelated options leak in):
- CONFIG_INIT_ENTRYPOINT="init_main"
- CONFIG_SYSTEM_NXINIT=y plus its Kconfig deps that were not already set:
CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS
(which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_ETC_ROMFS=y / CONFIG_FS_ROMFS=y to ship init.rc via ROMFS
No stack-size overrides are added: INIT_STACKSIZE and SYSTEM_NSH_STACKSIZE
keep their Kconfig defaults (DEFAULT_TASK_STACKSIZE).
Five configs (dynconns, module, module32, sotest, sotest32) had
CONFIG_BINFMT_DISABLE=y, which blocks CONFIG_LIBC_EXECFUNCS and thus
CONFIG_SYSTEM_NXINIT. Since nxinit spawns services via exec(), binfmt is
re-enabled in those five. They also enable CONFIG_LIBC_ENVPATH but did
not ship a /bin, so nxinit's posix_spawnp("sh") resolved via PATH and
failed with ENOENT ("Error Starting service 'console': 2"). Add
CONFIG_FS_BINFS=y and CONFIG_PATH_INITIAL="/bin" to those five so the
builtin apps are visible under /bin and the console service starts,
matching the working sim:nsh config.
citest additionally needed CONFIG_ETC_ROMFSDEVNO=1 (matching the 53
other sim configs that already set it to avoid the same collision):
sim_registerblockdevice() (arch/sim/src/sim/sim_blockdevice.c, called
from up_initialize() before any application task starts) unconditionally
registers a FAT ramdisk at /dev/ram0 whenever CONFIG_FS_FAT is set, and
citest is one of the few switched configs with CONFIG_FS_FAT=y that had
never overridden CONFIG_ETC_ROMFSDEVNO away from its Kconfig default of
0. With nxinit, romdisk_register() for /etc's ROMFS at that same minor
number then fails with -EEXIST and nxinit aborts with "Error Opening
/etc/init.d/init.rc" since it treats a missing init.rc as fatal;
nsh_main() silently tolerated the identical failure before this switch
(logs "init: open failed: 2" and continues to the nsh prompt), so the
/etc mount had actually never worked for citest even pre-nxinit.
Add boards/sim/sim/sim/src/etc/init.d/init.rc (registers a "console sh"
service guarded by CONFIG_SYSTEM_NSH; "on init" starts it), shipped via
ROMFS in the Make build (RCSRCS) and CMake (nuttx_add_romfs()), both gated
on CONFIG_ETC_ROMFS && CONFIG_SYSTEM_NXINIT so non-nxinit configs are
unaffected.
Switching to nxinit means nsh_main()/nsh_initialize() (which used to run
/etc/init.d/rc.sysinit and rcS to mount /tmp and /data) no longer runs on
the 46 sim configs that already had CONFIG_ETC_ROMFS=y on master, so
those mounts would otherwise be lost. /bin (binfs) and /proc (procfs) are
unaffected: sim_bringup() (called from board_late_initialize(), before
any entrypoint task starts, independent of nsh_main/init_main) already
mounts them unconditionally on master, and this PR does not touch that
file. init.rc's "on init" action reproduces the rest of rc.sysinit's
mounts (tmpfs, or the FAT-backed /tmp ramdisk via mkrd + mkfatfs + mount
for boards without CONFIG_FS_TMPFS) plus the hostfs /data mount that
used to live in rcS, inlining them directly instead of spawning the
standalone rcsysinit/rcS scripts through a "service ... oneshot"
indirection. nxinit has no builtin mount/mkrd/mkfatfs yet, so each of
these commands still resolves through its posix_spawnp() sh fallback;
that limitation is unchanged by this PR and is left for a follow-up
(either a native mount() call in sim_bringup() for the fixed-path
mounts, or a builtin in nxinit). The 6 configs that also enable
CONFIG_FS_FAT get an explicit CONFIG_ETC_FATDEVNO=2 so this ramdisk does
not collide with /etc's romdisk.
Now that every sim nsh_main + CONFIG_ETC_ROMFS config has switched to
nxinit, boards/sim/sim/sim/src/etc/init.d/rcS and rc.sysinit are dead
code: no remaining sim config calls nsh_initialize() (the only caller of
those scripts), so remove both files outright and drop them from
boards/sim/sim/sim/src/CMakeLists.txt and Makefile's ROMFS RCSRCS list
(init.rc is shipped instead, as above, only when CONFIG_SYSTEM_NXINIT=y).
The remaining ROMFS-enabled sim configs whose entrypoint isn't nsh_main
(nxlines/nxwm/toybox) never executed rcS/rc.sysinit either (their
entrypoint never calls nsh_initialize()), so they lose nothing but a few
unused bytes from their ROMFS image; sim:nxlines was rebuilt to confirm
it still links and boots with an empty etc/init.d/.
init.rc also uses <nuttx/macro.h>'s CONCATENATE() instead of a local
CONCAT_()/CONCAT() pair, matching existing NuttX convention instead of
duplicating a macro the tree already provides.
sim:windows and sim:windows64 are excluded and stay on nsh_main: they
build under MSVC in CI, and CONFIG_SYSTEM_NXINIT pulls in
apps/system/nxinit/action.c, which fails to compile under MSVC because
list_peek_head_type() (include/nuttx/list.h) uses a GCC
statement-expression the MSVC C compiler does not support; separately,
CONFIG_ETC_ROMFS routes them through nuttx_add_romfs()'s POSIX-shell
genromfs/xxd/sed custom build step, which cmd.exe cannot parse either.
Both are pre-existing MSVC gaps in nxinit/the ROMFS CMake helper, not
something this defconfig-only PR should fix, so these two configs are
left on nsh_main.
Testing (sim, host gcc): sim:nsh boots into nxinit with nsh spawned as
its service (init task = init_main, sh = its child), and now shows the
same five mount points as master (/bin /data /etc /proc /tmp), matching
the pre-switch nsh_main baseline; /data round-trips a write to the host
filesystem. The five binfmt configs reach an interactive nsh prompt
(help/uname work) instead of failing to start the console; e.g.
sim:module:
BEFORE fix: Error Starting service 'console': 2
AFTER fix: nsh> help / nsh> uname -a (console up)
init.rc's inlined FAT/tmpfs mount was verified by preprocessing it with
cpp under both CONFIG_FS_FAT and CONFIG_FS_TMPFS: the expansion matches
rc.sysinit's mount sequence (CONCATENATE() resolves to /dev/ram2, etc.).
sim:citest specifically verified with gdb: before the ETC_ROMFSDEVNO fix,
register_blockdriver("/dev/ram0") is called twice (once by
sim_registerblockdevice() from up_initialize(), once by nx_romfsetc());
the second call returns -EEXIST and nxinit aborts. After setting
CONFIG_ETC_ROMFSDEVNO=1, sim:citest boots cleanly into nxinit (ps shows
init_main waiting on its child sh, matching sim:nsh), and the compiled
ROMFS image contains only init.rc. sim:nxlines, a non-nxinit
CONFIG_ETC_ROMFS config, was rebuilt to confirm it still links and boots
with the now-empty etc/init.d/ (rcS/rc.sysinit removed).
Assisted-by: opencode-agent/claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Adds a section covering CONFIG_SENSORS_LSM6DS3TRC_FIFO: what it changes
(one interrupt/I2C read per watermark instead of per sample) and its
three limitations while it's on -- both sub-sensors forced to the same
ODR, temperature no longer per-sample (one read per drain applied to
the whole batch), and both sub-sensors must stay physically enabled
regardless of subscription, since the chip's FIFO write trigger needs
both running -- plus the watermark/ORB-buffer-size relationship callers
need to respect.
Also documents a related chip quirk found during bench testing:
diff_words reads 0 at the exact moment a real FIFO overrun occurs, even
though the FIFO is still completely full of valid, retained data (a
forced read past that point recovers real samples, not garbage). This
isn't a bug in this driver: ST's own engineers confirm the same
behavior for this chip family on their community forum (thread
"LSM6DS3 FIFO status clarification", td-p/184022), and the mainline
Linux st_lsm6dsx driver doesn't attempt to recover from it either -- it
only special-cases an empty FIFO, not an overrun one. Documenting this
in a comment rather than adding recovery logic: with the small
watermark this driver uses, reaching a real overrun at all means the
drain has already fallen many seconds behind, and ST's own guidance for
this condition is to avoid it via watermark sizing rather than recover
from it.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Hardware testing (single-topic FIFO subscriptions, register dumps via
manual i2c commands) turned up two independent bugs that together
made the FIFO silently never accumulate data for a single-topic (e.g.
accel-only) subscription, while showing FIFO_STATUS2 stuck reporting
OVER_RUN and FIFO_FULL_SMART with a simultaneous zero DIFF_FIFO count:
- The LSM6DS3TR-C's FIFO write trigger (data-ready-based, the only mode
this driver uses) only fires while BOTH the accelerometer and the
gyroscope are physically running, regardless of which one(s) are
actually decimated into the FIFO pattern -- confirmed in the
datasheet's FIFO section ("the ODR must be lower than or equal to
both the accelerometer and gyroscope ODRs") and reproduced by
register-level testing with the unsubscribed sensor powered down vs.
powered up. lsm6ds3trc_fifo_configure() now forces whichever
sub-sensor isn't subscribed to run at the shared rate anyway (still
excluded from the pattern, so this costs no extra I2C bandwidth on
drain, just that sensor's own unavoidable power draw), and brings it
back down once neither sub-sensor is subscribed.
- Separately, lsm6ds3trc_fifo_configure() reconfigured decimation,
watermark and ODR while the FIFO was still running in Continuous
mode from a previous configuration. Reproduced manually: reconfiguring
live leaves FIFO_STATUS1/2 stuck reporting a stale diff count even
once the trigger fix above is in place; resetting through Bypass mode
first (which also empties the FIFO) before writing the new settings,
the same procedure the datasheet documents for changing FIFO
settings, and only re-entering Continuous mode last, is what actually
gets the diff counter to track correctly.
Also fixes two bit-definition bugs found while cross-referencing the
real ST datasheet instead of the in-tree lsm6dsl.h header used as a
starting point: MASK_FIFO_DIFF_HI was 4 bits (0x0f) instead of the
documented 3 (0x07), and MASK_DEC_FIFO_XL/SHIFT_DEC_FIFO_GY assumed
2-bit decimation fields instead of the documented 3-bit ones.
Verified on hardware: accel-only, gyro-only, and both-topics
subscriptions all now drain cleanly at the configured watermark with
no overrun, sustained over tens of seconds of continuous streaming.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Previously, activate() always fell back to a hardcoded ODR_52HZ (or the
other sub-sensor's rate, in FIFO mode) whenever a sub-sensor went from
disabled to enabled, discarding whatever rate the application had
explicitly requested via set_interval() before disabling it. An
application that only ever wants, say, 25Hz would see the sensor
restart at 52Hz on every re-activation, and in FIFO mode this fills the
FIFO faster than intended, defeating the point of choosing a lower ODR
for power savings.
Add last_odr, which -- unlike odr -- survives being disabled. activate()
now restores it on the next enable, only falling back to ODR_52HZ on a
sub-sensor's genuine first-ever activation.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Interrupt-driven mode so far pushes one uORB event per physical sample:
one I2C burst read and one interrupt per sample, at whatever ODR the
topic is running. That's the dominant power cost for a
battery-constrained use case sampling continuously -- draining the
chip's FIFO in batches cuts both by roughly the watermark size.
The LSM6DS3TR-C's FIFO is the older ST "pattern" style (no per-sample
tag byte, unlike LSM6DSO/ISM330): FIFO_CTRL3's per-sub-sensor decimation
bits choose which of gyro/accel feed the FIFO (0 = excluded, 1 = no
decimation -- only 0/1 are used here), FIFO_CTRL5 sets one shared
FIFO-only ODR, and FIFO_STATUS1/2's DIFF_FIFO reports how many 16-bit
words are waiting. Reused the existing INT1 wiring, but switched from
DRDY (per-sample) to FTH (threshold reached) when
CONFIG_SENSORS_LSM6DS3TRC_FIFO is on -- new bool that's a whole-driver
mode switch, not a per-instance choice, so a board doesn't change; only
its Kconfig does.
lsm6ds3trc_fifo_configure() re-derives and writes the decimation bits,
FIFO ODR, and watermark threshold (in words = watermark-in-samples *
words-per-pattern, 3 with one sub-sensor active or 6 with both) from
current dev->gyro/accel enabled+odr state; called from activate() and
set_interval(). Both sub-sensors are forced to the same ODR while FIFO
is on -- decimation factors > 1 for independent per-topic rates is real
complexity (matching ODR ratios to decimation values) left for later.
lsm6ds3trc_fifo_worker() replaces lsm6ds3trc_worker() under the Kconfig
guard: reads DIFF_FIFO, bursts that many words (rounded down to a whole
pattern chunk, capped at 2x the configured watermark so a late drain
doesn't overflow the read buffer -- whatever's left over just waits in
the chip's own FIFO for the next drain), then walks the buffer decoding
each chunk into a push_event() same as before. FIFO entries don't carry
their own timestamp, so each one is interpolated backwards from the
ISR's timestamp by the configured ODR interval. Temperature isn't part
of the FIFO pattern (FIFO_TEMP_EN stays off to keep the pattern width
simple); one direct OUT_TEMP_L read per drain is applied to the whole
batch instead.
Validated on the bench, both pattern widths: with both topics
subscribed (6-word pattern) and with only the accelerometer (3-word),
samples arrive in watermark-sized bursts with interpolated timestamps
spaced by the exact configured ODR interval (52Hz -> 19230us between
every consecutive sample, matched exactly), sane accel/gyro values, no
I2C errors, no overruns, sustained for 15+ seconds continuous.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
FOREACH_ARG() hands the position of each argument as the expression
"count - N", which can be used as a value but cannot be pasted into an
identifier, because "##" pastes a single token. Hand it out as a
literal instead, so that an action macro can build a symbol name out of
it, which is what a subsystem needs when the link order of its objects
has to follow the declaration order.
The list is reversed through REVERSE_ARG() so that the position becomes
the level of the chain, and each step emits the recursion before its own
action so that the actions still come out in the order the arguments
were given. This is how the same problem is solved upstream in Zephyr,
whose FOR_EACH_IDX() also reverses the list before walking a per arity
chain.
The index values are unchanged, so the arithmetic use keeps working:
NOTE_PRINTF_TYPES(), the only user in tree, produces the same tags for
every argument count. It now supplies the leading zero itself, because
FOREACH_ARG() no longer expands to "0" when the list is empty. An empty
list expanding to nothing is what lets an action expanding to
declarations be used at file scope.
Assisted-by: Claude Code
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
nuttx-ntfc-testing's release-0.0.1 tag pins ntfc.yaml's citest
requirement to CONFIG_INIT_ENTRYPOINT=nsh_main, so any sim/citest
defconfig that switches to a different init entrypoint (e.g. nxinit's
init_main) fails CI with:
OSError: Missing kconfig dependency: ['CONFIG_INIT_ENTRYPOINT', 'nsh_main']
Maintainer raiden00pl cut nuttx-ntfc-testing release-0.0.2, which drops
that CONFIG_INIT_ENTRYPOINT requirement from ntfc.yaml, and requested
both nuttx and nuttx-apps workflows be updated to it:
https://github.com/apache/nuttx-ntfc-testing/issues/7#issuecomment-5480486089
Only the `git clone -b release-0.0.1` line is changed; the unrelated
`ntfc==0.0.1` PyPI package pin is untouched.
Assisted-by: opencode-agent/claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
make export writes several names into LDNAME for boards that use
more than one linker script. The exported toolchain.cmake only
prefixed the first file, so ld searched for the rest in the
application build directory.
Normalize NUTTX_PATH so the generated -T arguments do not keep
the scripts/../scripts form.
Fixesapache/nuttx#19820.
Signed-off-by: Zhaoqi Xu <lzy00419@outlook.com>
Wire the RTL8721F (amebagreen2) into the shared Ameba timer driver
(arch/arm/src/common/ameba/ameba_timer.c), registered at /dev/timer0
(TIM1) and /dev/timer1 (TIM2). Only the per-chip base addresses, RCC
masks and IRQs differ, so this adds a small ameba_timer_chip.h (the two
32-bit basic LTIM timers at 0x40819200 / 0x40819400, 32.768 kHz,
APBPeriph_LTIM1/2, IRQ_TIMER1/2, verified against the SoC hal_platform.h
/ sysreg_lsys.h / vector table) plus the Make.defs/CMakeLists build
hooks, the fwlib ram_common/ameba_tim.c RAM source (now also pulled in
by CONFIG_AMEBA_TIMER, matching the PWM rule), the board bring-up
registration and a timer defconfig. The shared driver is unchanged.
TIM0 is left untouched because the boot ROM claims it as the always-on
system timer; reprogramming it would break every SDK delay.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Wire the RTL8720F into the shared Ameba timer driver
(arch/arm/src/common/ameba/ameba_timer.c), registered at /dev/timer0
(TIM1) and /dev/timer1 (TIM2). Only the per-chip base addresses, RCC
masks and IRQs differ, so this adds a small ameba_timer_chip.h (the two
32-bit basic LTIM timers at 0x40808200 / 0x40808400, 32.768 kHz,
APBPeriph_LTIM1/2, IRQ_TIMER1/2, verified against the SoC hal_platform.h
/ sysreg_lsys.h / vector table) plus the Make.defs/CMakeLists build
hooks, the fwlib ram_common/ameba_tim.c RAM source (now also pulled in
by CONFIG_AMEBA_TIMER, matching the PWM rule), the board bring-up
registration and a timer defconfig. The shared driver is unchanged.
TIM0 is left untouched because the boot ROM claims it as the always-on
system timer; reprogramming it would break every SDK delay.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Add a parameterised NuttX timer lower-half for the Realtek Ameba
general-purpose timers, sitting on the SDK fwlib RTIM register layer and
registered at /dev/timerN. The shared driver
(arch/arm/src/common/ameba/ameba_timer.c) reads a per-chip instance
table (ameba_timer_chip.h) for each timer's base, input clock, RCC gate
masks and IRQ; the period is programmed directly in microseconds and
converted to the 32-bit auto-reload with one clkfreq formula.
On the pke8721daf two of the 32.768 kHz "basic" (LTIM) timers are
exposed: /dev/timer0 is TIM1 and /dev/timer1 is TIM2. TIM0 is left
untouched because the boot ROM claims it as the always-on system timer
(SYSTIMER); reprogramming it would break every SDK delay. The RTIM
time-base entry points resolve to ROM, while the interrupt-clear and
period-change helpers come from the fwlib RAM source ameba_tim.c (shared
with the PWM driver).
Verified on hardware with examples/timer against both devices: the
update interrupt fires at the requested 1 s interval (measured with the
independent ROM SYSTIMER = 32768 ticks = 1.000 s).
Also whitelist the vendor RTIM_ symbol prefix in tools/nxstyle.c,
alongside the existing RCC_/SYSTIMER_ Ameba SDK entries.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Whitespace only: blank lines after declarations, misindented switch
bodies and brace alignment. nxstyle runs over the whole of any file a
change touches, and merging the CAN ioctl options renames a config in
every SocketCAN driver.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
TX-complete and the deadline watchdog each queued their own callback on
the same work_s, and work_queue() cancels whatever is pending when a
work_s is reused, so whichever ran second was dropped: deadlines were
left set, the TX interrupt mask stayed off, or expired frames were never
aborted. Both now queue imxrt_tx_work(), which retires completions
before it aborts expired mailboxes.
Add SIOCGCANERRORS so a socket can read fault confinement, TEC/REC, a
monotonic bus error count and the RX mailbox overrun count. SIOCGCANSTATE
reports sleep/operational, not fault confinement, hence a new command.
The error count is sampled from the clear-on-read ESR1 error flags at
every driver entry rather than from ERRINT, which fires per error frame
and storms at bus rate once the bus is dead. Frames the CAN socket layer
drops for want of an IOB now count as rx_dropped in the netdev
statistics as well as in the global CAN statistics.
Tested on an i.MX RT1176 (ARK FMU-v6XRT) running PX4 with two DroneCAN
nodes: unplugging one node the ioctl reports error-passive, TEC 128,
REC 0 and a monotonic error count, matching ECR/ESR1 read over SWD at
20 Hz, while the other interface stays error-active with zero errors.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
NETDEV_CAN_BITRATE_IOCTL, NETDEV_CAN_FILTER_IOCTL and
NETDEV_CAN_STATE_IOCTL guarded identical option blocks, and every
SIOCxCANxxx case in netdev_ifr_ioctl() forwarded a member of the same
ifr_ifru union to d_ioctl(). One option and one case block now cover
all of the CAN commands; drivers and defconfigs are updated to the
new name.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The SIOCxCANxxFILTER cases in fdcan_netdev_ioctl() call
stm32_addextfilter(), stm32_delextfilter(), stm32_addstdfilter() and
stm32_delstdfilter(), none of which exist anywhere in the tree. The
block only ever compiled because no stm32h7 config enables
NETDEV_CAN_FILTER_IOCTL; enabling it breaks the link. The commands now
fall through to the existing -ENOTSUP default, which is also what a
caller observed before.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
48-pin 1MB F412. CE was the only 48-pin part listed, so boards using
STM32F412CGU6 had to select a 512KB chip. Feature counts are identical
to CE, so it shares the block.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
100-pin 1MB F412 (LQFP/UFBGA). Without this, boards using
STM32F412VGH6 have to select the 48-pin 512KB CE.
STM32_NGPIO is 113 rather than the real 81 I/Os because
STM32_NGPIO_PORTS is (N+15)>>4 and 81 yields six ports A-F, so
PH0/PH1 could not be configured. 113 matches ZG and gives A-H.
CE/ZG chip.h counts and the family HAVE_* list are corrected in
the same change: CE has no FSMC, the die has TIM6/7/9-14 and
SPI4/5, ZG USART is 4, I2S is 5. FSMC is only bonded on 100/144-pin,
so HAVE_FSMC is selected on VG/ZG and not on CE.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
CONFIG_ESP32S3_TICKLESS hangs forever the first time a task calls a
sleep/timeout with a fractional-second component of roughly 134ms or
more (e.g. usleep(500000)) while another task is also pending a
timeout.
Root cause: NSEC_2_CTICK() computes ((nsec) * CTICK_PER_USEC) /
NSEC_PER_USEC. `nsec` (struct timespec's tv_nsec) is a 32-bit `long`,
and CTICK_PER_USEC is 16 (the S3's systimer runs at 16MHz), so the
multiplication overflows a 32-bit signed int for any tv_nsec at or
above INT32_MAX / 16 (~134,217,728 ns). The overflowed (negative)
result then gets added into up_timer_start()'s `uint64_t cpu_ticks`,
wrapping around to a value near UINT64_MAX. tickless_setcounter()
then programs the systimer alarm that many ticks in the future --
effectively never -- so nxsched_process_timer() is never called and
the waiting task sleeps forever.
Reproduced on real esp32s3-xiao hardware: apps/testing/ostest hung
indefinitely right after starting user_main(), whose first statement
is usleep(500000). Instrumented up_timer_start() to print its inputs
and observed exactly the described overflow (cpu_ticks close to
UINT64_MAX for tv_nsec=510000000). Confirmed root cause is the
concurrent-timeout case specifically: user_main's usleep() alone
works, and ostest_main's own usleep() alone works, but the two
together (matching ostest's actual task_create() + concurrent
usleep() pattern) reproduce the hang every time.
Fix: cast to uint64_t before multiplying in all three *_2_CTICK
macros, forcing 64-bit arithmetic throughout, matching how the
CTICK_2_* (division) macros are already overflow-safe.
Validated on esp32s3-xiao: with the fix, the full ostest suite (built
with CONFIG_ESP32S3_TICKLESS=y) runs past the point it used to hang
and completes end to end.
Note: while testing, ostest's own round-robin test (rr_test) failed
near the end of the run -- the two same-priority SCHED_RR threads did
not appear to interleave under tickless. That looks like a separate,
likely more architectural issue (time-slice preemption needs its own
periodic re-arm, independent of one-shot sleep timeouts) and is not
addressed by this fix; filing separately.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Replace iLD union types and __mfcr/__mtcr intrinsics with uint32_t
and tricore_mfcr/tricore_mtcr. Replace the iLD-specific
to HW full capacity (8 sets / 24 data / 16 code regions).
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
Refactor kflags/uflags into a per-set flags[] array indexed by set
number, and add a cpuset field to filter regions per CPU. Rewrite
mpu_initialize to loop over all protection sets.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
C++ strict mode drops the GNU ", ##__VA_ARGS__" comma elision, so
GET_ARG_COUNT() and REVERSE_ARG() misselect their dispatch entry with
zero varargs. Centralize the empty-argument handling in GET_ARG_COUNT
(via __VA_OPT__ for C++) and make REVERSE_ARG and FOREACH_ARG dispatch
through CONCATENATE(prefix, GET_ARG_COUNT(...)), removing the two
duplicated 33-entry selector lists.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
string(REPLACE) splits on every space, so a flag such as
-I"/path with spaces" becomes several bogus compile options.
Use separate_arguments(UNIX_COMMAND), matching EXTRA_FLAGS.
Signed-off-by: Zhaoqi Xu <lzy00419@outlook.com>
Both files put the body of the relocation switch at the same indent as the
switch braces, so nxstyle reports forty-four errors in each and any patch
whose hunks land near them fails the check job.
Giving the body its level takes the bit diagrams in the comments one column
past the line limit. The rulers say Instr rather than Instructions, which is
enough and is what the same rulers further down already do. A comment that
had no code on its line becomes a sentence of its own, and two that were a
column out are put right.
Whitespace and comments only. Compiled before and after for cortex-m7 and
cortex-m33: the disassembly is identical.
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
mtd_partition(mtd, firstblock, nblocks) takes the partition offset and
size in units of the underlying device "blocks" (geo.blocksize), not
erase blocks. Several board drivers accumulated partoffset and computed
the partition size in erase-block units and passed them straight to
mtd_partition(), so on devices where blocksize != erasesize (W25/SST25:
256B vs 4KB, SAMD5E5 progmem: 512B vs 8KB) every partition came out
erasesize/blocksize (16x) too small and misaligned.
Convert partoffset and partszbytes to geo.blocksize units at the
mtd_partition() call site while keeping the erase-block accumulation.
Affected boards:
- stm32f103-minimum (W25)
- at32f437-mini (W25)
- stm32f429i-disco (SST25F064, enabled in the extflash defconfig)
- metro-m4 (SAMD5E5 progmem)
Also fix pre-existing nxstyle violations in the touched files so the
change passes checkpatch (see CONTRIBUTING.md).
Assisted-by: DeepSeek Harness:deepseek-v4-flash
Signed-off-by: rongbaichuan <rongbaichuan1027@163.com>
Required to run the qemu-intel64 citest/NTFC configuration on CI; the
image only shipped qemu-system-arm and qemu-system-misc.
Signed-off-by: raiden00pl <raiden00@railab.me>
The Tab5 ships in two hardware variants and the board supported only
one of them. The earlier units carry an ILI9881C panel and a GT911
touch controller, the later ones a ST7121/ST7123 panel and a ST7123
touch controller, and the two always come as a pair. On an earlier
unit the panel stays lit but black, and the touch bring-up fails with
"failed to register ST7123: -5".
Add the ILI9881C initialization table, taken from the Espressif BSP,
along with the display timings it needs, which differ from the ST7123
ones in the DPI clock (60 MHz instead of 70 MHz) and in every porch.
The panel identification lives on command page 1 and is read and
logged during bring-up, so the boot log says which panel answered.
Add the GT911 to the touch controller choice. These units have a
pull-up to 3V3 on the touch interrupt line that keeps the controller
from scanning, so the line is driven low instead of being used as an
interrupt, and contacts are picked up when the device is read. The
controller identification is logged the same way.
Split esp32p4_touch.c into one file per controller, which is how the
panels are already handled, and document both variants together with
the I2C scan that tells which one is fitted. The defaults are
unchanged, so an existing configuration still selects the ST7121
panel and the ST7123 touch controller.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Two defects keep the driver from reporting touches on a board that
cannot use the interrupt line.
The register write built two messages joined by I2C_M_NOSTART. That
puts the same bytes on the wire as a single three byte message, but
resuming a transfer without a start condition is optional, and a
controller that does not implement it fails the transfer. On the
ESP32-P4 every write returned -ETIMEDOUT, so the buffer status clear
at 0x814E never reached the controller and gt9xx_read_touch_data()
returned an error for every read. Send the register address and the
value as a single message.
read() returned a full struct touch_sample_s even when the controller
reported no contact, with npoints set to zero. A caller that judges
the read by its return value takes that for valid data: the LVGL
touchscreen driver reads a second sample to decide whether to keep
reading, always gets one, so it sets continue_reading on every pass
and lv_indev_read() never returns. The display then stops refreshing
after the first frame while the touch reads spin. Return -EAGAIN when
there is no contact and the file was opened with O_NONBLOCK, which is
what the touchscreen upper half does in the same situation. A
blocking reader keeps the previous behaviour.
While here, add the blank line after the declaration in gt9xx_poll() that
nxstyle asks for. It predates this change, but the CI runs checkpatch over
every file a commit touches, so it has to go.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Pre-existing violations in this file, reported by checkpatch because the
preceding commit touches it:
nrf53_gpiote.c:185: Missing blank line after declarations
nrf53_gpiote.c:213: Bad alignment
nrf53_gpiote.c:216: Bad alignment
nrf53_gpiote.c:259: Bad right brace alignment
Add the blank line after the declarations in the channel-callback block,
indent the two `break;` statements into their case bodies, and align the
brace closing the per-port `for` loop with its opening at line 209 (it
sat at seven spaces, so neither the loop's eight nor anything else).
Whitespace only — no functional change, brace count unchanged.
Signed-off-by: AlmAck <gluca86@gmail.com>
The driver presents a single channel space of GPIOTE_CHANNELS entries
across the application core's two GPIOTE peripherals, and splits it:
inst = (channel < GPIOTE_PER_CHANNEL) ? 0 : 1;
rchan = (inst == 1) ? channel : (channel - GPIOTE_PER_CHANNEL);
rchan is the channel index within the selected instance, used to build
the per-channel register offsets, so it must be
rchan = channel - GPIOTE_PER_CHANNEL * inst
The ternary has the two arms the other way round: a channel on instance
0 gets rchan = channel - GPIOTE_PER_CHANNEL, which is negative, and a
channel on instance 1 gets an index still offset by a full instance.
The interrupt handler in this same file already applies that mapping in
the opposite direction, converting a per-instance channel back to the
global one:
off = i + GPIOTE_PER_CHANNEL * inst;
so the two were inconsistent, and it is the rchan sites that were wrong.
Per the nRF5340 Product Specification, 'GPIOTE - GPIO tasks and
events', the application core has two GPIOTE instances, GPIOTE0 (secure,
base 0x5000D000) and GPIOTE1 (non-secure, base 0x4002F000), each with
eight channels and its own CONFIG[n] array at offset 0x510 + 4n for
n = 0..7. This matches GPIOTE_PER_CHANNEL == 8, the two base addresses
in hardware/nrf53_memorymap_cpuapp.h, and NRF53_GPIOTE_CONFIG_OFFSET()
in hardware/nrf53_gpiote.h, so rchan is required to be in 0..7 and a
negative value cannot address a CONFIG register.
With a negative rchan the CONFIG register write for a channel on
instance 0 lands below the instance base instead of in CONFIG[n], so the
channel is never configured and its GPIOTE interrupt is never enabled.
On nrf5340-dk this makes the board buttons dead.
Both call sites are corrected.
Signed-off-by: AlmAck <gluca86@gmail.com>
Correct the misspelled up_timer_initialize() and up_initialize()
API names in the tickless OS documentation to match the declarations
in include/nuttx/arch.h.
Signed-off-by: arnavsharma990 <2006arnavsharma@gmail.com>
The XIAO ESP32-S3 Sense's onboard microSD slot (Seeed XIAOML Kit) is
wired to SPI2 through the GPIO matrix: SCK=GPIO7, MOSI=GPIO9,
MISO=GPIO8 (confirmed against espressif/arduino-esp32's
XIAO_ESP32S3/pins_arduino.h) and CS=GPIO21 (confirmed against this
project's own working xiaoml_bench_logger.ino, which tries CS
candidates {21, 3} in that order -- GPIO3 is a documented fallback,
not the real pin; a Seeed wiki page that names GPIO3 as CS turned out
to be wrong and was the initial, unsuccessful attempt here).
Wires up board_sdmmc_spi_initialize() (common esp32s3 board code,
CONFIG_MMCSD_SPI) into this board's bringup, and adds the
esp32s3_spi2_status() callback (SPI_STATUS_PRESENT for SPIDEV_MMCSD(0))
that esp32s3-devkit and other in-tree boards already provide -- the
esp32s3-xiao board had no SPI board file at all before this.
Validated on the bench: CMD0/CMD41/CMD58 handshake succeeds, SD ver2
card identified (SanDisk 32GB, 62333952 sectors), mounts as vfat,
survives umount+remount with a written file intact.
Needed board defconfig additions (not included in this NuttX-tree
commit; see the 61680_FW project repo for the board config that turns
this on):
CONFIG_ESP32S3_SPI2=y
CONFIG_ESP32S3_SPI2_CSPIN=21
CONFIG_ESP32S3_SPI2_CLKPIN=7
CONFIG_ESP32S3_SPI2_MOSIPIN=9
CONFIG_ESP32S3_SPI2_MISOPIN=8
CONFIG_MMCSD=y
CONFIG_NSH_MMCSDSPIPORTNO=2
CONFIG_FS_FAT=y
CONFIG_FAT_LFN=y
CONFIG_FAT_LCNAMES=y
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: Felipe Moura <mouraf@fiteclabs.org.br>
bt_conn_send() splits an outgoing L2CAP PDU into HCI ACL fragments no
larger than g_btdev.le_mtu, the controller's HCI ACL data packet length.
The first fragment caps its length correctly:
len = remaining;
if (len > g_btdev.le_mtu)
{
len = g_btdev.le_mtu;
}
The continuation loop below uses '<' instead of '>', so a continuation
shorter than le_mtu has its length raised to le_mtu rather than left
alone. Both len and remaining are uint16_t, which turns a wrong length
into an underflow:
With le_mtu 251 and a 300-byte PDU, the first fragment takes 251 bytes
and leaves remaining == 49. The loop then raises len from 49 to 251, so
memcpy(bt_buf_extend(buf, len), ptr, len);
reads 202 bytes past the end of the source, and
remaining -= len;
evaluates 49 - 251 as a uint16_t, wrapping to 65334. On the next
iteration len is 65334, which is not less than le_mtu, so it survives
the cap. bt_buf_extend() carries only a DEBUGASSERT on tailroom, so
with assertions disabled it adds 65334 to buf->len and returns, and the
memcpy writes 64 KB into a pooled buffer sized for a few hundred bytes.
Only the last fragment of a multi-fragment PDU is normally shorter than
le_mtu, so the first fragmented transmission triggers it.
Signed-off-by: AlmAck <gluca86@gmail.com>
STM32_NGPIO_PORTS is (N+15)>>4. 81 (the real pin count) yields six
ports A-F, so PH0/PH1 cannot be configured. 113 matches the F40x
100-pin entries and gives A-H.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
board_buttons() loops over the four buttons but read the GPIO of
g_buttons[BUTTON_BTN1] on every iteration, so all four bits of the
returned set reflected the state of button 1 alone.
Matches the equivalent loop in nrf52840-dk's nrf52_buttons.c.
Signed-off-by: AlmAck <gluca86@gmail.com>
Adopt the zbus message bus on the linum-stm32h753bi (first adopter
board):
- scripts/flash.ld: include the iterable sections common fragments
(2 lines: common-rom.ld inside .text, common-ram.ld inside .data).
- configs/zbus/defconfig: board configuration enabling zbus with all
observer types, the zbus example and its cmocka test suite
(./tools/configure.sh linum-stm32h753bi:zbus).
- Board documentation: describe the new configuration.
Validated on hardware: the 16-test cmocka suite passes twice in the
same boot and the zbus example produces the expected output.
Assisted-by: Claude Code
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
NuttX-side support for the zbus message bus port (apps/system/zbus in
nuttx-apps), built on the link-time iterable sections infrastructure
added in a companion PR:
- include/nuttx/linker/common-rom.ld and common-insert.ld: register the
zbus channel, observer and channel observation iterable sections
(ITERABLE_SECTION blocks guarded by CONFIG_ZBUS, no-op otherwise) for
the include and the zero-touch INSERT modes respectively;
common-ram.ld: note that zbus needs no RAM sections.
- Documentation/applications/system/zbus: Sphinx documentation for the
zbus application, with the upstream Zephyr diagrams (Apache-2.0).
- .codespellrc: skip the reused zbus SVG diagrams (embedded base64
raster data trips the spell checker).
Assisted-by: Claude Code
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
set_sporadic_param() tested rtcb (the calling task) instead of tcb (the
task being modified). A cross-task sched_setparam() therefore either
skipped the sporadic parameter update entirely or, when the calling
task was itself sporadic, reset a task that had no sporadic state.
Use tcb consistently and drop the now-unused rtcb argument.
Signed-off-by: yushuailong <yyyusl@qq.com>
The policy flag bits were cleared before the switch statement, so the
checks testing whether the task was previously SCHED_SPORADIC could
never be true. As a result nxsched_stop_sporadic() was never called
when a sporadic task switched to SCHED_FIFO/SCHED_RR, leaking the
sporadic state, and a sporadic-to-sporadic reconfiguration ran
initialize instead of reset.
Clear the policy flag bits only after the previous policy has been
evaluated, right before the new policy bits are set.
Signed-off-by: yushuailong <yyyusl@qq.com>
Fixed all the issues reported by checkpatch.sh in stm32_eth_m3m4_v1.c,
stm32f7/stm32_ethernet.c, stm32h5/stm32_ethernet.c, stm32h7/stm32_ethernet.c
Signed-off-by: alexcekay <alexander@auterion.com>
The STM32 Ethernet MAC drivers hard-code a 60-second TX watchdog
timeout. While this is a reasonable general default, certain board
designs and use-cases require a shorter or longer value.
Introduce CONFIG_STM32_ETH_TXTIMEOUT via the shared Kconfig.eth
with a #ifndef fallback. The default is kept at 60 seconds
to preserve existing behavior.
Assisted-by: Claude Code:claude-sonnet-5
Signed-off-by: alexcekay <alexander@auterion.com>
nxsched_stop_sporadic() freed tcb->sporadic but left
TCB_FLAG_SCHED_SPORADIC set in tcb->flags. On thread exit,
nxtask_recover() calls nxsched_stop_sporadic() and the final context
switch in up_exit() then sees the stale SPORADIC policy flag and calls
nxsched_suspend_sporadic() on a TCB whose sporadic state is already
freed, tripping DEBUGASSERT(tcb->sporadic) and hanging the system
(reproduced by ostest sporadic_test on sim, present on master).
Clear the policy bits inside nxsched_stop_sporadic() so every caller
leaves the TCB in a consistent state.
Signed-off-by: yushuailong <yyyusl@qq.com>
Adds a dedicated page (matching the lsm6dso32 one, the closest
register-compatible driver already documented) instead of a plain list
entry: chip description, registration examples for both polling and
interrupt-driven mode -- including the single-shared-INT-pin
config_s/attach() shape this driver actually uses, unlike sensors that
need one interrupt pin per sub-sensor -- and the two custom ioctls
(SNIOC_WHO_AM_I, SNIOC_SETFULLSCALE) with their argument units.
Requested in review on this PR.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
No driver exists for this exact chip. lsm6dsl.c is the closest
register-compatible match but is the deprecated legacy char-device
style; lsm6dso32_uorb.c is the closest uORB-style match but is for a
different chip variant. The new driver borrows lsm6dso32_uorb.c's
structure (dual sensor_lowerhalf_s, raw I2C_TRANSFER helpers) and
lsm6dsl.h's register map -- fixing a bug in the header it was ported
from along the way: LSM6DSL_FIFO_CTRL2_SHIFT is defined as 255 instead
of 0.
Delivery mode is chosen the same way mpu6050 does: kthread polling by
default, or interrupt-driven if the board supplies attach(). Unlike
the earlier lsm6dso32-style design this went through first -- one INT
pin and one activate()/interrupt path per sub-sensor -- the shipped
version uses a single shared INT pin for both, mirroring mpu6050's own
one-handler-one-worker design (#19601) instead. The two-independent-
paths version worked for accel alone but was intermittently broken for
gyro: activate() sometimes never actually turned CTRL2_G on even
though the interrupt-enable bit was written correctly, and other times
the whole console hung -- a real race, never conclusively root-caused
on a serial console with no JTAG available. The LSM6DS3TR-C supports
OR'ing both DRDY_XL and DRDY_G onto one pin via independent enable
bits in that pin's INTn_CTRL register, so there was no need for two
paths in the first place: one ISR times the burst, one HPWORK worker
reads OUT_TEMP_L..OUTZ_H_A (14 contiguous bytes covering temp, gyro
and accel in one I2C transaction) and pushes whichever topic(s) are
currently subscribed. activate() now just flips each sub-sensor's own
bit in the shared register instead of running its own attach.
On the XIAO ESP32-S3 with Seeed's IMU Breakout Board, INT1/INT2 route
to GPIO3/GPIO4 (confirmed from the breakout board's schematic, not
guessed). Only INT1/GPIO3 is wired up, since one pin is now enough;
GPIO4/INT2 is documented as available but unused.
Also: CTRL1_XL's FS_XL bits were never actually written to match the
driver's own software default (4g) -- registration set the in-memory
value but the chip stayed at its 2g reset default until a caller
issued an explicit SNIOC_SETFULLSCALE. register() now writes it.
Validated on the bench, both modes, reproduced across multiple fresh
reboots: WHO_AM_I reads 0x6a, sensor_accel0/sensor_gyro0 stream
continuously. Interrupt mode delivers ~300 samples of each per 6s
window with shared timestamps down to the microsecond between the two
topics per event, confirming both come from the same burst read.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Fixes several bugs in EDID parsing and consolidates syslog output in
videomode_dump to prevent broken lines.
Specific changes include:
- Corrected bitwise masking for _HACT_HI (0xf0) and _HBLK_HI (0x0f)
to properly extract the upper bits of horizontal active and blanking
timings.
- Multiplied raw EDID pixel clock by 10 to convert it into kHz, matching
the expectation of the videomode struct dotclock field.
- Combined fragmented syslog calls in videomode_dump into a single line
to prevent unwanted newlines from splitting the output across multiple logs.
Signed-off-by: Lwazi Dube <lwazeh@gmail.com>
This commit introduces EDID reading and parsing to the JZ4780 display
driver, replacing hardcoded resolution limits with dynamic mode selection
based on the connected display's capabilities.
Specific changes include:
- Implemented I2C DDC master communication for the HDMI controller to
read EDID blocks from monitors.
- Added dynamic mode selection to calculate bandwidth and pick the best
supported resolution, prioritizing the EDID preferred mode.
- Dynamically allocated framebuffer bounds (g_planeinfo and g_videoinfo)
based on parsed EDID dimensions.
- Configured GPIO pin multiplexing for HDMI power, DDC, and control pins
(POWER_EN, CEC, SCL, SDA) to enable display power and communication
on the CI20 board.
Signed-off-by: Lwazi Dube <lwazeh@gmail.com>
