Hi,
Anyone know of example code that’s using the newer remoteproc interface? Also, is there a way to convert pasm binary files to elf format for the firmware loader?
Would like to play around with the latest 3.14 TI kernel, but haven’t been able to find much info on the PRU side…
Thanks,
Jon
As I read here http://processors.wiki.ti.com/index.php/PRU-ICSS_Getting_Started_Guide
There are some examples included in the SDK.
I’m downloading it to check that, but for now i’m still using the old patch method to enable pruss 
Regards,
Cedric
I believe that PRUSpeak(https://github.com/deepakkarki/pruspeak/) makes use of remoteproc. I haven’t made the transition yet, but I’m definitely curious about it. The complexity of implementing remoteproc seems much, much greater than using UIO or /dev/mem mapping. What is the benefit of using remoteproc over the other methods?
Thanks,
I’ve also found the BeagleLogic project that’s using the remoteproc interface.
Am also just at the curious stage, it looks like remoteproc/rpmsg is the preferred interface going forward, but it seems much more complicated!
Regards,
Jon
I believe that PRUSpeak(GitHub - deepakkarki/pruspeak: BotSpeak interpreter for the BeagleBone Black's PRU) makes use
of remoteproc. I haven't made the transition yet, but I'm definitely curious
about it. The complexity of implementing remoteproc seems much, much greater
than using UIO or /dev/mem mapping. What is the benefit of using remoteproc
over the other methods?
I'm not sure of all the advantages, but here are some:
* The more "Linux" way to do it with the remote processor being
abstracted as a processor and not just some random memory mapped thing
* Uses the kernel firmware loader making managing firmware something
that can be easily coupled with the kernel and standard file formats
* Processor-agnostic communication abstractions such that
"platform-specific remoteproc drivers only need to provide a few
low-level handlers, and then all rpmsg drivers will then just work"[1]
* From a performance perspective, it enables handing of remote
processor events from the kernel level which avoids a userspace
context switch
* Vring communication can be rather efficient as seen in the case of BeagleLogic
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/remoteproc.txt
So where are the PRU examples of this ? To me this whole concept sounds very far fetched, but I will be the first to admit this would be a very very cool feature.
And by examples, I mean an introductory “hello world” app. Not an already working project with tens of thousands of lines of code to wade through.
Hi,
There isn’t really a “hello world” for remoteproc as you would have to write a kernel module or modify the remoteproc kernel module to do anything concrete with the PRU remoteproc driver as of now. Plus if vrings do not really suit your application, then you will have to develop your own userspace layer to expose functionality to userspace. I’ve done it with a character device in BeagleLogic - the buffers can be read(), mmap()-ed, and poll()-ed, and there’s some sysfs attributes and ioctl()'s for configuration. You might want to think of other possibilities depending upon your application.
The basic unit of communication between remoteproc and the PRU as of now is using downcalls and syscalls.
A syscall is when the PRU raises an IRQ and halts itself, storing some values in its registers. The kernel module handles the syscall IRQ, it reads the registers, manipulates them and resumes the PRU over the HALT instruction. See here for an example code of the syscall on the PRU side.
A downcall is initiated by the kernel module. Think of it as calling a function in the PRU from the kernel module and receiving the return value back in the kernel module.
The PRU has to be polling for the downcall, and it acknowledges with a special syscall. Then the function handle_downcall is called, which receives the downcall value and the parameters. So the handle_downcall (example) is a switch-case thing where the PRU does something and once it returns from this function, there is a syscall triggered which signals that the downcall is complete, the kernel module reads the return value of the function, after which the downcalling function in the kernel module returns with the return value.
I can go on and make thjs post TL;DR but the crux is that remoteproc currently is very application-specific and you have to twist and adapt the kernel module to your needs. Once the remoteproc stuff gets finalized, ideally there would be a generic framework and userspace layer on top of the driver to allow you to write your own applications from userspace, in a similar way as it is currently done using libprussdrv.
I’m speaking all this from experience gained while developing BeagleLogic, and that was for the 3.8.13 kernel. With the BeagleBoard community now migrating to a 3.14 based kernel, BeagleLogic will have to be ported to 3.14 which uses a new pru_rproc driver , and I will see how it can be done as there are differences between them, and some functionality will have to be added to the new driver.
Unfortunately I believe wading through thousands line of code would be the only option for now if you want to develop a new application.
Kumar, thank you very much for your reply.
It seems as though I may need to take the time to read through your project brief, and possibly code to get a rough idea of use case - And if it is suitable for me. Quite honestly, I’m not even sure yet what I’d use a PRU for in a project. This is to say, I know what a PRU is, I know what a PRU is capable of ( mostly ), and how some have put it to use.
I do have one project in mind which requires high speed PWM / ADC - Think up to around 2MHz / 2msps. However the more I think about the project, the more I think the BBB, and both PRUs are not as suitable as something lIke a TI C2000 ( Delfino ).
Still, the “idea” of remoteproc is still very interesting to me. I’ll definitely do some reading on the subject.
Thanks again for your reply.