On Mon, Jun 29, 2026 at 05:48:04PM -0700, Tanmay Shah wrote: > Remote processor can crash or hang during normal execution. Linux > remoteproc framework supports different mechanisms to recover the > remote processor and re-establish the RPMsg communication in such case. > > Crash reporting on AMD-Xilinx platform: > > 1) Using debugfs node > > User can report the crash to the core framework via debugfs node using > following command: > > echo 1 > /sys/kernel/debug/remoteproc/remoteproc0/crash > > 2) Remoteproc notify to the host about crash state and crash reason > via the resource table > > This is a platform specific method where the remote firmware contains > vendor specific resource to update the crash state and the crash > reason. Then the remote notifies the crash to the host via mailbox > notification. The host then will check this resource on every mbox > notification and reports the crash to the core framework if needed. > > Crash recovery mechanism on AMD-Xilnx platform: > > There are two mechanisms available to recover the remote processor from > the crash. 1) boot recovery, 2) attach on recovery > > Remoteproc core framework will choose proper mechanism based on the > rproc features set by the platform driver. > > 1) Boot recovery > > This is the default mechanism to recover the remote processor. > In this method core framework will first stop the remote processor, > load the firmware again and then starts the remote processor. On > AMD-Xilinx platforms this method is supported. The default coredump > method is supported. > > 2) Attach on recovery > > If RPROC_ATTACH_ON_RECOVERY feature is enabled by the platform driver, > then the core framework will choose this method for recovery. > > On versal and later platforms following is the sequence of events expected > during remoteproc crash and attach on recovery: > > a) Remoteproc attach/detach flow is working, and RPMsg comm is established > b) Remote processor (RPU) crashed (crash not reported yet) > c) Platform management controller is instructed to stop and reload elf > on inactive remote processor before reboot (platform specific method) > d) Platform management controller reboots the remote processor > e) Remote processor boots again, and detects previous crash (platform > specific mechanism to detect the crash) > f) Remote processor Reports crash to the Linux (Host) and wait for > the recovery. > g) Linux performs full detach and reattach to remote processor. > h) Normal RPMsg communication is established. > > It is required to destroy all RPMsg related resources and recreate them > during recovery to establish successful RPMsg communication. To achieve > this complete rproc_detach followed by rproc_boot calls are needed. That > is what this patch-series is fixing along with adding rproc recovery > methods for AMD-Xilinx platforms. > > Change log: > > Changes in v6: > - %s/XLNX_RPROC_FW_CRASH_REASON/XLNX_RPROC_FW_CRASH_REPORT/ > - fix if else condition to reduce indent level > - %s/crash_state/crashed > - move setting rproc feature during probe > - remove redundant clearing of the features during detach() op >
Applied. Thanks, Mathieu > Changes in v5: > - cache crash report to a local variable then act on it. > - End crash report string with '\0' without relying on fw > > Changes in v4: > - Optimize crash resource memory by changing type to u32 to u8 > - Introduce version field in the crash resource > - Check crash related condition before rproc state related condition > - Move crash reporting to the bottom half of the isr instead of > actual irq handler > - Introduce 16 bytes array in the crash report to store crash reason > in the string format > - Remove redundant type cast > > Changes in v3: > - %s/kick/mailbox notification/ > - %s/core framework/rproc core framework/ > - fold simple function within zynqmp_r5_handle_rsc(). > - remove spurious change > - reset crash state after reporting the crash > - document set and reset of ATTACH_ON_RECOVERY flag > - set recovery_disabled flag to false > - check condition rproc->crash_reason != NULL > > > Changes in v5: > - use local variable to access crash report pointer > - End crash report string with '\0' without relying on fw > > Changes in v4: > - move pieces needed from rproc_detach() to rproc_attach_recovery() to > cleanup the resources > - use rproc_attach() over __rproc_attach() to create resources again > - keep rproc_trigger_recovery() unmodified > - Optimize crash resource memory by changing type to u32 to u8 > - Introduce version field in the crash resource > - Check crash related condition before rproc state related condition > - Move crash reporting to the bottom half of the isr instead of > actual irq handler > - Introduce 16 bytes array in the crash report to store crash reason > in the string format > - Remove redundant type cast > > Changes in 3: > - both rproc_attach_recovery() and > rproc_boot_recovery() are called the same way. > - remove unrelated changes > - %s/kick/mailbox notification/ > - %s/core framework/rproc core framework/ > - fold simple function within zynqmp_r5_handle_rsc(). > - remove spurious change > - reset crash state after reporting the crash > - document set and reset of ATTACH_ON_RECOVERY flag > - set recovery_disabled flag to false > - check condition rproc->crash_reason != NULL > > Changes in v2: > - use rproc_boot instead of rproc_attach > - move debug message early in the function > - clear attach recovery boot flag during detach and stop ops > > Tanmay Shah (2): > remoteproc: core: full attach detach during recovery > remoteproc: xlnx: add crash detection mechanism > > drivers/remoteproc/remoteproc_core.c | 15 +++++- > drivers/remoteproc/xlnx_r5_remoteproc.c | 70 ++++++++++++++++++++++++- > 2 files changed, 83 insertions(+), 2 deletions(-) > > > base-commit: 78fb7968943f5064766af7f33d82e6bfe90e0db0 > -- > 2.34.1 >
