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

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.

[lupyuen]

Hi @linguini1: I'm testing a new way to Build PRs in Our Own NuttX Repos, wonder if you would like to try out, and give your feedback to @simbit18 and me? Thank you so much :-)

1. Demo Video in YouTube
   Demo Video in Google Drive
2. Browse to github.com/NuttX/manual-nuttx-ci
3. Click "Fork" to clone the repo
4. Click "Actions > Enable GitHub Actions"
5. Click "Manually Build NuttX > Run Workflow"
6. Enter the following:
   • Repo for NuttX: linguini1/nuttx
   • NuttX Branch: byebye-archinit
   • Repo for NuttX Apps: apache/nuttx-apps
   • NuttX Apps Branch: master
   • Host Platform: all
7. And the PR Build should start. Lemme know if it doesn't work thanks!
8. Why are we doing this? Earlier this year, we saw very high usage of GitHub Runners. By building PRs in Our Own NuttX Repos, we will greatly reduce our usage of GitHub Runners, so that ASF Infrastructure Team won't revoke our access to GitHub CI. So we hope everyone can help out thanks :-)

[linguini1]

I will definitely try this! It may take a while, school is getting a little busy at the moment, but once I do I'll let you know!

[linguini1]

This PR has been rebased onto the latest master, and the new boards mentioned by @michallenc have had the same changes applied to them to remove board_app_initialize.

I am currently just waiting on the CI test to pass locally before running it on upstream (thanks @lupyuen , it works really well!). You can see it here: https://github.com/linguini1/manual-nuttx-ci/actions/runs/25074089470

I unfortunately have no way to test/resolve the issues found with the ESP32-devkitc boards. This is otherwise ready to merge. I would really hate to delay it because it becomes a lot of work to rebase every once in a while, but I would need some help fixing the ESP32 issues. It seems we've so far narrowed it down to SMP configs having issues when initialized through board_late_initialize instead of NSH_ARCHINIT, and this was also a problem on master that had gone undiscovered until now.

@fdcavalcanti the only difference I can see for esp32-devkitc's late initialization process compared to the board_app_initialize on master is the following SMP-related line added to the late init function:

nuttx/boards/xtensa/esp32/esp32-devkitc/src/esp32_boot.c

Lines 86 to 96 in 369755d

	#ifdef CONFIG_SMP
	/* To avoid corrupting the heap, this region of memory (~3KB) is not
	* included until the APP CPU has started.
	* So we can't add it with the rest of the regions at xtensa_add_region(),
	* that function is called early from up_initialize(). We wait until the
	* SMP bringup is complete.
	*/
	umm_addregion((void *)HEAP_REGION_ROMAPP_START,
	(size_t)(HEAP_REGION_ROMAPP_END - HEAP_REGION_ROMAPP_START));
	#endif

If you have time, do you think you could test by:

• Checking out to this patch (byebye-archinit)
• Modifying boards/xtensa/esp32/esp32-devkitc/src/esp32_boot.c to remove everything in th #ifdef CONFIG_SMP guard as shown above
• Trying the same failing SMP configurations you initially tried for esp32-devkitc and report if it still fails? If not, I think we can remove this logic and that might be the fix.

[fdcavalcanti]

Hi @linguini1, please edit the following defconfigs on commit boards: Remove NSH_ARCHINIT and board_app_initialize:

• Board: esp32-devkitc
  • wifi_smp
  • wifi
  • sta_softap
  • spiflash
  • smp
  • mcuboot_update_agent

Set CONFIG_MM_REGIONS=5 instead of 4. That should fix the problem.
Once you do that I can try CI on it again.

[linguini1]

@fdcavalcanti MM_REGIONS=5 has now been added!

[fdcavalcanti]

Seems there are build issues on CI

[linguini1]

Seems there are build issues on CI

@fdcavalcanti I have cancelled the NuttX CI right now as I wait for my local, manual CI to run (to preserve resources). There are currently no build errors for the devkitc, I have just corrected some defconfig files that needed to be refreshed and style issues. I presumed you were referring to running the changes on your Espressif CI, which should be fine to do with the current changes.

[fdcavalcanti]

Yes but I saw some checks on the CI here that failed. Anyway, I tested on the Espressif CI and it seems fine, just do one last change please: edit esp32-devkitc:ble defconfig and set MM_REGIONS=4.

After this we should be good to go. Great job!

[linguini1]

Okay, it should all be good now! Thanks so much for the testing @fdcavalcanti ! I really appreciate your help!