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 <yyrk...@gmail.com> 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 <john3...@gmail.com > <mailto:john3...@gmail.com>> 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 <yyrk...@gmail.com >> <mailto:yyrk...@gmail.com>> 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 <yyrk...@gmail.com >> <mailto:yyrk...@gmail.com>> 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 >> <char...@steinkuehler.net <mailto:char...@steinkuehler.net>> 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 >> char...@steinkuehler.net <mailto:char...@steinkuehler.net> >> >> -- >> 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 beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard%2bunsubscr...@googlegroups.com>. >> 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 beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.com>. >> 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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > 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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
