This commit moves the rpmsg library and examples away from using the
SOC mailboxes. Master interrupt events in the PRU-ICSS interrupt
controller are now being used for the signaling between the PRUs and
the ARM core(s).
PRU-ICSS System Events 16 and 17 are being used for PRU0 in all
subsystems and System Events 18 and 19 are being used for PRU1.
This change is necessary because existing devices may not have enough
mailboxes to support each PRU core (AM437x) and future devices (k2g)
based on the KeyStone architecture do not have mailboxes at all.
This change simplifies the PRU_RPMsg_Echo_Interrupt examples to the
point that the PRU_RPMsg_Echo_Polling examples are no longer
necessary so they have been removed.
The nested while loops in the RPMsg examples have been simplified.
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.
Oh, that is complete bunk and you know it. PRUSSDRV is nothing more than a UIO hack.
RPMSG/REMOTEPROC is a lot more in that it support virtual drivers so you can have ethernet, serial, spi, i2c, and more virtual drivers that are defined in firmware. Also, the same implementation supports DSPs, CortexM4s, and other other OS running on other ARM cores. You cannot compare apples and oranges with the one being a minimal/simplistic implementation and the other supporting a full featured interprocessor communications.
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.
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.
Yes, you’re right. The task is to load or reload firmware to the PRUSS and run it, controlled by host software executing under user privilegues. Prussdrv fulfills this task, the other doesn’t. So I compared apples and oranges. Apples and oranges shouldn’t go into the same am335x_pru_package. Thanks for your indorsement.
All that features (you forget to mention debugging) are not really made for main stream users. And who cares about that features when the solution doesn’t provide the basics (and is slow and memory consuming and not really easy to handle and is limited to a special compiler and …)?
I wonder how such an experimental peace of software can find its way to any linux image and all users have to work around it, in order to make their system usable. Even if it’ll be working and will be useful some times in future, this is stuff for an external package in the depths of the development section, and shouldn’t pollute any image by default.
Well, I’m assuming everyone is using the term Remoteproc to refer to the whole echo system because Remoteproc KM doesn’t do anything more than power on, load the code on the PRU, start the code and power off. It doesn’t handle any communications between the PRU and ARM processors. It is Virtio/RPMSG that handle the communications between Linux and PRU.
I am not arguing the need for a separate repo, because the original one has a loader defined and that would conflict with RemoteProc, which is just a loader. The examples that Jason suggested might be added to the repo could be done with minimal mods. The one thing I don’t like about UIO is it cannot handle interrupts in userspace, so this will always compromise responsiveness.
One other thing, I don’t know why TI labels the code as experimental, because it is fully functional and robust. Even with the changes over the last year, there wasn’t a lot of change to the examples, so the impact on developers code was minimal. Also, I believe you don’t have to use the “special compiler” if you create resource tables manually.
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.
Anyway, who knows. Maybe in the future remoteproc will evolve into something better than uio_pruss. But I can not help but feeling that a lot of time and effort us being wasted on something, where that effort could instead be put into improving uio_pruss. We do not need userspace interrupts other that how they’re already implemented ( through /proc/interrupts, and /proc/irq ). But if we did somehow have userspace interrupts in relation to the PRU’s. It would slow things down considerably. Which is why it is generally a bad idea to have userspace interrupts, as such, to begin with.
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”
Again, this makes no sense. /proc is just a processor monitor and doesn’t provide any interface between kernel and userspace. The only way to convey interrupts to userspace with UIO is via kernel events and latency could be 10s or 100s of milliseconds when the cpu is under load. With RPMSG, code runs as a kernel module, so you have access to real interrupts and hence it is more responsive. Also, the interface to userspace is flexible, either via /dev, Sysfs, Debugfs, etc.
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.