Uhm, I am a bit afraid this may be too big impact with not much clear benefit? But I may be wrong :-P
Will this process be reversible after change? For instance existing working solutions could still work as before or something will be removed and make this impossible? Would this only impact new in-tree configurations but old out-of-tree will still work unaffected? I agree this process is complex, but still not well documented, which may be source of the problem? I would start with creating good documentation of the current boot process, with detailed steps, diagrams, etc. So we have good reference starting point. Then we may think about optimizations? I did not follow the discussion before well enough sorry, maybe I missed agreements, maybe I am wrong :-P -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Thu, Feb 19, 2026 at 6:47 AM Matteo Golin <[email protected]> wrote: > > Hello everyone, > > I have decided to work on tackling this issue: > https://github.com/apache/nuttx/issues/11321 > > The crux of it is: many boards rely on NSH to initialize > peripherals/board-level systems. This is done through the user-space call > to boardctl(BOARDIOC_INIT). However, BOARD_LATE_INITIALIZE also does the > same thing. This is confusing for many users and also results in boards > having out-of-sync init methods (i.e. late_init does something different > than app_init, but they shouldn't). To simplify the initialization and > reduce user confusion, the suggestion was to completely remove > BOARDIOC_INIT/board_app_initialize and NSH_ARCHINIT in favour of > BOARD_LATE_INITIALIZE. This is a massive breaking change and was put on the > to-do list for 13.0.0 but it hadn't been picked up yet and we're still in > time for 13.0.0. > > I have a draft PR open here to the kernel with most of the boards adhering > to the new changes: https://github.com/apache/nuttx/pull/18408 > > And here to the apps repo removing references to BOARDIOC_INIT and > NSH_ARCHINIT: https://github.com/apache/nuttx-apps/pull/3405 > > These PRs are large, introduce breaking changes, and touch many different > boards (not all of which I am able to test on my limited hardware set). I > would appreciate eyes on these PRs to see if there are any flaws in my > initial approach and also in case anyone would like to volunteer to test > the changes on some hardware (I don't own anything with an STM32 for > instance). > > The CI is also going to report a lot of errors due to the changes being > across both repositories (and they will be out of sync with each other in > the CI runs), hence the importance of testing :) > > Thanks for your feedback in advance (and maybe your time testing if you > can!) > Matteo
