Hi Matteo,

I will fork the next release branch on 1st of March so that we have 1 month
to test the release.

I propose that we name this release 13.0.0 and we put all planned breacking
changes in the new release

Best regards
Alin

On Thu, 19 Feb 2026, 06:47 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
>

Reply via email to