arch/mcx-nxxx: Add support for NXP MCX-N236 CPU

[pussuw]

Summary

This adds minimal support for NXP MCX-N236 CPU. Peripherals supported are:

• GPIO
• PINMUX
• CLOCK
• LPUART

An example board, FRDM-MCXN236 is also added, with a basic profile that boots into nsh.

Impact

No impact on existing code, a new architecture entirely is added with an example board implementation.

Testing

Tested by booting nsh on FRDM-MCX236 evaluation kit.
Ran ostest once.

Final memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena       62928    62928
ordblks         2        5
mxordblk    5b5a0    56c80
uordblks     7380     9ae8
fordblks    5b5a0    58e38
user_main: Exiting
ostest_main: Exiting with status 0
stdio_test: Standard I/O Check: fprintf to stderr
nsh> 

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. While it provides a summary and testing information, it lacks crucial details.

Here's a breakdown of what's missing:

• Summary: While it describes the what, it lacks the why. Why is MCX-N236 support needed? What use cases does it address? The "how" is also too brief. It lists peripherals but doesn't explain how they are implemented (e.g., new drivers, modifications to existing ones). Issue references are missing.

• Impact: The impact section is too general. While it states "no impact on existing code," it needs to address all the specific points:

  • New feature? Yes, explicitly state this.
  • User impact? Likely yes, as a new architecture and board are available. Even if minimal, this should be mentioned.
  • Build impact? Yes, the build system needs to be aware of the new architecture and board. This should be described.
  • Hardware impact? Yes, obviously, as this supports new hardware. Be more specific.
  • Documentation? Does this PR include documentation for the new architecture and board? If not, it should, and this needs to be called out.
  • Security? Even if there's no known security impact, it's good practice to explicitly state that security implications were considered.
  • Compatibility? Likely no impact, but state it explicitly.

• Testing: "No other testing was performed whatsoever" is a red flag. While booting into nsh is a good start, it's insufficient. At a minimum:

  • More Specific Build Host Info: Provide details like the specific Linux distribution, GCC version, etc.
  • More Target Details: Specify the FRDM-MCXN236 configuration used (e.g., clock speed, memory configuration).
  • More Extensive Tests: Test the listed peripherals (GPIO, PINMUX, CLOCK, LPUART) individually. Provide logs for each peripheral test, both before (if applicable) and after the changes. Just booting to nsh doesn't prove these peripherals work correctly.
  • Before Logs: If there were no "before" logs (because the functionality didn't exist), explain that explicitly. Don't just leave the section empty.

In short, the PR needs significantly more detail and more thorough testing before it can be considered complete. It needs to convince reviewers that the changes are well-motivated, correctly implemented, and thoroughly tested.

[hartmannathan]

I don't have this hardware to run actual tests, but the patch merges cleanly, builds successfully, and code LGTM. Only one minor nit (spelling in a comment)... Thanks for adding new architecture and board support!

[hartmannathan]

Suggested change

	/* Enable interrupt on idle and erros */
	/* Enable interrupt on idle and errors */

[cederom]

Thank you @pussuw amazing work!! :-)