> > *The IPU’s are CortexM4 processors. * > *Regards,* > *John*
You're just now figuring that out ? On Sat, Feb 20, 2016 at 11:20 PM, John Syne <[email protected]> wrote: > The IPU’s are CortexM4 processors. > > Regards, > John > > > > > On Feb 20, 2016, at 9:53 PM, William Hermans <[email protected]> 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 <[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. > > > -- > 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.
