Hi,

I will ask the PRU experts to comment. Note that reply may be delayed due to upcoming holidays.

Girish Tummala said:

1. Using uio_pruss driver

2. Using remoteproc and rpmsg

3. Using Virtio

These are all closely related.  I don't think you want to use #3 (at least not directly).  Rpmsg builds on top of virtio, though note that rpmsg is only available in kernel space.  So if you're trying to communicate with the PRU from a kernel driver, then rpmsg is likely the right route.  If you're looking to communicate to the PRU from user space, then you would need to build a driver that interfaces between user space and kernel space.  That's where the uio solution comes into play, i.e. it's an example implementation of how you might interact with the PRU from user space.

Thanks for clarifying this.

Also do you have any comments on my initial thoughts on allocating a buffer in the local PRU memory and have ARM fill the buffer with the data to be passed on to PRU?

I am planning to use CMEM on the linux side to allocate buffer in the 8KB data memory of PRU and them send the memory physical address(or offset) to PRU using rpmsg.

The PRU can then locally read the buffer using the offset from the 8KB data memory.

Does this all makes sense?

Or is there a more proper(efficient) way to handle data transfer between ARM and PRU?

Thanks.

UIO is an example loader. I would just use remoteproc for loading.

Our PRU support for the AM57xx was added only beginning with Processor SDK 2.00 (4.1 kernel). We don't have official support in place for 3.14.

The recommended path is to download the latest PRU software here:

www.ti.com/.../pru-swpkg

There is training material on how to use it here:

processors.wiki.ti.com/.../PRU_Training:_Hands-on_Labs

I suggest starting with an EVM running Proc SDK 2.00 to make sure you can get everything working as a baseline. Then you could look into backporting it to 3.14 if that's a firm requirement.

Hi Brad,

I did follow all these steps. I am currently able to communicate to PRU successfully. I was able to run the "rpmsg_pru_user_space_echo" on the linux side and did get response from the PRU.

Now I am at a stage where I have to implement things beyond just running the sample program successfully.

My question above regarding buffered data transfer between ARM and PRU relates to this effort.

I modified the question to be more precise. I am pasting it again below:

Also do you have any comments on my initial thoughts on allocating a buffer in the local PRU memory and have ARM fill the buffer with the data to be passed on to PRU?

I am planning to use CMEM on the linux side to allocate buffer in the 8KB data memory of PRU and them send the memory physical address(or offset) to PRU using rpmsg.

The PRU can then locally read the buffer using the offset from the 8KB data memory.

Does this all makes sense?

Or is there a more proper(efficient) way to handle data transfer between ARM and PRU?

Thanks again!

Girish Tummala said:

I did follow all these steps. I am currently able to communicate to PRU successfully. I was able to run the "rpmsg_pru_user_space_echo" on the linux side and did get response from the PRU.

Did you do Lab 5 Part 3?  That's where you learn to programmatically send buffers using APIs.

Girish Tummala said:

I am planning to use CMEM on the linux side to allocate buffer in the 8KB data memory of PRU and them send the memory physical address(or offset) to PRU using rpmsg.

The PRU can then locally read the buffer using the offset from the 8KB data memory.

Does this all makes sense?

It sounds like you're more or less planning to bypass all the RPMSG communication layers by rolling your own.  Did I understand your solution correctly?

Brad Griffis said:

Did you do Lab 5 Part 3?  That's where you learn to programmatically send buffers using APIs.

Lab 5 Part 3 is exactly what I tried and I am able to successfully send 100 messages back and forth between application and PRU1.

However, from my previous experience with rpmsg, I remember that there is a limitation on rpmsg buffer size that limits the amount of data that can be transferred and this might not work for the purpose intended.

While working on DSP, Robert Tivy suggested using CMEM to allocate buffer and just pass the physical address of the buffer to the DSP.

I was thinking on those lines for PRU as well. I will still use the RPMSG communication layer, but just send the physical address across to the PRU, instead of the actual data. The PRU when it receives the physical address can retrive the actual data from that location.

Brad Griffis said:

It sounds like you're more or less planning to bypass all the RPMSG communication layers by rolling your own.  Did I understand your solution correctly?

No I will not bypass the RPMSG communication layers, like I mentioned above, I am planning to just send the physical address to PRU using RPMSG and let PRU retrieve data from that address.

-Girish

Hello Girish

Have you found a solution to what you asked above (how to transfer large amount of data between ARM (Linux user space) and PRU or from PRU to ARM?

I am faced with the same questions. While Rpmsg can perform the task, I cannot sustain continuous data transfer from an external ADC connected to the PRU to Linux user space as the PRU firmware is held up attending to the task of pushing data to the vring buffers. Is there a more efficient way for large data transfer? Hope the TI folks can help to enlighten 

Hi,
Even we tried to find an efficient way, but ended up using rpmsg as it was sufficient for the data we wanted to transfer to PRU.