On Sun, 13 Dec 2015 17:22:43 -0700, you 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.
Atmel has made a processor (Xmega E series) that has some programmable logic built in. The idea is that by turning over some simple tasks to the hardware, you get very low latency, very fast response times, and do not have to deal with the time penalties imposed by an operating system. The rest of the Xmega chips already have an event system that with DMA, could take the A/D outputs and automatically put them in an array for you, giving you a periodic interrupt when done. All this without the processor doing anything other than a setup. Even running bare metal, it is likely that a hardware system (such as the Xmega or the PRU) will give you faster response times and higher data rates. Now tools to use that, well, that's the rub. Currently, for some designs, I would have to rely on an FPGA with hardwired logic for fast data acquisition and (some) processing. DSP? Think a processor with extra instructions for multiply/divide and such that runs fast enough to do FFT (Fast Fourier Transforms) on a waveform. Those will result in a spectrum produced from the data. You can do things with that spectrum (filtering, for instance) that you cannot easily do with the waveform in the time (waveform on an oscilloscope) domain. Harvey > >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.
