> On Jun 25, 2016, at 11:56 AM, Jason Kridner <[email protected]> wrote: > > I will work to enable uio_pruss functionality, and I think that is what you > want, not just getting remoteproc out. Please don’t do that. Robert Nelson has the “bone” kernel for this purpose which supports pruss_uio by default and does not have RemoteProc/RPMSG installed. The “ti” kernel however does the reverse, with the RemoteProc/RPMSG installed by default and pruss_uio no installed. I believe the two frameworks conflict so it is not possible to have both installed.
Regards, John > On Sat, Jun 25, 2016 at 10:39 AM TJF <[email protected] > <mailto:[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 > > 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. > > 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. > > > 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. > > 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.) > > 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. > > > 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. > > > 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. > > 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. > > 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). > > > 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 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. > > > 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. > > 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. > > 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/CA%2BT6QPn8oKQ5jP-D1fhA%3DF6e6%2BeX1c4rFUfLuVj7ZhBbPoQnnA%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPn8oKQ5jP-D1fhA%3DF6e6%2BeX1c4rFUfLuVj7ZhBbPoQnnA%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/8C51D579-1830-4758-967B-61EB2270FC04%40gmail.com. For more options, visit https://groups.google.com/d/optout.
