PRU Bridge [GsoC 2015]

[shubhangi....@itbhu.ac.in]

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

[Kumar Abhishek]

Hi Shubhangi,

On Thu, Feb 19, 2015 at 10:50 PM, <shubhangi....@itbhu.ac.in> wrote:

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.

​
The firmware running on the PRU is also a part of the PRUSS Support of Newer Kernels/PRU Bridge projects. I mean to say that the users would be uploading their own firmware which is written in the form of a standardized framework on the PRU side as well. There are interrupts between the ARM core and PRU as well (you can read further on it) which can be used as well if you are inside the kernel. The framework could figure out a way to export these interrupts to userspace if needed. I suggest that you also see the documentation for libprussdrv to get a more clear idea.

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.

​That's the way current implementations/firmware does things. However such implementations as of now are ad hoc; very application specific. The idea is to have a standard channel for future applications to build upon (see design goals section of the 'PRUSS support for newer kernels'). Data exchange through reading/writing bytes is good but it would be better, for example to do a "remote function call" i.e. call a subroutine inside the PRU from the ARM core and vice versa (also called upcalls/downcalls). It would be better to think of alternative approaches as well, and that would form a part of the proposal as it gets discussed.

There can be drivers at two levels - the userspace level and also the kernel level. The kernel level drivers register themselves with the PRU core driver and get interrupts redirected as well. BeagleLogic and BotSpeak use a sort of "hacky" approach to do this, but it can be done in a better manner. The userspace drivers interact with the kernel through a standardized interface.

You are welcome join on #beagle-gsoc at IRC as well (irc.freenode.net) for further discussion.

Best Regards

Abhishek

 

Shubhangi Gupta
Indian Institute of Technology, Varanasi
Electrical engineering

--
You received this message because you are subscribed to the Google Groups "BeagleBoard GSoC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard-gs...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deepak karki]

On Thursday, 19 February 2015 22:50:00 UTC+5:30, shubhangi....@itbhu.ac.in wrote:

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) .

[shubhangi....@itbhu.ac.in]

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 :)

[Kumar Abhishek]

​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​

[Shubhangi Gupta]

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 :)
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

[Shubhangi Gupta]

Please review my proposal on melange.
Thanks

[jason...@gmail.com]

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