armv7-m,armv7-r,armv8-m:MPU Add mpu_reset and ARM_MPU_EARLY_RESET

[davids5]

Summary

   When NuttX is booted from a foreign (non NuttX)
   bootloader. There as a possibility that the
   bootloader configured the MPU, in an
   incompatible way for the NuttX memory usage.

   The option to reset the MPU before it is initialized
   may not succeed if the bss and data initialization
   code violated the previous MPU configurations.

   Added herein are ARM_MPU_RESET and
   ARM_MPU_EARLY_RESET. The former can be used
   If the system is capable of booting and running
   NuttX MPU configuration code without an MPU
   violation. The latter is used if the system can
   not run the bss and data initialization code.

   These are options so that a NuttX may be configured to
   not clobber a bootloader MPU configuration in a system
   that is architected to share the MPU configuration task.

Impact

Allows systems with bootloader that configures MPU to boot NuttX.

No impact on existing system as settings Kconfig.

Testing

PX4:
cuav_nora
cuav_x7pro
cubepilot_cubeorange
holybro_durandal-v1
mro_ctrl-zero-h7-oem
mro_ctrl-zero-h7
mro_pixracerpro

[davids5]

@xiaoxiang781216 would you have time to review this?

[patacongo]

Please review the naming conventions here: https://cwiki.apache.org/confluence/display/NUTTX/Naming+of+Architecture%2C+MCU%2C+and+Board+Interfaces

[davids5]

@patacongo - thank you for the reference. Given some of the current code, I am still unclear as the the correct choice.

Should the following mpu_xxx functions be prefixed to `arm_mpu_xx

What would you use in this situation for the naming?

[davids5]

@xiaoxiang781216 - changed the interface as you suggested. I believe all your concerns are addressed.

[davids5]

@xiaoxiang781216 last FP was fixing unused warning

[hartmannathan]

I recently (a few months ago) ran into a dilemma with a bootloader that leaves the MCU in a non-reset state and wondered what to do about it. But then other work happened.

Thanks for adding this.