!boards: Simplify NuttX initialization

[linguini1]

Summary

BREAKING CHANGE

This change simplifies the NuttX initialization logic by:

• Replacing NSH_ARCHINIT with CONFIG_BOARD_LATE_INITIALIZE in defconfigs
• Removing BOARDIOC_INIT/board_app_initialize
• Ensuring that board_late_initialize performs the same function as
  board_app_initialize did so any defconfigs relying on NSH_ARCHINIT will not
  break.

This is related to #11321.

Twin PR in NuttX apps should be merged at the same time: apache/nuttx-apps#3405

Impact

Almost every single board/configuration in the NuttX source tree, since many
relied on NSH for initialization.

This is a breaking change that removes the user's ability to use BOARDIOC_INIT
as well. Users are provided with quick-fixes in the commit messages for how to
fix any breakages. BOARDIOC_FINALINIT should be used instead for applications
that truly require full control over the initialization process. For every other
application, BOARD_LATE_INITIALIZE should be enabled to have the NuttX kernel
perform initialization before launching into the app.

Testing

I will be testing on the platforms available to me (simulators and whatever
hardware I own). Testing from community members with hardware across the
architectures affected would be greatly appreciated. If you do want to help with
testing, please provide logs in the PR comments for the affected defconfigs you
tested.

Testing of applications can be seen in the twin PR: apache/nuttx-apps#3405

OS Test logs

• sim:nsh: sim-nsh.txt
• qemu-armv8a:nsh: qemu-armv8a-nsh.txt
• qemu-armv7a:nsh: qemu-armv7a-nsh.txt
• rv-virt:nsh: rv-virt-nsh.txt
• raspberrypi-4b:sd: rpi4b-sd.txt (verify SD filesystem is mounted + ostest)
• samv71-xult:nsh, samv71-xult:netnsh: See comment

[linguini1]

Notes for reviewers on the initial draft:

1. This is obviously a huge change so it would be great to have some testing on platforms which I am not able to test on my own hardware (i.e. any STM32, the Espressif internal CI would be good to run, anyone with tricore/renesas/sparc/etc. boards).
2. Unfortunately I don't think this can be split across multiple PRs, since removing NSH_ARCHINIT relies on board_late_initialize to have identical contents to board_app_initialize. The removal of BOARDIOC_INIT might be able to get split but since this change is going to touch almost every board, it should just be done simultaneously to reduce the chance of making errors. I am open to suggestions as I realize this is a monster PR, but I can't think of a better approach.
3. I think I will eventually squash all of the commits replacing board_app_initialize -> board_late_initialize into one, since anyone bisecting later would probably treat this entire change as one unit. Please let me know if it's advisable to squash in any other way as well. For now this helps me keep track of everything while the change is under review
4. I think this should go surprisingly smoothly for most configurations; a majority of the boards that are affected had a very standard setup for app_init/late_init where they both did the exact same thing
5. Anything beyond removing BOARDIOC_INIT, board_app_initialize and NSH_ARCHINIT are outside of the scope of this PR. I will not be addressing anything else in the boot process that is independent from these changes (i.e. non-standard naming of files for boot logic, etc.)

[fdcavalcanti]

@linguini1 this is a great initiative.
Please share your process or a board example and I can do it on ESP boards.

[linguini1]

this is a great initiative. Please share your process or a board example and I can do it on ESP boards.

Hi @fdcavalcanti, if you're talking about making the changes, I think all ESP boards should be included in this patch already (xtensa/risc-v). They were actually quite easy since the board_late_init and board_app_init logic were pretty much identical.

If you're talking about how to test, the process would be to configure the build system for one of the modified ESP32 configurations (i.e. nsh) and just boot into NuttX, check that things look okay and run ostest.

Hope I understood correctly, thanks for your help!

[michallenc]

Did tests on SAMv7 boards:

• samv71-xult:nsh

NuttShell (NSH) NuttX-12.12.0
nsh> uname -a
NuttX 12.12.0 f3140f1a1f Feb 24 2026 11:42:19 arm samv71-xult
nsh> free
      total       used       free    maxused    maxfree  nused  nfree name
     381608       8200     373408       8984     372992     27      2 Umem
nsh> 

• samv71-xult:netnsh with DHCP enabled

michal@acer:~$ telnet 10.0.2.69
Trying 10.0.2.69...
Connected to 10.0.2.69.
Escape character is '^]'.
NuttShell (NSH) NuttX-12.12.0
nsh> uname -a
nsh: &uname: command not found
nsh> uname -a
NuttX SAMV71-XULT 12.12.0 f3140f1a1f Feb 24 2026 11:58:32 arm samv71-xult
nsh> 
nsh> 
nsh> 
nsh> 

Also tested on a custom board that initializes many peripherals - PWM, LCD, RS485 ports, Ethernet, SD card, Flash and all seems to be working fine 👍

[acassis]

@linguini1 @michallenc I don't know if you guys paid attention to it, but this "&" is appearing every time someone connects via telnet:

michal@acer:~$ telnet 10.0.2.69
Trying 10.0.2.69...
Connected to 10.0.2.69.
Escape character is '^]'.
NuttShell (NSH) NuttX-12.12.0
nsh> uname -a
nsh: &uname: command not found

It was not happening few weeks ago, so it is a regression, I will map this Issue

[linguini1]

Thanks for testing @michallenc !

I hadn't noticed that @acassis , but I have not used telnet. I don't think that regression is related to this PR.

[acassis]

Thanks for testing @michallenc !

I hadn't noticed that @acassis , but I have not used telnet. I don't think that regression is related to this PR.

No, sorry if you understand this way. In fact this issue started few weeks ago. I mapped this issue here: #18431

[linguini1]

CI is passing! Hooray!

The steps now are:

• Get some more community testing to cover more of the major chipsets (anyone with STM32s, that would be highly appreciated)
• Wait until the release branch is made on March 1, then this can be rebased onto main and merged to make the June 1 release
• Merge the corresponding nuttx-apps PR
• Completely remove the BOARDIOC_INIT interface in a subsequent PR now that no more boards depend on it and CI checks will be synced with the nuttx-apps change.

@fdcavalcanti this should be ready for ESP32 testing now if you're still able to help test it!