RPU Fault Injection Test

Copy the BOOT.bin file for the RPU fault injection application <build_path>/rpu_fault_injection/BOOT.bin to the SD Card, 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 RPU output.

Figure 1. RPU Fault Injection Output

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

The RPU 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 0.

Figure 2. PL Memory and Peripherals Test Results (RPU)

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 RPU

You can refer to A closer Look at the Platform Management Unit (PMU) for a detailed understanding of how this was accomplished.

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

Figure 4. Unlock XMPU_PL (RPU)

As shown in the previous figure, the LOCK register is read and indicates the status as locked. The register is cleared and then re-read. The RPU is an authorized master in the LOCK_BYPASS registers and retains write privileges to the XMPU_PL configuration registers.