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 ?
>
>> 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 ?
> Regards,
> Loic
>>
>> Regards,
>>
>> Clément
