How is that a BS example? The example shows an ARM kernel module sending a message to the PRU, which interrupts the PRU, which then copies the message from the PRU rx buffer to the PRU tx buffer, which then executes a callback on the ARM kernel module. You should be able to take that code and make it do anything you need.
Regards, John > On Dec 13, 2015, at 3:21 PM, William Hermans <[email protected]> wrote: > > By real world I mean a real world useful example. Not some BS spit 100 > "hello" messages out into dmesg. > > On Sun, Dec 13, 2015 at 4:19 PM, William Hermans <[email protected] > <mailto:[email protected]>> wrote: > OK, so show us a real world example of rpmsg. > > On Sun, Dec 13, 2015 at 3:53 PM, John Syne <[email protected] > <mailto:[email protected]>> wrote: > OK, so maybe you can explain why you think there is a difference between > writing PRU firmware targeting PRUSS vs PRU firmware targeting remoteproc? > The only difference is the API. You can build the firmware for each in the > same way. The only reference to CCSV6 is the examples TI created for > remoteproc. Someone updated those examples to build with GCC. So I don’t > understand what you mean by forced to use “close source tools”. Nothing in > remoteproc is closed source. All remoteproc does is load the firmware on the > PRU and then start the code. virtio_rpmsg_bus handles the communications > between ARM and the PRU. > > Regards, > John > > > > >> On Dec 13, 2015, at 12:43 PM, William Hermans <[email protected] >> <mailto:[email protected]>> wrote: >> >> We're not talking about the X15 in this post, and personally, I probably >> won't be using an X15 for a long, long time. Too much board, for too much >> money. >> >> On Sun, Dec 13, 2015 at 1:30 PM, John Syne <[email protected] >> <mailto:[email protected]>> wrote: >> Remoteproc/RPMSG is a standard in mainline for interfacing ARM to other >> processors on the same SOC. On the x15, this will be the only way you can >> interface to the DSP, M4’s, etc. Other vendors have adopted this solutions >> as well. >> >> Regards, >> John >> >> >> >> >>> On Dec 13, 2015, at 12:25 PM, William Hermans <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> So, not to argue, but my point of view. I have no problem with people using >>> remoteproc, *if* that's what they want to do. At the same time, I feel that >>> it should not be "forced down our throats", because right now, it is not >>> ready for prime time. uio_pruss is a known quantity, lots of people have >>> documented their use of it, and remoteproc is barely documented at all. >>> Passed that, from what I've seen so far, only closed source tools can be >>> used with remoteproc, on the beaglebones. >>> >>> I did see someone post a gcc "port" of one of Jason Reeders guides . . . >>> but no mention of toolchain setup, or anything else. >>> >>> So until documentation is up to snuff, and we're not forced to use close >>> source tools. I'll always consider remoteproc as something not to be used >>> seriously. I'm sure I'm also not alone. >>> >>> On Sun, Dec 13, 2015 at 1:17 PM, William Hermans <[email protected] >>> <mailto:[email protected]>> wrote: >>> With newer kernels, you need to use the standard Linux remote-proc >>> interface, rather than the legacy UIO driver. >>> >>> Not exactly. Only if you're using the *TI kernels. The *bone kernels have >>> uio_pruss enabled. >>> >>> >>> william@beaglebone:~$ uname -r >>> 4.1.12-bone-rt-r16 >>> william@beaglebone:~$ sudo sh -c "echo 'pru_enable' > >>> /sys/devices/platform/bone_capemgr/slots" >>> william@beaglebone:~$ ./ti/lsuio-0.2.0/lsuio >>> uio7: name=pruss_evt7, version=1.0, events=0 >>> map[0]: addr=0x4A300000, size=524288 >>> map[1]: addr=0x9E880000, size=262144 >>> uio6: name=pruss_evt6, version=1.0, events=0 >>> map[0]: addr=0x4A300000, size=524288 >>> map[1]: addr=0x9E880000, size=262144 >>> uio5: name=pruss_evt5, version=1.0, events=0 >>> map[0]: addr=0x4A300000, size=524288 >>> map[1]: addr=0x9E880000, size=262144 >>> uio4: name=pruss_evt4, version=1.0, events=0 >>> map[0]: addr=0x4A300000, size=524288 >>> map[1]: addr=0x9E880000, size=262144 >>> uio3: name=pruss_evt3, version=1.0, events=0 >>> map[0]: addr=0x4A300000, size=524288 >>> map[1]: addr=0x9E880000, size=262144 >>> uio2: name=pruss_evt2, version=1.0, events=0 >>> map[0]: addr=0x4A300000, size=524288 >>> map[1]: addr=0x9E880000, size=262144 >>> uio1: name=pruss_evt1, version=1.0, events=0 >>> map[0]: addr=0x4A300000, size=524288 >>> map[1]: addr=0x9E880000, size=262144 >>> uio0: name=pruss_evt0, version=1.0, events=0 >>> map[0]: addr=0x4A300000, size=524288 >>> map[1]: addr=0x9E880000, size=262144 >>> >>> The pru_enable device tree file is pretty simple too: >>> >>> /dts-v1/; >>> /plugin/; >>> >>> / { >>> compatible = "ti,beaglebone", "ti,beaglebone-black"; >>> >>> /* identification */ >>> part-number = "pruss_enable"; >>> version = "00A0"; >>> >>> fragment@0 { >>> target = <&pruss>; >>> __overlay__ { >>> status = "okay"; >>> >>> }; >>> }; >>> >>> }; >>> >>> Also, yes, everything works fine. I've tested various PRU git projects, and >>> they all seem to work fine. >>> >>> >>> On Sun, Dec 13, 2015 at 9:30 AM, Charles Steinkuehler >>> <[email protected] <mailto:[email protected]>> wrote: >>> On 12/13/2015 4:37 AM, Strawson wrote: >>> > Sadly I'm running into the same missing uio directories now that I'm >>> > trying >>> > to get my beaglebone code that was stable on the 3.8 kernel and Wheezy >>> > image. My old compiled dtbo wouldn't load with a 4.1 kernel until it was >>> > recompiled. Even with it loaded, the following modules don't load: PRU, >>> > eQEP, PWM, and GPIO_buttons. I spent today hacking together workarounds >>> > for >>> > the latter 3, but the PRU still has me stumped. >>> > >>> > Looking closely, the am335x-boneblack.dtb file has changed quite a bit. >>> > Once decompiled I have the following entries for the PRUSS: >>> >>> With newer kernels, you need to use the standard Linux remote-proc >>> interface, rather than the legacy UIO driver. >>> >>> -- >>> Charles Steinkuehler >>> [email protected] <mailto:[email protected]> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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 [email protected] >>> <mailto:beagleboard%[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >>> >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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 [email protected] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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 [email protected] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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 [email protected] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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 [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > > -- > For more options, visit http://beagleboard.org/discuss > <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 [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
