> -----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.
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
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
