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]> wrote: > 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.
