Le mar. 1 sept. 2020 à 22:41, Loic PALLARDY <[email protected]> a écrit :

>
>
>
>
> > -----Original Message-----
>
> > From: boot-architecture <[email protected]> On
>
> > Behalf Of Stefano Stabellini
>
> > Sent: mardi 1 septembre 2020 22:19
>
> > To: François Ozog <[email protected]>
>
> > Cc: [email protected];
> [email protected];
>
> > Tomas Evensen <[email protected]>
>
> > 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 <[email protected]> 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
>
> > [email protected]
>
> > https://lists.linaro.org/mailman/listinfo/boot-architecture
>
> --
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
[email protected] | Skype: ffozog
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to