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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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. >> >> >> -- >> 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.
