AXI Permissions

The AxProt[2:0] (ARPROT and AWPROT, collectively) holds the permission levels for the AXI transaction. AxProt[0] indicates the Privilege level, AxProt[1] indicates Security level, and AxProt[2] indicates whether it's an instruction or data type transaction. The definitions and values are shown in Table 1.

ARPROT:	Read Transaction Permissions

AWPROT:	Write Transaction Permissions

AxProt[1]holds the security level for the AXI transaction. In the Processing System (PS), the TrustZone (TZ) setting for an AXI master is transferred over the AXI3 infrastructure using AxUser[10], but this information is not transferred to the AXI4 PL interfaces. Unfortunately, AxProt[1] does not directly reflect the TZ setting for all masters.

PS masters having a TZ NONSECURE register setting, such as DMAs, use AxProt[1] to communicate the AXI Permission security level in accordance with its TZ setting. Therefore, regardless of whether isolation is enabled in the design, the DMA may be dynamically configured to make AXI transfers with either secure or non-secure AXI Permissions.

The APU sets AxProt bits in accordance with the exception level of the thread requesting the AXI transfer. Bare-metal standalone OS applications always execute at EL3 (AxProt[1]=0) which is AXI secure. Therefore, even if an APU application may be considered non-secure in the Isolated System, its AXI Permissions indicate it as it being secure. This is why you must use Master IDs to control region access authorization. However, APU applications running from a Linux kernel execute at EL0 (AxProt[1]=1) which is non-secure and may be elevated by the OS or hypervisor.

The RPU and PMU do not support multiple exception levels and always operate at EL3. Therefore, you must use the MasterIDs to block their access to a region.