Branch: refs/heads/master
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/c00633a6ab8f...1e06a82f039c
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…
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
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>
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…