> On Jun 16, 2016, at 2:42 PM, Jason Kridner <[email protected]> wrote: > > The repository includes a number of documents, providing a bit of a > one-stop-shop for PRU documentation. A migration guide from UIO_PRUSS to > REMOTEPROC would seem reasonable to add. There's also source to an assembler. > > More responses below... > > On Thu, Jun 16, 2016 at 3:42 PM John Syne <[email protected] > <mailto:[email protected]>> wrote: > Looking at am335x_pru_package, I see things like loaders which conflict with > RemoteProc so I’m not sure that is such a good idea. Are you proposing to > modify the TI examples to work with UIO_PRUSS? That would be a horrible idea > as I have already described the limitations of UIO_PRUSS. > > No, I'm saying that the existing UIO_PRUSS examples should be made to > continue to work on the latest kernels. This might require a way to > transition control from kernel to userspace for the PRU control registers. > > The inclusion of additional REMOTEPROC-only examples could illustrate why to > migrate. It seems to me some of the PRU GSoC projects like BeagleLogic might > also be suitable to integrate here, as we haven't gotten them integrated into > the standard images otherwise yet. > > > TI already have a set of examples and a step by step process on how to build > and use these examples, but I’m talking about augmenting the documentation to > make it easier to understand/use. > > I agree that the documentation should be the focus. I thought the older round > of documentation wasn't so bad, but there is much more to document now with > REMOTEPROC. I'm just saying that making the documentation comprehensive in > once place would be ideal. I think this is key. The layout should foster an incremental learning process, starting with a 10,000 foot overview and then encompassing the ability to drill down to learn the details with suitable examples. > > I’m also proposing to extend the existing examples with real world examples > that can serve as a template for developers. I’m not sure what Jason Reeder’s > schedule looks like, but either he can assist with the development, or just > monitor the development of the examples in such a way that he can take > ownership of the examples. > > Monitoring the external development of extending these examples, including > the GSoC work which is on-going, would be great. Not sure if he can commit to > that. >From Jason Reeder’s response, it looks like we have his support. I think it is >important that we try to maintain a single code base for both TI distribution >and Robert Nelson’s Debian releases. This way Jason Reeder won’t have to do >this work at home ;-) From a maintenance point of view I think this make the >most sense also. > > I'll just note again that that particular repository has external patches > already and cannot be integrated back into a release by TI (at least not at > any reasonable level of effort). > > > Given that RPMSG/RemoteProc is to replace UIO-PRUSS, my only goal here is to > get the community behind RPMSG/RemoteProc so that we are all pulling in the > same direction. At the moment, developers are having a difficult time > understanding the framework and this in large part is why we are seeing > resistance to change. > > Agreed, which is why I want to meet them at the information source they are > using today. You can tell by the reaction that it is an important resource > and care should be extended to updating it. It seems to me the right place to > try to prove the value of REMOTEPROC/RPMSG. I’m sure there are many BeagleBoard developers are going to be very happy to hear this. > > > Finally, developers have complained about poor performance, and perhaps we > need investigate why they are seeing this. Perhaps there is something in the > framework, or perhaps their implementation is wrong. > > Yeah, I'd like to know more details about that as well. I have a near-term > need to migrate some UIO_PRUSS code > (https://github.com/StrawsonDesign/Robotics_Cape_Installer/tree/master/install_files/pru > > <https://github.com/StrawsonDesign/Robotics_Cape_Installer/tree/master/install_files/pru>) > to REMOTEPROC and the author has some of this same concern. http://theembeddedkitchen.net/beaglelogic-goes-kernel-mode-with-pru-remoteprocweek-2-3/190 <http://theembeddedkitchen.net/beaglelogic-goes-kernel-mode-with-pru-remoteprocweek-2-3/190>
This show that libprussdrv was too slow and had to change to remoteproc to improve throughput, which is contrary to what the UIO-PRUSS developers are saying. Regards, John > > > Regards, > John > > > > >> On Jun 16, 2016, at 12:10 PM, Jason Kridner <[email protected] >> <mailto:[email protected]>> wrote: >> >> Nice request. >> >> I'd suggest putting things into the am335x_pru_package on GitHub, but I >> know there are some issues in bringing back code into TI. I'd just suggest >> updating that same sort of package such that we can merge the deltas, but >> one place with a full experience. >> >> Thoughts? >> >> On Thu, Jun 16, 2016 at 12:04 PM John Syne <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Jason, >> >> I have been part of the discussion on this issue spanning several threads >> and I have yet to hear anyone offer any concrete suggestions on how to make >> RPMSG/RemoteProc better, so here are my thoughts on the steep learning curve >> required to use RPMSG/RemoteProc. I think the structure of the framework >> doesn’t need to change and I would not like to see registers turned over to >> user space. I think we just need to simplify the learning curve. >> >> I started by trying to read all the docs and this was my first issue. The >> docs are all over the place, presentations are also spread all over the >> place. To start, I would like to see a more structured set of docs that >> cover everything, from understanding the hardware, the interfaces between >> PRU and ARM, and how everything fits together (RemoteProc, Virtio, RPMSG, >> etc). >> >> I ported RPMSG/RemoteProc from the V3.8 kernel to V4.1 kernel for both BBB >> and BeagleBoard-x15 and during that process, I learned how the whole echo >> system worked. I didn’t learn this from the docs. Later some PRU >> presentations did a better job of explaining the structure, but the use of >> TI's very technical acronyms made the docs difficult to understand. I mean, >> what does virtio, mailbox, vrings, etc mean. I had to read the code to >> understand the concepts and this should not be necessary. >> >> The examples tended to be overly simplistic and don’t necessarily show the >> capabilities of the framework. Perhaps we should call for a list of examples >> developers would like to see and we can work on providing a solution that >> developers can use as a template. >> >> I would be interested in hearing what other think about my proposal. >> >> Regards, >> John >> >> >> >> >> >>> On Jun 16, 2016, at 3:25 AM, Jason Kridner <[email protected] >>> <mailto:[email protected]>> wrote: >>> >> >>> Thanks John. Remoteproc wasn't derived in a vacuum. Every approach provides >>> trade-offs. The constant uninformed assertion that everything is faster if >>> handled by userspace reflects on the struggles we've had to communicate the >>> value of working in the kernel process. >>> >>> I'd like to see a better way of maintaining both, that is to turn the >>> registers back over to userspace, disabling the kernel driver other than >>> UIO. I need to work on articulating that desire. >>> >>> As to the claim that remoteproc is slower---given that the kernel owns the >>> interrupts, I don't see how userspace can service them faster. Examples >>> like BeagleLogic show that remoteproc can be quite fast. The high speed >>> communication between the PRUs and the rest of the system, coupled with >>> their high-speed interface to the external world, are what make them so >>> valuable. Defining some common effective ways of communicating using kernel >>> drivers would seem to make it much simpler for people to develop code >>> quickly. >>> >>> Anyway, we should spend some time with this repo making sure both driver >>> mechanisms are supported and their values articulated. Simply ignoring the >>> remoteproc interface supported in the mainline kernel doesn't make sense to >>> me. >>> On Thu, Jun 16, 2016 at 2:20 AM John Syne <[email protected] >>> <mailto:[email protected]>> wrote: >>> One other thing, if you don’t like some features of RPMSG/REMOTEPROC, then >>> why not provide input to the developers with any suggestions you think will >>> make things better? I have spoken to Jason Reeder and Suman Anna several >>> times and they have been very responsive to my input. >>> >>> Regards, >>> John >>> >>> >>> >>> >>> >>>> On Jun 15, 2016, at 8:53 PM, TJF <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>> >>>> >>>> >>>> Am Mittwoch, 15. Juni 2016 23:47:11 UTC+2 schrieb Jason Kridner: >>>> How is it nonsense? >>>> >>>> There's no realistic concept up to now. Significant changes every now and >>>> then, like the one documented here. >>>> >>>> Some developers may see some advantages anytime in the future, at least if >>>> they use the matching compiler. But currently, from my (and the users) >>>> point of view, remoteproc has less features, is slower, and takes more >>>> kernel memory than the prussdrv solution. In short: experimental, not >>>> ready for productive code. Regretfully I think about every minute I spent >>>> in learning and testing yet. >>>> >>>> -- >>>> 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/bc2d2003-6593-4759-99ca-2b7a95b8d33f%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/beagleboard/bc2d2003-6593-4759-99ca-2b7a95b8d33f%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/F78DF15C-A7CF-4AC5-82DE-604CE7F74E75%40gmail.com >>> >>> <https://groups.google.com/d/msgid/beagleboard/F78DF15C-A7CF-4AC5-82DE-604CE7F74E75%40gmail.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/CA%2BT6QPmqZkBh5%3DNxHU75UZLtWWL83JOVoBmdi4P5cNCLnwsjGA%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmqZkBh5%3DNxHU75UZLtWWL83JOVoBmdi4P5cNCLnwsjGA%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 > <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/CF9664BE-5A74-4B4F-B57D-A84B4B3598D3%40gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CF9664BE-5A74-4B4F-B57D-A84B4B3598D3%40gmail.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/CA%2BT6QPkxJvhQQRyysHPzT6cMvacV%3DVfwVYW4s1UasJxb8n-gRg%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPkxJvhQQRyysHPzT6cMvacV%3DVfwVYW4s1UasJxb8n-gRg%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/05F33B1B-5DB1-48FD-8280-D7F577110C84%40gmail.com. For more options, visit https://groups.google.com/d/optout.
