- Openamp-rp - lists.openampproject.org

[OpenAMP/meta-openamp] 49ddd1: libmetal-xlnx: Merge in Xilinx 2022.2 release

by Bill Mills

Branch: refs/heads/master-next Home: https://github.com/OpenAMP/meta-openamp Commit: 49ddd1933e362c299310bab2571cb8a2a40fcfb2 https://github.com/OpenAMP/meta-openamp/commit/49ddd1933e362c299310bab2571c… Author: Mark Hatle <mark.hatle(a)kernel.crashing.org> Date: 2022-11-08 (Tue, 08 Nov 2022) Changed paths: A recipes-openamp/libmetal/libmetal-xlnx_v2022.2.bb M vendor/xilinx/recipes-openamp/libmetal/libmetal_%.bbappend Log Message: ----------- libmetal-xlnx: Merge in Xilinx 2022.2 release Signed-off-by: Mark Hatle <mark.hatle(a)kernel.crashing.org> (cherry picked from commit 8678b5740c8e46010742888787806757b179ba81) Signed-off-by: Mark Hatle <mark.hatle(a)kernel.crashing.org> Commit: 9f33f80721147ca15ac49d1e08fbba9859088d43 https://github.com/OpenAMP/meta-openamp/commit/9f33f80721147ca15ac49d1e08fb… Author: Mark Hatle <mark.hatle(a)kernel.crashing.org> Date: 2022-11-08 (Tue, 08 Nov 2022) Changed paths: A recipes-openamp/open-amp/open-amp-xlnx_v2022.2.bb M vendor/xilinx/recipes-openamp/open-amp/open-amp_%.bbappend Log Message: ----------- open-amp-xlnx: Merge in Xilinx 2022.2 release Signed-off-by: Mark Hatle <mark.hatle(a)kernel.crashing.org> (cherry picked from commit 889ec35932e2b009cb6b9ca87a33ce87a87291af) Signed-off-by: Mark Hatle <mark.hatle(a)kernel.crashing.org> Commit: 90519a331b5169a55fa332dc4b67855e9f5ef409 https://github.com/OpenAMP/meta-openamp/commit/90519a331b5169a55fa332dc4b67… Author: Mark Hatle <mark.hatle(a)kernel.crashing.org> Date: 2022-11-08 (Tue, 08 Nov 2022) Changed paths: M conf/layer.conf Log Message: ----------- meta-openamp: declare the layer also compatible with langdale Signed-off-by: Mark Hatle <mark.hatle(a)kernel.crashing.org> (cherry picked from commit 7d3227ad0320e1a6d389f913fd0e4f552db43a5d) Signed-off-by: Mark Hatle <mark.hatle(a)kernel.crashing.org> Commit: 11dc317f784aa84110cdb515ae20b2d7208ce461 https://github.com/OpenAMP/meta-openamp/commit/11dc317f784aa84110cdb515ae20… Author: Mark Hatle <mark.hatle(a)amd.com> Date: 2022-11-08 (Tue, 08 Nov 2022) Changed paths: M vendor/xilinx/recipes-kernel/linux/linux-%.bbappend R vendor/xilinx/recipes-kernel/linux/openamp-kmeta/cfg/remoteproc-zynqmp.cfg R vendor/xilinx/recipes-kernel/linux/openamp-kmeta/cfg/remoteproc-zynqmp.scc R vendor/xilinx/recipes-kernel/linux/openamp-kmeta/cfg/sparsevmemmap.cfg R vendor/xilinx/recipes-kernel/linux/openamp-kmeta/cfg/sparsevmemmap.scc A vendor/xilinx/recipes-kernel/linux/openamp-xilinx-kmeta/cfg/remoteproc-zynqmp.cfg A vendor/xilinx/recipes-kernel/linux/openamp-xilinx-kmeta/cfg/remoteproc-zynqmp.scc A vendor/xilinx/recipes-kernel/linux/openamp-xilinx-kmeta/cfg/sparsevmemmap.cfg A vendor/xilinx/recipes-kernel/linux/openamp-xilinx-kmeta/cfg/sparsevmemmap.scc Log Message: ----------- vendor linux-%.bbappend: Move kmeta to vendor specific name Re-using the base openamp-kmeta name meant that only this one was available and not both the base and vendor version. Rename to vendor specific to allow both paths to be available for parsing. Signed-off-by: Mark Hatle <mark.hatle(a)amd.com> (cherry picked from commit ac878a11dd9c15e09b32c5e504fa92e984f7ee58) Signed-off-by: Mark Hatle <mark.hatle(a)kernel.crashing.org> Commit: 1e06a82f039cb162930e984b00a38bec8dcdc7dd https://github.com/OpenAMP/meta-openamp/commit/1e06a82f039cb162930e984b00a3… Author: Bill Mills <bill.mills(a)linaro.org> Date: 2022-11-08 (Tue, 08 Nov 2022) Changed paths: M recipes-kernel/linux/openamp-kmeta/cfg/openamp.cfg M recipes-kernel/linux/openamp-kmeta/cfg/remoteproc-arm64.cfg M recipes-kernel/linux/openamp-kmeta/cfg/remoteproc-armv7a.cfg Log Message: ----------- kernel config fragments: add RPMSG_CTRL and RPMSG_TTY Since 5.18 RPMSG_CTRL is separate from RPMSG_CHAR. Enabled it as a module. Older kernels will ignore this. You will get a warning. Also enable RPMSG_TTY driver for TTY devices from RPMSG This is done in the qemu and generic machines only for now. Signed-off-by: Bill Mills <bill.mills(a)linaro.org> Signed-off-by: Mark Hatle <mark.hatle(a)kernel.crashing.org> Compare: https://github.com/OpenAMP/meta-openamp/compare/49ddd1933e36%5E...1e06a82f0…

3 years, 12 months

1
0
0 0

[OpenAMP/open-amp] 5a8a5d: virtio: virtio-mmio framework configuration

by Arnaud Pouliquen

Branch: refs/heads/virtio-exp Home: https://github.com/OpenAMP/open-amp Commit: 5a8a5ddff04d80b83618d66617647a36bb54913d https://github.com/OpenAMP/open-amp/commit/5a8a5ddff04d80b83618d66617647a36… Author: Dan Milea <dan.milea(a)windriver.com> Date: 2022-11-07 (Mon, 07 Nov 2022) Changed paths: M cmake/options.cmake M lib/CMakeLists.txt Log Message: ----------- virtio: virtio-mmio framework configuration Introduced configuration option for enabling virtio MMIO support. Signed-off-by: Dan Milea <dan.milea(a)windriver.com> Commit: fb61aedaa250e771ae0ef23fc80fd3ca6b57905f https://github.com/OpenAMP/open-amp/commit/fb61aedaa250e771ae0ef23fc80fd3ca… Author: Dan Milea <dan.milea(a)windriver.com> Date: 2022-11-07 (Mon, 07 Nov 2022) Changed paths: M lib/include/openamp/virtio.h A lib/include/openamp/virtio_rng.h M lib/virtio_mmio/CMakeLists.txt M lib/virtio_mmio/virtio_mmio.c A lib/virtio_mmio/virtio_rng.c Log Message: ----------- virtio-mmio: entropy device Added virtio entropy device support. Signed-off-by: Dan Milea <dan.milea(a)windriver.com> Commit: 9a574c5dc59ec23f3093b700968b42080c324a25 https://github.com/OpenAMP/open-amp/commit/9a574c5dc59ec23f3093b700968b4208… Author: Dan Milea <dan.milea(a)windriver.com> Date: 2022-11-07 (Mon, 07 Nov 2022) Changed paths: A lib/include/openamp/virtio_net.h M lib/virtio_mmio/CMakeLists.txt A lib/virtio_mmio/virtio_net.c Log Message: ----------- virtio-mmio: network device Added virtio network device support. Signed-off-by: Dan Milea <dan.milea(a)windriver.com> Commit: b3d2eeedf705947f8e56dcd658fe14f4892b87e1 https://github.com/OpenAMP/open-amp/commit/b3d2eeedf705947f8e56dcd658fe14f4… Author: Dan Milea <dan.milea(a)windriver.com> Date: 2022-11-07 (Mon, 07 Nov 2022) Changed paths: A lib/include/openamp/virtio_serial.h M lib/virtio_mmio/CMakeLists.txt A lib/virtio_mmio/virtio_serial.c Log Message: ----------- virtio-mmio: console device Added virtio console device support. Signed-off-by: Dan Milea <dan.milea(a)windriver.com> Compare: https://github.com/OpenAMP/open-amp/compare/9942d7967d88...b3d2eeedf705

3 years, 12 months

1
0
0 0

[OpenAMP/open-amp]

by Arnaud Pouliquen

Branch: refs/heads/v2022.10 Home: https://github.com/OpenAMP/open-amp

4 years

1
0
0 0

[OpenAMP/libmetal]

by Arnaud Pouliquen

Branch: refs/heads/v2022.10 Home: https://github.com/OpenAMP/libmetal

4 years

1
0
0 0

[OpenAMP/open-amp]

by Arnaud Pouliquen

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

4 years

1
0
0 0

[OpenAMP/libmetal]

by Arnaud Pouliquen

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

4 years

1
0
0 0

[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

4 years

1
0
0 0

[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>

4 years

1
0
0 0

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…

4 years

2
1
0 0

Delaying Release of OpenAMP Library v2022.10

by Ed Mooring

Hi all, During the late stages of testing of the v2022.10 OpenAMP library, I ran across a failure that looks like there is an unexpected interaction between the library and the Linux remoteproc implementations. We have decided to delay the release until we understand the problem better. Regards, Ed M

4 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

Openamp-rp