Also, instead of saying "use the bone kernel instead". Do realize that the TI kernel has some useful features that are not implemented into the *bone* kernel config, at minimum.
So the point is, this "toy" is a community "toy". Not just for you. On Sat, Jun 25, 2016 at 12:35 PM, William Hermans <yyrk...@gmail.com> wrote: > There, now everyone can clean their messy images . . . > > https://github.com/wphermans/bbb-cleanup/blob/master/beaglebone-cleanup.md > > On Sat, Jun 25, 2016 at 12:16 PM, William Hermans <yyrk...@gmail.com> > wrote: > >> @Jason Kridner >> >> I do not think anyone is asking to remove remoteproc, and replace it with >> uio_pruss. What we've been asking, at least I have been asking is give us >> the option. >> >> For example, all those modules listed in the output from my lsmod on a >> fresh install of the latest Jessie testing image: >> >> debian@beaglebone:~/nfs$ uname -r >> 4.4.12-ti-r31 >> debian@beaglebone:~/nfs$ cat /etc/dogtag >> BeagleBoard.org Debian Image 2016-06-19 >> >> Anyway all those kernel modules should *NOT* be enabled by default. With >> exception of perhaps the USB gadget drivers(and nfsd is something I >> personally loaded ). Personally, I would prefer they were not loaded by >> default, but I can understand the need. Additionally, those kernel modules >> should be loaded via a device tree file as in how the original uio_pruss >> module is loaded. >> >> So again. I do not care what you all at TI work on. It's not my place to >> say one way or another. But please do not force us to endure your >> developers poor clean up abilities. But I will say, that looking at that >> mess that is the output of lsmod from a released debian image. You all must >> have zero pride in your work . . . Harsh ? Maybe overly harsh yes, but >> think about the message you developers are putting out there with that mess. >> >> Also as TJF mentioned. Feel free to create your own little sandbox, and >> then include the stuff you have finished into the released images. That, >> would make me happy, as well as many others, I'm sure. It's either that, or >> I'm forced to clean up your mess. Which I am perfectly capable of doing. >> But that's not the point. >> >> Additionally, I am grateful for the work *EVERYONE* has done for the >> community. Even the people I'm bitching at right now. Take it as overly >> critical constructive complaints. If you want. >> >> On Sat, Jun 25, 2016 at 11:56 AM, Jason Kridner <jkrid...@beagleboard.org >> > wrote: >> >>> 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 >>> <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. >>> >> >> > -- 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/CALHSORobVtuniGF-zG4OHg3iELHhJC5jGhNfeGH_s7D8_Cw%3DrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
