> On Jun 17, 2016, at 7:17 AM, TJF <[email protected]> wrote: > > @John Syne: > Correct, remoteproc is stabil since month. Stabil in the point that it isn't > usable. And that's why it is and it should be experimental. And experimental > features shouldn't polute the main stream images! I don’t agree, remoteproc framework has undergone changes, but these changes didn’t result in significant changes to the example code so user code was easily updated when upgrading to a newer version of remoteproc. With your thinking, Devicetree shouldn’t be in mainline either. > > > @Jason Reeder and Suman Anna: > Thanks for joining that discussion and for sharing your project. You defined > big targets, unfortunatelly you forget about the basics. Following your > current concept, prussdrv can never get replaced by your solution. > > One reason is execution speed. It might be suitable for BeagleLogic, which > uses minimal communication between ARM and PRUs before and after the > measurement, in non-time critical situations. In contrast, my project > libpruio is designed to work in the main controller loop. Everyting is time > critical here. Therefor I use a messaging system simmilar to the one in > RPMsg, but highly speed optimized. Just one example: In order to send a > message from ARM to PRU, if I'd switch to RPMsg, I'd have to use function > pru_rpmsg_send() for that purpose. Just the preparation of that function call > (five parameters on stack) needs five times more CPU cycles than my solution. > Additional CPU cycles are consumed in the kernel code and furthermore on the > PRU side, before the message arrives. Not worth discussing. I believe your use case is a special one and may not be served by remoteproc. Communicating between PRU and ARM in the main control loop seems odd. Normally, the tight control loop runs on one PRU, dumping to shared memory and the other PRU handles the communications between PRU and ARM. Why doesn’t this work for you? > > A second point is the firmware load. Do you realy want to force users to use > CCS and the Processor SDK (m$ habits on an open source comminity?). The PRU > (and the other subsystems you target like DSP, ...) are made for high speed > tasks. My prefered language in that case is assembler, and I'm not alone in > thinking that. Your solution needs a feature to load assembler generated > firmware, if you still target to replace UIO_PRUSS anytime. And it's out of > question to remove and reload the kernel driver for firmware updates. What if > one PRU should run while updating the firmware on the other? Furthermore it > needs a feature to reload firmware with user privileges! Here I agree with you. It should definitely be possible to add and remove firmware at runtime. Given that remoteproc can load, start and stop firmware, why not enable a feature for a user with the correct group permissions to load/reload new firmware at runtime? This might be done via a debugfs interface.
Also, your point about assembler support is quite valid and I would suggest that an assembler template/example be created for remoteproc. Alternatively, you can always start with a C version and then optimize the assembler output. > > The next point is the messaging system and its big memory consumption. What > if an application doesn't need it and wouldn't use it? Currently I cant find > any feature for high speed data exchange between ARM and PRU via DRam or SRam > memory. > > In short, if you want to fulfill the expectations Jason Kridner or John Syne > spend on your project (replacing UIO_PRUSS), you have to redo your concept > and start from scratch. Not true. I think the main framework is sound even if it does not suite your strange use case. Perhaps there is a way to augment the framework with a quick message transfer. Just some thoughts from my side. In any case, thank you for your valuable input which I hope will guide Jason and Suman in their future development. Regards, John > > Your system has to be scalable, starting at a feature set (and resource > consumption) similar to UIO_PRUSS (load-start-stop firmware, bidirectional > access DRam-IRam-SRam-INTC). When firmware contains the .resource_table > section, then load your additional drivers and do all your remoteproc magic. > But otherwise just load and start the firmware, without consuming additional > resources. Let the user choise his development tools. Do not consume any > resources until you get firmware to load. > > > @Jason Kridner: Just to make it clear, when you continue supporting the > replacement of UIO_PRUSS by remoteproc, then in long term all high perfomance > PRU projects like libpruio will die! > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/5b4e534e-d8a0-4280-a4c3-c49ae2fefeea%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/5b4e534e-d8a0-4280-a4c3-c49ae2fefeea%40googlegroups.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/64D864AC-12A2-47D3-B8B2-8A742642C281%40gmail.com. For more options, visit https://groups.google.com/d/optout.
