Hi Clément,
> -----Original Message-----
> From: Clément Leger <cleger@xxxxxxxxx>
> Sent: lundi 4 mars 2019 09:09
> To: Loic PALLARDY <loic.pallardy@xxxxxx>
> Cc: linux-remoteproc <linux-remoteproc@xxxxxxxxxxxxxxx>
> Subject: Re: dynamic vring allocation and 64 bits resources/loader
>
> Hi Loïc, thanks for your answer,
>
> ----- Mail original -----
> > De: "Loic PALLARDY" <loic.pallardy@xxxxxx>
> > À: "Clément Leger" <cleger@xxxxxxxxx>, "linux-remoteproc" <linux-
> remoteproc@xxxxxxxxxxxxxxx>
> > Envoyé: Dimanche 3 Mars 2019 21:22:16
> > Objet: RE: dynamic vring allocation and 64 bits resources/loader
>
> > Hi Clément,
> >
> >> -----Original Message-----
> >> From: linux-remoteproc-owner@xxxxxxxxxxxxxxx <linux-remoteproc-
> >> owner@xxxxxxxxxxxxxxx> On Behalf Of Clément Leger
> >> Sent: jeudi 28 février 2019 08:44
> >> To: linux-remoteproc <linux-remoteproc@xxxxxxxxxxxxxxx>
> >> Subject: dynamic vring allocation and 64 bits resources/loader
> >>
> >> Hi,
> >>
> >> I am currently implementing remote proc for our processor and after
> some
> >> tests,
> >> I have the following questions.
> >>
> >> 1) When allocating vring dynamically (da == (-1)), the remoteproc core
> >> allocates
> >> carveouts for each of these vrings:
> >>
> >> [ 34.410000] remoteproc remoteproc0: rsc: type 3
> >> [ 34.420000] remoteproc remoteproc0: vdev rsc: id 7, dfeatures 0x0, cfg
> len 0,
> >> 2 vrings
> >> [ 34.430000] remoteproc remoteproc0: vdev rsc: vring0: da 0xffffffff, qsz
> 256,
> >> align 4096
> >> [ 34.430000] remoteproc remoteproc0: vdev rsc: vring1: da 0xffffffff, qsz
> 256,
> >> align 4096
> >> [ 34.450000] remoteproc remoteproc0: carveout va (____ptrval____),
> dma
> >> 0x000000011ec88000, len 0x3000
> >> [ 34.460000] remoteproc remoteproc0: carveout va (____ptrval____),
> dma
> >> 0x000000011ec8c000, len 0x3000
> >> [ 34.460000] remoteproc remoteproc0: da = 0x0 len = 0x10440 va =
> >> 0x(____ptrval____)
> >> [ 34.490000] remoteproc remoteproc0: da = 0x10440 len = 0x10 va =
> >> 0x(____ptrval____)
> >> [ 34.500000] remoteproc remoteproc0: da = 0x10450 len = 0xc4f0 va =
> >> 0x(____ptrval____)
> >> [ 34.520000] remoteproc remoteproc0: da = 0xa46000 len = 0x2b4 va =
> >> 0x(____ptrval____)
> >> [ 34.530000] remoteproc remoteproc0: da = 0xe3e8 len = 0x58 va =
> >> 0x(____ptrval____)
> >> [ 34.550000] remoteproc remoteproc0: registered virtio0 (type 7)
> >> [ 34.560000] remoteproc remoteproc0: remote processor cluster1 is now
> up
> >> Hello world from cluster1
> >> VRING0 da: 0xffffffff, pa: 0, notify_id: 0
> >> VRING1 da: 0xffffffff, pa: 0, notify_id: 1
> >>
> >> Rsc table contains the following:
> >>
> >> /* Virtio device entry */
> >> {
> >> RSC_VDEV, VIRTIO_ID_RPMSG, 0, 0, 0, 0, 0,
> >> NUM_VRINGS, {0, 0},
> >> },
> >> /* Vring rsc entry - part of vdev_rsc entry */
> >> {
> >> (-1), VRING_ALIGN, VRING_SIZE, 0, 0
> >> },
> >> {
> >> (-1), VRING_ALIGN, VRING_SIZE, 0, 0
> >> },
> >>
> >> I was expecting remoteproc core to update vring pa but the
> >> rproc_alloc_registered_carveouts function only update resources for
> >> carveouts.
> >
> > Only da is used by coprocessor, pa is only for the host. That's why pa is not
> > updated.
> > Just take care that da may be updated after coprocessor boot. You need to
> wait
> > for first mailbox kick or vdev status in resource table before accessing vring
> > information.
>
> Ok, I was expecting the address to be directly updated.
>
> This lead me to another question regarding the kicking mecanism.
> Our interrupts are triggered using mailboxes. Since mailboxes are dynamically
> allocated, to avoid hardcoding it in the firmware, I would like to be able to
> send the mailbox address in some resources.
> This lead me to vendor resources. I have seen that they are declared in
> OpenAMP
> and that the rproc backends can handle them. However, this is not
> implemented in
> the kernel. I added the same mecanism in remoteproc-core to allow rproc
> backends
> to handle such resources.
> Are these patches of any interest ?
This topic has been discussed in OpenAMP context. TI and Xilinx have already their own solution, but no proposal sent on ML yet.
Please send an RFC.
>
> >
> >> Is this the expected behaviour or am I missing something ? I tried adding
> two
> >> carveouts named after the vdev%dvring%d scheme and the carveout
> >> resources are
> >> indeed correctly updated (but vring are still not updated). BTW, I'm
> working
> >> on a v5.0-rc5 kernel if its of any interest.
> >>
> >> 2) Regarding resource structs (rsc_*). They are all defined using u32 types
> >> (da, etc for instance). I saw it was planned to support 64 bits resources in
> >> some mail from 2018. However, this does not seems supported yet. Are
> >> there
> >> any new plans to support it ?
> >
> > Still planned, need first to introduce resource table versioning
> >
> >>
> >> 3) Same question regarding an elf64 loader.
> >
> > Needed indeed...
>
> Would you mind if I contribute one ?
Please feel free to contribute on such feature.
Regards,
Loic
>
> > Regards,
> > Loic
> >>
> >> Regards,
> >>
> >> Clément
