On Tue, 1 Sep 2020, François Ozog via System-dt wrote:
On Tue, 1 Sep 2020 at 14:49, Tomas Evensen tomase@xilinx.com wrote: Here are some brief notes from the meeting.
If nothing else as a showcase on how much we miss Nathalie when she is on vacation 😉 Krzysztof Kepa – GE Mathieu Poirier – Linaro Etsam Anjum – Mentor Anrnoud Pouliquen – ST Loic Pallardy - ST Suman Anna - TI Dan Milea – Wind River Mark Dapoz – Wind River Tomas Evensen – Xilinx Stefano Stabellini – Xilinx Bruce Ashfield – Xilinx Ed Mooring – Xilinx Ben Levinsky - Xilinx Stefano went through slides. Overall idea: 1. Specify remoteproc channels with minimal information in System-DT in a way that is as common as possible for all vendors. In particular, we are avoiding to have to specify the same memory regions in more than one place. A resource group is specially marked to contain most information. 2. Use Lopper to create the vendor specific remoteproc specification Generating reserved-memory, etc. information that has duplicate information. For the time being, no plans to unify the vendor specific information that goes into the traditional device tree for Linux 3. Later (or in parallel), but without making it a gating item, start discussions on what we can do to unify the vendor specific information in the traditional DT Discussion about how TI and ST might generate their specific information from this specification. Stefano to send out examples and slides. Ben: Xilinx backend to Lopper is upstreamed and available as an example. Might change as upstreaming continues. Question: * How do we configure VirtIO?Could you describe more the VirtIO question so that relationship with Linaro project Stratos is assessed?
I think this point refers to various vdev<x> buffers described under /reserved-memory which are linked from RemoteProc. From the Xilinx bindings:
reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges;
rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed40000 0x4000>; }; rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed44000 0x4000>; }; rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed48000 0x100000>; }; rproc_0_reserved: rproc@3ed000000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed00000 0x40000>; }; };
-----Original Message----- From: boot-architecture boot-architecture-bounces@lists.linaro.org On Behalf Of Stefano Stabellini Sent: mardi 1 septembre 2020 22:19 To: François Ozog francois.ozog@linaro.org Cc: boot-architecture@lists.linaro.org; system-dt@lists.openampproject.org; Tomas Evensen tomase@xilinx.com Subject: Re: [System-dt] Notes (brief) from System DT call: OpenAMP bindings
On Tue, 1 Sep 2020, François Ozog via System-dt wrote:
On Tue, 1 Sep 2020 at 14:49, Tomas Evensen tomase@xilinx.com wrote: Here are some brief notes from the meeting.
If nothing else as a showcase on how much we miss Nathalie when sheis on vacation 😉
Krzysztof Kepa – GE Mathieu Poirier – Linaro Etsam Anjum – Mentor Anrnoud Pouliquen – ST Loic Pallardy - ST Suman Anna - TI Dan Milea – Wind River Mark Dapoz – Wind River Tomas Evensen – Xilinx Stefano Stabellini – Xilinx Bruce Ashfield – Xilinx Ed Mooring – Xilinx Ben Levinsky - Xilinx Stefano went through slides. Overall idea: 1. Specify remoteproc channels with minimal information in System-DTin a way that is as common as possible for all vendors.
In particular, we are avoiding to have to specify the same memoryregions in more than one place. A resource group is specially
marked to contain most information. 2. Use Lopper to create the vendor specific remoteproc specification Generating reserved-memory, etc. information that has duplicateinformation.
For the time being, no plans to unify the vendor specific informationthat goes into the traditional device tree for Linux
3. Later (or in parallel), but without making it a gating item, startdiscussions on what we can do to unify the vendor
specific information in the traditional DT Discussion about how TI and ST might generate their specific informationfrom this specification.
Stefano to send out examples and slides. Ben: Xilinx backend to Lopper is upstreamed and available as anexample. Might change as upstreaming continues.
Question: * How do we configure VirtIO?Could you describe more the VirtIO question so that relationship with
Linaro project Stratos is assessed?
I think this point refers to various vdev<x> buffers described under /reserved-memory which are linked from RemoteProc. From the Xilinx bindings:
reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed40000 0x4000>; }; rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed44000 0x4000>; }; rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed48000 0x100000>; }; rproc_0_reserved: rproc@3ed000000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed00000 0x40000>; };};
ST proposed an RFC to decouple virtio rpmsg device from rproc one. In this proposal, a DT node is introduced to described HW associated to virtio device (share memory, mboxes...) in order to make description generic between different SoCs. As Stephano is proposing a generic way to populate DT kernel rproc node from system DT, I propose to think about virtio rpmsg device node definition (and why not any virtio device) in a second step. Regards, Loic
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Le mar. 1 sept. 2020 à 22:41, Loic PALLARDY loic.pallardy@st.com a écrit :
-----Original Message-----
From: boot-architecture boot-architecture-bounces@lists.linaro.org On
Behalf Of Stefano Stabellini
Sent: mardi 1 septembre 2020 22:19
To: François Ozog francois.ozog@linaro.org
Cc: boot-architecture@lists.linaro.org;
system-dt@lists.openampproject.org;
Tomas Evensen tomase@xilinx.com
Subject: Re: [System-dt] Notes (brief) from System DT call: OpenAMP
bindings
On Tue, 1 Sep 2020, François Ozog via System-dt wrote:
On Tue, 1 Sep 2020 at 14:49, Tomas Evensen tomase@xilinx.com wrote:
Here are some brief notes from the meeting.If nothing else as a showcase on how much we miss Nathalie whenshe
is on vacation 😉
Krzysztof Kepa – GEMathieu Poirier – LinaroEtsam Anjum – MentorAnrnoud Pouliquen – STLoic Pallardy - STSuman Anna - TIDan Milea – Wind RiverMark Dapoz – Wind RiverTomas Evensen – XilinxStefano Stabellini – XilinxBruce Ashfield – XilinxEd Mooring – XilinxBen Levinsky - XilinxStefano went through slides.Overall idea:1. Specify remoteproc channels with minimal information inSystem-DT
in a way that is as common as possible for all vendors.
In particular, we are avoiding to have to specify the same memoryregions in more than one place. A resource group is specially
marked to contain most information.2. Use Lopper to create the vendor specific remoteprocspecification
Generating reserved-memory, etc. information that has duplicateinformation.
For the time being, no plans to unify the vendor specificinformation
that goes into the traditional device tree for Linux
3. Later (or in parallel), but without making it a gatingitem, start
discussions on what we can do to unify the vendor
specific information in the traditional DTDiscussion about how TI and ST might generate their specificinformation
from this specification.
Stefano to send out examples and slides.Ben: Xilinx backend to Lopper is upstreamed and available as anexample. Might change as upstreaming continues.
Question:* How do we configure VirtIO?Could you describe more the VirtIO question so that relationship with
Linaro project Stratos is assessed?
I think this point refers to various vdev<x> buffers described under
/reserved-memory which are linked from RemoteProc. From the Xilinx
bindings:
reserved-memory {#address-cells = <1>;#size-cells = <1>;ranges;rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 {compatible = "xilinx,openamp-ipc-1.0";no-map;reg = <0x3ed40000 0x4000>;};rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {compatible = "xilinx,openamp-ipc-1.0";no-map;reg = <0x3ed44000 0x4000>;};rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {compatible = "xilinx,openamp-ipc-1.0";no-map;reg = <0x3ed48000 0x100000>;};rproc_0_reserved: rproc@3ed000000 {compatible = "xilinx,openamp-ipc-1.0";no-map;reg = <0x3ed00000 0x40000>;};};ST proposed an RFC to decouple virtio rpmsg device from rproc one. In this proposal, a DT node is introduced to described HW associated to virtio device (share memory, mboxes...) in order to make description generic between different SoCs.
Is there a possible relationship with FF-A memory allocations ? I feel that memory reservations are better off dealt with through that mechanism.
As Stephano is proposing a generic way to populate DT kernel rproc node from system DT, I propose to think about virtio rpmsg device node definition (and why not any virtio device) in a second step.
Regards,
Loic
boot-architecture mailing list
boot-architecture@lists.linaro.org
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
boot-architecture@lists.linaro.org
-
François Ozog -
Loic PALLARDY -
Stefano Stabellini