The S32Z280 example BSP comments contradict the code and each other

[fdesbiens]

The S32Z280-594EVB example board support package under ports/cortex_r52/gnu/example_build/s32z280_evb/ carries several comments that contradict either the code beside them or each other. They describe the exact MPU and memory behaviour that anyone auditing the protection boundary has to reason about, which makes them more costly than ordinary comment rot.

The contradictions

mpu.h:42-63 — obsolete access-permission calibration. The header opens with a block stating that PRBAR.AP occupies bits 3:2 and that the encoding is reversed from the architecture, presented as calibrated against hardware. Immediately below it, the correct description follows: AP[2:1], where AP[2] selects read-only and AP[1] grants EL0 access, with a note that the reversal was an artefact of earlier code shifting AP into the wrong bits. The first block is false and should be deleted. Left in place it tells the next reader the architecture is bit-reversed, which is exactly the mistake that produced silently writable read-only regions the first time.

mpu.c:49-65 — duplicated block. #include "platform.h", the progress-marker comment, the probe_stage declaration and the MARK macro all appear twice in succession.

mpu.c:395-412 — TCM mapping. States that BTCM and CTCM are disabled and unmapped, then maps BTCM. Current startup enables BTCM.

link.lds:31-33 — TCM usage. States the TCMs are unused, while the same script defines ATCM and BTCM sections and places content in them.

mpu.c:460-483 — module window ownership. States the module window is opened only around a load. In the current design the window is owned by the scheduler, which opens it for any thread that does not own a module and closes it for one that does.

mpu.h:98-105 — what mpu_init() does. States that it enables both caches. The implementation enables the MPU and leaves cache enable to cache.c.

Two related items to fold in

Region-overlap wording. Two comments in the example board support packages describe an access matching more than one enabled MPU region as UNPREDICTABLE:

• ports/cortex_r52/gnu/example_build/s32z280_evb/mpu.c:100 — "PMSAv8-R makes overlapping regions UNPREDICTABLE"
• ports/cortex_r52/gnu/example_build/fvp_baser_aemv8r/mpu.h:57 — "shareability the TRM defines as UNPREDICTABLE"

Both date from #606. Cortex-R52 TRM r1p3 section 8.1 specifies the behaviour instead: "A translation fault is taken for the following reasons: If an access hits in more than one region in one of the MPUs." The abort observed on the S32Z280 is the architected result, not a part-specific resolution of unpredictable behaviour. The mutual-exclusion design that rests on it is correct and should stay; only the rationale needs correcting, so that a deterministic protection fault is not mistaken for silicon calibration behaviour.

Region-count check. The FVP mpu_init() enforces the module manager's 17-region minimum. The S32Z280 implementation checks only that its own eight boot regions fit, then programs region 16 unconditionally. The S32Z2 reference manual section 6.3.1.2 guarantees 20 EL1 regions on this part, so this is not a live failure, but the general claim that both board support packages refuse a shortfall is inaccurate. Either add the same check, or narrow the documentation to the fixed S32Z280 configuration.

[fdesbiens]

Narrowed the region-overlap item. As filed it read as though the wording were spread across the board support packages generally; two of the occurrences it would have covered were introduced by #639 and have since been corrected there, so claiming them here would have left this issue asking for work already done. What remains is exactly two lines, both from #606 and both outside that PR's diff, and they are now named with their text. The rest of the issue is unchanged.