On the contrary, the TI kernel is for all TI processors and not just for the BBB. If you want features added to the “bone” kernel, why not request those features be added.
Regards, John > On Jun 25, 2016, at 12:57 PM, William Hermans <yyrk...@gmail.com> wrote: > > 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 > <mailto:yyrk...@gmail.com>> wrote: > There, now everyone can clean their messy images . . . > > https://github.com/wphermans/bbb-cleanup/blob/master/beaglebone-cleanup.md > <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 > <mailto: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 > <mailto: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 > <mailto: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: > 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 beagleboard+unsubscr...@googlegroups.com > <mailto: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 > <https://groups.google.com/d/optout>. > > > > > -- > 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 beagleboard+unsubscr...@googlegroups.com > <mailto: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 > > <https://groups.google.com/d/msgid/beagleboard/CALHSORobVtuniGF-zG4OHg3iELHhJC5jGhNfeGH_s7D8_Cw%3DrA%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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/D1C05486-ACC0-4090-8443-979C5F98F547%40gmail.com. For more options, visit https://groups.google.com/d/optout.
