Regards, John
> On Jun 16, 2016, at 2:40 PM, Jason Reeder <jasonree...@gmail.com> wrote: > > John, > > Have you seen our PRU-ICSS landing page: > http://processors.wiki.ti.com/index.php/PRU-ICSS > <http://processors.wiki.ti.com/index.php/PRU-ICSS>Yeah, this is my main > starting point, but I hadn’t noticed the PID motor control demo and that > looks like an excellent example of how to use RPMSG/RemoteProc. > and also the Remoteproc/rpmsg sub page on that wiki: > http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg > <http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg>I > don’t recall seeing this doc before which goes the the bigger point, the > layout of the wiki is just horrible. Other than clicking on each and every > link, better to layout the wiki in such a way that reflects the way a > developer will learn each aspect of the framework. The layout of this > document probably is a good place to start, with links for each block > providing more details. For example, VRING, what is it, how do I use it, what > are the limitations, etc. The section describing the resource table should > include the layout and how it is used. Some developers want to use GCC and > not TI’s proprietary C Compiler, so what needs to change to use GCC. Another point, when I look at “lsmod”, I see pruss_remoteproc, virtio_rpmsg_bus and rpmsg_pru, not pruss_rproc and pruss as described in this document so an explanation of what changed and when is necessary. > > If so, let me know which parts are unclear/insufficient and I can work to > improve those. Of course, all of the work and documentation on that wiki will > be geared toward to the TI Processor SDK Linux distribution. For the most part, you have most of what you already need. It is just badly organized and the TI acronyms need to be explained. Also, I’ve seen several PRU presentation that I don’t see in this wiki. I’ll have to look for these links. I hear from the UIO-PRUSS developers about how great their documentation is. Perhaps it isn’t the UIO-PRUSS doc that is good, but one of the libraries such as libpruio which lead the developer through an incremental learning curve. The examples are explained line by line. Maybe on of the UIO-PRUSS developers can direct us to what they consider excellent documentation. > > Keep in mind that the latest changes to the pru-software-support-package > rpmsg examples are tightly coupled to the current work that Suman is doing on > an upcoming 4.4 kernel from TI. So the latest examples are not going to work > until the Linux drivers are updated to use interrupts instead of mailboxes as > well, which is why I revved the major version of the package to v5. Yeah, Suman made us aware of this issue, but the changes to the examples look pretty straight forward. > > I would love to see the pru-software-support-package and rpmsg pick up steam > in the community. However, any work that would not benefit the TI Linux > distribution directly will have to be done at home on my own time. I'm not > opposed to that idea though as my Beaglebone Green Wireless just arrived in > the mail this afternoon and I'll be needing to get more familiar with the > community distribution anyway. My thinking is it shouldn’t matter if we are using TI’s distribution or Robert Nelson’s Debian distribution. The framework should be the same and the examples should work on both distributions. I want to thank you giving us your input and for all the hard work you have done on RPMSG/Remoteproc. Regards, John > > Jason Reeder > > On Thursday, June 16, 2016 at 2:42:26 PM UTC-5, john3909 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. > > 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’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. > > 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. > > 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. > > Regards, > John > > > > >> On Jun 16, 2016, at 12:10 PM, Jason Kridner <jkri...@ <>beagleboard.org >> <http://beagleboard.org/>> 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 <john...@ <>gmail.com >> <http://gmail.com/>> 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 <jason....@ <>hangerhead.com >>> <http://hangerhead.com/>> 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 <john...@ <>gmail.com >>> <http://gmail.com/>> 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 <jeli.f...@ <>gmail.com >>>> <http://gmail.com/>> 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 beagleboard...@ <>googlegroups.com <http://googlegroups.com/>. >>>> 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 beagleboard...@ <>googlegroups.com <http://googlegroups.com/>. >>> 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 beagleboard...@ <>googlegroups.com <http://googlegroups.com/>. >> >>> 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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/c6ad2c0e-6c40-43ee-9e05-b7edcffcdfa4%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/c6ad2c0e-6c40-43ee-9e05-b7edcffcdfa4%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 --- 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/45EC287B-5FE4-46E3-9873-A57E68E63209%40gmail.com. For more options, visit https://groups.google.com/d/optout.
