boards/esp32s3: switch remaining boards' defconfigs to nxinit entrypoint by JianyuWang0623 · Pull Request #19954 · apache/nuttx

JianyuWang0623 · 2026-08-24T16:25:20Z

Summary

The lckfb-szpi-esp32s3 board's defconfigs already run nxinit (init_main)
as system init instead of nsh_main (see #19946, still open at the time of
this PR). This extends the same switch to the remaining 12 boards under
boards/xtensa/esp32s3 that still used nsh_main (esp32s3-8048S043,
esp32s3-box, esp32s3-devkit, esp32s3-eye, esp32s3-korvo-2, esp32s3-lcd-ev,
esp32s3-lhcbit, esp32s3-m5-cardputer, esp32s3-meadow, esp32s3-touch-lcd7,
esp32s3-ws-lcd128, esp32s3-xiao), for consistency across all esp32s3 boards.
106 defconfigs changed, one commit per board.

For each defconfig:

CONFIG_INIT_ENTRYPOINT switched from "nsh_main" to "init_main"
CONFIG_INIT_STACKSIZE set to 8192, and CONFIG_SYSTEM_NSH_STACKSIZE
set to 8192 for the nsh console service launched by init.rc. See the
Testing section below for the measured stack usage behind this value —
it is not a guessed number.
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_ETC_ROMFS/CONFIG_FS_ROMFS added where missing, needed to ship
init.rc via the board's ROMFS

nsh keeps running, just as a console service started by init.rc
(boards/xtensa/esp32s3/common/src/etc/init.d/init.rc) instead of the
top-level init.

Policy question worth raising explicitly

CONFIG_SYSTEM_NXINIT (apps/system/nxinit/Kconfig) still depends on
CONFIG_EXPERIMENTAL. This PR turns on CONFIG_EXPERIMENTAL=y for the
esp32s3 boards' existing defconfigs in place, rather than adding new
*-nxinit-style variant configs alongside the existing ones. The only other
upstream precedent for CONFIG_SYSTEM_NXINIT today
(boards/arm64/bcm2711/raspberrypi-4b/configs/nxinit) took the
add-a-variant-config approach instead of converting an existing board's
configs in place. Flagging this up front rather than waiting for it to come
up in review — happy to switch to variant configs if that is the preferred
pattern for a still-EXPERIMENTAL component.

Impact

Affects only defconfigs under boards/xtensa/esp32s3 (12 boards, 106
defconfigs). No change to shared arch/board source, no ABI/API changes.
Stack and image footprint change on these boards only:

CONFIG_INIT_STACKSIZE becomes 8192 everywhere. Across these 106
defconfigs it was previously 3072 (79 configs), 4096 (12), already 8192
(12), and absent (3) — absent meaning the 2048 Kconfig default.
CONFIG_SYSTEM_NSH_STACKSIZE=8192 is a new line in 105 of the 106; only
esp32s3-devkit:stack set it before, at 4096. Previously the shell
inherited CONFIG_DEFAULT_TASK_STACKSIZE, which is 2048 in 94 of these
defconfigs and 4096 in the other 12.
103 defconfigs newly enable CONFIG_ETC_ROMFS (esp32s3-devkit's
fastboot, fastboot_tcp and romfs already had it), which adds the
shared init.rc to the board's ROMFS image.
104 defconfigs newly enable CONFIG_EXPERIMENTAL (esp32s3-devkit:python
and esp32s3-devkit:sotest already had it) — see the policy note above.

Testing

Build Host: Linux x86_64, xtensa-esp32s3-elf-gcc 12.2.0 (ESP-IDF toolchain)
Target: esp32s3 (12 boards, 106 defconfigs)

103 of 106 changed defconfigs build cleanly with make on this host. CI
covers 104 of the 106: tools/ci/testlist/xtensa-03.dat is the whole
/xtensa/esp32s3 tree minus esp32s3-devkit:python and
esp32s3-devkit:qemu_openeth, and the Linux (xtensa-03) job additionally
runs the tools/refresh.sh defconfig normalization check on each config it
builds. That job passed on an earlier revision of this branch; for the current
revision please read the CI status on this PR rather than this paragraph. The
3 local failures below are host-environment issues, not regressions:

esp32s3-devkit:qemu_openeth — link step fails with MERGEBIN error: Missing argument for binary files directory (missing ESPTOOL_BINDIR),
a local build-invocation issue; excluded from CI's xtensa-03 list anyway.
esp32s3-devkit:stack — linker segfaults (make[1]: *** [Makefile:183: nuttx] Segmentation fault), a local toolchain issue on this host,
reproduced identically on unmodified code before this patch.
esp32s3-devkit:ulp — context step fails (check_rv_toolchain) due to
a missing local RISC-V ULP cross-toolchain.

tools/checkpatch.sh -g apache/master..HEAD passes on the full diff.
tools/refresh.sh --silent was also run locally on the defconfigs touched
last (esp32s3-touch-lcd7:lcd, esp32s3-devkit:stack, esp32s3-box:buttons,
esp32s3-eye:gpio, esp32s3-lcd-ev:buttons) plus esp32s3-devkit:nsh and
esp32s3-box:nsh as controls: no savedefconfig diff on any of the 7.

Stack sizing: measured, not guessed

No hardware was attached for any of these 12 boards in this session.
Runtime behavior of the nxinit/init.rc mechanism was instead verified on
lckfb-szpi-esp32s3 hardware (which already uses the identical mechanism),
since init_main taking over as system init and starting nsh as a console
service is a chip/OS-level behavior, not board-specific.

CONFIG_STACK_COLORATION was enabled on lckfb-szpi-esp32s3 to measure real
stack high-water marks (ps's USED/FILLED columns) rather than pick
8192 by trial and error. The worst-case scenario is a defconfig where
init.rc starts more than one service concurrently — the adb defconfig
(console sh + adbd) was used for this:

INIT_STACKSIZE=2048 (Kconfig default, pre-conversion) + NSH_STACKSIZE=2048:
  sh crashes outright — xtensa_user_panic: User Exception ... task: sh

INIT_STACKSIZE=4096:
  init_main FILLED=99.5% — critical, one bad rc.d line away from overflow

INIT_STACKSIZE=8192:
  init_main FILLED=53.6% (USED=4336/8192) — healthy margin

For a single-service defconfig (plain nsh, only the console service),
init_main at the pre-conversion default of 3072 does not actually
overflow — measured FILLED was 46.9% (about 1.4KB used). The failure mode
that motivates raising INIT_STACKSIZE uniformly is specifically the
multi-service case (adb, fastboot, etc.), not every defconfig on this
family. 8192 is taken as the uniform value across all 106 defconfigs because:
(1) it comfortably covers the worst measured case with ~2x margin, and
(2) keeping it board/config-specific is exactly the kind of per-defconfig
detail that is easy to miss — this PR's own review caught 3 defconfigs where
the conversion script failed to add INIT_STACKSIZE at all, silently
falling back to the 2048 default and reintroducing the crash. A uniform
value removes that failure mode structurally.

Two of the converted defconfigs, esp32s3-devkit:knsh and
esp32s3-devkit:ksta_softap, are CONFIG_BUILD_PROTECTED=y builds, where
nxinit runs in user space and starts its services through posix_spawn.
Those two are build-verified only — the protected-build path has had no
runtime verification here.

ps output for init_main/sh on the nsh defconfig, before/after the
entrypoint switch (STACK_COLORATION disabled here, so no USED/FILLED
columns — this pair is about init_main taking over as the boot sequence
owner, not stack margin):

Before (nsh_main as top-level init)

nsh> ps
  TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK COMMAND
    0     0     0   0 FIFO     Kthread   - Ready              0000000000000000 0003040 Idle_Task
    2     2     0 100 RR       Task      - Running            0000000000000000 0003000 nsh_main

After (init_main as top-level init, nsh as a console service it spawns)

nsh> ps
  TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK COMMAND
    0     0     0   0 FIFO     Kthread   - Ready              0000000000000000 0003040 Idle_Task
    2     2     0 100 RR       Task      - Waiting  Semaphore 0000000000000000 0008120 init_main
    3     3     2 100 RR       Task      - Running            0000000000000000 0008144 sh

init_main (PID 2) is the parent of the nsh console service sh (PID 3),
confirming nxinit is in control of the boot sequence. Additional checks after
the switch:

nsh> ls /
/:
 dev/
 etc/
 proc/
nsh> uname -a
NuttX 13.0.1-RC0 73ad366f45c-dirty ... xtensa lckfb-szpi-esp32s3
nsh> free
      total       used       free    maxused    maxfree  nused  nfree name
     389240      21960     367280      22328     367200     60      2 Umem

/proc stays mounted (ls / succeeds, no crash in read_pseudodir), and
free/uname respond normally. The 73ad366f45c-dirty build stamp above is
the raw uname -a output from the test build: that commit was the head of the
lckfb branch in #19946 at the time, and it has since been rebased away, so the
SHA no longer resolves. It is left as logged rather than rewritten.

github-actions · 2026-08-24T17:09:17Z

MemBrowse Memory Report

No memory changes detected for:

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 73c949c) 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 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 73c949c) 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-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 73c949c) 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-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 73c949c) 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-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 73c949c) 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 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 73c949c) 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-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 73c949c) 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 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 73c949c) 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 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 73c949c) 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-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 73c949c) 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 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 73c949c) 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-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 73c949c) 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>

acassis · 2026-08-25T13:51:32Z

@JianyuWang0623 please normalize: boards/xtensa/esp32s3/esp32s3-m5-cardputer/configs/lvglterm/defconfig

github-actions Bot added Size: XL The size of the change in this PR is very large. Consider breaking down the PR into smaller pieces. Board: xtensa labels Aug 24, 2026

JianyuWang0623 force-pushed the esp32s3-nsh-to-init-allboards branch from f51a14a to 2654254 Compare August 25, 2026 02:55

simbit18 requested review from eren-terzioglu, fdcavalcanti, tmedicci and xiaoxiang781216 and removed request for eren-terzioglu August 25, 2026 03:57

JianyuWang0623 added 12 commits August 25, 2026 16:59

JianyuWang0623 force-pushed the esp32s3-nsh-to-init-allboards branch from 2654254 to ff92018 Compare August 25, 2026 09:07

jerpelea approved these changes Aug 25, 2026

View reviewed changes

JianyuWang0623 force-pushed the esp32s3-nsh-to-init-allboards branch 2 times, most recently from d4adb3d to d06cc19 Compare August 25, 2026 10:49

acassis approved these changes Aug 25, 2026

View reviewed changes

acassis marked this pull request as ready for review August 25, 2026 14:03

acassis merged commit 87db6b2 into apache:master Aug 25, 2026
26 of 27 checks passed

Navigation Menu

Uh oh!

boards/esp32s3: switch remaining boards' defconfigs to nxinit entrypoint - #19954

boards/esp32s3: switch remaining boards' defconfigs to nxinit entrypoint#19954
acassis merged 12 commits into
apache:masterfrom
JianyuWang0623:esp32s3-nsh-to-init-allboards

JianyuWang0623 commented Aug 24, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 24, 2026 •

edited

Loading

Uh oh!

acassis commented Aug 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

JianyuWang0623 commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Policy question worth raising explicitly

Impact

Testing

Stack sizing: measured, not guessed

Before (nsh_main as top-level init)

After (init_main as top-level init, nsh as a console service it spawns)

Uh oh!

github-actions Bot commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

MemBrowse Memory Report

Uh oh!

acassis commented Aug 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

JianyuWang0623 commented Aug 24, 2026 •

edited

Loading

github-actions Bot commented Aug 24, 2026 •

edited

Loading