[meta-xilinx] Linux/FreeRTOS AMP vrings
Wendy Liang
wendy.liang at xilinx.com
Wed Sep 2 13:26:48 PDT 2015
Hi Edward,
> -----Original Message-----
> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
> bounces at yoctoproject.org] On Behalf Of Edward Wingate
> Sent: Wednesday, September 02, 2015 12:55 PM
> To: Nathan Rossi <nathan at nathanrossi.com>
> Cc: meta-xilinx at yoctoproject.org
> Subject: Re: [meta-xilinx] Linux/FreeRTOS AMP vrings
>
> On Tue, Sep 1, 2015 at 1:35 AM, Nathan Rossi <nathan at nathanrossi.com>
> wrote:
> >
> > So if you want the linux-xlnx_3.19 equivalent use commit id
> > "3f30b3337af61f1ed98f7185e37c6bf9202b3204". And set the SRCREV in your
> > local.conf like so:
> >
> > SRCREV_pn-linux-xlnx-dev = "3f30b3337af61f1ed98f7185e37c6bf9202b3204"
> >
>
> Thanks, Nathan, this worked perfectly. I'm running kernel 3.19 now and Linux is
> still giving vring buffer addresses of 0x1f440xxx to CPU1, while reading from
> 0x1e440xxx.
>
> To recap, Linux is putting rpmsg vring buffers at va 0x9f440000, physical address
> 0x1e440000:
> virtio_rpmsg_bus virtio0: buffers: va 9f440000, dma 0x1e440000
>
> This is consistent with /proc/vmallocinfo:
> 0x9f000000-0xa1001000 33558528 dma_init_coherent_memory+0x4c/0xe0
> phys=1e000000 ioremap
>
> But then Linux is initializing the vring descriptors with buffer addresses of
> 0x1f440xxx, instead of 0x1e440xxx.
>
> When CPU1 writes data to the vring buffer and kicks Linux, Linux then reads the
> buffer from 0x1e440xxx (which is consistent with where they were allocated,
> but not consistent with what was told to CPU1).
>
> Anyway, I'm at a total loss of where to go from here. I want to get to the
> bottom of this, but need to forge ahead and will just manipulate the vring
> addresses on CPU1 side before reading/writing them (and hope it doesn't come
> back to bite me too hard later).
>
> Thanks all, for your help. If you have any further ideas of where I might look
> next, I'd appreciate hearing them. I said before, I tried to follow how the
> virtual-to-physical address conversion occurs, but I got lost due to the many
> layers of macros that also depend on what CPU architecture is in use.
rpmsg_probe() from drivers/rpmsg/virtio_rpmsg_bus.c will allocate the buffers, and in the end
it will call virtqueue_add() from drivers/virtio/virtio_ring.c to set the addr.
You can add some print into those functions to see what value from Linux side it get.
> But I
> wouldn't think there's such a glaring bug in the virtual memory address
> conversion though. There must be something basic I'm missing or some
> misconfiguration on my part, but I don't know what it could be.
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
More information about the meta-xilinx
mailing list