PRU Bridge [GsoC 2015]

Hey,
I found the ‘PRU bridge’ as well as ‘PRUSS support for newer kernels’ ideas very interesting. I have good knowledge of C and a know a substantial know-how of linux kernel programming and device trees ( I have been reading up on these as well as PRU speak). I have worked with embedded systems and would like to suggest a thing or two. Please correct me if I am moving towards the wrong direction. As given under ‘PRU Bridge’ idea, the PRU will be in an event loop listening for events. Since we are trying to streamline communication between ARM and PRU, isn’t an event loop similar to polling for data written in the shared memory. This would more or less dedicate one PRU entirely for communication and leave us with one for the actual program. Instead we can write a C library for PRU with functions such as mem_read( ) and mem_write( ) which are called when the PRU programmer requires data to be read or written to or from the shared memory. Further we can have flags in the shared memory which can be set by the linux driver and checked/cleared by the PRU to see if data has been written/read. Please discuss if I am incorrect.

Shubhangi Gupta
Indian Institute of Technology, Varanasi
Electrical engineering

Hi Shubhangi,

Hey,
I found the ‘PRU bridge’ as well as ‘PRUSS support for newer kernels’ ideas very interesting. I have good knowledge of C and a know a substantial know-how of linux kernel programming and device trees ( I have been reading up on these as well as PRU speak). I have worked with embedded systems and would like to suggest a thing or two. Please correct me if I am moving towards the wrong direction. As given under ‘PRU Bridge’ idea, the PRU will be in an event loop listening for events. Since we are trying to streamline communication between ARM and PRU, isn’t an event loop similar to polling for data written in the shared memory. This would more or less dedicate one PRU entirely for communication and leave us with one for the actual program. Instead we can write a C library for PRU with functions such as mem_read( ) and mem_write( ) which are called when the PRU programmer requires data to be read or written to or from the shared memory. Further we can have flags in the shared memory which can be set by the linux driver and checked/cleared by the PRU to see if data has been written/read. Please discuss if I am incorrect.

Thats exactly the plan, plus mem_read, mem_write are non blocking (if you set them to be). The “event loop” part depends on the developer who is writing code for the PRU (check for events only when you want to – thats how it’s done in pru speak) .

Hey,
I found the ‘PRU bridge’ as well as ‘PRUSS support for newer kernels’ ideas very interesting. I have good knowledge of C and a know a substantial know-how of linux kernel programming and device trees ( I have been reading up on these as well as PRU speak). I have worked with embedded systems and would like to suggest a thing or two. Please correct me if I am moving towards the wrong direction. As given under ‘PRU Bridge’ idea, the PRU will be in an event loop listening for events. Since we are trying to streamline communication between ARM and PRU, isn’t an event loop similar to polling for data written in the shared memory. This would more or less dedicate one PRU entirely for communication and leave us with one for the actual program. Instead we can write a C library for PRU with functions such as mem_read( ) and mem_write( ) which are called when the PRU programmer requires data to be read or written to or from the shared memory. Further we can have flags in the shared memory which can be set by the linux driver and checked/cleared by the PRU to see if data has been written/read. Please discuss if I am incorrect.

Thats exactly the plan, plus mem_read, mem_write are non blocking (if you set them to be). The “event loop” part depends on the developer who is writing code for the PRU (check for events only when you want to – thats how it’s done in pru speak) .

Can this project involve writing an Rpmsg driver specific for PRU on top of the existing core linux Rpmsg framework. I came across this http://processors.wiki.ti.com/index.php/PRU-ICSS_Rpmsg_Driver but no such driver seem to exist. Alongside the driver, an Rpmsg library for the PRU which will cater to read/write functions will be needed. Both an optimized remoteproc and Rpmsg for the PRU will a well written userspace API ( for python/js ) can provide complete solution of loading firmware,halting/resuming/reseting PRU as well as communication between the ARM & PRUs can be accomplished. Shall I delve deeper into this ? Thanks for helping :slight_smile:

​Rpmsg is the way currently things are supported in the kernel with respect
to the remoteproc infrastructure, but one of the mentors previous year had
expressed disapproval with the rpmsg framework, the reasons being related
to latency as far as I can recall.

A good stress test for checking the latency would be to get BeagleLogic
ported to this new framework as it is quite demanding in terms of data
transfer speed and IRQ rate. If it ​runs well enough, it can be assumed
that the rpmsg framework would be good for most applications. Trying and
seeing if you can get something more about it would be nice. For example,
trying to write a dummy rpmsg driver and a corresponding userspace app
exchanging data with the app could be a good starting point according to me.

​Regards
Abhishek​

I have read and understood PRUSpeak, BeagleLogic and pru-rproc.c code. Compiled and run both of them. Alexander told me to try develop a module which toggles led though PRU by writing char to sysfs. In the process I prodded through various resource on PRU, manuals, device trees, prussdrv lib, firmware codes, kernel programming, etc and gained considerable knowledge. Here’s the link to the repo : https://github.com/shubhi1407/LEDtoggle Has been put together in a couple of days so code is a bit unclean but does the work :slight_smile:
I wish to develop a message-passing framework for communication between ARM-PRU0-PRU1 as posted on the ideas page. Keeping upstreaming in mind this framework will form the basis for communication in all future PRU projects. Working on proposal. Please suggest if something else needs to be done.

Shubhangi Gupta

Please review my proposal on melange.
Thanks

I know I’m late to this thread but if you check the PRU Software Support Package (https://git.ti.com/pru-software-support-package/pru-software-support-package/ or http://www.ti.com/tool/PRU-SWPKG) it has been updated to include exactly what you mentioned above (an RPMsg driver specific for PRU that exposes a character device to user space as well as an PRMsg library for the PRU).

The PRU library source is found here: https://git.ti.com/pru-software-support-package/pru-software-support-package/trees/master/lib/src/rpmsg_lib
The Linux driver is found in this patch: https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/patches/0002-rpmsg-pru-Add-a-PRU-RPMsg-driver.patch

Examples showing the RPMsg PRU usage can be found in the examples folder: https://git.ti.com/pru-software-support-package/pru-software-support-package/trees/master/examples
Hands-on Labs involving RPMsg can be found on the wiki that you referenced above: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_5:_RPMsg_Communication_between_ARM_and_PRU

The PRU-ICSS_Rpmsg_Driver wiki page should be updated within the next few weeks to reflect all of this.

Thanks,

Jason Reeder