Gave each thread its own MPU window, and made a violation fault

[fdesbiens]

First step towards a ThreadX module port for this core. Before writing a module manager, three questions are worth answering on the actual part: can PMSAv8-R regions be switched per thread, what does that cost, and does a violation actually fault.

What it does

Two threads each own a 4 KB window at the top of DRAM2. The windows are carved out of the broad data region in mpu.c, because isolation is only meaningful in memory no other region already covers — every other region in that map is a wide RW window, so a private buffer inside one would be reachable by every thread whatever else was programmed.

Each thread writes its own window, which must succeed, then reaches for the other thread's, which must fault. The second half is the part that matters: a test that only shows a thread reaching its own memory would pass just as well with no protection at all.

Result

Reproducible across three runs:

thread 0 window 0x3187E000  own: reachable  other: faulted
thread 1 window 0x3187F000  own: reachable  other: faulted
PASS each thread reached its own window and faulted on the other
region switch cost, cycles: 562 to 604

The cost matters for what comes next

A context switch on this part is about 1400 cycles, so switching one region adds roughly 40%. Most of that is the dsb/isb pair rather than the register writes, so a module switch programming several regions should batch the barriers once at the end rather than per region. Worth knowing before the module manager is designed around per-region barriers.

Scope, stated plainly

The window is applied by the thread calling thread_mpu_activate, not by the scheduler. The port's scheduler does call _tx_execution_thread_enter under TX_ENABLE_EXECUTION_CHANGE_NOTIFY, which would make it automatic — but that macro is read by port assembly compiled into the shared threadx library, so enabling it would oblige all nine example targets in this port, including the FVP ones, to supply the four execution hooks. A ThreadX module port carries its own copies of the port assembly for exactly that reason, and that is where the switch belongs.

There is no user mode, no syscall boundary and no loader here. This is a step, not a substitute.

Fault recovery

The fault is survivable the same way the boot probes make it survivable: fault_expected tells the data abort handler to record the violation and resume after the faulting access. That works in thread context because the handler returns where it came from rather than to a fixed recovery point.

Known issue this run exposed, not in this PR

The deep-stack figures from #636 do not reproduce in this image: BTCM spread is ~6,500 against DRAM0's ~6,800, where #636 measured 2,020 against 6,860, and absolute minima moved from 42,868 to 49,520. The cause looks like a gap in #636 — deep_touch is a single placement, never given the alignment sweep that #631 applied to the cache benchmark and #632 to the handler. So #636's 3.4×-tighter-jitter claim should not be relied on until that measurement is alignment-swept. Filed here so it is not lost; it needs its own change.