APU Subsystem Restart - 2020.2 English

Zynq UltraScale+ MPSoC Software Developer Guide (UG1137)
Document ID
UG1137
Release Date
2021-01-05
Version
2020.2 English

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.

Note: The FSBL is re-entrant. Hence, the APU can simply re-execute the FSBL without having to reload a clean copy.

The following figure shows the APU subsystem restart process.

Figure 1. 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 ATF
  • 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.

Important: While APU subsystem consists solely of PS components, it is often the case that APU subsystem also includes IP peripherals implemented in PL. Unfortunately, isolation configuration menu does not include features to assign PL IPs to different subsystems. As a result, all IPs instantiated in Vivado are added to the generated device tree source (DTS) file. In order to properly define the APU subsystem, all PL IPs that do not belong in the APU subsystem need to be manually removed from the DTS file. Otherwise, drivers for all the soft IPs will be enabled for Linux, and APU will attempt to manage all the soft IPs even when the APU is going through a warm restart.
Important: During a subsystem restart, all components in the subsystem must be in the idle state, followed by reset. This is implemented for supported components in the PS. For all IPs in PL of a subsystem that are AXI slaves, no additional tasks are required to idle them. You may supply code to reset these slaves if desired. For PL IPs that are AXI masters, you must provide the necessary code to stop and complete all AXI transactions from the master as well as to reset it. See Idle and Reset of Peripherals for details on adding the idle and reset code.

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.