@ 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 <soapy-sm...@comcast.net> 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 > --- > 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. > 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. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqhD-ubwQoV4GX7wXNe0-bAZ0be%3Ds57uSqsQWbEMhEKLQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
