I will work to enable uio_pruss functionality, and I think that is what you want, not just getting remoteproc out. On Sat, Jun 25, 2016 at 10:39 AM TJF <jeli.freih...@gmail.com> 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: > > 1. do I want to make something completely new, or > 2. 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 --- 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/CA%2BT6QPn8oKQ5jP-D1fhA%3DF6e6%2BeX1c4rFUfLuVj7ZhBbPoQnnA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
