Ah, so I just use CCSV6 which has all the scripts that take the CortexM4s out of reset and configures their memory map so that I can write code and debug pretty quickly. Now if you don’t use CCSV6, you have to do all that via the CortexA15s and that is going to be very difficult for development. I’ve been doing this on the OMAP5 for several years, which has many of the same features as AM5728. I also use CCSV6 for the DSPs, which have the same issues. The TI DSP C compiler is highly optimized for the C66 DSP which has many cores that operate in parallel. Also, the instrumentation provided by CCSV6 makes it possible to do very accurate measurements while running live code. This is especially important for multithreaded applications. BTW, I believe CCSV6 doesn’t need a license for code that is less than 16K.
Regards, John > On Feb 20, 2016, at 10:30 PM, William Hermans <[email protected]> wrote: > > 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] > <mailto:[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] > <mailto:[email protected]>> wrote: > The IPU’s are CortexM4 processors. > > Regards, > John > > > > >> On Feb 20, 2016, at 9:53 PM, William Hermans <[email protected] >> <mailto:[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] >> <mailto:[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 <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 >> <[email protected] <mailto:[email protected]>> wrote: >> On Sat, Feb 20, 2016 at 2:45 PM, William Hermans <[email protected] >> <mailto:[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 >> <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] >> <mailto:beagleboard%[email protected]>. >> 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 [email protected] >> <mailto:[email protected]>. >> 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 [email protected] > <mailto:[email protected]>. > 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 [email protected] > <mailto:[email protected]>. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
