| Note |
|---|
If you need access to the 2017.4 BSP or the 2017.4 version of this wiki page, please contact your Xilinx FAE for assistance. |
Table of Contents
| Table of Contents |
|---|
Introduction
Zynq UltraScale+ MPSOC supports various type of reset from the simplest system reset to the much more complicated subsystem restart. In any system or subsystem which has a processor component and a programmable logic component, reset must entail both reset to the hardware as well as software. Reset to the hardware includes resetting of the processor, all peripherals associated with the system/subsystem, cleaning up of the memory as needed, and making sure that the interconnect is in a clean state, capable of routing traffic. Reset to the software results in the processor starting from the reset vector. However, designer must make sure that valid and clean code for system/subsystem is located at the reset vector in order to bring the system back to a clean running state.
Resets for Zynq UltraScale+ are broadly divided into two categories, full system resets and subsystem restarts. Full system resets include Power On Reset (POR), system-reset and PS-only-reset. Subsystem restarts include APU subsystems and RPU subsystem restarts. A subsystem in Zynq UltraScale+ is composed of all of the components of a particular operating system. This page describes an example of how to design a project with multiple subsystems in it, and how to cleanly reset each one.
Subsystem Steps
The following steps describe how to implement subsystem restart. For more details on any of these steps, refer to UG1137 Software Developer's Guide, Chapter 12. Refer to the next section for a detailed example.
- Define the subsystem using the isolation configuration menu in Vivado and export to hdf.
- Prepare Petalinux project with following changes w.r.t default 2018.3 bsp
- Modify device tree source file (dts) of Linux to exclude PL IPs that are not part of APU subsystem.
- Add rpu_firmware application binaries
- Add remoteproc.dtsi to allow remoteproc to load the rpu binaries
- Add pmu-fw and ATF flags to enable warm restart, recovery, escalation
- Add pmu-fw code patches to idle PL peripheral for given master
- For RPU subsystem restart, make PM aware rpu applications. Make linker script inline with remoteproc.dtsi
- Build using Petalinux.
Note: If none of the peripheral idling, recovery or escalation features are needed then there is no requirement to define the subsystem in isolation configuration.
PS only and System restart can be triggered from Linux directly. Though APU subsystem restart without peripheral idling is not recommended and can have adverse effect.
An Example
The following figure shows the example design described by this document. It consists of an APU subsystem, RPU subsystem, and miscellaneous PL connections. It was built from the Xilinx ZCU102 Board Support Package (BSP) hardware design, and enhanced to have more hardware components added and isolation enabled.
...
One can observe BRAM contents not changing across APU only and PS only reboot.
To start rpu0 application:
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ echo r50_app > /sys/class/remoteproc/remoteproc0/firmware $ echo start > /sys/class/remoteproc/remoteproc0/state |
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ echo r51_app > /sys/class/remoteproc/remoteproc1/firmware $ echo start > /sys/class/remoteproc/remoteproc1/state |
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ echo stop > /sys/class/remoteproc/remoteproc0/state |
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ echo stop > /sys/class/remoteproc/remoteproc1/state |
Recovery and Escalations
In many use cases, recovery and escalation are turned on as they are critical for getting back into a healthy state when the system is hung. This example design also has them enabled.
...