RPU Subsystem Restart - 2022.2 English

Zynq UltraScale+ MPSoC Software Developer Guide (UG1137)

Document ID
UG1137
Release Date
2022-11-02
Version
2022.2 English

RPU as Master

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

Note: RPU only subsystem restart is supported only with FSBL running on RPU just as 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.

Once all the subsystems have started and represent a clean running state, the health of the RPU subsystem can be monitored using an LPD WDT (watchdog timer) by an application running on 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 RPU subsystem restart. For more information, see the LPD WDT section.

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

Implementation

The implementation is same as APU only subsystem restart except that 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 RPU running an FSBL and RPU application in addition to 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 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. 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 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 command, RPU watchdog timeout or message from the RPU to APU via message pipe may trigger the RPU subsystem restart. Then, APU issues remoteproc command to 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 above diagram represents a clean running state for all subsystems, Linux, RPU, PMU and CSU. In the flowchart, APU receives a RPU subsystem restart request. When APU receives the restart request, it uses remoteproc features to stop the RPU subsystem, load new firmware code, and then starts the RPU subsystem again. The flow chart shows the use of a RPU WDT. The RPU periodically boosts the watch dog. If the RPU hangs, WDT times out. Linux will receive the timeout and restarts the RPU subsystem.

Implementation

You must define the RPU subsystem using the Isolation Configuration view in Vivado PCW, and both PMU and APU subsystems are required. In addition, two configurations are possible for the RPU subsystem: RPUs in lock step mode or in split mode. See the Isolation Configuration Consideration wiki page for more information on subsystem configuration. Sharing of peripherals between subsystems are not supported. Make sure that the peripherals in all subsystems are mutually exclusive.

Important: In the process of 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. User may supply code to reset the slaves if desired. For PL IPs that are AXI masters, user 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.

RPU subsystem restart is supported with Linux kernel implementation of remoteproc on APU in conjunction with OpenAMP library on RPU. It is currently not supported with Linux userspace OpenAMP library on APU. RPU application must be written in accordance with the OpenAMP application requirements. See Libmetal and OpenAMP for Zynq Devices User Guide (UG1186) for more information. Note that the rpmsg is not required for remoteproc. You can employ rpmsg feature to provide a communication pipe between the two processors. However, remoteproc is independent of rpmsg. To make remoteproc function properly with subsystem restart, RPU application needs to include a resource table with static shared memory allocation. 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 Libmetal and OpenAMP for Zynq Devices User Guide (UG1186) to satisfy the remoteproc requirement, but not beyond that. After initialization, the RPU application needs to signal to the PMU that it is Power Management (PM) aware by calling XPm_InitFinalize().

Note: If you call XPm_InitFinalize() too early, then the slaves that are not yet initialized are powered off. They will be powered up again when the RPU application comes around to initialize them, which will incur some additional power-up latency. See 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.