@John3909: Am Samstag, 25. Juni 2016 21:53:10 UTC+2 schrieb john3909: > > Why don’t you use the “bone” kernel which pruss_uio as default. >
That's what I do. > The “ti” kernel has RemoteProc/RPMSG as default. I don’t understand you > problem here. > There'll be no more problem when we follow my proposal and remove the remoteproc framework from the mainstream. But in the current situation the problem is to find an answer when a user asks "How to test a ti-rt kernel with libpruio?". > 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. > Why should I spent time on that investigation? Better convince me by telling me: how much do you think your thingy can increase libpruio throughput? > I continue to say that you are using RemoteProc/RPMSG incorrectly. > Obviously you have no idea how libpruio works and you have no experience on the usecase it's made for. Do you really think you can give a professional opinion on correct or incorrect? I'm sure I use it correct, because I don't use it at all, since it doesn't fulfill the requirements. > 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. > It makes no sense to discuss that in detail here, since you obviously have no idea on rapid prototyping controllers. (I can give you a private lesson if you like.) > These are generally toys. The vast majority of drivers are Kernel based > drivers. > I don't know all the other drivers you stated here. But in case of one-wire your "generally toys" (all four) do the heavy work in real world projects. Because your "vast majority" (I count one) isn't able to perform a simple broadcast trigger for multiple Dallas sensors, and misses lots of other features like setting limits, ... In my experience, and in case of one-wire usecase, the kernel driver is the toy. And there're much and good reasons why the userspace drivers are under continuous development (and the kernel driver isn't). Try a little bit thinking outside your box. 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. > My libpruio driver has lots of validations. Ie. you can find many posts at this forum regarding a validation bug, where the maximum sampling rate for ADC sampling was calculated too much on the save side. Do you really think that only kernel code can validate? But please read my statement again. I'm not talking about physical security, nor about arbitrary periperals. I'm talking about the PRUSS and their firmware, which can access all CPU memory without any kernel protection. I'm talking about software security. > Hence why you want to Kernel based driver to validate the firmware. Again, > userspace driver can place whatever code it wants on the PRU. > Right, whatever code it wants. Ie. a virus. And it's really hard to find a virus running on the PRUSS. Currently, I see no way how a kernel driver should validate if the firmware is free of virus. And when firmware is loaded from files and started by command line, it's much more easy to run a virus on the PRUSS, in contrast to loading and running it by prussdrv. With remoteproc, it even doesn't need any command line action: just copy the virus to /lib/firmware and name it am335x-pru$[0|1]-fw, and it will run at next boot time. This is a massive safety risc in the current remoteproc concept. It shouldn't be that easy to install and run malware. 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. > How is this related to my statement you qouted? This framework works for me so I certainly don’t want it removed. > Fine, go ahead. (BTW: which projects did you realise yet?) Once you read my statements again, you'll find out that I only want to remove a dangerous software from the mainstream, but not completely. So you can still use your be-loved thingy. Just load it as an option. > 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. > Once again, I've problems with remoteproc. And I've problems with the framework and its design. It doesn't make sense to talk about details. In order to make this framework usable, it needs talk about general issues, like Do we really need PRU access from kernel space? If so, how to handle the additional riscs? ... And this needs other than traditional thinking, since riscs regarding the PRUSS are different from riscs handled by any kernel driver before. But this discussion is pointless, since Suman said that he don't want to start from scratch. (He may change his mind when he reconsiders the riscs of the current design.) > 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. > See my answer above. TI kernels do not only differ from remoteproc. Some of my users want to test the real-time features, which aren't in the bone channel. I try to help them. I try to find a way that prefers corporate development to mutual exclusion by downgrading. > The reason it was added to mainstream was to encourage support by other > vendors which has already started. > Obviously too early. > Since pruss_uio is only supported on one platform, it shouldn’t be > included in mainstream. > An unsave, experimental framework also shouldn't be included in mainstream. I'd try to make both optional and choise in device tree when enabling the PRUSS. 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/d9d9f9ee-8ba7-4ff0-a874-965f8d1a61c2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
