Openamp-rp November 2022

openamp-rp@lists.openampproject.org

3 participants
25 discussions

Start a nNew thread

[OpenAMP/open-amp]

by Arnaud Pouliquen

Branch: refs/tags/v2022.10.0 Home: https://github.com/OpenAMP/open-amp

1 year, 5 months

[OpenAMP/libmetal]

by Arnaud Pouliquen

Branch: refs/tags/v2022.10.0 Home: https://github.com/OpenAMP/libmetal

1 year, 5 months

[OpenAMP/open-amp] 46d041: zynqmp_r5 resource table: Change notifyid for the ...

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: 46d041808804f83a902a9f60fdfb6beffed22470 https://github.com/OpenAMP/open-amp/commit/46d041808804f83a902a9f60fdfb6bef… Author: Ed Mooring <ed.mooring(a)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(a)gmail.com> Commit: 568d507be81a27230ba3f0260485f2ee699f5aa0 https://github.com/OpenAMP/open-amp/commit/568d507be81a27230ba3f0260485f2ee… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2022-11-04 (Fri, 04 Nov 2022) Changed paths: M VERSION Log Message: ----------- release: open-amp 2022.10.0 Set library version to 1.3.0 Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Signed-off-by: Ed Mooring <ed.mooring(a)gmail.com> Compare: https://github.com/OpenAMP/open-amp/compare/88d2e4ce38b8...568d507be81a

1 year, 5 months

[OpenAMP/open-amp] 88d2e4: zynqmp_r5 resource table: Change notifyid for the ...

by Ed Mooring

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: 88d2e4ce38b8fe4af4ce84b2ec68a6b10a328169 https://github.com/OpenAMP/open-amp/commit/88d2e4ce38b8fe4af4ce84b2ec68a6b1… Author: Ed Mooring <ed.mooring(a)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(a)gmail.com>

1 year, 5 months

Items for OpenAMP RP call

by ben levinsky

Hi All, I have 2 items for discussion for the community call tomorrow: For the Remoteproc-core API rproc_get_by_child I have a use case where I would like to call this on the current rproc->device. 2 things: 1. At https://github.com/torvalds/linux/blob/master/drivers/remoteproc/remoteproc… There may be a bug here in that if the device is copied, then device->type comparison will fail. Can we change this to “if (!strncmp(dev->type->name, (&rproc_type)->name, strlen((&rproc_type)->name)) ? That way even if the device is copied the check will work. 1. For the same API, is it Ok to extend the for loop so it supports search on the ‘current’ device passed in? That is change https://github.com/torvalds/linux/blob/master/drivers/remoteproc/remoteproc… “for (dev = dev->parent; dev; dev = dev->parent) {“ to “for (; dev; dev = dev->parent) {“ This way we can account for the current device having the rproc dev. The reasoning for why this arises is that I have a use case where a driver is trying to call rproc_boot() to establish an RPMsg connection. (1) comes up because a device structure is copied so the comparison will not work as currently constructed. (2) comes up in our use case because the rproc structure device in an internal driver doesn’t yet have a child to iterate up from. (2) is solved in our use case by starting at the current device. Thanks, Ben Hi All, I have 2 items for discussion for the community call tomorrow: For the Remoteproc-core API rproc_get_by_child I have a use case where I would like to call this on the current rproc->device. 2 things: 1. At [1]https://github.com/torvalds/linux/blob/master/drivers/remotep roc/remoteproc_core.c#L2644 There may be a bug here in that if the device is copied, then device->type comparison will fail. Can we change this to “if (!strncmp(dev->type->name, (&rproc_type)->name, strlen((&rproc_type)->name)) ? That way even if the device is copied the check will work. 2. For the same API, is it Ok to extend the for loop so it supports search on the ‘current’ device passed in? That is change [2]https://github.com/torvalds/linux/blob/master/drivers/remotep roc/remoteproc_core.c#L2643 “for (dev = dev->parent; dev; dev = dev->parent) {“ to “for (; dev; dev = dev->parent) {“ This way we can account for the current device having the rproc dev. The reasoning for why this arises is that I have a use case where a driver is trying to call rproc_boot() to establish an RPMsg connection. (1) comes up because a device structure is copied so the comparison will not work as currently constructed. (2) comes up in our use case because the rproc structure device in an internal driver doesn’t yet have a child to iterate up from. (2) is solved in our use case by starting at the current device. Thanks, Ben References 1. https://github.com/torvalds/linux/blob/master/drivers/remoteproc/remoteproc… 2. https://github.com/torvalds/linux/blob/master/drivers/remoteproc/remoteproc…

1 year, 5 months

2024

2023

2022

2021

2020

2019

Openamp-rp November 2022