The IPU’s are CortexM4 processors. Regards, John
> On Feb 20, 2016, at 9:53 PM, William Hermans <yyrk...@gmail.com> wrote: > > 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 <yyrk...@gmail.com > <mailto:yyrk...@gmail.com>> 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 <http://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 > <przemek.klosow...@gmail.com <mailto:przemek.klosow...@gmail.com>> wrote: > On Sat, Feb 20, 2016 at 2:45 PM, William Hermans <yyrk...@gmail.com > <mailto:yyrk...@gmail.com>> 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 > <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 > <mailto:beagleboard%2bunsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > > -- > For more options, visit http://beagleboard.org/discuss > <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 > <mailto:beagleboard+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
