For an APU subsystem only restart, you must define the APU subsystem using PCW in the Vivado design tools. The PMU executes the function to restart the APU subsystem. First, the PMU idles all components in the APU subsystem. When all is quiet, the PMU will reset each component, including the APU processors. When the reset is released, it will re-execute the FSBL code in the OCM. The task carried out by the FSBL for restart differs only slightly than that of the POR.
The following figure shows the APU subsystem restart process.
The start of this flow diagram represents a clean running state. Linux, RPU, PMU, and CSU subsystems are in running status. The health of the APU subsystem is monitored by an APU WDT (watchdog timer). Linux runs a background application which periodically boosts the watchdog to prevent it from timing out. If an APU subsystem hangs, the WDT times out. The timeout interrupts the PMU and results in an APU subsystem restart. Alternatively, you can invoke the APU subsystem restart by directly calling for it in Linux.
Implementation
To support any subsystem restart, a subsystem must first be defined in the Vivado design tools using the Isolation Configuration view. For an APU subsystem running Linux, the following APU subsystem are required in addition to the default PMU subsystem:
- A secure APU system for running the FSBL and TF-A
- A non-secure APU subsystem for running Linux.
See Sub-system Power Management for more information on subsystem configuration and an example of the APU only subsystem.
See GPIO Reset to PL for design issue and guidelines pertaining to using
resetn
signal from PS to PL (ps_resetn
). You
can optionally enable the recovery and escalation features as desired. Building
Software for detailed instructions on building the software.