OK, so show us a real world example of rpmsg. On Sun, Dec 13, 2015 at 3:53 PM, John Syne <[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]> 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]> 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]> 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]> >> 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]> 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] >>>> >>>> -- >>>> 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. >>>> >>> >>> >> >> -- >> 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. >> >> >> >> -- >> 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. >> > > > -- > 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. > > > -- > 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. > -- 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.
