I think more correctly said. They're similar to a Cortex M4 that sits on an Lx host processor interconnect. So you can not just use the eabi-none gcc port to make them work . . .
On Sat, Feb 20, 2016 at 11:22 PM, William Hermans <[email protected]> wrote: > *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.
