Hi Jason Reeder, I think William forgot to include you in his response. As you can see, William is an experienced developer who had difficulty understanding the RPMSG/Remoteproc framework. A lot of this I believe is TI’s tendency to use terminology assuming the reader is familiar with and in most cases we are not. I agree with William that canned examples are no substitute for a document that explains how something works. For example, what are VRings. Now I know that they are virtual ring buffers, but what are the interfaces, how do they work, what are their limitations, how responsive are they, throughput, etc. Same for Virtio. How does it work, how are drivers abstracted, what is the messaging format, etc. At each level, an explanation is necessary and as William indicated, a good API doc is also necessary.
I’ve seen this requirement to use GCC in place of CCS several times so an explanation on how to use GCC would be helpful. I have asked William to post links to good pruss_uio docs that might serve as a guide. Regards, John > On Jun 16, 2016, at 6:19 PM, William Hermans <[email protected]> wrote: > > @ Jason Reeder > > I have seen much of your documentation on the ti wiki pages, as I spent a > week or two a bit at a time attempting to get something working to test > remoteproc. Here, one could probably very easily duplicate exactly what > you've done, and get exactly what you've demonstrated, working. The problem > here is that this does not teach anyone anything. So, if I for example wanted > to write host code using GCC instead of CCS. There is not enough information > for anyone to make this happen easily. *WITHOUT* digging into the source > code, or pouring over what little information there is on the web about > remoteproc. Which by the way most of that outside information is irrelevant > because they do not have PRUs. > > So, I stopped attempting to test remoteproc, because there is not enough good > documentation on the subject. exact step guides are useless if all you really > need to know exactly what needs doing for this to work. How does one write a > PRU config( hex ) files? What are the purpose of these files, and what is a > minimal example. Which drivers are needed ? Where is the API documentation ? > > You all need to make this dead simple to setup, not matter where a developer > is coming from. Otherwise you're going to end up with a bunch of very > experience pissed off developers, who do not even want to bother with > remoteproc. This means, that exact step guides for CCS only will not cut it. > > On Thu, Jun 16, 2016 at 6:06 PM, Greg <[email protected] > <mailto:[email protected]>> wrote: > Hi Suman, that confirms what I suspected about this new module pruss_intc. > I am going to continue to experiment with the old and new PRU package and see > if I can determine the problem. > I think I need to look at the device tree I am using and see if it has the > required properties. > > Regards, > Greg > > On Thursday, June 16, 2016 at 8:02:08 PM UTC-4, Anna, Suman wrote: > Hi Greg, > > > Yes, we have introduced pruss_intc new on 4.4 kernel and this module now > manages the PRUSS INTC. It provides the irqchip/irqdomain which will allow > client users to use standard DT properties for listing the PRU system events > as interrupts and use standard Linux APIs. There is still some more work to > be done there (ability to add system event to PRU channel mapping to host > interrupt from DT) rather than having to provide that mapping data in > firmware resource table, so the MPU-side clients can be cleanly separated and > depend on Linux infrastructure alone. > > > I am not sure how much the kernel you are using has caught up to the changes > I have been doing on my tree, but there are a few changes over the last week > where we added and switched over to PRU system events instead of mailboxes > for scalability purposes (mailboxes would work too provided you choose > mailboxes in DT over interrupts). This is what Jason was referring to as > v5.0.0. > > > Regards > > Suman > > > > -- > 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]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/b629798b-8703-4c5c-8e9b-f055745165ad%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/b629798b-8703-4c5c-8e9b-f055745165ad%40googlegroups.com?utm_medium=email&utm_source=footer>. > > 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]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CALHSORqhD-ubwQoV4GX7wXNe0-bAZ0be%3Ds57uSqsQWbEMhEKLQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CALHSORqhD-ubwQoV4GX7wXNe0-bAZ0be%3Ds57uSqsQWbEMhEKLQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/01D86E77-ABC7-4323-8BD9-61AA9E367720%40gmail.com. For more options, visit https://groups.google.com/d/optout.
