I do expect that TI will improve the documentation on their implementation of remoteproc / rpmsg sometime in the future though. As in the case of the X15, there are not only 4 on die PRU's, but there are 4 IPU's( 2 usable for general purpose ), and two DSP's( on the dual core A15 ). I've no idea what TI has compiler / assembler wise for these DSP's but the IPU's from what I understand are fairly new( in the context of general purpose ). So I'd assume this is where remoteproc / rpmsg will make the most sense. the on die IPU's
On Sat, Feb 20, 2016 at 10:39 PM, William Hermans <[email protected]> wrote: > *William,* >> >> * I must be missing something, because I see remoteproc as a* >> * communication and management mechanism for code on CPUs other than the* >> * main processor. The actual code that you are running on those* >> * subsidiary processors does not depend on the mechanism you use for* >> * talking to it (other than the parts that do the talking, of course).* >> >> * In particular, running ADC, I2C or GPIO should be the same, regardless* >> * whether you use remoteproc or not---what changes is how you tell this* >> * code what to do.* >> >> * Does it make sense to you?* > > > What it is suppose to do hs always made sense to me. How exactlyit is > done, is another story. > > with uio_prussdrv, you have a driver module, which sets various things up, > loads the PRU binary, and then enables / runs the PRU(s). On the PRU side, > the code runs, communicates with various peripherals as needed( usually > one, if any ), and then the PRU code performs it's function as specified in > assembly. Sometimes, dumping data into ddr3( as per the example ), and > sometimes not. > > Anyway, the above is a fairly rough description, but how each aspect > communicates with the other is abundantly clear in code. Some have even > attempted to describe what happens, but if you ask me inadequately. No > matter though the code is pretty clear. > > With remoteproc, the Documentation/*txt documentation is very minimal, and > does not describe the process in which it works very well. However, the > code is fairly clear as to how the ARM, and PRU sides communicate with one > another( rpmsg ). However, what is not clear, is how the PRU code actually > manipulates the physics on system hardware. Additionally, to confuse > matters even more, the assembler has changed to a compiler( C - clpru ), > and there is something like "map" files for hardware configuration that do > not seem to be very well documented. Just some examples, that are not very > clear as to how, or why these are even needed. > > So here I am, attempting to learn a few things new to me. Documentation is > very poor, TI refuses to answer any questions in relation to PRUs on their > e2e forums(" go to beagleboard.org google groups . . ." ). I spend > several days learning about everything PRU related, and immediately pick up > the concept of uio_prussdrv. Still having a hard time with the TI C > compiler on the PRU side of things, largely due to these mysterious > configuration files. But no matter, the TI Assembler is fairly straight > forward, the PRU instruction set is a minimal Cortex M3 set, and easy. > > Anyway, for context of my competence level. Not long ago I wrote a set of > processes / applications to read from the CANBUS in realtime, decode the > CANBUS data, and shuffle this decoded data out over a websocket. This > required me learning several aspect of Linux systems programming from > scratch. Including POSIX shared memory files, socketCAN, and process > spawning / management. All from scratch, since this was my first major > Linux application. All of this including reverse engineering parts of the > high level CANBUS protocol took me around a month. The point here is, I > have no problem picking up / understanding technologies, and / or API's, > libraries, and such that I've previously have had no experience with. *So > long* as there is at least a little decent documentation on the subject, or > I can talk to someone who does understand things that may be confusing to > me. > > Additionally, I'm not saying exactly that remoteproc can't be made to > work, because obviously it can. What I am saying is that since the concept > is so poorly documented, is still in experimental phase, and now I learn > that it is slower than traditional prussdrv drivers / methods. That it's > just not worth my time to even attempt to get working. > > That and I *have* spent some time ( roughly a week ), *just because* I'm > the type that does not mind experimenting with new technology in software. > But only new technology that is not too argumentative. As my time is far > too valuable to me than to screw around with technology that honestly makes > very little sense to me. > > Also for what it is worth. remoteproc / rpmsg in my own mind is far more > useful in cases where a processor may have multiple application / general > purpose cores. In that one core can be made to run Linux, while the others > can be made to run bare metal - Simultaneously. Less useful on the case of > the PRUs since we already have a software layer that is well documented, > works very well, and quite honestly far superior to remoteproc / rpmsg in > this case. If nothing else. Speed. > > > On Sat, Feb 20, 2016 at 9:45 PM, Przemek Klosowski < > [email protected]> wrote: > >> On Sat, Feb 20, 2016 at 2:45 PM, William Hermans <[email protected]> >> wrote: >> > Is it really so much to ask for example code to demonstrate how to >> interact >> > with the on die hardware ? Without having to download 1GB of pretty much >> > useless library . . . >> >> William, >> >> I must be missing something, because I see remoteproc as a >> communication and management mechanism for code on CPUs other than the >> main processor. The actual code that you are running on those >> subsidiary processors does not depend on the mechanism you use for >> talking to it (other than the parts that do the talking, of course). >> >> In particular, running ADC, I2C or GPIO should be the same, regardless >> whether you use remoteproc or not---what changes is how you tell this >> code what to do. >> >> Does it make sense to you? >> >> -- >> 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.
