JianyuWang0623 opened a new pull request, #20088:
URL: https://github.com/apache/nuttx/pull/20088
## Summary
Re-enables nxinit as the top-level init on esp32s3-xiao (restoring the
entrypoint switch from `7cc6707a76b10cc951f209c09b7f2b6cd228e535`,
reverted in `76b90e02cbe4967193b620abcb1efb9f6b3f8f5b` after a
real-hardware regression report — board hangs, no USB console, on
Seeed XIAO ESP32-S3), this time actually fixing the root cause 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 entrypoint switch on its own is
not sufficient — it would just reintroduce the same regression, so
that revert is folded into this change rather than kept as a separate,
individually-broken commit.
Fix, using the `"console"` service option added to nxinit by the
companion apache/nuttx-apps#3776:
- `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. Generated
with `make savedefconfig` against both defconfigs (byte-identical to
the committed diff, no manual edits).
**Depends on apache/nuttx-apps#3776** (`"console"` service option) —
without it, `init.rc`'s `console` line would fail to parse.
## Impact
- esp32s3-xiao `combo`/`usbnsh` defconfigs: top-level init switches
from `nsh_main` to nxinit (`init_main`), matching every other
esp32s3 board already on nxinit; nsh runs as a console service
started by `init.rc` instead of being init itself.
- No other board's `init.rc` behavior changes (`"console"` option is
opt-in per service; `exec -- sercon` is gated on
`CONFIG_SYSTEM_CDCACM`, which no other esp32s3 board currently
enables).
## Testing
Build-verified:
```
$ ./tools/configure.sh -l esp32s3-xiao:usbnsh && make -j8
...
MKIMAGE: ESP32-S3 binary
Successfully created esp32s3 image.
Generated: nuttx.bin
$ ./tools/configure.sh -l esp32s3-xiao:combo && make -j8
...
MKIMAGE: ESP32-S3 binary
Successfully created esp32s3 image.
Generated: nuttx.bin
$ tools/checkpatch.sh -g HEAD
✔️ All checks pass.
```
Verified end to end on real Seeed XIAO ESP32-S3 Sense hardware
(`usbnsh`, apps checked out at apache/nuttx-apps#3776). Real physical
reset (`dmesg` shows a clean USB disconnect/reconnect, not just a
software-triggered one):
```
usb 1-2.3: USB disconnect, device number 97
usb 1-2.3: New USB device found, idVendor=0525, idProduct=a4a7
usb 1-2.3: Product: CDC/ACM Serial
usb 1-2.3: Manufacturer: NuttX
```
Serial console over that device:
```
nsh> uname -a
NuttX 13.0.1-RC0 7cc6707a76b-dirty Sep 8 2026 10:53:53 xtensa esp32s3-xiao
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
4 4 2 100 RR Task - Running
0000000000000000 0008144 sh
nsh> ls /etc
/etc:
init.d/
```
`init_main` (nxinit) is PID 2, parent of `sh` (PID 4) — confirming
nxinit is genuinely running as top-level init and has successfully
spawned the console service, not just that the board booted.
Also independently reproduced the pre-fix regression on the same
physical board (real hard reset, no `esptool`/JTAG involved): with
`entrypoint=init_main` and the old plain-`"sh"` init.rc, the board's
USB device disappears entirely after reset and never re-enumerates —
matching the original bug report exactly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
