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/CALHSORpd6h9MgUxM%2BVsFdUOHo%2BSetsCu4wX%3Di0RDaET47sNwyg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
