Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: 88d2e4ce38b8fe4af4ce84b2ec68a6b10a328169 https://github.com/OpenAMP/open-amp/commit/88d2e4ce38b8fe4af4ce84b2ec68a6b10... Author: Ed Mooring ed.mooring@gmail.com Date: 2022-11-04 (Fri, 04 Nov 2022)

Changed paths: M apps/machine/zynqmp_r5/rsc_table.c

Log Message: ----------- zynqmp_r5 resource table: Change notifyid for the virtio device.

1. At firmware build time, the resource table for the Xilinx zynqmp_r5 is set up with notifyid==0 for the rpmsg virtio device. The vrings are set up with notifyid==1 for vring0 and notifyid==2 for vring1.

2. When the firmware is loaded onto the R5 via the Linux remoteproc sysfs interface, the kernel remoteproc implementation ignores the notifyid values for the vrings, and reallocates them, changing the resource table. On the Xilinx configuration I tested on, this results in vring0 being allocated notifyid 0, and vring1 being allocated notifyid 1.

3. When the remote processor is started, it parses the resource table. When it gets to the virtio device, it calls handle_vdev_rsc(), which in turn calls remoteproc_allocate_id() with the vdev's notifyid of 0. This successfully returns 0. Then handle_vdev_rsc() goes through the vrings. On vring0, it calls remoteproc_allocate_id(), with notifyid set to 0, because Linux changed vring0.notifyid from 1 to 0 in (2) above. This results in remoteproc_allocate_id() returning RSC_NOTIFY_ID_ANY. This causes handle_vdev_rsc() to return -RPROC_ERR_RSC_TAB_NP after commit 03c80a1, which causes the firmware startup to fail.

This appeared to work in previous versions, because remoteproc_allocate_id() returning RSC_NOTIFY_ID_ANY was effectively ignored, leaving the notifyid unchanged and allowing execution to continue.

Set the value of notifyid for the virtio device (rvdev) to 31 to avoid possible conflicts with the Linux imposed values.

Signed-off-by: Ed Mooring ed.mooring@gmail.com