I was wondering what the memory map of an SOC that includes a ARMv8-M TrustZone enabled system would like. Is it fixed or is it variable ? Based on the ARMv8-M ARM, it appears that things like the SAU, MPU, NVIC etc are all memory mapped and are expected to be at fixed address. Does this mean there is one SAU and one MPU for an entire SOC even if it includes multiple ARMv8-M cores?
section b7.1 of the ARMv8-M ARM has a system address map which defines addresses and the memory properties. If this address map is fixed, why do we need an MPU which has configurable regions with different memory attributes ?
The answer to this question depends on how the SoC has been configured. If the MPU is not chosen as a configuration option, then the SoC will end up using the default ARMv8-M memory map shown in the chapter titled "B6.1 Address map" from ARMv8-M Architecture Reference Manual (ARM DDI 0553A.a) currently available at: developer.arm.com/.../armv8-m-architecture-reference-manual If the MPU is chosen as a configuration option, then the SoC resets using the default memory map, but software can program the MPU to change the memory map settings at runtime, for example, create regions with different access permissions, e.g., Read-Only, Read-Write or eXecute Never, or regions with different cacheable properties, or regions that can be shared with other masters in the same system. The processor's private peripheral registers are accessed via a Private Peripheral Bus (PPB), which maps onto a 1MB region (0xE0000000-0xE00FFFFF) within the System space. Peripheral registers like the NVIC, MPU and SAU registers always appear at the same locations in the memory as far as the programmer is concerned, despite any changes to the MPU configuration. This is confirmed by rule RMNSK in the ARMv8-M Reference Manual: "Accesses to the Private Peripheral Bus (PPB) always use the default system address map." A system that is configured with the Security Extension will contain an SAU (Secure Attribution Unit) and probably an IDAU (Implementation Defined Attribution Unit). The SoC designer can decide whether the SAU configures all memory as Secure at reset, by ensuring that the SAU_CTRL.ALLNS register is always reset to zero, setting all memory, apart from some specific regions in the PPB space, to Secure state. This is true for Cortex-M33 and Cortex-M23 processors. Setting SAU_CTRL.ALLNS bit to zero prevents an external IDAU (Implementation Defined Attribution Unit) overriding any security level. If the SoC designer decides that the SAU_CTRL.ALLNS register is always reset to 1, then it is up to the IDAU to determine the default security settings at reset. At runtime, the SAU can be reconfigured by secure software. The IDAU is implementation defined so it is up to the SoC designer as to whether it is programmable. The IDAU in SDK-200 is fixed and cannot be reprogrammed. It has been evenly split into 16 separate regions so that it can simply use bit 28 of the address to establish whether an access is secure or non-secure. community.arm.com/.../your-questions-answered-secure-iot-system-on-armv8-m Finally, to answer your question about multi-processor systems, each Processing Element in a SoC, for example, a Cortex-M33 processor, has its own MPU and SAU. I hope this answer helps. Let me know if you have any further questions.
You're welcome. In addition to what Pete said with regard to 4), a slightly more convoluted but possibly cheaper solution would be to connect the same interrupt source to both processors' NVICs. The software would then need to determine which processor handles that interrupt. For example, the corresponding interrupt handlers (for both processors) could use a mutex to ensure that both processors don't end up trying to work with the same peripheral at the same time.