Robert, By the way, there is only one remoteproc / rpmsg example there. The rest is either uio based, or completely non relevant( demonstrating some "new" gcc feature ).
On Sun, Dec 13, 2015 at 5:33 PM, William Hermans <yyrk...@gmail.com> wrote: > . . . And my god, what is this supposed to be ? C ? > > > https://github.com/dinuxbg/pru-gcc-examples/blob/master/blinking-led/pru/resource_table_0.h#L43-L72 > > On Sun, Dec 13, 2015 at 5:22 PM, William Hermans <yyrk...@gmail.com> > wrote: > >> I actually think remoteproc / rpmsg is usefu for multi core systems. Say >> a dual core ARM processor where one core is running Linux, and the other is >> running bare metal for <whatever> deterministic purpose. I am however still >> unconvinced how it is useful when you have multiple cores on die that are >> not all application based processors. Such as the PRUs, or on die M4 / IPU >> on the X15's processor. DSP . . . yeah I do not know enough about those to >> make that call. >> >> On Sun, Dec 13, 2015 at 5:05 PM, William Hermans <yyrk...@gmail.com> >> wrote: >> >>> It's a BS example because it does not illustrate how remoteproc and >>> rpmsg are useful. It also does not illustrate how to access the hardware >>> modules through this technology. Here . . . >>> >>> Something useful -> https://github.com/boxysean/beaglebone-DMX >>> Something else useful -> https://github.com/pgmmpk/beaglebone_pru_adc >>> Yet another something useful -> >>> https://github.com/abhishek-kakkar/BeagleLogic >>> >>> All these have been in the wild for a long time. They work, and the >>> hardware / software paradigm is well known, and explained many times all >>> over the web. >>> >>> Show us how to blink USR0, then explain how that works. Or even show us >>> how to use any on die hardware module, or something that can be "plugged >>> in" to demonstrate an immediate result. Without having to hook up external >>> electronics / circuits. >>> >>> That is why uio_pruss is better than remoteproc. People understand it, >>> or if they do not, they can read about it, and grasp the concept fairly >>> quickly. Because there is a lot of good documentation, and many, many good >>> examples that cover just about any on die hardware module. >>> >>> Anyway, I think the burden is actually on you, to explain to me, and >>> others why remoteproc / rpmsg is any good and should be used. Since, >>> uio_pruss has been around since 2011 or earlier, and is perfectly >>> functional. With that said, regurgitating sentiments such as "bla blah blah >>> has adopted x.y.z" is going to do you no good. We do not care who as >>> adopted what, and why. We want to know why remoteproc, and rpmsg is worth >>> out time investment. Especially considering we already have a large time >>> investment with uio_pruss. >>> >>> On Sun, Dec 13, 2015 at 4:40 PM, John Syne <john3...@gmail.com> wrote: >>> >>>> 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 <yyrk...@gmail.com> 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 <yyrk...@gmail.com> >>>> wrote: >>>> >>>>> OK, so show us a real world example of rpmsg. >>>>> >>>>> On Sun, Dec 13, 2015 at 3:53 PM, John Syne <john3...@gmail.com> 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 <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> >>>>>> 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> >>>>>>> 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> >>>>>>> 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> 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 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> 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. >>>> >>>> >>>> -- >>>> 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. >>>> >>> >>> >> > -- 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.
