> On Jun 27, 2016, at 12:51 AM, TJF <jeli.freih...@gmail.com> wrote: > > @John3909: > > Am Sonntag, 26. Juni 2016 20:13:12 UTC+2 schrieb john3909: > It makes no sense to discuss that in detail here, since you obviously have no > idea on rapid prototyping controllers. (I can give you a private lesson if > you like.) > On the contrary, perhaps you should explain the use case so everyone here can > understand what it is you cannot do with RemoteProc/RPMSG. Give some examples > of how you do this with libpruio. I just don’t understand the need for > communications with Linux in a tight control loop, but I’m hoping you can > enlighten us on the issue ... > > I think Suman did already know what libpruio (and many other high performance > PRU projects) need. But here's a private lesson for you: There is no "need > for communications with Linux in a tight control loop". We need direct memory > access between PRU and ARM CPU. No Linux inbetween. We need to bypass all > that vring and RPMsg magic. We gain for speed and small memory footprints. We > want to save resources for future extensions and we don't want to spend > resources for features that we neither need nor want. While I haven’t tried this, I don’t believe there is anything in the RemoteProc/RPMSG framework that prevents you from doing this now. You can still use RemoteProc to load/start/stop your PRU firmware and you don’t have to use virtio or rpmsg, but rather create a new KM to do just this. Suman does this make sense? > > ... and hopefully move this discussion forward. > > To get this discussion forward, we have to move backwards. Neither Suman nor > myself want this. So the best way to solve the conflict is, that we get both > of our concepts optional. The user should decide if he wants to drive a > Jaguar or a Bentley. > > Since the Bentley has an open trunk where any agressor can easy hide a big > bomp, it is a MUST-HAVE to get it out of the mainstream. Remeber, PRUSS can > access ALL memory. A PRU virus can even override kernel space memory or > manipulate kernel drivers. All the safety strategies you explained to William > are pointless when a PRU virus overrides your instructions. With network > access, a small loader on the PRU could exchange the complete system, > auto-started by remoteproc at boot time. And all that vring and RPMsg magic > make it even more easy to develop such a malware. Currently, remoteproc is > some kind of VCE (virus construction environment), inbuild in the kernel > source. So how do you propose to modify the PRU firmware without root access? On the other hand, your libpruio app runs in userspace, so it is easy to swap out that app and bypass all security. > > I wonder how you can speak about safety and support such a concept at the > same time. If you're not just declaiming phrases you learned at highschool, > if you have a brain of your own and you're using it, if you really were > interested in security, you would second my proposal to make remoteproc > optional, and remove it from mainstream. Your childish antics say more about you and this isn’t helpful in this discussion. Keep the discussion professional and reframe from getting personal. You really are not listening, RemoteProc/RPMSG are here to say because of all the other processors TI support and several other vendors have decided to support this framework also. Nothing you say is going to change that. All you can do is request that it is improved to suite your needs, or you will have to build your own custom kernel without RemoteProc/RPMSG to support libpruio. RemoteProc/RPMSG will be the standard interprocessor communications framework in Linux. Take this chance to influence the development. Everything else is futile. > > Think of this discussion as a cooperative one were everyone should ultimately > benefit. > > Fine that we are at one with this, and you are also ready for corporate > development, now. This is so silly and you should be better than this.
Regards, John > > BR > > -- > 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/ebf4bf3f-b545-4efe-9af8-0cb07833217a%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/ebf4bf3f-b545-4efe-9af8-0cb07833217a%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/432E3539-A001-4E44-A598-A78D0257F50D%40gmail.com. For more options, visit https://groups.google.com/d/optout.
