mirror of
https://github.com/OpenAMP/open-amp.git
synced 2026-02-06 11:13:09 +08:00
46d0418088
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>