I’ve included Ohad Ben-Cohen who was one of the originators of the RemoteProc/RPMSG framework. Hopefully he will be able to provide some prospective of what he was thinking when he created this framework.
> On Jun 25, 2016, at 7:39 AM, TJF <[email protected]> wrote: > > @John: > > ... so what do you want removed? There is nothing left to be removed. > > I want removed: > > pru_rproc 12632 0 > pruss_intc 7223 1 pru_rproc > Why don’t you use the “bone” kernel which pruss_uio as default. The “ti” kernel has RemoteProc/RPMSG as default. I don’t understand you problem here. > Do you remember, that's the main topic in this discussion? > > I think TJF is confusing throughput with latency. From the BeagleLogic > project, they were able to achieve better throughput with RemoteProc, but TJF > is able to achieve lower latency with PRUSS_UIO. From what TJF explained, > the latency occurs because of 5 parameters that must be pushed onto the stack > for each call. > > I don't think that I'm confusing anthing here. If BeagleLogic could really > achieve better throughput with remoteproc, they must have had a masive > problem in their code before. I cannot imagine how any driver could have a > positive influence on libpruio thoughput. Look at the BeagleLogic development blog, where he explains the throughput problem with pruss_uio. When he changed to RemoteProc/RPMSG, the throughput increased dramatically. > > And regarding latency, the five parameters are just the start. Then kernel > code and PRU code adds further latency. (And yet the five parameters are much > too much for my usecase.) The remoteproc concept isn't made for high > performance and it doesn't provide any "hack" to pass it by. I continue to say that you are using RemoteProc/RPMSG incorrectly. You shouldn’t have a tight control loop between the PRU and ARM because this makes no sense. Linux is non deterministic so why would you want to compromise the PRU by making it dependent on the communications with Linux. Either use one PRU for the control loop and another for communicating with Linux, or use DMA to pass data between PRU and ARM. > > Yeah, so long as you don’t need security, interrupt handling, virtual > peripherals (firmware defined devices), etc, why not use a hack to accomplish > your task. I guess there is a reason why Linux doesn’t have a lot of > userspace drivers. > > I see lots of userspace drivers in the real world. Ie. regarding one-wire > support I know about four. And the numbers will increase, unless kernel > development gets closer to user needs. These are generally toys. The vast majority of drivers are Kernel based drivers. > > I need security, a high-level target in my projects. That's why I don't like > virtual peripherals. That's why I don't want to load my firmware from files. > (I've seen projects where firmware files from userspace gets linked to > /lib/firmware and loaded. Or when a project runs from SD card, an aggressor > can easy put the card in a laptop and override the firmware files in kernel > space.) Once you compromise physical security, you have no security, period, so this is a silly point to make. There a many Linux device drivers that rely on firmware and these are all done is a secure way. The purpose of a kernel driver is to validate the user parameters and prevent operations outside well defined limits. Userspace drivers have no such validation and can do whatever they please, hence no security. > > So how does this project provide any additional security? When a user stops > the libpruio firmware at the wrong point using "unbind", this may damage the > hardware. > > Remember, the PRUSS are a safety risc per se. Old-fashioned thinking doesn't > match the current situation. Im contrast to an arbitrary peripheral > subsystem, the PRUSS can access all CPU memory. And the kernel cannot protect > any memory against PRU access. That's why PRU control from the command line > will not add any security. Instead it'll increase the risc. Hence why you want to Kernel based driver to validate the firmware. Again, userspace driver can place whatever code it wants on the PRU. > > This is what I like most about RemotProc/RPMSG, in that you are using the > same framework between ARM, PRU, DSP, etc. > > If I'd be an RPi3 user, I'd love this too. Since it'd help me to develop a > PRU emulator, using 1, 2 or 3 of the cores for real time tasks. Sure, such a > project wouldn't really help the BBB community and it wouldn't be good for > TIs buisiness. So I wonder why TI managers allow to develop this remoteproc > thingy in public. TI have several processors that have PRU, DSP, CortexM4 in addition to one or more ARM processors. Just look at the BeagleBoard-x15 for example. > > Suman, you have done very good work. Please take the criticism as suggestions > on how to make RemoteProc/RPMSG better. We understand that you have many > other responsibilities at TI and we want to be respectful of your time. Thank > you again for all your help. > > Good work for whom? Competitors are happy. But high performance PRU projects > doesn't work any more with TI kernels since kernel 4.x (that's nearly two > years now). And further corporate development is blocked until we find a > solution. This framework works for me so I certainly don’t want it removed. > > I also have many other responsibilities. And here, I try to build a bridge, > and I try to slow down (or stop) the current process of kernel development > drifting away from user needs. I think it would be more productive to make suggestions on how to improve the RemoteProc/RPMSG. BTW, I’m sure you don’t have any problem with RemoteProc, because it is just loading and starting/stopping the firmware on the PRU. PRUSS_UIO has a similar firmware loader. So perhaps we should concentrate on Virtio, vring or RPMSG. > > BR > > > @Suman > > Thank you for your answer. Most of your colleagues just stop answering and > break the discussion when it comes to the point. I really appreciate your > effort. > > And thank you for the examples. They may help others to get started with your > framework. At the moment, for me, there is still no reason why I should spend > time in testing. > > I don't know if pasm assembler is still a supported tool by TI. > > As far as I understand, PRU isn't supported by TI at all yet. But pasm is the > first tool available, and therefor a lot of projects are based on it. You > shouldn't ignore it. > > /dev/mem is your friend. > > I don't like /dev/mem. PRUSS are my friends. > > Define mainstream. > > By mainstream I mean the system a user gets when he installs an image. > > It is optional, it is not even enabled by default in omap2plus_defconfig. If > one doesn't want to spend time, one can always go back to how they were using > it with whatever patches they had before. > > Yes, downgrading is an option in any case of conflicts. It's the last option. > And I think it shouldn't be the standard answer when kernel developers learn > about user needs. > > Your project is not optional. As you can see in Williams post, your driver > gets installed by default in any TI image. > > Please try to imagine: not every user compiles his own kernel. Instead, most > users download and install a prepared image. And this is how it should be > (@RCN: thanks for all your efforts). Once again, why not install the “bone” kernel which has pruss_uio as default. Why do you insist on installing the “ti” kernel which has RemoteProc/RPMSG as default and then insist on removing RemoteProc/RPMSG. This makes no sense to me. > > And may I know how would you have done it if you were to redo it from scratch > supporting both kernel and userspace? You are only looking at it from > userspace angle, and as long as you stick to that, any kernel framework will > indeed look like bloat. > > User space is what kernel is made for. A kernel without userspace > applications makes no sense. And when a kernel framework looks bloated from > userspace angle, it may be bloated. > > You may know how I'd have started your project. As I said, I'd first make the > decision: > do I want to make something completely new, or > do I want to replace an existing solution? > In first case, I would create an experimental project, far away from > mainstream. In the later case I'd care about existing code and solutions (and > I wouldn't go mainstream as well, unless I got the basics working and > documented with examples on how to migrate). > > As far as I understand your project, you made this decision. But you didn't > leave the mainstream yet (and I don't understand how you could enter). The reason it was added to mainstream was to encourage support by other vendors which has already started. > > The TI kernel is not just about BBB, there are 4 other SoC families and > multiple boards where PRU is now supported. And we do have userspace needs as > well for Industrial usecases, they will get addressed in the upcoming months. > You might very well find a thing or two w.r.t UIO in an upcoming Processor > SDK release. > > I know that you work for other SoC families as well. I wonder why you don't > add your project to the Processor SDK as an insiders' tip or special offer. > By the way, libpruio is already used in lots of industrial and scientific > projects today. Since pruss_uio is only supported on one platform, it shouldn’t be included in mainstream. > > I understand that it's frustrating that the new framework does not address > all your needs at the moment, and this is an active development so I will be > continuing to close the gaps during the year. > > It isn't frustrating that your framework doesn't adress my needs. I wouldn't > even care about that. It's frustrating that such a framework is in the > mainstream kernel (images). And it's frustrating that this could get fixed > very easy, but hasn't been done yet. Again, use the “bone” kernel. This is why Robert Nelson has the “bone” kernel. > > Do whatever you think that'll be helpful for anyone at anytime. But do it in > a sandbox. Don't block corporate development. Don't steal users resources. > Don't add further riscs to kernels for boards with PRUSS. > > Please work with Jason Kridner for any further issues or concerns... > > For Jason Kridner I can only repeat: do everthing possible to get remoteproc > out of mainstream. It blocks the PRUSS development in BB community and > endangers the BB project. I completely disagree with this request. 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/ba07164c-b44e-4f6e-b172-f460f1adb995%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/ba07164c-b44e-4f6e-b172-f460f1adb995%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/F1F468E4-4065-4FA3-83EF-05707413D03B%40gmail.com. For more options, visit https://groups.google.com/d/optout.
