!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!

[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!

[linguini1]

This is now ready for review

[jerpelea]

@linguini1 We are ready for branch out
Do you want to merge the patches to master?

[acassis]

Don't merge before the 12.13 be created. I'm opening this change request just to avoid mistakes here.

[acassis]

@linguini1 We are ready for branch out Do you want to merge the patches to master?

Alin (same as nuttx-apps), let's follow with your suggested plan:

- next release is 12.13.0 (branch out 1 March)
- planned Jun release 13.0.0 (branch out 1 Jun)

Not big breaking changed to 12.13.

[jerpelea]

@linguini1 We are ready for branch out Do you want to merge the patches to master?

Alin (same as nuttx-apps), let's follow with your suggested plan:

- next release is 12.13.0 (branch out 1 March)
- planned Jun release 13.0.0 (branch out 1 Jun)

Not big breaking changed to 12.13.

12.13 branch created

[linguini1]

Hi @jerpelea , let's save this one for the 13.x branch on June 1 instead.

[fdcavalcanti]

@linguini1 great job!

I noticed issues so far only on ESP32, but will keep testing:

On esp32-devkitc the following configs are failing on startup when DEBUG_ASSERTIONS are enabled:

• ble, mcuboot_update_agent, psram, smp, spiflash, wifi_smp
• This probably fails on other ESP32 boards.

2026-03-02 13:43:06 [CPU1] dump_assert_info: Current Version: NuttX  12.12.0 0c904fec99e5 Mar  2 2026 13:40:32 xtensa
2026-03-02 13:43:06 [CPU1] dump_assert_info: Assertion failed idx < 3: at file: mm_heap/mm_initialize.c:117 task(CPU1):

The thing in common on those configs is that they all use SMP.

Seems the fix is to increase +1 to CONFIG_MM_REGIONS on the configs that have SMP, but I fail to see the reason right now.

[linguini1]

Thank you @fdcavalcanti for testing! Do you know if any of those issues were present prior to this patch?

I do not have an esp32-devkitc board but I do have the Xiao C3, so I will try to reproduce there as well and see if I can figure out what it may be.

[fdcavalcanti]

Thank you @fdcavalcanti for testing! Do you know if any of those issues were present prior to this patch?

I do not have an esp32-devkitc board but I do have the Xiao C3, so I will try to reproduce there as well and see if I can figure out what it may be.

I did a quick test on master and it is working fine for spiflash and smp defconfigs.
It only happens on ESP32, I did not see any test failures related to this change on other devices, even Xtensa ones.