soc: xlnx: zynqmp: exception vectors MPU entry invalid if SRAM base address is 0x0

[ibirnbaum]

Describe the bug

With the current MPU regions setup specified at the ZynqMP SoC level, builds for targets which use 0x0 as the SRAM base address (which is not advisable due to the special quality of the ATCM and BTCM memory areas, but still, it could work depending on the CPU configuration) will fail once the MPU is enabled due to a MPU region priority error:

• the MPU region entry for the exception vectors @ 0x0 is the first MPU region entry and is configured as P:RO, U:NA non-cachable
• the SRAM region entry is the second entry and is configured as P:RW, U:NA, XN, cacheable.

If the SRAM base address is 0x0, those two entries overlap, which is supported by the MPU, however, the region configuration with the highest region index is the effective one when more than region entry exists for a particular address. Therefore, the generic SRAM region configuration overrules the vectors region configuration, making the exception vectors not only writable but also non-executable, causing the system to crash once the first exception is to be handled after enabling the MPU. This is effectively an error of the MPU region ordering. The rom_region setup is correct however, being ordered after the sram region.

Regression

• This is a regression.

Steps to reproduce

Can't be reproduced with in-tree ZynqMP-based hardware at the time being, and the qemu_cortex_r5 QEMU version doesn't seem to care about this issue (also doesn't care about memory that's unavailable on actual hardware). Current qemu_cortex_r5 is also not affected due to having a non-zero SRAM base address. Tested with a ZCU102 board.

Relevant log output

Impact

Major – Severely degrades functionality; workaround is difficult or unavailable.

Environment

Host OS: Ubuntu 24
Zephyr: current main
SDK: 0.16.4

Additional Context

No response