Linux-remoteproc Archive mirror
 help / color / mirror / Atom feed
From: Simon Maurer <mail@maurer.systems>
To: linux-remoteproc@vger.kernel.org
Subject: remoteproc over PCIe
Date: Tue, 9 May 2023 15:42:27 +0200	[thread overview]
Message-ID: <72ff39f1-b966-a089-0f3c-9216d8a38e77@maurer.systems> (raw)

Hi,
I've got a "Zynq PCIe FMC Carrier Evaluation Board" with a x86 host. The 
Zynq 7000 is an FPGA with 2x Cortex-A9, on which ZephyrOS with the 
OpenAMP framework is running. The VirtIO ring and the buffer for the 
RPMSGs are located in the nocache memory section of the ZephyrOS. The 
card DDR-RAM and the CPU control registers are mapped into PCIe BARs. On 
the FPGA the "AXI Memory Mapped To PCI Express" IP core is used, so the 
kernel has mmio access to the card DDR-RAM.
Besides the kernel module, I had to do a few modifications elsewhere in 
the kernel. In remoteproc_virtio.c I implemented the get_shm_region 
function for the rproc_virtio_config_ops. This gives access to the rpmsg 
buffer, that is already mapped. In virtio_rpmsg_bus.c this function is 
used instead of allocating a new region. This is just a proof of 
concept, but it seems to be working, ttyRPMSG is created and I can send 
and receive messages.
But what would be the clean way to do this? I'm thinking about 
implementing dma_map_ops for the vdev, but maybe there is a better solution?

Best regards,
Simon

             reply	other threads:[~2023-05-09 13:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 13:42 Simon Maurer [this message]
2023-05-09 17:08 ` remoteproc over PCIe Arnaud POULIQUEN
2023-05-10 13:06   ` Simon Maurer
  -- strict thread matches above, loose matches on Subject: below --
2025-01-22 15:59 [PATCH] remoteproc: add optional hook for resource checking Simon Maurer
2025-01-22 18:53 ` RemoteProc over PCIe Simon Maurer
2025-01-27 16:27   ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=72ff39f1-b966-a089-0f3c-9216d8a38e77@maurer.systems \
    --to=mail@maurer.systems \
    --cc=linux-remoteproc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).