WiP: PRU - remoteproc + rpmsg

[yyrkoon 250]

Keep in mind this as the title suggests is a work in progress. So I will be putting up a lot of information, as I figure it out. perhaps code, and questions etc. Anyone is welcome to comment, make suggestion and offer advice, etc.

 

With the above said, there is already information on the TI wiki on how to set this up, and use it from within CCSv6. This is not the approach I'm personally going after. I intend to achieve the same result, without using CCS, and hopefully using gnu tools as much as possible. As remoteproc is nothing specific to TI, or the PRU's. Also, I have a lot to learn, and a lot of information to parse. So if anyone is expecting me to instantly come up with a solution. . . that is not how this project is going to work for me.

 

Additionally, I do not always have the time to spend on just sitting around all day, working on projects like this. Then even if I did, I'm not sure I'd want to be constantly at it . . . so again, this process will take some time.

 

I have been in contact, somewhat, with the person who got remoteproc_pruss working on the beaglebone, and beagleboard X15 images. Who is also using CCS, with  jtag debugging, etc.

[yyrkoon 250]

So starting with this: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_4:_Introduction_to_Linux_driver

 

For now I'm fairly sure LAB 4, in the context of not using CCS can be completely bypassed. As RCN's repo's have TI, and *bone kernels install-able via APT. e.g. no need to rebuild your own kernel, and the example files I think are also as per: https://groups.google.com/forum/#!searchin/beagleboard/[beagleboard]$20kernel$20updates$20thread|sort:relevance/beagleboard/oTGj4Fxyxto/zM9GYtzUCQAJ

 

John Syne got the remoteproc_pruss working

Grab the firmware:

cd /opt/scripts/tools/
git pull
sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x* /lib/firmware/

sudo reboot

sudo modprobe rpmsg_client_sample

 

 

Seems pretty straight forward. So now, I'm reading over LAB5 to see what I can figure out.

[yyrkoon 250]

Just an update. I have not worked on this at all since the day I made the last post. Honestly, I get to reading through some of the implementation code. and example code . . . and I do not like how it is set up currently. The fact that the only working how to's I know of "require" CCS makes me want to put this on the back burner. Which is exactly what I'm thinking I'll do - For now.

 

In the meantime, I've been reading on, and experimenting with UIO a little. Seems very interesting, as a way to use a generic kernel module "stub", and userland code to create a "driver" for just about any hardware. I'm still learning about this, but with the help of another person have a UIO ADC driver working. I will post on this once I figure more out . . .

 

EDIT:

 

By the way, UIO is also what the PRUSS use as a driver module, to communicate between the PRU's, and a userland C app . . . the module uio_pruss exposes PRU shared memory, DDR memory through this interface. When you load that module, you should then be able to see 8 new devices in /dev/uioX (0-7). Again, I'm still learning about all this. SO I'm not 100% sure how all this works, but I'm working on all that . . .

[yyrkoon 250]

Dimitar Dimitrov has started porting the CCS labs to GCC here: https://github.com/dinuxbg/pru-software-support-package.

 

After scanning through the various files, it seems reasonably decent. Baring coding style . . .which I'm not sure whose style that is, but it's fugly as hell.