Zynq 7-Series with Linux Userspace RPMsg Example
Jeremy
Jiaying Liang
From: open...@googlegroups.com [mailto:open...@googlegroups.com]
On Behalf Of Jeremy
Sent: Thursday, February 23, 2017 1:17 PM
To: open-amp
Subject: [open-amp] Zynq 7-Series with Linux Userspace RPMsg Example
Hello,
I have a Zynq 7-Series board and my configuration (desired) is to have Linux running on CPU 0 and a bare metal application running on CPU 1 where I would like to be able to execute the bare metal app from Linux user space and have it execute on the unused CPU1.
In reading UG1186 I see examples for this however this note: "Note: This RPMsg in Linux userspace example only supports Zynq® UltraScale+™ MPSoC devices"
gives me pause: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_4/ug1186-zynq-openamp-gsg.pdf#page=22
Questions:
? Is the Zynq 7-Series supported in this manner or do I need to use the module load/unload method?
[Wendy] Zynq7 series is not supported in this manner.
For Zynq, you will still need to user load/unload zynq_remoteproc method.
If it is supported I am unsure of how to make the necessary device tree (DTS) modifications to configure the shared memory.
I did notice this for what I assume is for the module load/unload technique for the Zynq 7-Series.
? Is this correct for the user space application and if not is there an example of the configuration for the 7-Series?
{
amba {
remoteproc0: remoteproc@0 {
compatible = “xlnx,zynq_remoteproc”;
reg = < 0x00000000 0x10000000 >;
firmware = “firmware”;
vring0 = <15>;
vring1 = <14>;
};
};
};
[Wendy] For Zynq, 2016.4, “reg = < 0x00000000 0x10000000 >” is for firmware, vring and shared buffers.
The zynq_remoteproc kernel driver, declare DMA memory with the address specified with “reg”.
Also, when compiling the libbaremetal and open-amp, they depend on the generated BSP source files from XSDK.
? Should the BSP for their compilation be for CPU 0 or CPU 1 or does it matter?
[Wendy] the BSP should be compiled for CPU1. As the zynq_remoteproc driver makes the assumption that the “remote” is CPU1.
Thank you for your time.
Jeremy
--
You received this message because you are subscribed to the Google Groups "open-amp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
open-amp+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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.
Jeremy
I'll pursue the load/unload path then.
J
Jeremy
Hey Wendy,
vring0 = <15>;
vring1 = <14>;
Jiaying Liang
HI Jeremy,
Vring0 and vring1 are for the notification of vrings which is used to manage share buffers between the two processors.
Vring0 is the notification of the vring to Linux from the remote
Vring1 is the notification of the vring from Linux to the remote.
We uses software interrupts 15 and 14 for the notification.
When there is a buffer available from the remote to Linux, remote will raise vring0 interrupt; When there is a buffer available from Linux to remote, Linux will raise vring1 interrupt.
Jeremy
I wasn't sure if the interrupt integers were arbitrarily assigned here or if they were obtained somewhere else.
I appreciate your response Wendy.
vivozhang
Jiaying Liang
Hi Jeremy,
15,14 are soft interrupts, if you use Xilinx linux kernel, they are not used, otherwise, you will need to check if they are used for something else.
When a package is received on the bare-metal side, rpmsg_rx_callback() will be called. If you have any issues, you can try to print in this function to see
If it is called, if it can get a rx buffer from the vring, if the rx buffer address is correct.
Best Regards,
Wendy