@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!
@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. 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! 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. 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 --- 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/5b4e534e-d8a0-4280-a4c3-c49ae2fefeea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
