Visible to Intel only — GUID: fbj1659631532568
Ixiasoft
Visible to Intel only — GUID: fbj1659631532568
Ixiasoft
7.3.1.3. AxPROT[2:0] Considerations
The Arm* Protocol Specification allows AXI* masters to support more than one level of operating privilege and support Secure and Non-secure operating states. AxPROT[2:0] identifies an access according to:
AxPROT | Value | Function |
---|---|---|
[0] | 0 | Unprivileged access |
1 | Privileged access | |
[1] | 0 | Secure access |
1 | Non-secure access | |
[2] | 0 | Data access |
1 | Instruction access |
- EL0 – Application
- EL1 – OS
- EL2 – Hypervisor
- EL3 – Secure Monitor
Both the masters and the HPS must have the same level of Secure/Privilege mode when accessing the same memory. If the MPU is in EL1 (OS) or EL2 (ATF flow U-boot), accesses are using non-secure/privilege mode, hence the master must be using AxPROT set to 0x3 (‘b011). If the MPU is in EL3 (ATF/SPL, non-ATF U-boot), accesses are using secure/privilege mode, hence the master must be using AxPROT set to 0x1 (‘b001).
In the Example Transactions section that follows, the master is always set to AxPROT = (b’001), which allows data, secure, and privileged accesses to all areas of memory, similar to EL3 for the MPU. This example represents an master accessing memory, statically allocated by the Linux kernel at boot time, using the “mem=nn” kernel command line option. For more information on Memory allocation for DMA and the “mem=nn” command line option, refer to the Linux Kernel documentation. Other common examples of the accessing memory, which has been allocated by the Kernel running on the HPS, is Static allocation, Kernel allocation, and User Space allocation. These examples are available on Rocketboards.org.