RPU Subsystem Restart - 2025.1 English - UG1137

Zynq UltraScale+ MPSoC Software Developer Guide (UG1137)
Document ID
UG1137
Release Date
2025-06-25
Version
2025.1 English

RPU as Master

For an RPU subsystem only restart, you must define the RPU subsystem using PCW in the AMD Vivado™ Design Suite. The PMU executes the function to restart the RPU subsystem. First, the PMU checks if master's RPU and FSBL were initially running on the RPU. Then the PMU idles all components in the RPU subsystem. When all is quiet, the PMU resets each component, including the RPU processors. When the reset is released, it re-executes the FSBL code. FSBL for subsystem restart loads only the RPU partitions without interrupting other subsystems.

Note: RPU-only subsystem restart is supported only with the FSBL running on the RPU as the APU-only restart. Here the FSBL is re-entrant. Hence, the RPU can simply re-execute the FSBL without having to reload a clean copy.

After all the subsystems have started and represent a clean running state, the health of the RPU subsystem can be monitored using an LPD watchdog timer (WDT) by an application running on the RPU. This application must take care of boosting the watchdog to prevent it from timing out. If an RPU subsystem hangs, this WDT times out and interrupts the PMU, which results in the RPU subsystem restart.

Alternatively, you can invoke the RPU subsystem restart by directly calling for it in the RPU application.

Implementation

Implementation is the same as the APU-only subsystem restart except that the RPU subsystem must be defined in the Vivado Design Suite using the isolation configuration view.
Note: To support any subsystem restart, a subsystem must first be defined in the Vivado design tools using the isolation configuration view.

The RPU subsystem requires that the RPU is running an FSBL and RPU application in addition to the PMU subsystem. See Subsystem Power Management for more information on subsystem configuration and an example of the APU-only subsystem.

Important: During a subsystem restart, all components in the subsystem must be in the idle state, followed by a 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 can 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 issues and guidelines pertaining to using the resetn signal from PS to PL (ps_resetn). Optionally, you can enable the recovery and escalation features as desired. See Building Software for detailed instructions on building the software.

APU as Master

RPU subsystem restart requires the APU subsystem and one or more RPU subsystems are running in lock-step or split mode. The APU subsystem running Linux is the master of the RPU subsystems and manages the life cycle of the subsystem using the remoteproc feature of OpenAMP. APU uses remoteproc to load, start, and stop the RPU application. It also re-syncs the APU subsystem with RPU subsystem after the restart. APU subsystem can trigger a RPU restart by following sequence:

  1. First, it stops the RPU
  2. Loads the new firmware
  3. Then, it starts the RPU again.

Many events, including user commands, RPU watchdog timeouts, or messages from the RPU to the APU through the message pipe, can trigger a restart of the RPU subsystem. In response, the APU issues a remoteproc command to the PMU to start or stop the RPU, and the PMU changes the state of the RPU subsystem.

The following figure shows the RPU subsystem restart process.

Figure 1. RPU Subsystem Restart

The start of the previous diagram represents a clean, running state for all subsystems: Linux, RPU, PMU, and CSU. In the flowchart, the APU receives a restart request for the RPU subsystem. Upon receiving the restart request, the APU uses remoteproc features to stop the RPU subsystem, load new firmware code, and then restart the RPU subsystem. The flowchart also depicts the use of an RPU WDT. The RPU periodically resets the watchdog. If the RPU becomes unresponsive, the WDT times out. Linux receives the timeout signal and restarts the RPU subsystem.

Implementation

You must define the RPU subsystem using the isolation configuration view in the PCW, and both PMU and APU subsystems are required. Additionally, there are two configurations possible for the RPU subsystem: RPUs in lock-step mode or in split mode. Refer to the Isolation Configuration Consideration Wiki page for more information on subsystem configuration. Sharing of peripherals between subsystems is not supported, so ensure that the peripherals in all subsystems are mutually exclusive.

Important: In the process of restarting the subsystem, all components within the subsystem must be in the idle state, followed by a reset. This is implemented for the supported components in the PS. For all IPs in the PL of a subsystem that are AXI slaves, no additional tasks are required to idle them; you can provide code to reset the 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. Refer to Idle and Reset of Peripherals for details on adding the idle and reset code.

The RPU subsystem restart is supported with the Linux kernel implementation of remoteproc on the APU in conjunction with the OpenAMP library on the RPU. However, it is currently not supported with the Linux userspace OpenAMP library on the APU. The RPU application must be written in accordance with the OpenAMP application requirements. For more information, refer to the Libmetal and OpenAMP for Zynq Devices User Guide (UG1186).

The rpmsg feature is not required for remoteproc, however, you can use rpmsg to provide a communication pipe between the two processors. It is important to note that remoteproc is independent of rpmsg. To ensure proper functionality of remoteproc with subsystem restart, the RPU application needs to include a resource table with static shared memory allocation, as dynamic shared memory allocation is not supported for subsystem restart. You must implement the steps outlined in How to Write a Simple OpenAMP Application in the Libmetal and OpenAMP for Zynq Devices User Guide (UG1186) to meet the remoteproc requirements, but not beyond that. After initialization, the RPU application needs to signal to the PMU that it is power management (PM) aware by callingXPm_InitFinalize()

Note: If you call XPm_InitFinalize() too early, then the slaves that are not yet initialized are powered off. They power up again when the RPU application comes around to initialize them, which incurs some additional power-up latency. See the ZU+ Example - PM Hello World Wiki page for more information on how to write a PM aware RPU application.

Finally, you must ensure that the address of the reserved memory for RPU code is synchronized across all layers. It must be defined under memory for both APU and RPU subsystems in the isolation configuration of Vivado. The same address region should be used in the DTS file for OpenAMP overlay in Linux and again, in resource table and linker script for the RPU application.

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.