Adds GPIO defconfig on M5Stack Tab5. The example has one GPIO output
and one GPIO interrupt.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
Add an lstat method to mountpt_operations so that mounted file systems
can report link metadata without dereferencing symbolic links.
In mountptrename() and stat_recursive(), prefer lstat() over stat()
when it is available so that rename() and the non-following stat path
operate on the link itself rather than its target, matching POSIX
semantics.
Signed-off-by: zhengyu16 <zhengyu16@xiaomi.com>
resolve rename{7}:
On a call to rename(old, new), when the old argument points to the pathname of a directory, if the directory named by the new argument exists and is empty it shall be removed and old renamed to new.
resolve rename{23}:
EEXIST or ENOTEMPTY in errno and a return value of -1 on a call to rename(old, new) when the link named by new is a directory containing
entries other than dot and dot-dot. The named files are not changed.
Signed-off-by: zhengyu16 <zhengyu16@xiaomi.com>
1. add three func to mountpt_operations:
link
symlink
readlink
2. modify fs_link、fs_symlink、fs_readlink for mountpt
Signed-off-by: zhengyu16 <zhengyu16@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>
Wire the shared Ameba RTC driver (arch/arm/src/common/ameba/ameba_rtc.c)
into RTL8721F (amebagreen2). The driver is chip-agnostic and reads only
per-chip macros from ameba_rtc_chip.h; RTL8721F differs from amebadplus
only in the RTC interrupt vector (RTL8721F_IRQ_RTC, vector 41). The
APBPeriph_RTC masks and RTC_BASE_YEAR (1900) are identical across all
current Ameba chips.
- ameba_rtc_chip.h: per-chip RTC IRQ / clock masks / base year
- Make.defs, ameba_board.mk: compile ameba_rtc.c and the fwlib RAM
RTC source when CONFIG_AMEBA_RTC=y
- board: rtl8721f_rtc.c registers /dev/rtc0 from bringup
- configs/rtc: examples/alarm profile
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Wire the shared Ameba RTC driver (arch/arm/src/common/ameba/ameba_rtc.c)
into RTL8720F. The driver is chip-agnostic and reads only per-chip macros
from ameba_rtc_chip.h; RTL8720F differs from amebadplus only in the RTC
interrupt vector (RTL8720F_IRQ_RTC, vector 33). The APBPeriph_RTC masks
and RTC_BASE_YEAR (1900) are identical across all current Ameba chips.
- ameba_rtc_chip.h: per-chip RTC IRQ / clock masks / base year
- Make.defs, ameba_board.mk: compile ameba_rtc.c and the fwlib RAM
RTC source when CONFIG_AMEBA_RTC=y
- board: rtl8720f_rtc.c registers /dev/rtc0 from bringup
- configs/rtc: examples/alarm profile
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Expose the Ameba on-chip RTC as a NuttX date/time RTC at /dev/rtc0
(rdtime/settime) with a single one-shot alarm (setalarm/rdalarm/
cancelalarm/setrelative) that fires the RTC interrupt and the upper-half
callback. The same hardware also backs the arch date/time RTC hooks
(up_rtc_initialize/getdatetime/settime, g_rtc_enabled) so the NuttX
system time is seeded from it.
The driver sits on the SDK fwlib RTC API (mirrored structures + local
externs, no vendor headers pulled into the NuttX include world). The
fwlib RTC API lives in the RAM source ameba_rtc.c, so it is added to the
board fwlib build under CONFIG_AMEBA_RTC. The hardware keeps a year plus
a day-of-year (no month/day register); the driver bridges that to the
NuttX month/day calendar with the libc UTC routines (timegm/gmtime_r),
which is exact and reversible.
The only per-chip fact -- the RTC interrupt vector -- lives in the
per-chip ameba_rtc_chip.h; the shared driver is never edited for a new
Ameba chip. A configs/rtc profile (examples/alarm) is added for
verification.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
List every peripheral implemented by STM32U3C5, and update the common GPIO, EXTI
and USART driver paths after the Cortex-M33 migration.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Replace the enumerated STM32U3/U5 chip conditions in the common M33
source lists and the RCC dispatch header with a single STM32_COMMON_M33
symbol, following the existing STM32_COMMON_* convention.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Rename the U3 and U5 family-local Cortex-M33 RCC headers to
stm32_rcc_m33.h and dispatch to that private name for the two families
in the common RCC header.
This lets the shared M33 USART implementation use one include name
while RCC registers and clock definitions remain family-local. Extend
the stm32_ports.rst naming rules with the M33 header, source, and
Kconfig symbol conventions.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Rename the shared U3/U5 heap allocator to stm32_allocateheap_m33_v1.c
and keep its direct family selection in Make and CMake.
Size the primary region from a now-mandatory STM32_PRIMARY_SRAM_SIZE,
provided by the U5 chip header as the SRAM1 size, and drop the
U5-specific SRAM bank descriptions so the allocator carries no family
conditionals.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Rename the shared U3/U5 reset handler to stm32_start_m33_v1.c and keep
its direct family selection in Make and CMake.
Include stm32_userspace.h only under CONFIG_BUILD_PROTECTED and define
the SRAM2 span only when CONFIG_STM32_SRAM2_INIT requests the parity
initialization, so families without SRAM2 parity or userspace support
can use the file unchanged.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Rename the shared U3/U5 USART sources to stm32_serial_m33_v3.c and
stm32_lowputc_usart_m33_v3.c and gate them with a new
STM32_HAVE_IP_USART_M33_V3 symbol selected by the U3 and U5 peripheral
options. Rename the USART hardware header to stm32_uart_m33_v3.h with
its register map unchanged.
Store each port's RCC enable register and bit in the serial
descriptor, provided by the family RCC headers as
STM32_<port>_FREQUENCY, _RCC_REG and _RCC_EN, so common clock control
needs no family-specific switch. Correct the LPUART1 RX DMA map name
to DMAMAP_LPUART1_RX.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Rename the U3/U5 GPIO and EXTI sources to stm32_gpio_m33_v1.c and
stm32_exti_gpio_m33_v1.c and gate them with new
STM32_HAVE_IP_GPIO_M33_V1 and STM32_HAVE_IP_EXTI_M33_V1 symbols
selected by the U3 and U5 peripheral options.
Rename the GPIO and EXTI hardware headers to stm32_gpio_m33_v1.h and
stm32_exti_m33_v1.h with their register maps unchanged, dispatch to
them from the common GPIO and EXTI hardware headers by the new IP
symbols, and widen STM32_EXTI_EXTICR_PORT_MASK to the full 8-bit
EXTICR port-select field.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Remove the disabled CONFIG_STM32_SYSTICK_HCLKd8 reload path and the
non-functional clock-source write. SysTick always runs from HCLK on
these devices, so compute the reload value from STM32_HCLK_FREQUENCY
only.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Iterate the NVIC interrupt enable and priority registers from
STM32_IRQ_NEXTINTS instead of dumping a hardcoded U3/U5 register list,
so the helper works unchanged for any interrupt count.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Rename the U3/U5 idle, NVIC, and SysTick sources to the Cortex-M33 v1
naming convention: stm32_idle_m33_v1.c, stm32_irq_m33_v1.c, and
stm32_timerisr_m33_v1.c, and move them into their own Make and CMake
block, still selected by the direct U3/U5 family condition.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Switch all three esp32p4 boards' nsh defconfigs (esp32p4-function-ev-board,
esp32p4-pico-wifi-wareshare, esp32p4-tab5) from nsh_main to nxinit
(init_main) as the system init entry point, matching the esp32s3 boards'
existing nxinit configs for consistency across Espressif boards.
- Add boards/risc-v/esp32p4/common/src/etc/init.d/init.rc, copied from
the esp32s3 common version: registers a "console sh" service (nsh)
guarded by CONFIG_SYSTEM_NSH, plus adbd/fastbootd service stubs
guarded by their own Kconfig symbols for future reuse; "on init"
starts whichever services are enabled.
- boards/risc-v/esp32p4/common/src/Make.defs: ship init.rc via ROMFS
(RCSRCS) when CONFIG_SYSTEM_NXINIT=y, alongside the existing
rc.sysinit/rcS, mirroring esp32s3's Make.defs.
- Per board defconfig:
- CONFIG_INIT_ENTRYPOINT switched to "init_main"
- CONFIG_INIT_STACKSIZE=8192 (was unset/2048 default), matching the
value already used and measured on esp32s3 boards for the
nxinit init task running console-sh (and up to two services)
- CONFIG_SYSTEM_NXINIT=y added, plus its direct Kconfig dependencies:
CONFIG_LIBC_EXECFUNCS, CONFIG_SCHED_CHILD_STATUS (which depends on
CONFIG_SCHED_HAVE_PARENT); CONFIG_EXPERIMENTAL was already set on
all three boards
- CONFIG_SYSTEM_NSH_STACKSIZE=8192 added: nsh now runs as a service
spawned by init.rc instead of being init itself, so it needs its
own stack instead of borrowing the init stack
- CONFIG_ETC_ROMFS/CONFIG_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/risc-v/esp32p4/common/src/etc/init.d/init.rc), not as the
top-level init.
CMake: esp32p4's common/src/CMakeLists.txt currently has no ROMFS/RCSRCS
wiring at all (unlike e.g. esp32c3's nuttx_add_romfs() block), so
rc.sysinit/rcS/init.rc are only shipped via the Make build. This is a
pre-existing gap independent of this change and is left untouched here.
Verified all three defconfigs with:
./tools/configure.sh -l <board>:nsh
make -j$(nproc) CROSSDEV=riscv-none-elf-
using the xPack riscv-none-elf-gcc 14.2.0 toolchain (the local
riscv64-unknown-elf-gcc bare-metal toolchain lacks sys/cdefs.h needed
by esp-hal-3rdparty). All three link cleanly with no errors/warnings;
the built nuttx.bin contains the init.rc-embedded "service console sh"
string, confirming init.rc is picked up by the ROMFS build. Each
defconfig was regenerated with "make savedefconfig" to normalize
field ordering.
esp32p4 has no hardware attached in this session, so this change is
build-verified only; no flash/boot pass was performed.
Assisted-by: opencode/claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Blank lines only; `git diff --ignore-blank-lines` against the parent is empty.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
MAXMB resets to 0x0f, so OR-ing the intended value into MCR can only ever
raise it. Every configuration with fewer than 16 mailboxes therefore runs with
MAXMB = 15 and FlexCAN arbitrates over mailboxes the driver never initialised:
with the classic payload layout MB14 and MB15 hold power-on contents, and with
a 64-byte CAN FD layout they are past the end of the mailbox RAM region
entirely.
s32k1xx_flexcan.c already does this; carry the same two lines over.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
imxrt_transmit() wrote the caller's deadline into txmb[] before testing
whether it had already passed, and the early return for an expired deadline
then left that deadline behind on a mailbox holding no frame. The next
watchdog expiry finds it, counts a transmit timeout that did not happen, and
writes CAN_TXMB_ABORT into a mailbox the allocator may have handed to a live
frame in the meantime.
Compute the timeout first and store the deadline after the early return.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
imxrt_txtimeout_work() had four defects that together let one expired frame
take the interface down permanently.
It aborted mailbox RXMBCOUNT + mbi while the deadline it consulted belongs to
RXMBCOUNT + 1 + mbi, so every abort landed one mailbox low and mbi == 0 wrote
CAN_TXMB_ABORT into the buffer reserved for the ERR005829 workaround, while
the highest TX mailbox was never aborted at all.
Its expiry test read `now.tv_sec > d.tv_sec || now.tv_usec > d.tv_usec`, which
declares any deadline that crosses a second boundary expired: in that case the
deadline's microsecond field is always the smaller of the two. The `now` it
compared against was a struct timespec cast to a struct timeval, so writing
tv_usec wrote over tv_nsec and tv_sec was whatever the cast happened to line
up with.
imxrt_txdone() cancelled the watchdog but left txmb[].deadline set, so a
retired mailbox looked expired forever and the next watchdog expiry on any
other mailbox aborted whatever frame had since been loaded there.
The walk ran to TXMBCOUNT, which counts the reserved mailbox as well, so its
last iteration addressed mailbox TOTALMBCOUNT - one past the ring, and
mb_address[] one past its end. Only txmb[] never being written that far kept
it in bounds. TXMBRINGSIZE now names the ring size that the rest of the driver
already assumes.
Aborting a frame that is already on the wire raises a bit error, so the
transmit error counter climbs and the node goes error passive. Since
imxrt_txmb_next() only hands out a mailbox above every pending one, a mailbox
left in DATAORREMOTE also pins the allocator at TOTALMBCOUNT and transmit
never recovers.
Measured on an ARK FMU-v6XRT with a DroneCAN GNSS node on the bus, offering
736 frames/s (9% of a 1 Mbit/s bus) from the PX4 uavcan driver: before, the
interface transmitted 0 frames/s with ECR[TXERRCNT] pinned at 128 and
ESR1[FLTCONF] error passive, and stayed dead across a reboot. After, 734
frames/s, 0.1% loss, TXERRCNT 0, error active.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Add generic support for link-time registration of struct instances,
modeled after the Zephyr STRUCT_SECTION_* mechanism:
- include/nuttx/iterable_sections.h: STRUCT_SECTION_ITERABLE/DECLARE/
FOREACH/GET/COUNT macros placing instances in name-sorted linker
sections delimited by _<type>_list_start/_end symbols (attributes
through the nuttx/compiler.h macros; FOREACH takes a caller-declared
iterator, like list_for_every_entry).
- include/nuttx/linker/iterable_sections.ld: ITERABLE_SECTION() macro
emitting the KEEP + SORT_BY_NAME collection statements (linker
scripts in ARCHSCRIPT are CPP-preprocessed).
- include/nuttx/linker/common-rom.ld / common-ram.ld: central
aggregators meant to be included by board linker scripts (inside
.text and .data respectively); subsystems register their sections
here guarded by their Kconfig options, so the fragments expand to
nothing on configurations that do not use them.
- CONFIG_ITERABLE_SECTIONS_LINKER_INSERT + include/nuttx/linker/
common-insert.ld (added before the board script by tools/Config.mk and
by the top-level CMakeLists.txt): optional zero-touch mode that
supplements the board script through GNU ld INSERT AFTER, collecting
the subsystems' ITERABLE_SECTION blocks in one output section; the
common-rom.ld/common-ram.ld fragments expand to nothing in that mode.
See the option help for the constraints.
- Documentation/components/iterable_sections.rst.
First user: the Zephyr zbus message bus port (apps/system/zbus in
nuttx-apps); its board integration comes in a companion PR.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Reviewers on apps#3751 (support compound command and resetcause-based
triggers) asked for documentation of the new features. Add two
sections to the nxinit doc:
- "Built-in Properties": describes the sys.boot.reason property set
by NXInit at startup from BOARDIOC_RESET_CAUSE, its two value forms
(hardware cause with numeric subreason, or software reset reason
string), and behavior when CONFIG_BOARDCTL_RESET_CAUSE is disabled
or the boardctl() call fails.
- "Compound Commands": describes the && / || short-circuit semantics
for chaining commands on a single action line, including quoting
behavior.
Assisted-by: GitHubCopilot:claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
The idle stack area started at _ebss + CONFIG_IDLETHREAD_STACKSIZE *
CONFIG_SMP_NCPUS, so the first CONFIG_SMP_NCPUS stack slots after .bss
were never used - 16MiB on a 4-CPU configuration with a 4MiB idle
stack. Start the area at _ebss and let the heap begin that much
earlier.
The -16 offset is kept: it is what places the AP initial RSP set up in
intel64_head.S below the xcp->regs block that up_cpu_idlestack()
reserves at the top of the same stack. Without it both land on the
same 64-byte slot and the first context save corrupts the AP stack.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
intel64 port explicitly enumerates five idle-stack
addresses and rejects configurations with more than five CPUs.
Store the CPU0 stack top and calculate every CPU stack address
from its index.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The AP boot path masked RSP with ~XCPTCONTEXT_SIZE, which just clears
whichever bits happen to be set in the size (0x340 -> mask 0xfffffcbf).
That drops RSP by an arbitrary amount and only guarantees 16-byte
alignment, while the XSAVE area in the context needs 64.
Mask with ~(XCPTCONTEXT_ALIGN - 1) instead.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
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>
