- Openamp-rp - lists.openampproject.org

[OpenAMP/open-amp] b17761: virtio: follow virtio v1.2 spec, add more virtio s...

by Bowen

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: b177618da42e401c6d0f3810f7594f33023111c3 https://github.com/OpenAMP/open-amp/commit/b177618da42e401c6d0f3810f7594f33… Author: Bowen Wang <wangbowen6(a)xiaomi.com> Date: 2023-06-22 (Thu, 22 Jun 2023) Changed paths: M lib/include/openamp/virtio.h M lib/virtio/virtio.c Log Message: ----------- virtio: follow virtio v1.2 spec, add more virtio status and device id Follow the virtio v1.2 spec, add more virtio status and device id definition in virtio.h Signed-off-by: Bowen Wang <wangbowen6(a)xiaomi.com>

3 years

1
0
0 0

Open-amp bare-metal on STM32H7

by Karicheri, Murali

Hello, I am new to this mailing list. I have done some work recently to get the RPMSG sample running on a dual core STM32H device from ST and it works. In this case both Host and Remote runs Zephyr. My goal is to replace the Remote with a bare-metal and did some research and found open-amp can be used for the same. However, I don't see any libmetal port on STM32 under lib/system/generic. My understanding is that with this, I would be able to modify an existing example in open-amp (under https://github.com/OpenAMP/open-amp/tree/main/apps/examples/rpmsg_sample_ec…) to work with the Zephyr rpmsg example at https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/r…) Has anyone attempted anything like this that I can leverage on? Other than the libmetal port, what else would be needed to get this inter-work with Zephyr RPMSG sample or should I attempt a different sample from Zephyr to work with open-amp sample? Any help to get me in the right direction would be appreciated. Thanks. Murali Karicheri S&C Electric. ________________________________ NOTICE OF CONFIDENTIALITY: This message may contain information that is considered confidential and which may be prohibited from disclosure under applicable law or by contractual agreement. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. If you have received this email transmission in error, please notify the sender by replying to this email and then delete it from your system.

3 years, 1 month

2
1
0 0

[OpenAMP/open-amp] fe5ac7: CI: update checkout action to V3

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: fe5ac7a30542c02440ea91f209e120225350e389 https://github.com/OpenAMP/open-amp/commit/fe5ac7a30542c02440ea91f209e12022… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2023-06-05 (Mon, 05 Jun 2023) Changed paths: M .github/workflows/continuous-integration.yml Log Message: ----------- CI: update checkout action to V3 Node.js 12 actions are deprecated. Use the checkout V3 action to use Node.js 16 Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com>

3 years, 1 month

1
0
0 0

[OpenAMP/libmetal] 2345b7: CI: update checkout action to V3

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/libmetal Commit: 2345b74998e9c9a606266572c658f5e76fe7e82a https://github.com/OpenAMP/libmetal/commit/2345b74998e9c9a606266572c658f5e7… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2023-06-05 (Mon, 05 Jun 2023) Changed paths: M .github/workflows/continuous-integration.yml Log Message: ----------- CI: update checkout action to V3 Node.js 12 actions are deprecated. Use the checkout V3 action to use Node.js 16 Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Commit: cd104fa0fd89b722501aba948effe6e9f940b79c https://github.com/OpenAMP/libmetal/commit/cd104fa0fd89b722501aba948effe6e9… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2023-06-05 (Mon, 05 Jun 2023) Changed paths: M .github/actions/build_ci/entrypoint.sh Log Message: ----------- CI: fix zephyr build issue related to the VERSION file The Zephyr cmake fails in version.cmake because some fields are not present in the libmetal VERSION file Add dummy fields for the CI to fix compatibility issue Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Compare: https://github.com/OpenAMP/libmetal/compare/28fa2351d6a8...cd104fa0fd89

3 years, 1 month

1
0
0 0

Re: [RFC]: Variable RpMsg buffer size in Linux Kernel

by Arnaud POULIQUEN

ST Restricted > -----Original Message----- > From: Mathieu Poirier <mathieu.poirier(a)linaro.org> > Sent: Saturday, May 20, 2023 1:00 AM > To: Bill Mills <bill.mills(a)linaro.org> > Cc: Shah, Tanmay <tanmay.shah(a)amd.com>; ed.mooring(a)gmail.com; > tammy.leino(a)siemens.com; Arnaud POULIQUEN > <arnaud.pouliquen(a)st.com>; openamp-rp(a)lists.openampproject.org > Subject: Re: [RFC]: Variable RpMsg buffer size in Linux Kernel > > On Thu, 18 May 2023 at 10:27, Bill Mills <bill.mills(a)linaro.org> wrote: > > > > > > > > On 5/18/23 12:00 PM, Shah, Tanmay wrote: > > > Hi all, > > > > > > As of now, rpmsg buffer size is decided by RPMSG_BUF_SIZE macro. > > > This is fixed to 512 bytes. > > > > > > If platform needs to send larger than 512 bytes of payload, then the > > > payload needs to be split between multiple buffers. > > > > > > Instead of that, it would be useful if platform can configure > > > RPMSG_BUF_SIZE somehow. > > > > > > There are multiple options to achieve this: > > > > > > 1. Move RPMSG_BUF_SIZE to Kconfig -> The approach is not accepted as > > > single kernel may not work for all platforms. > > > 2. Keep device-tree property that mentions rpmsg buffer size. > > > 1. Something in dts: “rpmsg-buf-size = <512>” > > > 2. This way one kernel can work for all the platforms. If property > > > is not mentioned, then we fallback to default size of 512 bytes. > > > 3. Dynamic buffer allocation > > > 1. This effort was done previously. Please refer to following > > > discussion from kernel and openamp library: > > > > > > i.Openamp library: https://github.com/OpenAMP/open-amp/pull/155 > > > <https://github.com/OpenAMP/open-amp/pull/155> > > > > > > 1. Conclusion: > > > > > > https://github.com/OpenAMP/open-amp/issues/322#issuecomment- > 98657382 > > > 8 > > > <https://github.com/OpenAMP/open-amp/issues/322#issuecomment- > 9865738 > > > 28> > > > > > > ii.Kernel: > > > https://patchwork.kernel.org/project/linux-remoteproc/cover/15489492 > > > 80-31794-1-git-send-email-xiaoxiang(a)xiaomi.com/ > > > <https://patchwork.kernel.org/project/linux-remoteproc/cover/1548949 > > > 280-31794-1-git-send-email-xiaoxiang(a)xiaomi.com/> > > > > > > > Lore link to same: > > https://lore.kernel.org/lkml/20190605043452.GI22737@tuxbook-pro/T/ > > > > I saw nothing in this thread that I would call a rejection. > > > > It made the size choice based on the virtio config space which could > > come from firmware resource table now or virtio device config space if > > using virtio-mmio etc. > > > > Bjorn did point out that a system where each side allocated its own > > buffers of whatever size desired would be more flexible but: > > * did not object to this step > > * that would be a pretty big departure from what we have not and we > > would still need to negotiate its use. > > > > The biggest issues I saw with the patch series was the details of how > > it did the config. That could have been fixed with a bit more effort. > > > > I would vote we just resurrect this patch set and clean it up rather > > than going down the DTS route. > > > > I agree - I did not find anything controversial in that patchset either. We can > start with that and later supplement with the DTS if needed. Also in favor of this approach Regards, Arnaud > > > Bill > > > > > 2. As part of this, RPMSG_BUF_SIZE is configurable on library side, > > > but not on kernel side. > > > > > > If it looks reasonable to go with approach 2 without side-effects, I > > > can develop and send the patch. > > > > > > Thanks, > > > > > > Tanmay > > > > > > > -- > > Bill Mills > > Principal Technical Consultant, Linaro > > +1-240-643-0836 > > TZ: US Eastern > > Work Schedule: Tues/Wed/Thur

3 years, 1 month

2
1
0 0

[OpenAMP/open-amp] 1697a1: apps: zynqmp: Add Versal_net IPI values.

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: 1697a15f477578104e81092406fb2318a56e2f72 https://github.com/OpenAMP/open-amp/commit/1697a15f477578104e81092406fb2318… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2023-05-22 (Mon, 22 May 2023) Changed paths: M apps/machine/zynqmp/platform_info.c Log Message: ----------- apps: zynqmp: Add Versal_net IPI values. Enable Linux demos to run on Versal_net by updating the IPI values that are specific to this hardware platform. Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com>

3 years, 2 months

1
0
0 0

Re: [RFC]: Variable RpMsg buffer size in Linux Kernel

by Bill Mills

On 5/18/23 12:00 PM, Shah, Tanmay wrote: > Hi all, > > As of now, rpmsg buffer size is decided by RPMSG_BUF_SIZE macro. This is > fixed to 512 bytes. > > If platform needs to send larger than 512 bytes of payload, then the > payload needs to be split between multiple buffers. > > Instead of that, it would be useful if platform can configure > RPMSG_BUF_SIZE somehow. > > There are multiple options to achieve this: > > 1. Move RPMSG_BUF_SIZE to Kconfig -> The approach is not accepted as > single kernel may not work for all platforms. > 2. Keep device-tree property that mentions rpmsg buffer size. > 1. Something in dts: “rpmsg-buf-size = <512>” > 2. This way one kernel can work for all the platforms. If property > is not mentioned, then we fallback to default size of 512 bytes. > 3. Dynamic buffer allocation > 1. This effort was done previously. Please refer to following > discussion from kernel and openamp library: > > i.Openamp library: https://github.com/OpenAMP/open-amp/pull/155 > <https://github.com/OpenAMP/open-amp/pull/155> > > 1. Conclusion: > https://github.com/OpenAMP/open-amp/issues/322#issuecomment-986573828 <https://github.com/OpenAMP/open-amp/issues/322#issuecomment-986573828> > > ii.Kernel: > https://patchwork.kernel.org/project/linux-remoteproc/cover/1548949280-3179… <https://patchwork.kernel.org/project/linux-remoteproc/cover/1548949280-3179…> > Lore link to same: https://lore.kernel.org/lkml/20190605043452.GI22737@tuxbook-pro/T/ I saw nothing in this thread that I would call a rejection. It made the size choice based on the virtio config space which could come from firmware resource table now or virtio device config space if using virtio-mmio etc. Bjorn did point out that a system where each side allocated its own buffers of whatever size desired would be more flexible but: * did not object to this step * that would be a pretty big departure from what we have not and we would still need to negotiate its use. The biggest issues I saw with the patch series was the details of how it did the config. That could have been fixed with a bit more effort. I would vote we just resurrect this patch set and clean it up rather than going down the DTS route. Bill > 2. As part of this, RPMSG_BUF_SIZE is configurable on library side, > but not on kernel side. > > If it looks reasonable to go with approach 2 without side-effects, I can > develop and send the patch. > > Thanks, > > Tanmay > -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 2 months

1
0
0 0

[OpenAMP/libmetal]

by Arnaud Pouliquen

Branch: refs/tags/V2023.04.0 Home: https://github.com/OpenAMP/libmetal

3 years, 2 months

1
0
0 0

[OpenAMP/libmetal]

by Arnaud Pouliquen

Branch: refs/tags/v2023.04.0 Home: https://github.com/OpenAMP/libmetal

3 years, 2 months

1
0
0 0

[OpenAMP/openamp-system-reference]

by Arnaud Pouliquen

Branch: refs/tags/v2023.04.0 Home: https://github.com/OpenAMP/openamp-system-reference

3 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

Openamp-rp