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 <https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-firmware/pru_syscalls.asm> 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 <https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-firmware/beaglelogic-pru0.c#L106>) 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. On Tuesday, September 16, 2014 9:27:24 AM UTC+5:30, William Hermans wrote: > > 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. > > On Mon, Sep 15, 2014 at 8:51 PM, William Hermans <yyr...@gmail.com > <javascript:>> wrote: > >> 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. >> >> On Mon, Sep 15, 2014 at 8:10 PM, Jason Kridner <jkri...@beagleboard.org >> <javascript:>> wrote: >> >>> On Sat, Sep 13, 2014 at 5:10 PM, Michael M <mmcda...@gmail.com >>> <javascript:>> wrote: >>> > 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? >>> >>> 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 >>> >>> > >>> > >>> > On Friday, September 12, 2014 5:57:17 AM UTC-7, Cedric Malitte wrote: >>> >> >>> >> >>> >> >>> >> Le vendredi 12 septembre 2014 04:11:18 UTC-4, Jon E a écrit : >>> >>> >>> >>> 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 >>> > >>> > -- >>> > For more options, visit http://beagleboard.org/discuss >>> > --- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "BeagleBoard" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to beagleboard...@googlegroups.com <javascript:>. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to beagleboard...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
