prussdrv_map_extmem analog using pru_rproc

Skip to first unread message

Ethan Daniel Shea

Jun 18, 2019, 5:03:58 PM6/18/19
to BeagleBoard
The old UIO drivers had access to the prussdrv_map_extmem function which could be used to expose DDR3 memory to the pru, and prussdrv_get_phys_addr which could be used to communicate where the PRU should access data. This is useful when you want to transfer large amounts of data between the PRU and the ARM core. This can be seen in action here.

Is the same functionality available in the newer pru_rproc drivers? If not, what's the best way to do about doing large transfers between the PRU and the ARM core?


Jun 20, 2019, 4:16:14 AM6/20/19
to BeagleBoard
Hi Ethan!

There's no such feature in the rproc driver. Note: the rproc API changes two or three times a year. That's no stuff for productive code yet.

You can implement those functions in your code. Find the source in package am335x_pru_package in file


But why using rproc? uio_pruss privides what you desire.

Anyway, I'm not sure that mapped memory can fulfill you target (400Mbit/s), since all trafic is running over the OCP port. Better think about DMA transfer from fast PRU RAM (DRAM[1|2], SRAM) to ARM RAM.


Jun 21, 2019, 5:11:38 PM6/21/19
to BeagleBoard
Thanks TJF! It's a shame the support for rproc is lacking. Thanks for the resources, they will be helpful.

> But why using rproc? uio_pruss privides what you desire.
The thought was that since the uio driver is no longer being supported it would be better to go with the rproc driver so it's supported in the future. I'm working on a new product, so I'm trying to use the newest dependencies. At the same time, if rproc doesn't have the right features, then it's probably not the right thing to use.

Dimitar Dimitrov

Jun 22, 2019, 3:50:24 AM6/22/19
to BeagleBoard
If you have some experience writing kernel drivers, then it should not be hard. Surely a bit time consuming, though. 

You could create a small kernel driver that would allow userspace to mmap PRU memory, and use remotproc as a backend. There was even a GSoC proposal about it:

I suspect that the beaglelogic kernel driver already contains much of the needed code snippets.

Reply all
Reply to author
0 new messages