> On Jun 17, 2016, at 2:22 PM, Anna, Suman <[email protected]> wrote: > > Hi TJF, > > My responses inlined.. > > Regards > Suman > > From: John Syne [mailto:[email protected] <mailto:[email protected]>] > Sent: Friday, June 17, 2016 12:44 PM > To: [email protected] <mailto:[email protected]> > Cc: Reeder, Jason; [email protected] > <mailto:[email protected]>; Anna, Suman > Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed > > On Jun 17, 2016, at 7:17 AM, TJF <[email protected] > <mailto:[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. > > [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. ] I use CCS with JTAG and it works for me ;-) > > > 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.] This I did not know. That is excellent. > > > 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.] That will be great. > > 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.] I think what everyone was asking for is an example to show how this might be done. It seems like other than the ELF code, there is a resource table which is appended. How is this done? What is the format? Perhaps Jason can add something like this to his examples. > > 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.]. This is why this discussion is so helpful. Once again, I would ask that Jason add something like this to his examples. > > 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.] For some time I have been defending RPMSG/Remoteproc, but several PRUSS_UIO users complained that TI’s wasn’t supporting their framework, had no documentation and the samples sucked. I hope this discussion has put all that behind us. Clearly we can see that TI is actively working on this framework, and Jason Reeder is working on cleaning up the docs/examples. Hopefully in the not to distant future, we should have a framework that will satisfy most of the needs expressed here.
I just like the idea that I can use the same framework for communication between ARMv7, DSP, CortexM4, PRU, etc. Thank you again for all your hard work. Regards, John > > 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 > <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/A2601E6D-3735-4A39-9C58-7D7FBC24BCDB%40gmail.com. For more options, visit https://groups.google.com/d/optout.
