Hi TJF, My responses inlined..
Regards Suman From: John Syne [mailto:john3...@gmail.com] Sent: Friday, June 17, 2016 12:44 PM To: beagleboard@googlegroups.com Cc: Reeder, Jason; jkrid...@beagleboard.org; Anna, Suman Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed On Jun 17, 2016, at 7:17 AM, TJF <jeli.freih...@gmail.com<mailto:jeli.freih...@gmail.com>> 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. [Suman: We did make some core improvements/changes between our 4.1 kernel and 4.4 kernel trees (like pruss-intc), and we will be continuing on improving things. The same firmware images should work between 4.1 and 4.4 kernels provided you have similar DTS entries. The only disruption should be in the last week because of the switch from mailboxes to PRU events. You modify DTS to revert the patch that switches over, the old firmware should still work fine.] @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. [Suman: Where do you use this from, I assume userspace? Using what - Shared DRAM or regular PRU DRAM. ] 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. [Suman: I am not sure why you think CCS is needed for remoteproc. In fact, I don’t use CCS myself, and have added the single_step in debugfs so that I don’t need to connect a JTAG. It still needs couple more improvements (like ability to set PC) and then one can inspect PRU state using command line alone. As for CCS, I am sure there will be other set of users/customers/beginners who would want to use an IDE in getting up-to-speed as a stand-alone development. ] 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? [Suman: You don’t need to unload and reload the driver, the individual PRUs can be rebooted using sysfs bind and unbind without affecting the other PRU.] 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. [Suman: This is a feature missing even from the remoteproc core, and setting a new firmware name is definitely on my todo list and internal TI project need as well. The boot/shutdown etc is already added to remoteproc framework in latest upstream as a debugfs interface, but for production, it should probably be converted to a sysfs interface, depending on the individual platform remoteproc driver’s preference.] 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. [Suman: As for remoteproc driver, it really doesn’t matter what assembler/compiler is used for building a firmware image. Remoteproc core is standardized on ELF, and there is no reason to invent another format. As it is, the plain binary format is a problem for PRUSS since its address space is not unified (Address 0 for both IRAM and local DRAM). I don’t recall how prussdrv is managing this, or if they only deal with IRAM from the binary and leave the data sections for the application to copy over the interfaces to use Data RAMs. At the moment, all you would need is a small script to convert your binary into an ELF using objcopy to use with PRU remoteproc driver.] 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. [Suman: Right, the basic infrastructure is already there and you would need only to build upon it. For eg., at the moment, all you would need is a small kernel module, use pruss_request_mem_region to gain ownership of PRU memories, export it to userspace and use it however you want. The interrupts would have to go through kernel though. Maybe it is the same module that exports the above desired sysfs interfaces too.]. 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. [Suman: Thanks for sharing all your feedback and concerns. The userspace usecases are not lost on me, and we will continue to close the gaps.] Regards Suman 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 --- 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/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. -- 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/37C860A02101E749A747FA2D3C1E3C50040B7992%40DLEE11.ent.ti.com. For more options, visit https://groups.google.com/d/optout.
