feat(mpu): Cortex-R4F MPU (CP15) configuration driver #126

New issue

Closed

opened 2026-07-23 23:15:37 +00:00 by hoogv · 0 comments

hoogv commented

2026-07-23 23:15:37 +00:00

Owner

Found bringing up a downstream consumer project (awr6843_mss_barebones_example) on real AWR6843AOP hardware.

hal_soc_init() (hal/mss/soc/hal_soc.c) does not configure the MPU at all -- it only does BSS clock bring-up and the secure firewall. This project's own startup code disables the MPU entirely and leaves it that way. Confirmed on real hardware, via a controlled bisection, that this is NOT equivalent to an explicit MPU region table for peripheral-register sequences that depend on write ordering: hal_pinmux_set_pin_function()'s kick-unlock/write/kick-lock sequence (see issue #122/PR #123) silently failed to reach the pad with the MPU left disabled, and started working once peripheral space was explicitly marked Strongly-Ordered via an MPU region -- a plain "MPU disabled = unrestricted access" default apparently doesn't guarantee write ordering the way an explicit Strongly-Ordered region does.

Add a new hal_mpu driver (ENABLE_MPU_MODULE) with hal_mpu_config(): disables the MPU, programs a 12-region table (background/TCMA/TCMB/ext-flash/QSPI/peripheral-space/mailbox/HSRAM/EDMA/L3/ADCBUF/SW-buffer -- the peripheral-space region, covering both MSS_IOMUX and MSS_GIO, is Strongly-Ordered, the region that turned out to matter), then re-enables it. Not called automatically by hal_soc_init() -- a consumer calls it explicitly, before hal_soc_init(), if it touches peripherals with write-ordering-sensitive register sequences (which is most of them).

Values/order are a direct transliteration of a hardware-confirmed sibling project's own MPU bring-up (AWR6xxx_Toolchain's Universal_hal, soc_iwr68xx.c's mpu_config()) -- not independently re-derived from a TRM section (none was available to this project covering MPU region layout for this device).

Note on testability: this is CPU-core state (CP15 coprocessor registers), not a memory-mapped peripheral -- unlike every other driver in this HAL, hal_mpu_config()'s actual register writes cannot be exercised by a host unit test (no x86 equivalent to mcr/mrc). The region table itself is exposed as plain data (hal_mpu_region_table) and is what's host-tested.

Found bringing up a downstream consumer project (`awr6843_mss_barebones_example`) on real AWR6843AOP hardware. `hal_soc_init()` (`hal/mss/soc/hal_soc.c`) does not configure the MPU at all -- it only does BSS clock bring-up and the secure firewall. This project's own startup code disables the MPU entirely and leaves it that way. Confirmed on real hardware, via a controlled bisection, that this is NOT equivalent to an explicit MPU region table for peripheral-register sequences that depend on write ordering: `hal_pinmux_set_pin_function()`'s kick-unlock/write/kick-lock sequence (see issue #122/PR #123) silently failed to reach the pad with the MPU left disabled, and started working once peripheral space was explicitly marked Strongly-Ordered via an MPU region -- a plain "MPU disabled = unrestricted access" default apparently doesn't guarantee write ordering the way an explicit Strongly-Ordered region does. Add a new `hal_mpu` driver (`ENABLE_MPU_MODULE`) with `hal_mpu_config()`: disables the MPU, programs a 12-region table (background/TCMA/TCMB/ext-flash/QSPI/peripheral-space/mailbox/HSRAM/EDMA/L3/ADCBUF/SW-buffer -- the peripheral-space region, covering both MSS_IOMUX and MSS_GIO, is Strongly-Ordered, the region that turned out to matter), then re-enables it. Not called automatically by `hal_soc_init()` -- a consumer calls it explicitly, before `hal_soc_init()`, if it touches peripherals with write-ordering-sensitive register sequences (which is most of them). Values/order are a direct transliteration of a hardware-confirmed sibling project's own MPU bring-up (`AWR6xxx_Toolchain`'s `Universal_hal`, `soc_iwr68xx.c`'s `mpu_config()`) -- not independently re-derived from a TRM section (none was available to this project covering MPU region layout for this device). Note on testability: this is CPU-core state (CP15 coprocessor registers), not a memory-mapped peripheral -- unlike every other driver in this HAL, `hal_mpu_config()`'s actual register writes cannot be exercised by a host unit test (no x86 equivalent to `mcr`/`mrc`). The region table itself is exposed as plain data (`hal_mpu_region_table`) and is what's host-tested.

hoogv referenced this issue from a commit

2026-07-23 23:15:56 +00:00

feat(mpu): Cortex-R4F MPU (CP15) configuration driver

hoogv referenced this issue from a pull request that will close it,

2026-07-23 23:16:08 +00:00

feat(mpu): Cortex-R4F MPU (CP15) configuration driver #127

hoogv closed this issue

2026-07-23 23:16:15 +00:00