!apps: Simplify NuttX initialization

[linguini1]

Summary

BREAKING:

In an effort to simplify board initialization logic for NuttX, NSH will no longer support architecture initialization. This will happen during boot via the BOARD_LATE_INITIALIZE option. The boardctl command BOARDIOC_INIT is also no longer available from user-space.

Quick fix: Any application relying on BOARDIOC_INIT should now enable BOARD_LATE_INITIALIZE to have initialization performed by the kernel in advance of the application running. If control over initialization is still necessary, BOARDIOC_FINALINIT should be implemented and used. Boards relying on NSH for initialization should also enable BOARD_LATE_INITIALIZE instead.

Part of apache/nuttx#11321.

To be merged with twin PR to NuttX kernel: apache/nuttx#18408

Impact

This reduces the complexity of NuttX initialization by keeping it within the
kernel logic for the normal case. Users can still control initialization from
their application using BOARDIOC_FINALINIT instead.

This impacts almost every NuttX supported board, as many configurations relied
on NSH for initialization. This also impacts each application in the diff which
relied on BOARDIOC_INIT.

Testing

• NSH: tested by twin PR (see below)
• LVGL Demo: tested using raspberrypi-4b:lvgl (see image)

Testing of modified NuttX kernel defconfigs can be found in the twin PR: apache/nuttx#18408

[linguini1]

NOTE: The CI will always fail since it will be using a version of NuttX where the defconfigs still contain references to NSH_ARCHINIT.

[acassis]

@linguini1 @jerpelea since we need to wait until March 1 before including the breaking features that will not be in NuttX 13.x. I will change this PR to Draft to avoid someone accidentally merge it.

[cederom]

Thank you @linguini1 :-)

[jerpelea]

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

[acassis]

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

Alin, did you already created the branch 12.13? Otherwise this commit here will be in that 12.x branch, but we don't want it to happen, right?

[linguini1]

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

Hi @jerpelea, let's merge these after the branch out so that it will be in the June 1 release instead (hopefully with more of the other breaking changes)

[acassis]

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

Hi @jerpelea, let's merge these after the branch out so that it will be in the June 1 release instead (hopefully with more of the other breaking changes)

@linguini1 @jerpelea do you think it makes sense to create a unstable branch now, just to add these breaking changes? I think it will be strange to have this breaking changes into mainline now, because most of NuttX users think the main stream is stable.

@xiaoxiang781216 @raiden00pl @cederom @lupyuen @simbit18 @hartmannathan please comment what you think about it? Historically we never had a dev or unstable branch, but maybe in this case it could make more sense because these breaking only should appear into mainline on June

[linguini1]

Hi Alan, I think it's a good idea to put the breaking changes into main once the March 1 release is branched out. I did consider your concern on the mailing list when this was discussed, but it appears a dev branch is not part of the NuttX workflow.

The mainline has never been stable in my experience, and having the change in main will also mean it will be tested by those using the "cutting edge". Practically, I think nothing would be tested if it was on a dev branch. I would still appreciate help testing these patches further (on different targets/those people who are familiar with how to use some of the apps you mentioned earlier). These patches should only break things for users that have out-of-tree boards and custom apps using BOARDIOC_INIT.

[acassis]

Hi Alan, I think it's a good idea to put the breaking changes into main once the March 1 release is branched out. I did consider your concern on the mailing list when this was discussed, but it appears a dev branch is not part of the NuttX workflow.

The mainline has never been stable in my experience, and having the change in main will also mean it will be tested by those using the "cutting edge". Practically, I think nothing would be tested if it was on a dev branch. I would still appreciate help testing these patches further (on different targets/those people who are familiar with how to use some of the apps you mentioned earlier). These patches should only break things for users that have out-of-tree boards and custom apps using BOARDIOC_INIT.

Perfect! Something we need to consider is adding some warning at end of the building process explain: you are using a development version, be aware it could have bugs and breaking changes.

[raiden00pl]

main branch has never been stable on NuttX and we do not have the resources to maintain an additional unstable branch.

My opinion on breaking changes and bugs on master has been the same from the beginning: it's part of the software life cycle, there's no point in worrying about it too much, especially since we don't have the resources to handle it better.