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.
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 RPU subsystem requires RPU running an FSBL and RPU application in addition to PMU subsystem. 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. 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:
- First, it stops the RPU
- Loads the new firmware
- 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.
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.
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()
.
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.