Convert RPMsg examples from mailboxes to interrupts
The nested while loops in the RPMsg examples have been simplified.
This makes them a bit easier to understand.
Regards,
Greg
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/47782632-79dc-4bd2-8525-e5ce8c1f0cdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Anyone look at migrating these into the http://github.com/beagleboard/am335x_pru_package repo/package?
Please don't pollute the am335x_pru_package with remoteproc nonsense! Better create a separate package with a new name.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ef0f3726-1c77-4980-83d2-de95fa75bf24%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpJKNp_sdrhgqLf5e3wiKiAd6LQSmjCRd3geAH7tsu07Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPn%3DjLt-8%2Bc7tN%2BD8T3hZWJU1NhEQ3LsA0RfStrA6rqrbg%40mail.gmail.com.
How is it nonsense?
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/bc2d2003-6593-4759-99ca-2b7a95b8d33f%40googlegroups.com.
On Jun 15, 2016, at 8:53 PM, TJF <jeli.f...@gmail.com> wrote:
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/bc2d2003-6593-4759-99ca-2b7a95b8d33f%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/F78DF15C-A7CF-4AC5-82DE-604CE7F74E75%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmqZkBh5%3DNxHU75UZLtWWL83JOVoBmdi4P5cNCLnwsjGA%40mail.gmail.com.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/cd2c68d6-8cd6-415d-bccc-c907971b7660%40googlegroups.com.
On Jun 16, 2016, at 8:47 AM, TJF <jeli.f...@gmail.com> wrote:
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/cd2c68d6-8cd6-415d-bccc-c907971b7660%40googlegroups.com.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/bc2d2003-6593-4759-99ca-2b7a95b8d33f%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoQ1N4YqQHd_R6-zX4rcDGigjiG%3D%3DmpWu0ZY%3DR3k4_0_g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoDogei37WtJx20hXDnYRkMw61Rp%2BY3DO7r%2BY8pwy-gEw%40mail.gmail.com.
On Jun 16, 2016, at 3:25 AM, Jason Kridner <jason....@hangerhead.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmqZkBh5%3DNxHU75UZLtWWL83JOVoBmdi4P5cNCLnwsjGA%40mail.gmail.com.
Also, would suggest looking at open-amp. There is ongoing work trying to create a rpmsg framework for multiple platforms, i.2 imx6sx (ARM9/M4), Zync/Xilinx
Looking at am335x_pru_package, I see things like loaders which conflict with RemoteProc so I’m not sure that is such a good idea. Are you proposing to modify the TI examples to work with UIO_PRUSS? That would be a horrible idea as I have already described the limitations of UIO_PRUSS.
TI already have a set of examples and a step by step process on how to build and use these examples, but I’m talking about augmenting the documentation to make it easier to understand/use.
I’m also proposing to extend the existing examples with real world examples that can serve as a template for developers. I’m not sure what Jason Reeder’s schedule looks like, but either he can assist with the development, or just monitor the development of the examples in such a way that he can take ownership of the examples.
Given that RPMSG/RemoteProc is to replace UIO-PRUSS, my only goal here is to get the community behind RPMSG/RemoteProc so that we are all pulling in the same direction. At the moment, developers are having a difficult time understanding the framework and this in large part is why we are seeing resistance to change.
Finally, developers have complained about poor performance, and perhaps we need investigate why they are seeing this. Perhaps there is something in the framework, or perhaps their implementation is wrong.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CF9664BE-5A74-4B4F-B57D-A84B4B3598D3%40gmail.com.
On Jun 16, 2016, at 2:40 PM, Jason Reeder <jason...@gmail.com> wrote:John,Have you seen our PRU-ICSS landing page: http://processors.wiki.ti.com/index.php/PRU-ICSS
and also the Remoteproc/rpmsg sub page on that wiki: http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg
If so, let me know which parts are unclear/insufficient and I can work to improve those. Of course, all of the work and documentation on that wiki will be geared toward to the TI Processor SDK Linux distribution.
Keep in mind that the latest changes to the pru-software-support-package rpmsg examples are tightly coupled to the current work that Suman is doing on an upcoming 4.4 kernel from TI. So the latest examples are not going to work until the Linux drivers are updated to use interrupts instead of mailboxes as well, which is why I revved the major version of the package to v5.
I would love to see the pru-software-support-package and rpmsg pick up steam in the community. However, any work that would not benefit the TI Linux distribution directly will have to be done at home on my own time. I'm not opposed to that idea though as my Beaglebone Green Wireless just arrived in the mail this afternoon and I'll be needing to get more familiar with the community distribution anyway.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c6ad2c0e-6c40-43ee-9e05-b7edcffcdfa4%40googlegroups.com.
On Jun 16, 2016, at 2:42 PM, Jason Kridner <jkri...@beagleboard.org> wrote:The repository includes a number of documents, providing a bit of a one-stop-shop for PRU documentation. A migration guide from UIO_PRUSS to REMOTEPROC would seem reasonable to add. There's also source to an assembler.More responses below...On Thu, Jun 16, 2016 at 3:42 PM John Syne <john...@gmail.com> wrote:Looking at am335x_pru_package, I see things like loaders which conflict with RemoteProc so I’m not sure that is such a good idea. Are you proposing to modify the TI examples to work with UIO_PRUSS? That would be a horrible idea as I have already described the limitations of UIO_PRUSS.No, I'm saying that the existing UIO_PRUSS examples should be made to continue to work on the latest kernels. This might require a way to transition control from kernel to userspace for the PRU control registers.The inclusion of additional REMOTEPROC-only examples could illustrate why to migrate. It seems to me some of the PRU GSoC projects like BeagleLogic might also be suitable to integrate here, as we haven't gotten them integrated into the standard images otherwise yet.
TI already have a set of examples and a step by step process on how to build and use these examples, but I’m talking about augmenting the documentation to make it easier to understand/use.I agree that the documentation should be the focus. I thought the older round of documentation wasn't so bad, but there is much more to document now with REMOTEPROC. I'm just saying that making the documentation comprehensive in once place would be ideal.
I’m also proposing to extend the existing examples with real world examples that can serve as a template for developers. I’m not sure what Jason Reeder’s schedule looks like, but either he can assist with the development, or just monitor the development of the examples in such a way that he can take ownership of the examples.Monitoring the external development of extending these examples, including the GSoC work which is on-going, would be great. Not sure if he can commit to that.
I'll just note again that that particular repository has external patches already and cannot be integrated back into a release by TI (at least not at any reasonable level of effort).Given that RPMSG/RemoteProc is to replace UIO-PRUSS, my only goal here is to get the community behind RPMSG/RemoteProc so that we are all pulling in the same direction. At the moment, developers are having a difficult time understanding the framework and this in large part is why we are seeing resistance to change.Agreed, which is why I want to meet them at the information source they are using today. You can tell by the reaction that it is an important resource and care should be extended to updating it. It seems to me the right place to try to prove the value of REMOTEPROC/RPMSG.
Finally, developers have complained about poor performance, and perhaps we need investigate why they are seeing this. Perhaps there is something in the framework, or perhaps their implementation is wrong.Yeah, I'd like to know more details about that as well. I have a near-term need to migrate some UIO_PRUSS code (https://github.com/StrawsonDesign/Robotics_Cape_Installer/tree/master/install_files/pru) to REMOTEPROC and the author has some of this same concern.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPkxJvhQQRyysHPzT6cMvacV%3DVfwVYW4s1UasJxb8n-gRg%40mail.gmail.com.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1a05eb0b-3677-4d8b-8116-e236dc316186%40googlegroups.com.
Hi Greg,
Yes, we have introduced pruss_intc new on 4.4 kernel and this module now manages the PRUSS INTC. It provides the irqchip/irqdomain which will allow client users to use standard DT properties for listing the PRU system events as interrupts and use standard Linux APIs. There is still some more work to be done there (ability to add system event to PRU channel mapping to host interrupt from DT) rather than having to provide that mapping data in firmware resource table, so the MPU-side clients can be cleanly separated and depend on Linux infrastructure alone.
I am not sure how much the kernel you are using has caught up to the changes I have been doing on my tree, but there are a few changes over the last week where we added and switched over to PRU system events instead of mailboxes for scalability purposes (mailboxes would work too provided you choose mailboxes in DT over interrupts). This is what Jason was referring to as v5.0.0.
Regards
Suman
The constant uninformed assertion that everything is faster if handled by userspace reflects on the struggles we've had to communicate the value of working in the kernel process.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/37C860A02101E749A747FA2D3C1E3C50040B5629%40DLEE11.ent.ti.com.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b629798b-8703-4c5c-8e9b-f055745165ad%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqhD-ubwQoV4GX7wXNe0-bAZ0be%3Ds57uSqsQWbEMhEKLQ%40mail.gmail.com.
On Jun 16, 2016, at 6:19 PM, William Hermans <yyr...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqhD-ubwQoV4GX7wXNe0-bAZ0be%3Ds57uSqsQWbEMhEKLQ%40mail.gmail.com.
On Jun 17, 2016, at 7:17 AM, TJF <jeli.f...@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!
@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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5b4e534e-d8a0-4280-a4c3-c49ae2fefeea%40googlegroups.com.
On Jun 17, 2016, at 2:22 PM, Anna, Suman <s-a...@ti.com> wrote:Hi TJF,My responses inlined..RegardsSuman
From: John Syne [mailto:john...@gmail.com]
Sent: Friday, June 17, 2016 12:44 PM
To: beagl...@googlegroups.com
Cc: Reeder, Jason; jkri...@beagleboard.org; Anna, Suman
Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed
On Jun 17, 2016, at 7:17 AM, TJF <jeli.f...@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.
I use CCS with JTAG and it works for me ;-)[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?
This I did not know. That is excellent.[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.
That will be great.[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.
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.[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.
This is why this discussion is so helpful. Once again, I would ask that Jason add something like this to his examples.[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.
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.[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.]
RegardsSuman
Hi TJF,
My responses inlined..
Regards
Suman
From: John
Syne [mailto:john...@gmail.com]
Sent: Friday, June 17, 2016 12:44 PM
To: beagl...@googlegroups.com
Cc: Reeder, Jason; jkri...@beagleboard.org; Anna, Suman
Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed
@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
On Jun 17, 2016, at 2:22 PM, Anna, Suman <s-a...@ti.com> wrote:
Hi TJF,
My responses inlined..
Regards
Suman
From: John
Syne [mailto:john...@gmail.com]
Sent: Friday, June 17, 2016 12:44 PM
To: beagl...@googlegroups.com
Cc: Reeder, Jason; jkri...@beagleboard.org; Anna, Suman
Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed
On Jun 17, 2016, at 7:17 AM, TJF <jeli.f...@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. ]
I use CCS with JTAG and it works for me ;-)
Yeah, nothing wrong with CCS. It is always a tussle between using CCS or to load and start vs just connect & debug, especially for a target running Linux with remoteproc driver in place. One has to know enough to not let the GEL files execute unwanted register settings, but that’s expected of someone using a JTAG.
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 resource table format is based on a Type-Length-Value (TLV) format as documented in the kernel doc remoteproc.txt file Section 6. It is just a regular structure in a certain format that you add to your project and link to a special “.resource_table” ELF section. The current examples from the PRU Software Support package should already be showcasing this.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/remoteproc.txt
TI kernel has currently couple of extended resource types and that’s what is utilized to setup the PRU INTC mappings today. I will be improving the PRUSS INTC bindings to be able to specify the mappings to be able to do this from DT on the MPU-side without having to rely on firmware. Obviously, the whole lot can be done from firmware code as well, but PRU IRAMs being small, the instruction space is a premium with some applications expecting the entire setup to be done from ARM side. PRUSS INTC is not a traditional INTC in that it is the same IP that both MPU and PRU-sides have to program, so the ownership can never be partitioned cleanly.
Regards
Suman
Greg,
A quick test would be to revert the following patch (assuming you are using a BeagleBone variant) in your tree, if you continue to use your old firmware
https://github.com/beagleboard/linux/commit/620cab817e7a06065452d4c119c3066061ad5f03
regards
Suman
From: Greg
[mailto:soapy...@comcast.net]
Sent: Thursday, June 16, 2016 8:07 PM
To: BeagleBoard
Cc: soapy...@comcast.net; jkri...@beagleboard.org; Reeder, Jason; Anna, Suman
Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed
Hi Suman, that confirms what I suspected about this new module pruss_intc.
[Suman: Where do you use this from, I assume userspace? Using what - Shared DRAM or regular PRU DRAM.]
[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.]
[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.]
[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.]
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6c5d6da3-6465-4c67-a092-b54b8cc89871%40googlegroups.com.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/576DD831.3000705%40ti.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORo3Owydt2X%3D59OOa84PotpO8rUDAPKAnB1nMOrWyiMWOQ%40mail.gmail.com.
... so what do you want removed? There is nothing left to be removed.
pru_rproc 12632 0
pruss_intc 7223 1 pru_rproc
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.
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.
This is what I like most about RemotProc/RPMSG, in that you are using the same framework between ARM, PRU, DSP, etc.
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.
I don't know if pasm assembler is still a supported tool by TI.
/dev/mem is your friend.
Define mainstream.
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.
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.
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 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.
Please work with Jason Kridner for any further issues or concerns...
--
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...@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.
On Jun 25, 2016, at 7:39 AM, TJF <jeli.f...@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: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).
- do I want to make something completely new, or
- do I want to replace an existing solution?
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
---
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ba07164c-b44e-4f6e-b172-f460f1adb995%40googlegroups.com.
On Jun 25, 2016, at 11:56 AM, Jason Kridner <jkri...@beagleboard.org> wrote:I will work to enable uio_pruss functionality, and I think that is what you want, not just getting remoteproc out.
--
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...@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORobVtuniGF-zG4OHg3iELHhJC5jGhNfeGH_s7D8_Cw%3DrA%40mail.gmail.com.
It sure seems to me that if both can exist in the source tree and be selected at runtime with configuration (ideally via device tree, switchable later by loading and unloading modules), that would be the ideal solution. It sounds like John is saying this is technically not possible, but I feel like it should be (it is just code, after all).
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9F227F8C-8A4C-4FB6-A7C1-2D075CFD3429%40latencyzero.com.
Doesn't it "discover" devices by looking at the device tree?
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/C7759943-C3C3-475D-97E2-A57995AABEE1%40latencyzero.com.
Why don’t you use the “bone” kernel which pruss_uio as default.
The “ti” kernel has RemoteProc/RPMSG as default. I don’t understand you problem here.
Look at the BeagleLogic development blog, where he explains the throughput problem with pruss_uio. When he changed to RemoteProc/RPMSG, the throughput increased dramatically.
I continue to say that you are using RemoteProc/RPMSG incorrectly.
You shouldn’t have a tight control loop between the PRU and ARM because this makes no sense. Linux is non deterministic so why would you want to compromise the PRU by making it dependent on the communications with Linux. Either use one PRU for the control loop and another for communicating with Linux, or use DMA to pass data between PRU and ARM.
These are generally toys. The vast majority of drivers are Kernel based drivers.
Once you compromise physical security, you have no security, period, so this is a silly point to make. There a many Linux device drivers that rely on firmware and these are all done is a secure way. The purpose of a kernel driver is to validate the user parameters and prevent operations outside well defined limits. Userspace drivers have no such validation and can do whatever they please, hence no security.
Hence why you want to Kernel based driver to validate the firmware. Again, userspace driver can place whatever code it wants on the PRU.
TI have several processors that have PRU, DSP, CortexM4 in addition to one or more ARM processors. Just look at the BeagleBoard-x15 for example.
This framework works for me so I certainly don’t want it removed.
I think it would be more productive to make suggestions on how to improve the RemoteProc/RPMSG. BTW, I’m sure you don’t have any problem with RemoteProc, because it is just loading and starting/stopping the firmware on the PRU. PRUSS_UIO has a similar firmware loader. So perhaps we should concentrate on Virtio, vring or RPMSG.
Once again, why not install the “bone” kernel which has pruss_uio as default. Why do you insist on installing the “ti” kernel which has RemoteProc/RPMSG as default and then insist on removing RemoteProc/RPMSG. This makes no sense to me.
The reason it was added to mainstream was to encourage support by other vendors which has already started.
Since pruss_uio is only supported on one platform, it shouldn’t be included in mainstream.
On Jun 26, 2016, at 2:53 AM, TJF <jeli.f...@gmail.com> wrote:Obviously you have no idea how libpruio works and you have no experience on the usecase it's made for. Do you really think you can give a professional opinion on correct or incorrect? I'm sure I use it correct, because I don't use it at all, since it doesn't fulfill the requirements.
You shouldn’t have a tight control loop between the PRU and ARM because this makes no sense. Linux is non deterministic so why would you want to compromise the PRU by making it dependent on the communications with Linux. Either use one PRU for the control loop and another for communicating with Linux, or use DMA to pass data between PRU and ARM.
It makes no sense to discuss that in detail here, since you obviously have no idea on rapid prototyping controllers. (I can give you a private lesson if you like.)
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d9d9f9ee-8ba7-4ff0-a874-965f8d1a61c2%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqAE7kF3hLPcL9ZUkwp1Cb30MBarCj7oW3FLd9FNv-VGQ%40mail.gmail.com.
It makes no sense to discuss that in detail here, since you obviously have no idea on rapid prototyping controllers. (I can give you a private lesson if you like.)
On the contrary, perhaps you should explain the use case so everyone here can understand what it is you cannot do with RemoteProc/RPMSG. Give some examples of how you do this with libpruio. I just don’t understand the need for communications with Linux in a tight control loop, but I’m hoping you can enlighten us on the issue ...
... and hopefully move this discussion forward.
Think of this discussion as a cooperative one were everyone should ultimately benefit.
On Jun 27, 2016, at 12:51 AM, TJF <jeli.f...@gmail.com> wrote:@John3909:
Am Sonntag, 26. Juni 2016 20:13:12 UTC+2 schrieb john3909:It makes no sense to discuss that in detail here, since you obviously have no idea on rapid prototyping controllers. (I can give you a private lesson if you like.)On the contrary, perhaps you should explain the use case so everyone here can understand what it is you cannot do with RemoteProc/RPMSG. Give some examples of how you do this with libpruio. I just don’t understand the need for communications with Linux in a tight control loop, but I’m hoping you can enlighten us on the issue ...I think Suman did already know what libpruio (and many other high performance PRU projects) need. But here's a private lesson for you: There is no "need for communications with Linux in a tight control loop". We need direct memory access between PRU and ARM CPU. No Linux inbetween. We need to bypass all that vring and RPMsg magic. We gain for speed and small memory footprints. We want to save resources for future extensions and we don't want to spend resources for features that we neither need nor want.
... and hopefully move this discussion forward.
To get this discussion forward, we have to move backwards. Neither Suman nor myself want this. So the best way to solve the conflict is, that we get both of our concepts optional. The user should decide if he wants to drive a Jaguar or a Bentley.
Since the Bentley has an open trunk where any agressor can easy hide a big bomp, it is a MUST-HAVE to get it out of the mainstream. Remeber, PRUSS can access ALL memory. A PRU virus can even override kernel space memory or manipulate kernel drivers. All the safety strategies you explained to William are pointless when a PRU virus overrides your instructions. With network access, a small loader on the PRU could exchange the complete system, auto-started by remoteproc at boot time. And all that vring and RPMsg magic make it even more easy to develop such a malware. Currently, remoteproc is some kind of VCE (virus construction environment), inbuild in the kernel source.
I wonder how you can speak about safety and support such a concept at the same time. If you're not just declaiming phrases you learned at highschool, if you have a brain of your own and you're using it, if you really were interested in security, you would second my proposal to make remoteproc optional, and remove it from mainstream.
Think of this discussion as a cooperative one were everyone should ultimately benefit.
Fine that we are at one with this, and you are also ready for corporate development, now.
BR--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ebf4bf3f-b545-4efe-9af8-0cb07833217a%40googlegroups.com.
On Jun 27, 2016, at 1:49 AM, John Syne <john...@gmail.com> wrote:While I haven’t tried this, I don’t believe there is anything in the RemoteProc/RPMSG framework that prevents you from doing this now. You can still use RemoteProc to load/start/stop your PRU firmware and you don’t have to use virtio or rpmsg, but rather create a new KM to do just this. Suman does this make sense?On Jun 27, 2016, at 12:51 AM, TJF <jeli.f...@gmail.com> wrote:@John3909:
Am Sonntag, 26. Juni 2016 20:13:12 UTC+2 schrieb john3909:It makes no sense to discuss that in detail here, since you obviously have no idea on rapid prototyping controllers. (I can give you a private lesson if you like.)On the contrary, perhaps you should explain the use case so everyone here can understand what it is you cannot do with RemoteProc/RPMSG. Give some examples of how you do this with libpruio. I just don’t understand the need for communications with Linux in a tight control loop, but I’m hoping you can enlighten us on the issue ...I think Suman did already know what libpruio (and many other high performance PRU projects) need. But here's a private lesson for you: There is no "need for communications with Linux in a tight control loop". We need direct memory access between PRU and ARM CPU. No Linux inbetween. We need to bypass all that vring and RPMsg magic. We gain for speed and small memory footprints. We want to save resources for future extensions and we don't want to spend resources for features that we neither need nor want.
While I haven’t tried this, I don’t believe there is anything in the RemoteProc/RPMSG framework that prevents you from doing this now. You can still use RemoteProc to load/start/stop your PRU firmware and you don’t have to use virtio or rpmsg, but rather create a new KM to do just this. Suman does this make sense?So, thinking a little more about this, this new KM would support mmap() so that your userspace app/lib could access this memory directly. Linux is out of the way and yet everything is still secure ;-)
[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.]
Am I reading right here? My message is:And your advice is:
- Reduce resource consumption on a small SoC.
- Add a further module to a bloated framework.
PRUSS can access ALL memory. A PRU virus can even override kernel space memory or manipulate kernel drivers. All the safety strategies you explained to William are pointless when a PRU virus overrides your instructions.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGAQBn%2BAgt76ivjMW3h3Yon7hXbEROcU%2BwubWS4YG6%3DJg%40mail.gmail.com.
Also, /dev/mem/ + mmap() are identical to the PRU in relation to having direct access to any memory address. Which is why many people have concerns when it is used.
On Jun 27, 2016, at 11:16 AM, William Hermans <yyr...@gmail.com> wrote:By the way. You could lock down the PRUs the same way /dev/mem/ is locked down. /dev/mem/ requires root privileges.Also, /dev/mem/ + mmap() are identical to the PRU in relation to having direct access to any memory address. Which is why many people have concerns when it is used.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrgvE6hHNTbp0mXhqML3%3DA2vJNRCgqjDMpg5Pcr8%3DoqbQ%40mail.gmail.com.
virtio
has also been used in High-Performance Computing (HPC) research to develop inter-virtual machine (VM) communications through shared memory passing."--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a0fcf7b0-3682-4c4f-90de-a00fcfbdf0c1%40googlegroups.com.
This is a valid design pattern and you did very impressive things with
it, but it's not compatible with the basic design of Linux hardware
integration: I don't know of a single mainline kernel driver designed
this way.
... e.g. by disallowing full control of the entire physical address space.
The proper solution is to make the remoteproc project as if it's a working module *NOW*. Loadable module, that can play nice with the rest of the module world. Then mark it as experimental. Worry about the actual remoteproc implementation after that.
If RPMSG implements mmap(), then we might have a solution that should works for TJF.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e805ade3-116c-4296-81fd-802d6ad81b1b%40googlegroups.com.
It is hard to keep up with your changing priorities.
Addressing your security issues, you never answered my original question. How are you going to install PRU firmware ...
This is what makes the PRU secure. Without root permission, you cannot replace the PRU firmware, period.
You originally claimed that RemoteProc/RPMSG was bloated and slow, so I proposed a solution to address this issue by using zero copy techniques, but now this is no longer important to you.
It sounds like you are only interested in getting libpruio into mainline ...
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/106e6bd3-c256-4429-bd7f-ebac5a9f9c8b%40googlegroups.com.
What a silly argument. It is well known that when you don’t have physical security, you don’t have any security. Once you can replace the storage media, you can make the hardware do whatever you want. This is true of your laptop and your servers. Clearly by your argument, you haven’t even begun to understand security.
In addition, you should reframe from impugning a person's motivations or intentions.
If you didn’t know, for stability reasons, Linux do not remove fameworks unless they have been replaced by something better and in most cases the new framework is backward compatible with the new framework.
No one knows how many developers are using RemoteProc/RPMSG ...
so there is no ways that Linus or his deputies would permit the removal of this framework.
All you can do is attempt to make it better ...
so stop fighting a loosing battle and join me in fixing what you don’t like.
On Jun 30, 2016, at 2:11 AM, TJF <jeli.f...@gmail.com> wrote:Good morning John!
Am Mittwoch, 29. Juni 2016 17:07:05 UTC+2 schrieb john3909:What a silly argument. It is well known that when you don’t have physical security, you don’t have any security. Once you can replace the storage media, you can make the hardware do whatever you want. This is true of your laptop and your servers. Clearly by your argument, you haven’t even begun to understand security.
You're correct, I don't know much about the Linux terminologie and definitions. From the Linux point of view, this was evidently a silly argument. Do not fred. You're still leading by a two-digit score in this discipline.
Does that change much? No, there're still other ways to get firmware on the PRUSS. As a matter of fact there are solutions to use the PRUSS from user space. No example, because I don't want to continue in publishing "how to make a virus" tutorials here. If you don't believe that, just check out the libpruio examples. Most of them work with user privilegues, root permission is necessary for pinmuxing only.
In addition, you should reframe from impugning a person's motivations or intentions.
It's confusing when you talk to yourself.
If you didn’t know, for stability reasons, Linux do not remove fameworks unless they have been replaced by something better and in most cases the new framework is backward compatible with the new framework.
Obviously there're exceptions. The PRU support is neither better nor backward compatible to previous solutions. Oh sorry, not entirely correct: indeed it has better support for PRU virus activities, targeting the kernel space directly.
No one knows how many developers are using RemoteProc/RPMSG ...
This is an important point! Just a few unquantifiable developers will use it, but in the current configuration it endangers all BB systems by default.
so there is no ways that Linus or his deputies would permit the removal of this framework.
Is it mainline? I thought it's a TI feature. Anyhow, mainline isn't affected. This safety issue concerns boards with PRUSS, only.
All you can do is attempt to make it better ...
This is making it optional, or at least making PRUSS support optional in that framework and disable it by default.
so stop fighting a loosing battle and join me in fixing what you don’t like.
That's a damed good idea. Since here we've to wait for a management decision, why don't you use that time for fixing the issue from our March discussion? Or at least answer the still open question.
BR
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ee04b094-812b-43d8-b25a-5985a5fba148%40googlegroups.com.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ee04b094-812b-43d8-b25a-5985a5fba148%40googlegroups.com.
Anyway, this discussion is not productive as we are not going to find a solution if you do not want to propose solutions. Your proposed solution of making RPMSG/RemoteProc optional isn’t a solution. However, perhaps there is a way to move the DT PRUSS definition into an DT overlay and not include the PRUSS definition in the base DT tree. This would allow both uio_pruss and RemoteProc to live side by side. Perhaps this is what you should be working on. I’m sure Robert Nelson would be open to a solution like this if you found a way to make this work.
I will work to enable uio_pruss functionality, and I think that is what you want, not just getting remoteproc out.
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.
It sure seems to me that if both can exist in the source tree and be selected at runtime with configuration (ideally via device tree, switchable later by loading and unloading modules) ...
I'd try to make both optional and choise in device tree when enabling the PRUSS.
From: Robert Nelson <robert...@gmail.com>
Subject: Re: uio_pruss coexist with remoteproc
Date: June 30, 2016 at 11:43:29 AM PDT
To: John Syne <john...@gmail.com>
Hi John,
On Thu, Jun 30, 2016 at 12:57 PM, John Syne <john...@gmail.com> wrote:Hi Robert,
I’m trying to put this issue to bed. Since you had issues getting uio_pruss and remoteproc working together, I’m trying to understand the issue. My guess is that both kernel modules should build without conflict, but the DT has to choose one or the other. Is there a reason why we cannot move the PRUSS specs into a DT overlay, one for uio_pruss and one for remoteproc.
In our weekly meeting today, we talked about it for a good 30 minutes,
even had Suman come in on the line. TI is watching that thread, and
they have even more meetings scheduled.
What i would like to try to do, patch the uio_pruss driver so it can
use the same bindings as remoteproc (they use the same node label),
then users can either blacklist remoteproc or uio_pruss
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/407ecd81-8bc5-43bd-912a-ae480fb3954d%40googlegroups.com.