APU Fault Injection Test

Memory and Peripheral Protection Unit for PL Isolation in Zynq UltraScale+ Devices (XAPP1353)

Document ID
XAPP1353
Release Date
2022-05-04
Revision
1.1 English
  • Copy the BOOT.bin file for the APU fault injection application as follows to the SD card:
    <build_path>/apu_fault_injection/BOOT.bin
  • Place the SD Card into the socket J100 and power the board
    • After completing initial boot, the fault injection test runs and displays its output to terminals 0 and 1 as shown in the following figure. Term 0 shows the APU output, and term 1 shows the APU output.
Figure 1. APU Fault Injection Output

The read/write address tests shown in term 0 must either PASS or FAIL in correspondence to the isolation layout of the system. You can refer to figure 14 for further clarity.

The APU is designated non-secure, and hence can successfully read/write to NS (non-secure) and NS_SHARED (non-secure shared with secure) memory and peripherals. Each time a test fails, a violation is reported by the PMU in term 1.

Figure 2. PL Memory and Peripheral Test Results (APU)

Examine the term 0 output for the PL memory and peripheral tests, shown in the previous figure. The failed test, on PL_BRAM_S_BASE, violations are reported in term 1, as shown in the following figure.

Figure 3. PL Address Violations in APU
Note: There is one read permission violation and one write permission violation including the address and originating master ID. ErrorId:8 corresponds to activity detected on the pmu_error_from_pl port used by the zupl_xmpu_v1_0 irq port, in the PL design, to communicate interrupts to the PMU. The code to respond to this interrupt type has been added to the PMU firmware. You can refer to A closer Look at the Platform Management Unit (PMU) for a detailed understanding of how this was accomplished.

Examining the PL Peripherals tests leads to discovering that the read/write tests to the secure address PL_XMPU_S_START did not FAIL. This is only because these access attempts did not result in an AXI violation. The XMPU_PL was configured to Lock Out configuration changes by any master not authorized by the LOCK_BYPASS register.

Although the APU can read the configuration registers, any write attempts are ignored, however, the AXI transaction is processed without error.

The final test from term 0 is to unlock the XMPU_PL Configuration.

Figure 4. Unlock XMPU_PL (APU)

As shown in the previous figure, the LOCK register is read and indicates the status as locked. An attempt to clear the register is performed and then re-read. The attempt to write 0x0 to the register is ignored, and the lock remains active.

Tip: The PL design can be altered to completely isolate the S_AXI_XMPU slave configuration port of the zupl_xmpu_v1_0 core and block all read and write access from the unauthorized masters. An example of this is shown in the Isolating the XMPU_PL Configuration from the XMPU_PL Usage Examples section. This is left as an exercise for the reader.