As Robert has already said, RPMSG/RemoteProc will replace UIO_PRUSS. The problem is you haven’t taken the time to learn RPMSG/RemoteProc so you shouldn’t be providing advise to others. Your question “how does remoteproc make things better” has already been answered. It is possible to create firmware defined devices that can be accessed like any other Linux device under /dev. For example, I can create a Profibus device driver in firmware. To Linux, this would look no different to /dev/tty0. The Virtio is an extremely powerful concept. RPMSG/RemoteProc is implemented in kernel space and UIO_PRUSS is implemented in userspace. How many userspace device drivers exist in Linux? UIO_PRUSS is also a compromise to system security.
Givent the more simplistic example of toggling an LED, uio_pruss it might be easier to implement this in uio_pruss, but when you are talking about a more serious device interface, the infrastructure available with RPMSG/RemoteProc makes the implementation much easier. Speaking of deaf ears, I’m not sure the TI PRU developers are monitoring this mailing list, so send your suggestions/questions to the developers directly or post to the linux-OMAP mailing list or post comments to E2E. They were very helpful in helping me learn the ins and outs of RPMSG/RemoteProc. Your third paragraph makes no sense to me. My guess is you meant “Where remoteproc *would* shine, is on a system with additional on die computational cores” Regards, John > On Jun 16, 2016, at 9:54 AM, William Hermans <[email protected]> wrote: > > I voiced all these concerns and more months ago and apparently my concerns > fell on deaf ears. > > remoteproc is a really cool concept. But it's not meant for this board, > despite people trying to use a shoehorn to get the beaglebone 'horned in'. We > already have uio_pruss, and it has worked great for how many years now ? > *AND* how does remoteproc make things better in comparison to uio_pruss ? As > far as I can see, it doesn't. It does not make things any easier, and its all > the things TJF mentions above, and more( in the negative ). > > Where remoteproc *would* shine, is on a system without additional on die > computational cores( IPU, PRU, DSP, etc ), but a multi-core applications > processor. So that one core can run an OS, while the other runs bare metal. > *THAT* is the vision I see for remoteproc. > > On Wed, 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/CALHSORoQ1N4YqQHd_R6-zX4rcDGigjiG%3D%3DmpWu0ZY%3DR3k4_0_g%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CALHSORoQ1N4YqQHd_R6-zX4rcDGigjiG%3D%3DmpWu0ZY%3DR3k4_0_g%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/B7151377-9869-4FEA-947F-DD4AA70B15F6%40gmail.com. For more options, visit https://groups.google.com/d/optout.
