Zynq UltraScale Plus Restart solution

Explicit software action needed to run MBIST
System reset can be initiated by Linux command or watchdog timeout or PMU error management block.
For users interested in only system reset without apu/rpu subsystem restart, no subsystem/isolation configuration is required. Linux commands for setting reboot type and reboot will work without additional modifications.
Idle and Reset of PeripheralsIdle and Reset of Peripherals
As explained above, it is necessary to stop/complete any ongoing transaction by any IP or processor of the subsystem before resetting them, otherwise it may lead to hanging of the interconnect and eventually hanging of the entire system. Also to ensure proper operation by the IP after reboot, it is best to reset them and bring them to post bootrom state.
Note:
Refer GPIO reset to PL section to understand the implication of GPIO reset.
PS peripherals are also idled inIn the case of PS onlyuser invoked reboot of ps-only and System reset.system-reset command, PS peripherals are idled prior to invoking resets.
Custom Hooks
PMU firmware does not keep track of PL peripherals, hence there is not reset of idle/reset function implementations available in the pmu-firmware. But it is necessary to treat those peripherals in the same way we treated PS peripheral. One can add a custom hook in the idle_hooks.c file to idle PL peripheral and reset them. This hooks can be called from PmMasterIdleSlaves function in pm_master.c file of pmu firmware.
Recovering from a Hang System
RecoveryRecovery
system hang, the subsystemas indicated by FPT WDT timeout, PMU can be restarted.used to carry out a sequence of events to try and recover from the unresponsive condition. By default, when FPD WDt times out, PMU FW will not invoke any type of restart. This is termed recovery.so that user can specify the exact desired behaviort. However, Xilinx provides a typical recovery scheme in which PMU firmware can monitormonitors the state Linux. This featurescheme is not enabled by defaulttermed recovery and needs to be enabled at the build time.
This section explains the recovery for APU hang. Sincemethod of enabling this feature is detailed below.
Since RPU subsystem
To enable recovery, PMU firmware should be built with error management enable and recovery enabled. Following macros enables the Recovery feature.
ENABLE_EM
The last core just before going into WFI will issue pm_system_shutdown (PMU Firmware API) to pmu-firmware, which then will do APU only restart flow.
This feature must be enabled in ATF for recovery to work properly. It can be enabled by building ATF with ZYNQMP_WARM_RESTART=1 flag.
Modifying Recovery Scheme
When ENABLE_RECOVERY is turned on, Xilinx provides an recovery implementation in which a FPD WDT timeout results in the invocation of APU subsystem restart. User can easily modify the recovery behavior by modifying the code. Alternatively, an example of PMU FW invoking system-reset on FPD WDT timeout is detailed in AR #96463
EscalationEscalation
In the event where current recovery could not bring the system back to the working state, the system should escalate to a more severe type of reset on the next WDT expiry in order to try and recovery fully. It is up to the user to decide on the escalation scheme. A commonly used scheme starts with apu-restart on the first watchdog expiration, followed by ps-only reset on the next watchdog expiration, then finally system-reset.