> -----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 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>;
> };
> };
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
> https://lists.linaro.org/mailman/listinfo/boot-architecture