Getting the PRU up and running on 3.14 kernel has turned out to be very challenging. Had I been a hacker trying to make use of PRU for one of his or her projects, I would have definitely turned towards other alternatives by now.

As of now, a PRU user is largely at the mercy of driver author. To make the task more complicated there has been a substantial change in the way things were handled in kernel 3.8 and they way they work now in 3.14.

pruss_remoteproc module code modifications:

1. Prevent pruss_remoteproc module from loading during boot. ( Since 3.14 doesn't allow device trees to be loaded after boot, probing the driver when the device is instantiated should be avoided. )

2. Prevent firmware image from loading during probe time.

3. Expose sysfile file to write f/w name from userspace.

4. Set up PRU code generation environment ( SDK, PRU-addon pkg, CCS ) and compile firmware. ( TI pruss_remoteproc driver requires resource table with code )

5. Modify code to load firmware and boot PRU when required by user.

6. Explore mailbox framework for upcoming work. Mentor discussion reveals lack of PRU code space to implement this solution. Will work towards developing custom-light weight IPC model inspired from existing frameworks.

Code