!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
• esp32c3-xiao:ble: esp32c3-xiao.txt

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

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.

[michallenc]

Just a note that recently added boards will need to be changed as well before this is merged - #18475 and #18516.

Edit: marking it as a request change so it's not lost in the thread

[linguini1]

Once the March 1 release is finished I'll rebase this onto main and fix those remaining issues. Until then I still have to figure out what's causing issues with ESP32; I thought those would be pretty cut-and-dry since the old appinit only called esp32_bringup in most cases, but I suppose not!

[linguini1]

@fdcavalcanti I have tested on the esp32c3-xiao:ble config with debug assertions enabled and everything is working fine (logs at bottom of PR description). This is my only ESP device right now, and it's RISC-V not Xtensa, so maybe not particularly useful in reproducing the issue you noticed.

I took a look at the mainline initialization vs this patch, and the esp32-devkitc board already had an implemented version of board_late_initialize which is not modified in this patch. I did notice that in SMP builds it adds a memory region, but this step isn't performed in board_app_initialize. The two init methods are otherwise identical.

Would you be able to perform your test on esp32-devkitc for mainline again but this time enable CONFIG_BOARD_LATE_INITIALIZE instead of NSH_ARCHINIT? I'm wondering if the board_late_initialize logic was always faulty and it just wasn't noticed because NSH_ARCHINIT was used.

[fdcavalcanti]

@fdcavalcanti I have tested on the esp32c3-xiao:ble config with debug assertions enabled and everything is working fine (logs at bottom of PR description). This is my only ESP device right now, and it's RISC-V not Xtensa, so maybe not particularly useful in reproducing the issue you noticed.

I took a look at the mainline initialization vs this patch, and the esp32-devkitc board already had an implemented version of board_late_initialize which is not modified in this patch. I did notice that in SMP builds it adds a memory region, but this step isn't performed in board_app_initialize. The two init methods are otherwise identical.

Would you be able to perform your test on esp32-devkitc for mainline again but this time enable CONFIG_BOARD_LATE_INITIALIZE instead of NSH_ARCHINIT? I'm wondering if the board_late_initialize logic was always faulty and it just wasn't noticed because NSH_ARCHINIT was used.

@linguini1 I tried and here is the output.

• Replaced all defconfigs entries of esp32-devkitc: CONFIG_NSH_ARCHINIT -> CONFIG_BOARD_LATE_INITIALIZE on the main branch.

3 defconfig failures:

• smp
• mcuboot_nsh
• psram_usrheap

I was able to test using QEMU.

On SMP I got this error:

ABD[CPU0] __esp32_start: ESP32 chip revision is v3.0
[CPU0] dump_assert_info: Current Version: NuttX  10.4.0 c3b8c57e41 Mar 13 2026 11:08:04 xtensa
[CPU0] dump_assert_info: Assertion failed idx < 4: at file: mm_heap/mm_initialize.c:117 task(CPU0): AppBringUp process: Kernel 0x400d2bec

Which is the issue same we had before.
The mcuboot_nsh one is not clear to me, it worked locally but failed on CI (which is most likely a CI issue that I'm working on, so I would ignore it).

I'm not able to dig deeper right now, but seems you are on the right track.

[linguini1]

Thank you @fdcavalcanti ! I guess this never worked in mainline then. I'll take a closer look at those configurations (excepting mcuboot) to see if there's any signs in there.