This restores the entrypoint switch from commit
7cc6707a76 ("boards/esp32s3-xiao: switch
defconfigs to nxinit entrypoint"), reverted in 76b90e02cbe4967193
b620abcb1efb9f6b3f8f5b after a real-hardware regression report on
Seeed XIAO ESP32-S3 (board hangs, no USB console), and fixes the
actual root cause this time instead of just reverting it.
Root cause: the shared boards/xtensa/esp32s3 init.rc starts the
interactive console as a plain "sh", which, unlike nsh_main's
nsh_consolemain(), never registers/connects the CDC-ACM gadget this
board uses as its console (CONFIG_CDCACM_CONSOLE=y, no
CONFIG_DEV_CONSOLE). Restoring the previous commit's entrypoint switch
on its own is therefore not sufficient - it would just reintroduce the
same regression, so that commit is folded into this one rather than
kept as a separate, individually broken step.
Fix, using the "console" service option added to nxinit by a companion
apps change:
- init.rc: bring up the console gadget once, unconditionally, before
any service starts, via "exec -- sercon" (apps/system/cdcacm already
implements exactly this and depends on neither nxinit nor nsh); flag
the "console" service with the new "console" option so its stdio is
connected to the (now registered) gadget device.
- esp32s3-xiao's usbnsh/combo defconfigs: add CONFIG_SYSTEM_CDCACM=y so
sercon is actually built in. Verified with "make savedefconfig"
against both defconfigs (byte-identical, no manual edits beyond the
generated diff).
Verified end to end on real Seeed XIAO ESP32-S3 Sense hardware
(usbnsh): after this change the board enumerates its NuttX CDC-ACM
gadget on a normal reset and boots to an interactive nsh session
spawned by nxinit ("ps" shows init_main as PID 2, parent of "sh").
Assisted-by: Kiro:claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
The in-tree esp32s3-xiao board bringup never wires up Wi-Fi at all --
unlike esp32s3-devkit/esp32s3-eye, it has no
`#ifdef CONFIG_ESPRESSIF_WIFI` include of esp32s3_board_wlan.h and no
call to board_wlan_init(). Add both, mirroring those boards' pattern
and placement exactly.
On its own this is not enough for a board that also uses CONFIG_PM:
Wi-Fi's PHY/RF calibration inside board_wlan_init() cannot tolerate
the clock gating of PM_STANDBY (light sleep). If the idle task enters
light sleep while phy_init's calibration is still running -- which the
greedy governor is free to do the moment the CPU goes idle during
driver init -- the calibration hangs forever waiting on a clock that
just stopped. Confirmed on real XIAO ESP32-S3 hardware: with
CONFIG_PM + CONFIG_ESPRESSIF_WIFI both enabled and no guard, boot got
stuck 100% of the time right after the "net80211 rom version" line,
before phy_init ever printed, and never reached NSH -- reproducible
across repeated flashes, 50s+ waits, not even responding to a UART
wakeup keypress (a genuine hang, not quiet sleep).
Fixed by holding a stronger PM lock than PM_STANDBY for the duration
of board_wlan_init(): pm_stay(PM_IDLE_DOMAIN, PM_IDLE) blocks
PM_STANDBY/PM_SLEEP while still allowing normal CPU idle, and
pm_relax() releases it immediately after, restoring whatever floor the
board's own PM policy holds otherwise. Confirmed fixed on the same
hardware: boots clean to NSH with Wi-Fi + PM enabled together, `ps`
shows the wifi/netdev-wlan0 kernel threads running, and `wapi scan`/
`ifup wlan0` work normally.
esp32c3-devkit and esp32c6-devkit also combine CONFIG_PM with Wi-Fi,
but don't need this guard today: both call board_wlan_init() well
before esp_pmconfigure() (which is what actually arms the PM governor)
runs near the end of bringup, so PM isn't active yet during their
Wi-Fi init. This board's PM handling begins earlier in bringup, so the
two can race here.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-sonnet-5
A C++ module with a static object does not link. GCC registers each such
object's destructor with __cxa_atexit(dtor, obj, &__dso_handle), and
__dso_handle comes from crtbegin, which a module does not link:
hello++3.cxx:119: undefined reference to `__dso_handle'
It is reachable today with CONFIG_PIC, where a module is linked as an
executable and the symbol has to resolve. Without it the link is
relocatable, the symbol stays undefined and nothing complains until
something makes it resolve.
-fno-use-cxa-atexit registers the destructors with atexit() instead, which
puts them in .fini_array. That is also where libelf_uninit() looks for them
when the module is unloaded, so the flag that makes the link work is also
the flag that makes the destructors run.
The option goes wherever CXXELFFLAGS is defined, which is the architecture
Toolchain.defs and the boards that reassign it. The toolchains that are not
GCC or Clang are left alone: ceva, tricore, z16 and the z80 family.
The CMake build sets it once, next to where the architecture elf.cmake is
included. A generator expression keeps it off the C compiles, because the
option is valid for C++ alone and GCC warns about it otherwise, and the
compiler id gates it so that a toolchain which is neither GCC nor Clang does
not see it. It cannot go in the toolchain file itself: CMake reads that file
again inside try_compile, in a project that has not included the NuttX
extensions, so the call is an unknown command there.
Reproduced with apps/examples/elf on mps3-an547:picostest with CONFIG_PIC
enabled: hello++3 fails to link before and links after.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
nuttx-apps PR #3763 adds "default 4096 if LIBC_PRINT_EXTENSION" to
CONFIG_UORB_STACKSIZE. Both lckfb-szpi-esp32s3/qmi8658 and
esp32s3-ws-lcd128/imu-qmi8658 already set CONFIG_UORB_STACKSIZE=4096
explicitly, which now matches the new default and makes the line
redundant, so savedefconfig drops it -- causing the CI defconfig-sync
check (testbuild.sh -R) to flag these files as stale and fail the
xtensa-03 job.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-sonnet-5
This reverts commit 7cc6707a76.
Felipe Moura de Oliveira reported on the dev mailing list that this
commit hangs boot on real Seeed XIAO ESP32-S3 Sense hardware (chip
rev v0.2): both defconfigs (combo, usbnsh) never reach nx_start after
a normal reset (no console output, no USB enumeration; only ROM
download mode via the BOOT strap pin responds). JTAG (OpenOCD + GDB)
shows the core statically stuck inside the chip boot ROM address
range (0x40034000-0x40048000), with nx_start never reached at its
own address (0x42011068) in that build. Reverting only this commits
defconfig changes on top of current master fixes the boot.
Local static analysis (before/after build product comparison via
esptool image_info and readelf -S) ruled out image size/segment
count as the cause: both binaries have 3 segments, identical IRAM
segment address/size byte-for-byte, and the flash-mapped code/data
growth from this change is ~14.7KB total against an 8MB flash
budget. No hardware matching the reported board was available
locally to reproduce or bisect further; reverting to unblock master
per the reporters request while root cause is investigated with
real hardware access.
Reference: https://www.mail-archive.com/dev@nuttx.apache.org/msg15063.html
Assisted-by: Kiro:claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.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>
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>
The esp32s3-devkit:usbmsc config uses CONFIG_ESPRESSIF_SIMPLE_BOOT, so
the image is packaged with "esptool elf2image --ram-only-header". With
esptool v5.2.0, that path asserts that each flash segment satisfies
(f.tell() + 8 + BOOTLOADER_FLASH_OFFSET) % IROM_ALIGN
== segment.addr % IROM_ALIGN
When .flash.text lands right on a 64 KB (IROM_ALIGN) boundary the
assertion cannot be satisfied and elf2image fails with AssertionError,
even though NuttX itself links cleanly.
usbmsc is a plain C test and does not need the C++ runtime. Disabling
CONFIG_HAVE_CXX / CONFIG_HAVE_CXXINITIALIZE moves .flash.text off the
IROM_ALIGN boundary so the SIMPLE_BOOT image can be generated, without
changing the boot mode or the test's intent.
Signed-off-by: yukangzhi <yukangzhi@xiaomi.com>
The link support is no longer limited to the pseudo file system and now
covers both soft (symbolic) links and hard links across the VFS. Rename
the configuration option PSEUDOFS_SOFTLINKS to the more accurate FS_LINKS
and update all references in the source, headers, Kconfig, documentation
and board defconfigs accordingly.
This is a configuration rename; any out-of-tree defconfig that still
selects PSEUDOFS_SOFTLINKS must be updated to FS_LINKS.
Signed-off-by: zhengyu16 <zhengyu16@xiaomi.com>
Switch all esp32s3-8048S043 defconfigs (gpio, i2c, lcd, nsh, sdmmc, spi,
touchscreen) from nsh_main to nxinit (init_main) as the system init entry
point, matching the lckfb-szpi-esp32s3 board's existing nxinit configs
(see 73c949c87e) for consistency across esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified all 7 defconfigs (gpio, i2c, lcd, nsh, sdmmc, spi,
touchscreen) build cleanly with make. Runtime behavior (init_main
spawning nsh as a console service) was confirmed on lckfb-szpi-esp32s3
hardware, which shares the same nxinit/init.rc mechanism; this board
has no hardware attached for a flash/boot pass in this session, so the
build-verified defconfigs are the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-xiao defconfigs (combo, usbnsh) from nsh_main to
nxinit (init_main) as the system init entry point, matching the
lckfb-szpi-esp32s3 board's existing nxinit configs (see 73c949c87e)
for consistency across esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified both defconfigs (combo, usbnsh) build cleanly with make.
Runtime behavior (init_main spawning nsh as a console service) was
confirmed on lckfb-szpi-esp32s3 hardware, which shares the same
nxinit/init.rc mechanism; this board has no hardware attached for a
flash/boot pass in this session, so the build-verified defconfigs are
the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-ws-lcd128 defconfigs still on nsh_main
(imu-qmi8658, nsh, ostest, watchdog) to nxinit (init_main) as the
system init entry point, matching the lckfb-szpi-esp32s3 board's
existing nxinit configs (see 73c949c87e) for consistency across
esp32s3 boards. This board's coremark, notouch-lvgl and touch-lvgl
defconfigs use other custom entrypoints and are unaffected.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified all 4 defconfigs (imu-qmi8658, nsh, ostest, watchdog) build
cleanly with make. Runtime behavior (init_main spawning nsh as a
console service) was confirmed on lckfb-szpi-esp32s3 hardware, which
shares the same nxinit/init.rc mechanism; this board has no hardware
attached for a flash/boot pass in this session, so the build-verified
defconfigs are the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch both esp32s3-touch-lcd7 defconfigs (lcd, usbnsh) from nsh_main
to nxinit (init_main) as the system init entry point, matching the
lckfb-szpi-esp32s3 board's existing nxinit configs (see 73c949c87e)
for consistency across esp32s3 boards.
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added, needed to ship init.rc via the board's
ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified both defconfigs build cleanly with make. Runtime
behavior (init_main spawning nsh as a console service) was confirmed
on lckfb-szpi-esp32s3 hardware, which shares the same nxinit/init.rc
mechanism; this board has no hardware attached for a flash/boot pass
in this session, so the build-verified defconfigs are the extent of
local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-meadow defconfigs (nsh, usbnsh) from nsh_main to
nxinit (init_main) as the system init entry point, matching the
lckfb-szpi-esp32s3 board's existing nxinit configs (see 73c949c87e)
for consistency across esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified both defconfigs (nsh, usbnsh) build cleanly with make.
Runtime behavior (init_main spawning nsh as a console service) was
confirmed on lckfb-szpi-esp32s3 hardware, which shares the same
nxinit/init.rc mechanism; this board has no hardware attached for a
flash/boot pass in this session, so the build-verified defconfigs are
the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-m5-cardputer defconfigs (fb, lvgl, lvglterm, nsh,
sdcard, softap, wifi) from nsh_main to nxinit (init_main) as the
system init entry point, matching the lckfb-szpi-esp32s3 board's
existing nxinit configs (see 73c949c87e) for consistency across
esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified all 7 defconfigs (fb, lvgl, lvglterm, nsh, sdcard, softap,
wifi) build cleanly with make. Runtime behavior (init_main spawning
nsh as a console service) was confirmed on lckfb-szpi-esp32s3
hardware, which shares the same nxinit/init.rc mechanism; this board
has no hardware attached for a flash/boot pass in this session, so
the build-verified defconfigs are the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch the esp32s3-lhcbit usbnsh defconfig from nsh_main to nxinit
(init_main) as the system init entry point, matching the
lckfb-szpi-esp32s3 board's existing nxinit configs (see 73c949c87e)
for consistency across esp32s3 boards.
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added, needed to ship init.rc via the board's
ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified the usbnsh defconfig builds cleanly with make. Runtime
behavior (init_main spawning nsh as a console service) was confirmed
on lckfb-szpi-esp32s3 hardware, which shares the same nxinit/init.rc
mechanism; this board has no hardware attached for a flash/boot pass
in this session, so the build-verified defconfig is the extent of
local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-lcd-ev defconfigs (audio, buttons, lcd, lvgl, nsh,
ws2812) from nsh_main to nxinit (init_main) as the system init entry
point, matching the lckfb-szpi-esp32s3 board's existing nxinit configs
(see 73c949c87e) for consistency across esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified all 6 defconfigs (audio, buttons, lcd, lvgl, nsh, ws2812)
build cleanly with make. Runtime behavior (init_main spawning nsh as
a console service) was confirmed on lckfb-szpi-esp32s3 hardware, which
shares the same nxinit/init.rc mechanism; this board has no hardware
attached for a flash/boot pass in this session, so the build-verified
defconfigs are the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-korvo-2 defconfigs (audio, nsh, rtptools, sdmmc)
from nsh_main to nxinit (init_main) as the system init entry point,
matching the lckfb-szpi-esp32s3 board's existing nxinit configs (see
73c949c87e) for consistency across esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified all 4 defconfigs (audio, nsh, rtptools, sdmmc) build cleanly
with make. Runtime behavior (init_main spawning nsh as a console
service) was confirmed on lckfb-szpi-esp32s3 hardware, which shares
the same nxinit/init.rc mechanism; this board has no hardware attached
for a flash/boot pass in this session, so the build-verified
defconfigs are the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-eye defconfigs (gpio, i2c, lcd, nsh, usbnsh, wifi)
from nsh_main to nxinit (init_main) as the system init entry point,
matching the lckfb-szpi-esp32s3 board's existing nxinit configs (see
73c949c87e) for consistency across esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified all 6 defconfigs (gpio, i2c, lcd, nsh, usbnsh, wifi) build
cleanly with make. Runtime behavior (init_main spawning nsh as a
console service) was confirmed on lckfb-szpi-esp32s3 hardware, which
shares the same nxinit/init.rc mechanism; this board has no hardware
attached for a flash/boot pass in this session, so the build-verified
defconfigs are the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-devkit defconfigs still on nsh_main (adc, audio,
ble, blewifi, buttons, capture, crypto, cxx, efuse, elf, eth_lan9250,
fastboot, fastboot_tcp, gpio, i2c, i2schar, knsh, ksta_softap, mbedtls,
mcuboot_nsh, mcuboot_update_agent, motor, nsh, nxlooper, oneshot,
ostest, pm, psram_octal, psram_quad, psram_usrheap, pwm, python,
qemu_debug, qemu_openeth, qemu_toywasm, qencoder, random, rmt, romfs,
rtc, sdm, sdmmc, sdmmc_spi, smp, sotest, spi, spiflash, spislv,
sta_softap, stack, temperature_sensor, tickless, timer, toywasm, twai,
ulp, usb_device, usbnsh, watchdog, wifi) to nxinit (init_main) as the
system init entry point, matching this board's adb/txtable configs
that already use nxinit, and matching the lckfb-szpi-esp32s3 board
(see 73c949c87e) for consistency across esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
esp32s3-devkit:stack was the only defconfig that already set this
option (at 4096); it is raised to 8192 with the rest.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init, matching this board's existing adb/txtable configs.
Verified 59 of the 60 changed defconfigs build cleanly with make.
esp32s3-devkit:qemu_openeth fails to link on this host both before
and after this change (MERGEBIN error: missing ESPTOOL_BINDIR, a
pre-existing local build-invocation issue unrelated to this patch).
esp32s3-devkit:stack segfaults the linker on this host both before
and after this change (pre-existing toolchain issue on this host,
unrelated to this patch). esp32s3-devkit:ulp fails at context/rule
generation on this host due to a missing local RISC-V ULP toolchain
setup, also unrelated to this patch.
Runtime behavior (init_main spawning nsh as a console service) was
confirmed on lckfb-szpi-esp32s3 hardware, which shares the same
nxinit/init.rc mechanism; this board has no hardware attached for a
flash/boot pass in this session, so the build-verified defconfigs are
the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all esp32s3-box defconfigs (buttons, lvgl, lvgl-3, nsh,
touchscreen) from nsh_main to nxinit (init_main) as the system init
entry point, matching the lckfb-szpi-esp32s3 board's existing nxinit
configs (see 73c949c87e) for consistency across esp32s3 boards.
For each defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE set to 8192. Measured on lckfb-szpi-esp32s3
with CONFIG_STACK_COLORATION=y on the worst case available: a config
whose init.rc starts two services (console sh + adbd). At the 2048
Kconfig default the board panics at runtime (xtensa_user_panic, task
"sh"); at 4096 init_main reaches FILLED=99.5%, i.e. no headroom; at
8192 it settles at USED=4336 (53.6%). A single-service config only
fills 46.9% of a 3072-byte init stack, so 8192 is deliberately
uniform rather than minimal: it covers the two-service worst case
with roughly 2x margin and keeps every defconfig off the 2048
default, where the init stack overflows and clobbers the global
inode/mount tree - the procfs mount disappears, "ls /" crashes in
read_pseudodir and "ps" reports "/proc not mounted".
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS,
which depends on CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so the shell
workload is carried by its own stack rather than the init stack.
Without this it falls back to CONFIG_DEFAULT_TASK_STACKSIZE (2048
unless the defconfig overrides it) and crashes in getumask while
running "ps", too small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init.
Verified all 5 defconfigs (buttons, lvgl, lvgl-3, nsh, touchscreen)
build cleanly with make. Runtime behavior (init_main spawning nsh as
a console service) was confirmed on lckfb-szpi-esp32s3 hardware, which
shares the same nxinit/init.rc mechanism; this board has no hardware
attached for a flash/boot pass in this session, so the build-verified
defconfigs are the extent of local testing here.
Assisted-by: Kiro:claude-sonnet-5
Assisted-by: Kiro:claude-opus-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Switch all lckfb-szpi-esp32s3 defconfigs from nsh_main to nxinit
(init_main) as the system init entry point, for consistency across
the whole board (adb and txtable already used nxinit, see
73c949c87e).
For each defconfig (adb, camera, es7210, fastboot, fastboot_tcp,
gc0308, gpio, lcd, lvgl, nsh, pca9557, psram, pwm, qmi8658, sdmmc,
usb_device, uvc, vncviewer):
- CONFIG_INIT_ENTRYPOINT="nsh_main" -> "init_main"
- CONFIG_INIT_STACKSIZE raised to 8192. The default init and nsh
stacks overflow at runtime on this target: init_main overflows a
smaller stack (observed 100% usage with a corrupted task name),
clobbering the global inode/mount tree so the procfs mount
installed by board bringup disappears; "ls /" then crashes in
read_pseudodir and "ps" reports "/proc not mounted". Raising
CONFIG_INIT_STACKSIZE to 8192 drops init_main to about 61% usage
on hardware, and /proc stays mounted.
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies
(CONFIG_EXPERIMENTAL, CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS
which in turn selects CONFIG_SCHED_HAVE_PARENT)
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: the nsh console service
launched by init.rc also needs a larger stack, otherwise it
crashes in getumask while running "ps" because its stack is too
small to reach the procfs read path.
- ETC_ROMFS/FS_ROMFS added where missing, needed to ship init.rc via
the board's ROMFS
nsh continues to run as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc), not as the
top-level init, matching the adb/txtable configs.
Verified all 20 defconfigs (adb, camera, es7210, fastboot,
fastboot_tcp, fastboot_usb, gc0308, gpio, lcd, lvgl, nsh, pca9557,
psram, pwm, qmi8658, sdmmc, txtable, usb_device, uvc, vncviewer) build
cleanly with `make`. Flashed nsh and es7210 to hardware:
- nsh: UART0 console reachable, "ps" shows init_main (PID 2) as the
parent of nsh's "sh" (PID 3).
- es7210: adb reachable, "ps" shows init_main (PID 4) as the parent of
both "sh" (PID 5) and "adbd" (PID 6).
Assisted-by: Kiro:claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Adds PSEUDOTERM as selected Kconfig option on lvglterm demo defconfigs.
Required after changes on lvgl_term example app.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
esp32s3_bringup.c still guards on CONFIG_ESP32S3_RT_TIMER, includes
"esp32s3_rt_timer.h" and calls esp32s3_rt_timer_init(). None of those
exist any more: c17e16eaed ("xtensa/espressif: Update common-source
integration for Xtensa devices") deleted the chip-specific RT timer and
replaced it with the common-source HR Timer, and updated every other
esp32s3 board's bringup to CONFIG_ESPRESSIF_HR_TIMER /
"espressif/esp_hr_timer.h" / esp_hr_timer_init(). This board was missed.
The stale guard is not dead code: ESPRESSIF_WIRELESS selects
ESP32S3_RT_TIMER (which survives only as a deprecated alias that selects
ESPRESSIF_HR_TIMER), so enabling Wi-Fi on this board turns the guard on and
the build fails outright:
board/esp32s3_bringup.c:61:12: fatal error: esp32s3_rt_timer.h:
No such file or directory
No esp32s3-ws-lcd128 defconfig enables Wi-Fi, which is why CI has not
caught it.
Switch to the same guard, include and initializer the other esp32s3 boards
use. No functional change for the existing defconfigs: they leave both
ESP32S3_RT_TIMER and ESPRESSIF_HR_TIMER unset, so the block stays compiled
out.
Verified with esp32s3-ws-lcd128:nsh plus CONFIG_ESPRESSIF_WIFI=y (and the
Wi-Fi prerequisites the in-tree wifi defconfigs set: SCHED_LPWORK,
DRIVERS_WIRELESS/DRIVERS_IEEE80211, NETDEV_WIRELESS_IOCTL, IOB_NCHAINS,
TLS_TASK_NELEM, TIMER): the fatal error above before the change, a clean
build and image after it, with no other change to the configuration.
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
Assisted-by: Claude Opus 5 (Claude Code)
A protected build on the ESP32 could only use the legacy IDF image format.
Kconfig allowed simple boot to be selected with BUILD_PROTECTED, because the
legacy format is only a default and not a select, but the result did not link
and then did not boot.
Simple boot has no second-stage bootloader. __start() maps the flash itself,
so everything it reaches must already be in RAM. kernel-space.ld pinned none
of it, and it did not place esp32_start at all, so the entry point went to the
flash the code was about to map. The chip loaded the RAM segments, jumped to
0x400d0ba4 and took an IllegalInstruction on the first instruction.
So this pins the bootloader, flash, ROM, clock and log objects that
bootloader_init() and map_rom_segments() reach, along with esp32_start itself,
and defines the six _image_* symbols that __start() needs. All of it is
behind CONFIG_ESPRESSIF_SIMPLE_BOOT, so a legacy build gets the same IRAM it
had before.
kernel-space.ld also had no `#include <nuttx/config.h>'. It held no
conditionals until now, so nothing showed the omission: the new blocks
compiled away silently and the link failed as if the file had not been
changed.
The default is unchanged. A protected build still selects the legacy format
unless the user clears CONFIG_ESP32_APP_FORMAT_LEGACY.
Verified on an ESP32-DevKitC V4, ESP32-D0WD-V3 revision 3.1, with
esp32-devkitc:knsh and the legacy format turned off. The kernel flashes at
0x1000 and the user image at 0x90000, with no bootloader and no partition
table. It maps seven segments, reaches NSH, and runs ostest to the same point
as the legacy build.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
BUILD_PROTECTED defaults ESP32S3_APP_FORMAT_LEGACY to y, so a protected build
has always needed the ESP-IDF second-stage bootloader. Nothing about the
protected layout requires it: the kernel and user images are described
entirely by ESP32S3_KERNEL_OFFSET, ESP32S3_KERNEL_IMAGE_SIZE and
ESP32S3_KERNEL_RAM_SIZE, and esp32s3_userspace() maps the user image itself.
Three obstacles stood in the way.
Those three symbols were gated on ESP32S3_APP_FORMAT_LEGACY, but
protected_memory.ld needs all of them for KIROM, KDROM, UIROM, UDROM, KDRAM
and UDRAM. Without them the region lengths underflow to 2**64-1 and the
kernel/user RAM split lands nowhere, which the hardware reports as a DRAM0
PMS monitor violation once the first user process runs. The offset becomes
0x0 for simple boot, where the image is flashed at the start of the device.
protected_memory.ld had no case for a 32 MB part, so FLASH_SIZE was
undefined there and ROM, UIROM and UDROM underflowed the same way.
flat_memory.ld has had the case all along.
kernel-space.ld defined none of the symbols simple boot needs
(_image_irom_*, _image_drom_*, _bss_*), and kept none of the early code
resident. __start() runs bootloader_init() and map_rom_segments() before any
flash mapping exists, so everything they reach has to be in RAM -- including
map_rom_segments() itself, which unmaps the MMU it is running from, and
nuttx_enter_critical(), reached from rtc_clk_init() by way of regi2c. These
mirror what esp32s3_sections.ld already does for the flat build.
Verified on an ESP32-S3-WROOM-2 (32 MB octal flash), esp32s3-devkit:knsh with
FLASH_MODE_OCT: boots to NSH and runs ostest, where it reaches the same
timedmutex abort as every other target. The legacy path is untouched.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
A full ostest run never reached the end on esp32-devkitc:knsh. It stopped in
the barrier test:
barrier_test: ERROR thread 6 create, status=12
ostest_main: Exiting with status 256
The cause is the interaction of two settings that are each reasonable on their
own. CONFIG_TLS_ALIGNED is set and CONFIG_TLS_LOG2_MAXSTACK is 13, so every
pthread stack must start on an 8 KiB boundary. The barrier threads take the
2 KiB default stack, so each one occupies an 8 KiB aligned slot. Eight of them
do not fit the 96 KiB user heap of a protected build once the tests before them
have fragmented it, and up_create_stack() fails:
up_create_stack: ERROR: Failed to allocate stack, size 2048
The flat build has the same two settings and passes, because its heap is
320 KiB against 96 KiB here.
So this lowers the barrier thread count for this configuration only. Four
threads still test a barrier, and they leave margin: six was the most that
ever started, so six would pass with none.
The user heap cannot grow far. User data has to sit in the MMU governed window
of SRAM2, which is 128 KiB in total, and the kernel holds the first 32 KiB of
it.
Verified on an ESP32-DevKitC V4, ESP32-D0WD-V3 revision 3.1. All four threads
reach the barrier and ostest reports "Exiting with status 0".
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
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>
The terminal no longer has separate matrix and USB input sources: it
reads any keyboard through one path.
Left as it was, the unknown symbol would have been dropped and the
configuration would have fallen back to the touch variant, which is the
default. This board has no touchscreen, so the terminal would have had
no input at all and the build would have said nothing.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The Fn cursor cluster was reported as ordinary key presses carrying 0x80
to 0x83, chosen to sit above the printable range so that an application
could tell them apart from characters. That is the collision this work
exists to remove: a key that produces no character is a special key, and
the event type is what says so.
Report them as KEYBOARD_SPECPRESS carrying KEYCODE_UP and friends, which
is what every other keyboard does and what the applications now expect.
The character tables are untouched, so the layout and the shift map behave
exactly as before. Only the four Fn cursor keys change.
Not tested on hardware: the board was not available. It builds, and the
change is confined to the two lines that pick the event type.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Enable the OTG FS host on the Linum board so an external USB HID keyboard
can be used: configure the USB VBUS, power-switch and over-current GPIOs
at board bring-up (the power switch on PI12 is active low) and start the
USB host from stm32_bringup() through stm32_usbhost_initialize().
Add the lvglterm_kbda configuration - the LVGL terminal driven by a USB
HID keyboard on /dev/kbda - with the microSD card enabled alongside the
USB host. They coexist once CONFIG_MMCSD_MMCSUPPORT is left disabled, so
an SD card is not probed as an MMC device.
Also switch esp32s3-m5-cardputer:lvglterm to the renamed matrix-keyboard
input option (EXAMPLES_LVGLTERM_INPUT_KBD_MATRIX) to match the reworked
lvglterm example Kconfig.
Update the documentation accordingly: the LVGL Terminal example page for
the three-way input choice (touch, matrix, USB HID) with cursor-key
scrolling and per-variant configuration plus a photo of the USB variant
running on the Linum, the lvglterm_kbda entry on the Linum board page,
and the matrix-keyboard variant name on the M5Stack Cardputer board page.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The CI refresh step removes the explicit LVGL terminal keyboard input selection from the esp32s3-m5-cardputer lvglterm defconfig.
Update the saved defconfig so unrelated pull requests do not fail the normalize check on this board.
Signed-off-by: Old-Ding <ai.neo.ae86@gmail.com>
Add the 56-key matrix keyboard driver for the M5Stack Cardputer. The keys
form an 8x7 matrix behind a 74HC138 3-to-8 demultiplexer; the driver scans it
on the low-priority work queue and registers a keyboard device at /dev/kbd0,
reporting ASCII codes with SHIFT/CTRL and Fn (cursor) handling.
Add an "lvglterm" configuration that runs the on-screen NuttShell terminal
(apps/examples/lvglterm, physical-keyboard input variant) on the ST7789
display: the shell output is rendered in an LVGL text area and the keyboard
feeds the input. Wi-Fi is included so the on-screen shell can associate with
an access point using wapi.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The existing first-order LCG (seed = 470001 * seed % 999563) has several
quality problems:
- Output range limited to [1, 999562] (~20 bits) instead of full 32-bit
- Lower bits have very short periods (8-bit period = 1, 16-bit = 105)
- Overall period only ~1M, far too short for many applications
- Causes mbedtls_rsa_gen_key to loop forever when rand() consumption
aligns with the cycle length (issue #16760)
Replace the entire order-based LCG implementation (CONFIG_LIBC_RAND_ORDER
0-3) with Marsaglia's xorshift32:
- Full 32-bit output range
- Period 2^32 - 1 (~4.29 billion)
- Fast: just three XOR/shift operations
- No floating-point math needed
- No CONFIG_LIBC_RAND_ORDER configuration required
Remove the CONFIG_LIBC_RAND_ORDER Kconfig option and clean up all
defconfig references (12 boards) and related comments.
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
This port adds support for the M5Stack Cardputer (M5Stamp S3 /
ESP32-S3FN8, dual Xtensa LX7 @ 240 MHz, 8 MB flash, no PSRAM).
It reuses the common ESP32-S3 board helpers and ships these
configurations:
- nsh: NuttShell over the USB-Serial-JTAG console
- sdcard: microSD card on SPI3 (FAT)
- fb: ST7789 240x135 display exposed as a framebuffer
- wifi: Wi-Fi station
- softap: Wi-Fi SoftAP with DHCP server
- lvgl: LVGL graphics on the ST7789 (lvgldemo)
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
BREAKING CHANGE: bme680_register() takes an additional "*config" argument.
When config is NULL - driver behavior is the same as before.
With this change bme680 can be configured during registration in board logic.
This way we don't have to callibrate sensor from user-space but sensor is ready
to use after registration.
This change makes the registration the same as for bme688, which is a similar
sensor.
Signed-off-by: raiden00pl <raiden00@railab.me>
Replace the default nsh-based init flow on the lckfb-szpi-esp32s3 :adb
defconfig with system/nxinit so that services (sh console, adbd) are
spawned and reaped by init through /etc/init.d/init.rc.
- Enable CONFIG_SYSTEM_NXINIT and set INIT_ENTRYPOINT to init_main
(CONFIG_EXPERIMENTAL is required by SYSTEM_NXINIT).
- Add a common init.rc under boards/xtensa/esp32s3/common/src/etc/init.d
defining 'console' (sh) and 'adbd' services and starting both on init.
fastbootd is wired in for completeness when configured.
- Append the new init.rc to RCSRCS only when SYSTEM_NXINIT is enabled
so existing nsh-based configs remain unaffected.
Verified on lckfb-szpi-esp32s3 hardware: init_main spawns sh and adbd
(both with PPID=init), 'adb shell' reaches a working NuttShell.
Assisted-by: GitHubCopilot:claude-4.8-opus
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Fix crypto hash test errors due to SHA224 test which are not supported on NuttX for Xtensa based Espressif devices.
Signed-off-by: Eren Terzioglu <eren.terzioglu@espressif.com>
Increase MM_REGIONS from 5 to 6 to accomodate latest changes from
initialization refactor.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
The 32-bit system clock has a limited range (~497 days) and the
configuration knob is no longer worth the complexity given that
practically every modern target already enables it. Make 64-bit
time_t/clock_t/sclock_t/nuttx_time_t the only supported flavor.
Specifically:
- Drop the SYSTEM_TIME64 Kconfig option and its dependent
PERF_OVERFLOW_CORRECTION/HRTIMER guards in sched/Kconfig.
- Remove every #ifdef CONFIG_SYSTEM_TIME64 branch in headers
(include/{sys/types.h,limits.h,inttypes.h,nuttx/clock.h,
nuttx/fs/hostfs.h}) and core code paths
(sched/clock/clock.h, drivers/power/pm/pm_procfs.c,
drivers/rpmsg/rpmsg_ping.c, fs/procfs/fs_procfsuptime.c,
libs/libc/wqueue/work_usrthread.c,
arch/avr/src/avrdx/avrdx_timerisr_tickless_alarm.c).
- Strip CONFIG_SYSTEM_TIME64=y from every board defconfig.
- Update Documentation/guides/rust.rst accordingly.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
BREAKING CHANGE: remove PWM_MULTICHAN option
PWM_MULTICHAN option is redundant, we can just set CONFIG_PWM_NCHANNELS > 1.
At default CONFIG_PWM_NCHANNELS is set to 1, so the default behavior is preserved.
Access to single channel API is now `info->channels[0].XXX` instead of `info->XXX`
This is the first step to simplify PWM implementation and make it more portable.
Signed-off-by: raiden00pl <raiden00@railab.me>
Normalizes configurations after removal of some app-related init config
options due to simplification of NuttX init.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Since `NSH_ARCHINIT` is now removed, this commit cleans the last few
references to this option in the defconfig files that were recently
modified and escaped removal in initialization simplification commit.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
BREAKING: In an effort to simplify NuttX initialization, NSH_ARCHINIT is
removed. board_app_initialize is also removed. BOARD_LATE_INITIALIZE now
performs all board initialization logic, and is by default enabled. All
references to these symbols are removed. BOARDIOC_INIT remains, but will
result in -ENOTTY when called. It is to be removed in a later commit.
Quick fix: Boards relying on NSH_ARCHINIT should now enable
CONFIG_BOARD_LATE_INITIALIZE instead. If the application needs
fine-grained control over board initialization from userspace, the logic
performed by BOARDIOC_INIT may be copied to the board_finalinitialize
function and used instead via BOARDIOC_FINALINIT. All
board_app_initialize logic provided by NuttX is now moved to
board_late_initialize, and the same should be done for out-of-tree
boards.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
