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.
