Ti's RPMsg Examples Significantly Changed

[Greg]

I've been experimenting with the PRU support package, and noted this significant change to the RPMsg examples published by TI:

https://git.ti.com/pru-software-support-package

Commit message from May 20:

Convert RPMsg examples from mailboxes to interrupts

This commit moves the rpmsg library and examples away from using the
SOC mailboxes. Master interrupt events in the PRU-ICSS interrupt
controller are now being used for the signaling between the PRUs and
the ARM core(s).

PRU-ICSS System Events 16 and 17 are being used for PRU0 in all
subsystems and System Events 18 and 19 are being used for PRU1.

This change is necessary because existing devices may not have enough
mailboxes to support each PRU core (AM437x) and future devices (k2g)
based on the KeyStone architecture do not have mailboxes at all.

This change simplifies the PRU_RPMsg_Echo_Interrupt examples to the
point that the PRU_RPMsg_Echo_Polling examples are no longer
necessary so they have been removed.

The nested while loops in the RPMsg examples have been simplified.

This makes them a bit easier to understand.

Regards,

Greg

[Jason Kridner]

Thanks for the tip! Anyone look at migrating these into the http://github.com/beagleboard/am335x_pru_package repo/package?

--
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.

[TJF]

Am Mittwoch, 15. Juni 2016 14:35:12 UTC+2 schrieb Jason Kridner:

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.

[William Hermans]

Please don't pollute the am335x_pru_package with remoteproc nonsense! Better create a separate package with a new name.

I second that.

--

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.

[Jason Kridner]

How is it nonsense?

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpJKNp_sdrhgqLf5e3wiKiAd6LQSmjCRd3geAH7tsu07Q%40mail.gmail.com.

[William Hermans]

So in other words, Before you ruin a perfectly good git, someone needs to fork it.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPn%3DjLt-8%2Bc7tN%2BD8T3hZWJU1NhEQ3LsA0RfStrA6rqrbg%40mail.gmail.com.

[William Hermans]

Pollute away:

https://github.com/wphermans/am335x_pru_package

[TJF]

Am Mittwoch, 15. Juni 2016 23:47:11 UTC+2 schrieb Jason Kridner:

How is it nonsense?

There's no realistic concept up to now. Significant changes every now and then, like the one documented here.

Some developers may see some advantages anytime in the future, at least if they use the matching compiler. But currently, from my (and the users) point of view, remoteproc has less features, is slower, and takes more kernel memory than the prussdrv solution. In short: experimental, not ready for productive code. Regretfully I think about every minute I spent in learning and testing yet.

[John Syne]

Oh, that is complete bunk and you know it. PRUSSDRV is nothing more than a UIO hack. 

RPMSG/REMOTEPROC is a lot more in that it support virtual drivers so you can have ethernet, serial, spi, i2c, and more virtual drivers that are defined in firmware. Also, the same implementation supports DSPs, CortexM4s, and other other OS running on other ARM cores. You cannot compare apples and oranges with the one being a minimal/simplistic implementation and the other supporting a full featured interprocessor communications. 

Regards,

John

--
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.

[John Syne]

One other thing, if you don’t like some features of RPMSG/REMOTEPROC, then why not provide input to the developers with any suggestions you think will make things better? I have spoken to Jason Reeder and Suman Anna several times and they have been very responsive to my input. 

Regards,

John

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.

[Jason Kridner]

Thanks John. Remoteproc wasn't derived in a vacuum. Every approach provides trade-offs. 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.

I'd like to see a better way of maintaining both, that is to turn the registers back over to userspace, disabling the kernel driver other than UIO. I need to work on articulating that desire.

As to the claim that remoteproc is slower---given that the kernel owns the interrupts, I don't see how userspace can service them faster. Examples like BeagleLogic show that remoteproc can be quite fast. The high speed communication between the PRUs and the rest of the system, coupled with their high-speed interface to the external world, are what make them so valuable. Defining some common effective ways of communicating using kernel drivers would seem to make it much simpler for people to develop code quickly.

Anyway, we should spend some time with this repo making sure both driver mechanisms are supported and their values articulated. Simply ignoring the remoteproc interface supported in the mainline kernel doesn't make sense to me.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/F78DF15C-A7CF-4AC5-82DE-604CE7F74E75%40gmail.com.

[TJF]

Hi John!

Yes, you're right. The task is to load or reload firmware to the PRUSS and run it, controlled by host software executing under user privilegues. Prussdrv fulfills this task, the other doesn't. So I compared apples and oranges. Apples and oranges shouldn't go into the same am335x_pru_package. Thanks for your indorsement.

All that features (you forget to mention debugging) are not really made for main stream users. And who cares about that features when the solution doesn't provide the basics (and is slow and memory consuming and not really easy to handle and is limited to a special compiler and ...)?

I wonder how such an experimental peace of software can find its way to any linux image and all users have to work around it, in order to make their system usable. Even if it'll be working and will be useful some times in future, this is stuff for an external package in the depths of the development section, and shouldn't pollute any image by default.

[John Syne]

Well, I’m assuming everyone is using the term Remoteproc to refer to the whole echo system because Remoteproc KM doesn’t do anything more than power on, load the code on the PRU, start the code and power off. It doesn’t handle any communications between the PRU and ARM processors. It is Virtio/RPMSG that handle the communications between Linux and PRU. 

http://software-dl.ti.com/public/hpmp/sitara/sitara_pru_building_blocks_module_4.pdf

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmqZkBh5%3DNxHU75UZLtWWL83JOVoBmdi4P5cNCLnwsjGA%40mail.gmail.com.

[John Syne]

I am not arguing the need for a separate repo, because the original one has a loader defined and that would conflict with RemoteProc, which is just a loader. The examples that Jason suggested might be added to the repo could be done with minimal mods. The one thing I don’t like about UIO is it cannot handle interrupts in userspace, so this will always compromise responsiveness. 

Regards,

John

--
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.

[John Syne]

One other thing, I don’t know why TI labels the code as experimental, because it is fully functional and robust. Even with the changes over the last year, there wasn’t a lot of change to the examples, so the impact on developers code was minimal. Also, I believe you don’t have to use the “special compiler” if you create resource tables manually.  

Regards,

John

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.

[William Hermans]

I voiced all these concerns and more months ago and apparently my concerns fell on deaf ears.

remoteproc is a really cool concept. But it's not meant for this board, despite people trying to use a shoehorn to get the beaglebone 'horned in'. We already have uio_pruss, and it has worked great for how many years now ? *AND* how does remoteproc make things better in comparison to uio_pruss ? As far as I can see, it doesn't. It does not make things any easier, and its all the things TJF mentions above, and more( in the negative ).

Where remoteproc *would* shine, is on a system without additional on die computational cores( IPU, PRU, DSP, etc ), but a multi-core applications processor. So that one core can run an OS, while the other runs bare metal. *THAT* is the vision I see for remoteproc.

--

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.

[William Hermans]

Anyway, who knows. Maybe in the future remoteproc will evolve into something better than uio_pruss. But I can not help but feeling that a lot of time and effort us being wasted on something, where that effort could instead be put into improving uio_pruss. We do not need userspace interrupts other that how they're already implemented ( through /proc/interrupts, and /proc/irq ). But if we did somehow have userspace interrupts in relation to the PRU's. It would slow things down considerably. Which is why it is generally a bad idea to have userspace interrupts, as such, to begin with.

[John Syne]

As Robert has already said, RPMSG/RemoteProc will replace UIO_PRUSS. The problem is you haven’t taken the time to learn RPMSG/RemoteProc so you shouldn’t be providing advise to others. Your question “how does remoteproc make things better” has already been answered. It is possible to create firmware defined devices that can be accessed like any other Linux device under /dev. For example, I can create a Profibus device driver in firmware. To Linux, this would look no different to /dev/tty0. The Virtio is an extremely powerful concept. RPMSG/RemoteProc is implemented in kernel space and UIO_PRUSS is implemented in userspace. How many userspace device drivers exist in Linux? UIO_PRUSS is also a compromise to system security. 

Givent the more simplistic example of toggling an LED, uio_pruss it might be easier to implement this in uio_pruss, but when you are talking about a more serious device interface, the infrastructure available with RPMSG/RemoteProc makes the implementation much easier. 

Speaking of deaf ears, I’m not sure the TI PRU developers are monitoring this mailing list, so send your suggestions/questions to the developers directly or post to the linux-OMAP mailing list or post comments to E2E. They were very helpful in helping me learn the ins and outs of RPMSG/RemoteProc. 

Your third paragraph makes no sense to me. My guess is you meant “Where remoteproc *would* shine, is on a system with additional on die computational cores” 

Regards,

John

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.

[John Syne]

Again, this makes no sense. /proc is just a processor monitor and doesn’t provide any interface between kernel and userspace. The only way to convey interrupts to userspace with UIO is via kernel events and latency could be 10s or 100s of milliseconds when the cpu is under load. With RPMSG, code runs as a kernel module, so you have access to real interrupts and hence it is more responsive. Also, the interface to userspace is flexible, either via /dev, Sysfs, Debugfs, etc. 

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoDogei37WtJx20hXDnYRkMw61Rp%2BY3DO7r%2BY8pwy-gEw%40mail.gmail.com.

[John Syne]

Hi Jason,

I have been part of the discussion on this issue spanning several threads and I have yet to hear anyone offer any concrete suggestions on how to make RPMSG/RemoteProc better, so here are my thoughts on the steep learning curve required to use RPMSG/RemoteProc. I think the structure of the framework doesn’t need to change and I would not like to see registers turned over to user space. I think we just need to simplify the learning curve. 

I started by trying to read all the docs and this was my first issue. The docs are all over the place, presentations are also spread all over the place. To start, I would like to see a more structured set of docs that cover everything, from understanding the hardware, the interfaces between PRU and ARM, and how everything fits together (RemoteProc, Virtio, RPMSG, etc).

I ported RPMSG/RemoteProc from the V3.8 kernel to V4.1 kernel for both BBB and BeagleBoard-x15 and during that process, I learned how the whole echo system worked. I didn’t learn this from the docs. Later some PRU presentations did a better job of explaining the structure, but the use of TI's very technical acronyms made the docs difficult to understand. I mean, what does virtio, mailbox, vrings, etc mean. I had to read the code to understand the concepts and this should not be necessary. 

The examples tended to be overly simplistic and don’t necessarily show the capabilities of the framework. Perhaps we should call for a list of examples developers would like to see and we can work on providing a solution that developers can use as a template. 

I would be interested in hearing what other think about my proposal. 

Regards,

John

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.

[Jason Kridner]

Nice request.

I'd suggest putting things into the am335x_pru_package on GitHub, but I know there are some issues in bringing back code into TI. I'd just suggest updating that same sort of package such that we can merge the deltas, but one place with a full experience.

Thoughts?

[John Syne]

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.  

Regards,

John

[tcmichals]

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

1. able to create larger rpmsg sizes

2. baremetal library

etc... 

[Jason Reeder]

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.

Jason Reeder

[Jason Kridner]

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/CF9664BE-5A74-4B4F-B57D-A84B4B3598D3%40gmail.com.

[John Syne]

Regards,

John

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

Yeah, this is my main starting point, but I hadn’t noticed the PID motor control demo and that looks like an excellent example of how to use RPMSG/RemoteProc.

and also the Remoteproc/rpmsg sub page on that wiki: http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg

I don’t recall seeing this doc before which goes the the bigger point, the layout of the wiki is just horrible. Other than clicking on each and every link, better to layout the wiki in such a way that reflects the way a developer will learn each aspect of the framework. The layout of this document probably is a good place to start, with links for each block providing more details. For example, VRING, what is it, how do I use it, what are the limitations, etc. The section describing the resource table should include the layout and how it is used. Some developers want to use GCC and not TI’s proprietary C Compiler, so what needs to change to use GCC. 

Another point, when I look at “lsmod”, I see pruss_remoteproc, virtio_rpmsg_bus and rpmsg_pru, not pruss_rproc and pruss as described in this document so an explanation of what changed and when is necessary. 

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.

For the most part, you have most of what you already need. It is just badly organized and the TI acronyms need to be explained. Also, I’ve seen several PRU presentation that I don’t see in this wiki. I’ll have to look for these links. 

I hear from the UIO-PRUSS developers about how great their documentation is. Perhaps it isn’t the UIO-PRUSS doc that is good, but one of the libraries such as libpruio which lead the developer through an incremental learning curve. The examples are explained line by line. Maybe on of the UIO-PRUSS developers can direct us to what they consider excellent documentation.  

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.

Yeah, Suman made us aware of this issue, but the changes to the examples look pretty straight forward. 

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.

My thinking is it shouldn’t matter if we are using TI’s distribution or Robert Nelson’s Debian distribution. The framework should be the same and the examples should work on both distributions. 

I want to thank you giving us your input and for all the hard work you have done on RPMSG/Remoteproc.  

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c6ad2c0e-6c40-43ee-9e05-b7edcffcdfa4%40googlegroups.com.

[Greg]

Hi Jason-

I'm confused and I hope you can clear up things a bit.

I've got the older version of the pru package which works with the mailbox.

I was working with this just last week, and it compiled and worked perfectly with the rpmsg device appearing in /dev.

This is the example (similar to lab 5) PRU_RPMsg_Echo_Interrupt0.

I just updated the kernel to beaglebone 4.4.12-ti-r31.

Unfortunately I did not record the former kernel in which everything ran OK.

Now it is still compiling OK, but the firmwares do not run, as seen in dmesg.

Anyway, the most interesting this is the appearance of a new loadable module.

Here is a partial listing from lsmod:

pru_rproc              12632  0 

pruss_intc              7223  1 pru_rproc

pruss                   9408  0

This is the first time I have seen pruss_intc.

Modinfo indicates that this is the work of Andrew F. Davis.

Is this at least a partial release of what you describe as

an "upcoming 4.4 kernel from TI"?

Regards,

Greg

[John Syne]

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 think this is key. The layout should foster an incremental learning process, starting with a 10,000 foot overview and then encompassing the ability to drill down to learn the details with suitable examples. 

 

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.

From Jason Reeder’s response, it looks like we have his support. I think it is important that we try to maintain a single code base for both TI distribution and Robert Nelson’s Debian releases. This way Jason Reeder won’t have to do this work at home ;-) From a maintenance point of view I think this make the most sense also. 

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.

I’m sure there are many BeagleBoard developers are going to be very happy to hear this. 

 

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.

http://theembeddedkitchen.net/beaglelogic-goes-kernel-mode-with-pru-remoteprocweek-2-3/190

This show that libprussdrv was too slow and had to change to remoteproc to improve throughput, which is contrary to what the UIO-PRUSS developers are saying. 

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPkxJvhQQRyysHPzT6cMvacV%3DVfwVYW4s1UasJxb8n-gRg%40mail.gmail.com.

[John Syne]

From what Jason Reeder was saying, you need to update to pru-software-support-package V5. 

https://git.ti.com/pru-software-support-package

Regards,

John

-- 
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.

[Anna, Suman]

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

[Greg]

Hi Suman, that confirms what I suspected about this new module pruss_intc.

I am going to continue to experiment with the old and new PRU package and see if I can determine the problem.

I think I need to look at the device tree I am using and see if it has the required properties.

Regards,

Greg

[William Hermans]

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.

I have not seen anyone making that claim in any of these posts. Everyone knows that kernel space is faster, or if they do not, they should.

Now if you mean people like me claiming that uio_pruss is faster. Well, just because UIO drivers are partly userspace drivers, it does not mean these drivers do not have a kernel side driver too.

Now where I've gotten my information about remoteproc being slower has been from post on this group, as well as posts on the web discussing other hardware. Which, did not mention uio_pruss per se ( as thats a beagle only driver that I'm awre of ).

--

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.

[William Hermans]

@ Jason Reeder

I have seen much of your documentation on the ti wiki pages, as I spent a week or two a bit at a time attempting to get something working to test remoteproc. Here, one could probably very easily duplicate exactly what you've done, and get exactly what you've demonstrated, working. The problem here is that this does not teach anyone anything. So, if I for example wanted to write host code using GCC instead of CCS. There is not enough information for anyone to make this happen easily. *WITHOUT* digging into the source code, or pouring over what little information there is on the web about remoteproc. Which by the way most of that outside information is irrelevant because they do not have  PRUs.

So, I stopped attempting to test remoteproc, because there is not enough good documentation on the subject. exact step guides are useless if all you really need to know exactly what needs doing for this to work. How does one write a PRU config( hex ) files? What are the purpose of these files, and what is a minimal example. Which drivers are needed ? Where is the API documentation ?

You all need to make this dead simple to setup, not matter where a developer is coming from. Otherwise you're going to end up with a bunch of very experience pissed off developers, who do not even want to bother with remoteproc. This means, that exact step guides for CCS only will not cut it.

--

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.

[William Hermans]

Also, for the record, I was very easily able to get the uio_pruss examples working effortlessly using gcc from an Debian Wheezy x86 command line. Dead simple.

[Robert Nelson]

On Thu, Jun 16, 2016 at 6:17 PM, Anna, Suman <s-a...@ti.com> wrote:
> 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.

As of today, (4.4.12-ti-r31) we are sync'ed up with:

http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-rt-linux-4.4.y

http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=commit;h=39452940d0e4710677b7e50638885cc27d2ce70c

Which includes the mailboxes -> pru system events replacmement:

http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=commit;h=4cc71c5a52a1a9631a11b22524b2455baa3956ed

Regards,

--
Robert Nelson
https://rcn-ee.com/

[John Syne]

Hi William,

I think it would be helpful for Jason to see the pruss-uio docs you think are well written. I don’t want to provide Jason with a list of complaints, but rather a list of helpful suggestions that might guide him to a better solution. 

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqhD-ubwQoV4GX7wXNe0-bAZ0be%3Ds57uSqsQWbEMhEKLQ%40mail.gmail.com.

[John Syne]

Hi Jason Reeder,

I think William forgot to include you in his response. As you can see, William is an experienced developer who had difficulty understanding the RPMSG/Remoteproc framework. A lot of this I believe is TI’s tendency to use terminology assuming the reader is familiar with and in most cases we are not. I agree with William that canned examples are no substitute for a document that explains how something works. For example, what are VRings. Now I know that they are virtual ring buffers, but what are the interfaces, how do they work, what are their limitations, how responsive are they, throughput, etc. Same for Virtio. How does it work, how are drivers abstracted, what is the messaging format, etc. At each level, an explanation is necessary and as William indicated, a good API doc is also necessary. 

I’ve seen this requirement to use GCC in place of CCS several times so an explanation on how to use GCC would be helpful. 

I have asked William to post links to good pruss_uio docs that might serve as a guide. 

Regards,

John

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.

[TJF]

@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!

[John Syne]

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. 

@Jason Reeder and Suman Anna:
Thanks for joining that discussion and for sharing your project. You defined big targets, unfortunatelly you forget about the basics. Following your current concept, prussdrv can never get replaced by your solution.

One reason is execution speed. It might be suitable for BeagleLogic, which uses minimal communication between ARM and PRUs before and after the measurement, in non-time critical situations. In contrast, my project libpruio is designed to work in the main controller loop. Everyting is time critical here. Therefor I use a messaging system simmilar to the one in RPMsg, but highly speed optimized. Just one example: In order to send a message from ARM to PRU, if I'd switch to RPMsg, I'd have to use function pru_rpmsg_send() for that purpose. Just the preparation of that function call (five parameters on stack) needs five times more CPU cycles than my solution. Additional CPU cycles are consumed in the kernel code and furthermore on the PRU side, before the message arrives. Not worth discussing.

I believe your use case is a special one and may not be served by remoteproc. Communicating between PRU and ARM in the main control loop seems odd. Normally, the tight control loop runs on one PRU, dumping to shared memory and the other PRU handles the communications between PRU and ARM. Why doesn’t this work for you?

A second point is the firmware load. Do you realy want to force users to use CCS and the Processor SDK (m$ habits on an open source comminity?). The PRU (and the other subsystems you target like DSP, ...) are made for high speed tasks. My prefered language in that case is assembler, and I'm not alone in thinking that. Your solution needs a feature to load assembler generated firmware, if you still target to replace UIO_PRUSS anytime. And it's out of question to remove and reload the kernel driver for firmware updates. What if one PRU should run while updating the firmware on the other? Furthermore it needs a feature to reload firmware with user privileges!

Here I agree with you. It should definitely be possible to add and remove firmware at runtime. Given that remoteproc can load, start and stop firmware, why not enable a feature for a user with the correct group permissions to load/reload new firmware at runtime? This might be done via a debugfs interface. 

Also, your point about assembler support is quite valid and I would suggest that an assembler template/example be created for remoteproc. Alternatively, you can always start with a C version and then optimize the assembler output. 

The next point is the messaging system and its big memory consumption. What if an application doesn't need it and wouldn't use it? Currently I cant find any feature for high speed data exchange between ARM and PRU via DRam or SRam memory.

In short, if you want to fulfill the expectations Jason Kridner or John Syne spend on your project (replacing UIO_PRUSS), you have to redo your concept and start from scratch.

Not true. I think the main framework is sound even if it does not suite your strange use case. Perhaps there is a way to augment the framework with a quick message transfer. 

Just some thoughts from my side. In any case, thank you for your valuable input which I hope will guide Jason and Suman in their future development. 

Regards,

John

Your system has to be scalable, starting at a feature set (and resource consumption) similar to UIO_PRUSS (load-start-stop firmware, bidirectional access DRam-IRam-SRam-INTC). When firmware contains the .resource_table section, then load your additional drivers and do all your remoteproc magic. But otherwise just load and start the firmware, without consuming additional resources. Let the user choise his development tools. Do not consume any resources until you get firmware to load.


@Jason Kridner: Just to make it clear, when you continue supporting the replacement of UIO_PRUSS by remoteproc, then in long term all high perfomance PRU projects like libpruio will die!

--
For more options, visit http://beagleboard.org/discuss
---
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.

[John Syne]

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 ;-)

 

 

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

[Anna, Suman]

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. ]

 

 

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

[Anna, 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

[Anna, 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.

[TJF]

Hi Suman, thanks for your statements.

[Suman: Where do you use this from, I assume userspace? Using what - Shared DRAM or regular PRU DRAM.]

Yes, libpruio is a userspace library. I'm not familiar with your terminologie: Shared DRAM = SRam (12k@0x10000) and PRU DRAM = DRam (2x8k@[0x0|0x2000]), right? I use the later (similar to your solution).

[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.]

Reloading the kernel module for firmware updates is I what read several times at this forum. I didn't test yet. Sorry, if I confuse things here.

John asked alreay: Where can we find a tutorial / example on updating firmware the correct way? A further question: often I reload just a part of the IRam. I guess your concept doesn't support that?

[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.]

Seconding John: Where can we find a tutorial / example on how to load a fimware image cerated by the pasm assembler?

[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:

• Reduce resource consumption on a small SoC.

And your advice is:

• Add a further module to a bloated framework.

Are you joking?

Full sure, it's not only me who'd ask: Why should I spend time to extend a resource consuming framework that changes every now and then -- why should I start to follow a moving target, just to end up with a feature that I already have, working reliable since years? And why should hundred other developers do the same?

It has been said already. From the BBB point of view your project has nothing to offer. There are no MPU, DSP, ... processors. It's just about ARM and PRU. Your IPC is too slow. The complete topic is just about replacing a "hack" by a "real Linux driver". And this isn't worth to spend four times more memory and additional boot time and additional development man power, just to get what we have already.

When you aim to develop software for the main stream, replacing a proven solution, than YOU have to care about existing standards and start from that point.'This means redo your concept.

Otherwise, when you want to retain with your extisting infrastructure, it's OK as well. But:

• Make it optional. Place it in a separate package. Leave the main stream!

Let the users choise if they want to add and use your additional magic and if they want to spend their resources on that. And do not block TIs kernel development nor the BBB PRUSS development with your experimental project.

Please note: the PRUSS are an important topic. They're a major advantage the BBB has over its direct competitors, like RPi. When your project complicates and slows down the PRUSS development, this endangers the complete Beaglebone project.

[William Hermans]

TJF, and I rarely see things in a similar light, but I have to agree with him completely concerning his last post. Granted, I can't help but feel he is echoing some of my past concerns as well as adding his own.

One thing I am seeing here though is that *maybe* remoteproc for some. may never replace uio_pruss. But I'm seeing potential with using remoteproc as a Linux IPC mechanism similar to how named pipes, shared memory, and shared ports are used for the same. Except, using the PRU in this manner would offer some level of hardware offload benefit.

Granted, the same could be done using uio_pruss.

Also, why do I get the feeling that UIO is looked down on by several developers here ? I see nothing wrong with it. Only that on the userspace side interrupts are a bit of a hack. But would anyone care to tell me what /proc/interrupts, and /proc/irq/* are for ? I'll give you a hint. I already have a pretty good idea . . .

--

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.

[Greg]

Revised PRU examples working good when I created a new SD card with your latest and greatest fantastic scripts and guidance:

https://eewiki.net/display/linuxonarm/BeagleBone

Long term 4.4x

I was not successful with the kernel upgrade script to 4.4.12-ti-r31.

It's like the firmwares are being ignored, even the PRU_Halt, which is almost nothing.

I tried both old and new PRU support packages.  No difference.

Anyway, I like the fresh start with the new card, so I am not looking back.

Regards,

Greg

[Suman Anna]

Hi TJF,

On 06/18/2016 10:23 AM, TJF wrote:
> Hi Suman, thanks for your statements.
>
> [Suman: Where do you use this from, I assume userspace? Using what - Shared
>> DRAM or regular PRU DRAM.]
>>
>
> Yes, libpruio is a userspace library. I'm not familiar with your
> terminologie: Shared DRAM = SRam (12k@0x10000) and PRU DRAM = DRam
> (2x8k@[0x0|0x2000]), right? I use the later (similar to your solution).

Yeah, same ones. I don't use SRAM for PRU Shared Data RAM, as I use it
to mean the regular on-chip memory.

>
> [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.]
>>
>
> Reloading the kernel module for firmware updates is I what read several
> times at this forum. I didn't test yet. Sorry, if I confuse things here.

Yeah, it has come to my notice that this was being suggested previously
on TI forum threads not only for PRUs but for DSPs or IPUs on other SoCs
as well. The bind/unbind does give specific control for a core.

>
> John asked alreay: Where can we find a tutorial / example on updating
> firmware the correct way? A further question: often I reload just a part of
> the IRam. I guess your concept doesn't support that?

Why, it is supported. There are no distinctions made between IRAM,
DRAM0/1 or Shared DRAM. The ELF loader just goes by the program headers,
so if the new image only has a program header that loads into IRAM, then
it just loads that.

>
> [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.]
>>
>
> Seconding John: Where can we find a tutorial / example on how to load a
> fimware image cerated by the pasm assembler?

I don't know if pasm assembler is still a supported tool by TI. If so, I
will work with Jason Reeder to try to get something documented on the TI
wikis or in PRU Software Support documentation.

Anyway, here's some basic steps (thanks to a colleague) in converting a
bin file to an ELF image,

1. /* Convert your binary to prelim ELF */
objcopy -I binary -O elf32-little --rename-section .data=.text
<input.bin> <output.tmp>
2. /* Mark .text as executable, PRU remoteproc makes the distinction
between IRAM and DRAM0 based on the executable flags */
objcopy -I elf32-little --set-section-flags .text=code,alloc,load
<output.tmp>
3. Add a program header for loading the text
ld -n --accept-unknown-input-arch <output.tmp> -T linker_pru0.txt -o
prueth-pru0-firmware.elf --oformat=elf32-little -o <final-output.elf>

An example linker_pru0.txt is as follows,
SECTIONS
{
.text 0x0 : { *(.text); }
.resource_table 0x0 : { *(.resource_table); }
}

If you have a resource table binary data, that can be added in step 1 as
well, eg.

objcopy -I binary -O elf32-little --rename-section .data=.text
--add-section .resource_table=<rtable.bin> <input.bin> <output.tmp>

Obviously, a lot depends on what other data/sections you have within
your firmware in terms of your linker file and resource table section
placement.

Once I add the evt->channel->host interrupt mapping to DT for MPU, the
need for a resource table for MPU-related interrupt handling will mostly
go away. Until then, the interrupt mapping needs to come through
resource table, or if thats too painful, let the firmware code deal with
the mapping.

As for reloading a new non-ethernet firmware,
echo <pru-device> > /sys/bus/platform/drivers/pru-rproc/unbind
change correspoding firmware in /lib/firmware/
echo <pru-device> > /sys/bus/platform/drivers/pru-rproc/bind

>
> [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:
>

> - Reduce resource consumption on a small SoC.
>
> And your advice is:
>
> - Add a further module to a bloated framework.

It is about coming up with a framework that would satisfy both the
kernel and userspace needs as well. With libprussdrv, one simply cannot
use PRU from kernel-mode. Yes, there are gaps at the moment with the
current infrastructure, and I never said it is complete.

Going by your philosophy, you don't need Linux drivers at all. Mmap
everything and do everything in userspace, why bother with the kernel at
all? /dev/mem is your friend.

>
> Are you joking?
>
> Full sure, it's not only me who'd ask: Why should I spend time to extend a
> resource consuming framework that changes every now and then -- why should
> I start to follow a moving target, just to end up with a feature that I
> already have, working reliable since years? And why should hundred other
> developers do the same?
>
> It has been said already. From the BBB point of view your project has
> nothing to offer. There are no MPU, DSP, ... processors. It's just about
> ARM and PRU.

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.

Your IPC is too slow. The complete topic is just about
> replacing a "hack" by a "real Linux driver". And this isn't worth to spend
> four times more memory and additional boot time and additional development
> man power, just to get what we have already.
>
> When you aim to develop software for the main stream, replacing a proven
> solution, than YOU have to care about existing standards and start from
> that point.'This means redo your concept.

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.

>
> Otherwise, when you want to retain with your extisting infrastructure, it's
> OK as well. But:
>

> - Make it optional. Place it in a separate package. Leave the main
> stream!

Define mainstream. What's mainstream for you is downstream for me. And I
am not aware until recently that the TI kernel is getting merged into
BBB kernel. I don't even know the merge cycle that BBB kernel is
following. The kernel changes I add are geared towards internal TI
releases, and there's always a potential downside for merging the kernel
at random points.

>
> Let the users choise if they want to add and use your additional magic and
> if they want to spend their resources on that.

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 do not block TIs kernel
> development nor the BBB PRUSS development with your experimental project.
>
> Please note: the PRUSS are an important topic. They're a major advantage
> the BBB has over its direct competitors, like RPi. When your project
> complicates and slows down the PRUSS development, this endangers the
> complete Beaglebone project.

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, and
he can work internally within TI to raise requirements or prioritize
features for bridging the gaps. You can always post queries on the TI
E2E forum for continued support.

regards
Suman

[William Hermans]

heh, it's not about TI's support. It's about TI playing ball with the community. Instead of rocking the boat. Personally, I could say when I add the next feature to whatever - To go talk to my mom, because I don't want to hear it. But that wouldn't be very social would it ?

Yes, we can go back to and older config, but you people could also stop stepping all over the communities kernels, and then calling it your own. Right now, I have a stock image with 115M used memory right after a fresh reboot. I have sound, and driver for both sides of PRU modules ( remoteproc AND uio ), and I didn't even touch this image. Here, let me just show you this crap:

debian@beaglebone:~$ lsmod
Module                  Size  Used by
binfmt_misc             8862  1
usb_f_ecm               9336  1
g_ether                 4976  0
usb_f_rndis            22191  2 g_ether
u_ether                11898  3 usb_f_ecm,usb_f_rndis,g_ether
libcomposite           43717  3 usb_f_ecm,usb_f_rndis,g_ether
nfsd                  261377  2
spidev                  7523  0
omap_sham              21340  0
omap_aes_driver        19045  0
pwm_tiehrpwm            4706  0
tieqep                  8758  0
pwm_tiecap              3652  0
omap_rng                4423  0
rng_core                7703  1 omap_rng
c_can_platform          6602  0
c_can                   9577  1 c_can_platform
can_dev                11820  1 c_can
snd_soc_davinci_mcasp    17079  0
snd_soc_edma            1290  1 snd_soc_davinci_mcasp
snd_soc_omap            3058  1 snd_soc_davinci_mcasp
snd_soc_core          155549  3 snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap
snd_pcm_dmaengine       5209  2 snd_soc_core,snd_soc_omap
snd_pcm                83341  4 snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
snd_timer              19788  1 snd_pcm
snd                    59495  3 snd_soc_core,snd_timer,snd_pcm
soundcore               7637  1 snd
spi_omap2_mcspi        11148  0
evdev                  10695  1
uio_pdrv_genirq         3539  0
uio                     8822  1 uio_pdrv_genirq

pru_rproc              12632  0
pruss_intc              7223  1 pru_rproc
pruss                   9408  0

Why do I need all this garbage ? I didn't  enable it, and I really do not want, or need it.

debian@beaglebone:~$ free
             total       used       free     shared    buffers     cached
Mem:        504000     115864     388136       4344      16948      34548
-/+ buffers/cache:      64368     439632
Swap:            0          0          0

This is just sickening.

Anyway, it gets old having to go over these images that used to be nice, clean, and tidy. I guess I'm just going ot have ot start building my own images again, improve them myself. And not share the changes ? Isn't that how this community is supposed to work ?

--
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.

[John Syne]

I think you forgot to take your meds this morning. I’m not even sure what this has to do with RPMsg. Looking at this list you provided, I’m not sure what you think is garbage? In any case, if there is something you don’t need, simply modify your config and remove the features you don’t want. Remember, the default kernel wasn’t designed for “you", but targeted at the general developer community and they all have different requirements. I would say this was a good place to start and easily customized to meet my own requirements. 

So, looking at the list, USB, RNDIS, Ethernet, NFS, SPI, PWM, CAN, ALSA, UIO, Crypto and PRU are all important, so what do you want removed? There is nothing left to be removed. 

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORo3Owydt2X%3D59OOa84PotpO8rUDAPKAnB1nMOrWyiMWOQ%40mail.gmail.com.

[John Syne]

Problem with that approach is no possibility to handle interrupts, security is problematic and developers have to recreate almost everything from scratch. The calling mechanism (VRING) between PRU and ARM is quite efficient, but as TJF explained, the calling convention using multiple parameters does impact PRU performance. Perhaps look at ways to make the call work with less PRU cycles. 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.

>
>>
>> Are you joking?
>>
>> Full sure, it's not only me who'd ask: Why should I spend time to extend a
>> resource consuming framework that changes every now and then -- why should
>> I start to follow a moving target, just to end up with a feature that I
>> already have, working reliable since years? And why should hundred other
>> developers do the same?
>>
>> It has been said already. From the BBB point of view your project has
>> nothing to offer. There are no MPU, DSP, ... processors. It's just about
>> ARM and PRU.
>
> 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.

This is what I like most about RemotProc/RPMSG, in that you are using the same framework between ARM, PRU, DSP, etc.

>
> Your IPC is too slow. The complete topic is just about
>> replacing a "hack" by a "real Linux driver". And this isn't worth to spend
>> four times more memory and additional boot time and additional development
>> man power, just to get what we have already.
>>
>> When you aim to develop software for the main stream, replacing a proven
>> solution, than YOU have to care about existing standards and start from
>> that point.'This means redo your concept.
>
> 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.

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.

>
>>
>> Otherwise, when you want to retain with your extisting infrastructure, it's
>> OK as well. But:
>>
>> - Make it optional. Place it in a separate package. Leave the main
>> stream!
>
> Define mainstream. What's mainstream for you is downstream for me. And I
> am not aware until recently that the TI kernel is getting merged into
> BBB kernel. I don't even know the merge cycle that BBB kernel is
> following. The kernel changes I add are geared towards internal TI
> releases, and there's always a potential downside for merging the kernel
> at random points.

BBB has two kernels, the “bone" kernel which continues to use PRUSS_UIO and the “ti” kernel which tracks TI’s kernel development and support RemoteProc/RPMSG. From Robert Nelson comments in this thread, he does pull in RemoteProc/RPMSG patches from git.ti.com.

>
>>
>> Let the users choise if they want to add and use your additional magic and
>> if they want to spend their resources on that.
>
> 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.

For those developers who don’t want RemoteProc/RPMSG, they use Robert Nelson's “bone” kernel.

>
>> And do not block TIs kernel
>> development nor the BBB PRUSS development with your experimental project.
>>
>> Please note: the PRUSS are an important topic. They're a major advantage
>> the BBB has over its direct competitors, like RPi. When your project
>> complicates and slows down the PRUSS development, this endangers the
>> complete Beaglebone project.
>
> 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, and
> he can work internally within TI to raise requirements or prioritize
> features for bridging the gaps. You can always post queries on the TI
> E2E forum for continued support.

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.

Regards,
John
>
> regards
> Suman

[TJF]

@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:

1. do I want to make something completely new, or
2. do I want to replace an existing solution?

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).

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

[Jason Kridner]

I will work to enable uio_pruss functionality, and I think that is what you want, not just getting remoteproc out.

[William Hermans]

@Jason Kridner

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.

For example, all those modules listed in the output from my lsmod on a fresh install of the latest Jessie testing image:

debian@beaglebone:~/nfs$ uname -r
4.4.12-ti-r31
debian@beaglebone:~/nfs$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-06-19

Anyway all those kernel modules should *NOT* be enabled by default. With exception of perhaps the USB gadget drivers(and nfsd is something I personally loaded ). Personally, I would prefer they were not loaded by default, but I can understand the need. Additionally, those kernel modules should be loaded via a device tree file as in how the original uio_pruss module is loaded.

So again. I do not care what you all at TI work on. It's not my place to say one way or another. But please do not force us to endure your developers poor clean up abilities. But I will say, that looking at that mess that is the output of lsmod from a released debian image. You all must have zero pride in your work . . . Harsh ? Maybe overly harsh yes, but think about the message you developers are putting out there with that mess.

Also as TJF mentioned. Feel free to create your own little sandbox, and then include the stuff you have finished into the released images. That, would make me happy, as well as many others, I'm sure. It's either that, or I'm forced to clean up your mess. Which I am perfectly capable of doing. But that's not the point.

Additionally, I am grateful for the work *EVERYONE* has done for the community. Even the people I'm bitching at right now. Take it as overly critical constructive complaints. If you want.

--

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.

[William Hermans]

There, now everyone can clean their messy images . . .

https://github.com/wphermans/bbb-cleanup/blob/master/beaglebone-cleanup.md

[John Syne]

I’ve included Ohad Ben-Cohen who was one of the originators of the RemoteProc/RPMSG framework. Hopefully he will be able to provide some prospective of what he was thinking when he created this framework. 

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

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. 

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.

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. 

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.

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. 

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.

These are generally toys. The vast majority of drivers are Kernel based drivers. 

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.)

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.  

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.

Hence why you want to Kernel based driver to validate the firmware. Again, userspace driver can place whatever code it wants on the PRU. 

 

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.

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. 

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.

This framework works for me so I certainly don’t want it removed. 

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.

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. 

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).

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. 

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:

1. do I want to make something completely new, or
2. do I want to replace an existing solution?

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).

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 reason it was added to mainstream was to encourage support by other vendors which has already started. 

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.

Since pruss_uio is only supported on one platform, it shouldn’t be included in mainstream. 

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.

Again, use the “bone” kernel. This is why Robert Nelson has the “bone” kernel. 

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.

I completely disagree with this request. 

Regards,

John

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.

[John Syne]

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. 

Please don’t do that. Robert Nelson has the “bone” kernel for this purpose which supports pruss_uio by default and does not have RemoteProc/RPMSG installed. The “ti” kernel however does the reverse, with the RemoteProc/RPMSG installed by default and pruss_uio no installed. I believe the two frameworks conflict so it is not possible to have both installed. 

Regards,

John

-- 
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.

[William Hermans]

Also, instead of saying "use the bone kernel instead". Do realize that the TI kernel has some useful features that are not implemented into the *bone* kernel config, at minimum.

So the point is, this "toy" is a community "toy". Not just for you.

[John Syne]

On the contrary, the TI kernel is for all TI processors and not just for the BBB. If you want features added to the “bone” kernel, why not request those features be added. 

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORobVtuniGF-zG4OHg3iELHhJC5jGhNfeGH_s7D8_Cw%3DrA%40mail.gmail.com.

[Rick Mann]

> On Jun 25, 2016, at 12:56 , John Syne <john...@gmail.com> wrote:

>> 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.
>
> Please don’t do that. Robert Nelson has the “bone” kernel for this purpose which supports pruss_uio by default and does not have RemoteProc/RPMSG installed. The “ti” kernel however does the reverse, with the RemoteProc/RPMSG installed by default and pruss_uio no installed. I believe the two frameworks conflict so it is not possible to have both installed.

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).



--
Rick Mann
rm...@latencyzero.com

[William Hermans]

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).

Right now, I do not believe it is possible. But as you say - it should be. But this is one of the points I was eluding to in my rants. I think that ideally, there should be only one kernel, with the option to load whatever a user at the time wishes. Of course, it would not make sense to load two PRU drivers at once. Unless somehow it could be made to run two different drivers on each of the PRU cores. That might be cool . . .

Anyway, right now I do not think that the two PRU drivers are compatible with one another as kernel config options. *That* in my mind should be a paramount consideration.

--
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.

[John Syne]

If you read the discussion, TJF and William don’t want to build a custom kernel. So since you cannot have pruss_uio and RemoteProc/RPMSG, configured simultaneously, this is the dilemma we are facing. Currently Robert Nelson has configured the “bone” kernel to have pruss_uio dn the “ti” kernel to have RemoteProc/RPMSG. William is concerned that the “ti” kernel has more features than the “bone” kernel. Solution is to ask Robert Nelson to add the missing features to the “bone” kernel.

Regards,
John
>
>
>
> --
> Rick Mann
> rm...@latencyzero.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/9F227F8C-8A4C-4FB6-A7C1-2D075CFD3429%40latencyzero.com.

[Rick Mann]

> On Jun 25, 2016, at 14:44 , John Syne <john...@gmail.com> wrote:
>
>> On Jun 25, 2016, at 2:20 PM, Rick Mann <rm...@latencyzero.com> wrote:
>>
>>
>>> On Jun 25, 2016, at 12:56 , John Syne <john...@gmail.com> wrote:
>>
>>>> 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.
>>>
>>> Please don’t do that. Robert Nelson has the “bone” kernel for this purpose which supports pruss_uio by default and does not have RemoteProc/RPMSG installed. The “ti” kernel however does the reverse, with the RemoteProc/RPMSG installed by default and pruss_uio no installed. I believe the two frameworks conflict so it is not possible to have both installed.
>>
>> 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).
> If you read the discussion, TJF and William don’t want to build a custom kernel. So since you cannot have pruss_uio and RemoteProc/RPMSG, configured simultaneously, this is the dilemma we are facing. Currently Robert Nelson has configured the “bone” kernel to have pruss_uio dn the “ti” kernel to have RemoteProc/RPMSG. William is concerned that the “ti” kernel has more features than the “bone” kernel. Solution is to ask Robert Nelson to add the missing features to the “bone” kernel.

I'm not sure specifically what's preventing the two from being configured simultaneously, so long as both their code doesn't execute simultaneously. It seems one or the other or both can be modified to coexist in the configuration, and that may be the best way to ensure the kernel supports all users.

We have the source, it should be possible. The kernel can support multiple ethernet drivers configured simultaneously, why not multiple PRU drivers?

--
Rick Mann
rm...@latencyzero.com

[John Syne]

Think about what you are proposing. When the kernel loads, it discovers devices and then loads the appropriate drivers. Now what happens when it discovers the PRU, which driver does it load, PRUSS_UIO or RemoteProc?

Regards,
John

> --
> 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/19C6420A-AF09-4542-B907-AD54429E56B4%40latencyzero.com.

[William Hermans]

#1 It's not as if Robert doesn't have enough on his plate already.

#2 Forcing the need for two different release kernels is not the proper way to go about solving this problem.

So no, the proper solution is not to add more work for Robert. 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.

[Harvey White]

On Sat, 25 Jun 2016 18:32:51 -0700, you wrote:

>Think about what you are proposing. When the kernel loads, it discovers devices and then loads the appropriate drivers. Now what happens when it discovers the PRU, which driver does it load, PRUSS_UIO or RemoteProc?

Why not give it a configuration choice? Both modules can be optional,
load or not load only one. Develop your application to match.

You already do this with the pin overlays/pin mux.

Can you decouple it from the main program/OS and then have resources
that you need?

Harvey

[Rick Mann]

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/B5C4860B-52F9-485A-B268-65674695A127%40gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--
Rick Mann
rm...@latencyzero.com

[William Hermans]

Doesn't it "discover" devices by looking at the device tree?

For many devices, the kernel is sort of unaware until a device tree is loaded. Now by "unaware" I just mean that the kernel has been compiled with that module as a loadable module ( non static ), and a "hook" has been written into the main board file for specific modules. Which load when the device tree "hook" status has been changed to "Okay".

But you've probably been one or two of these yourself already. But here: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/uio_pruss_enable-00A0.dts#L22

As an example.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/C7759943-C3C3-475D-97E2-A57995AABEE1%40latencyzero.com.

[William Hermans]

Been, seen. It's all the same ;)

[John Syne]

> On Jun 25, 2016, at 7:45 PM, Rick Mann <rm...@latencyzero.com> wrote:
>
> Doesn't it "discover" devices by looking at the device tree?

Ideally, yes, but Robert said there is a conflict when both frameworks are built in the same kernel. Currently, both frameworks are not built into the kernel and both are configured as Loadable Modules. Also, it should be possible to have a separate Devicetree for each framework, but with the build conflict Robert is unable to do this at this time. My understanding is this is why the “bone” kernel exists. If Robert is able to resolve the build conflict, then is the “bone” kernel even necessary? Remember, the “ti” kernel is not just for the BBB, but also for the BeagleBoard-x15 so the RemoteProc/RPMSG is required to support the DSPs and CortexM4s, so kill the idea that RemoteProc/RPMSG is going away, it just isn’t. There is no pruss_uio equivalent for the DSPs or CortexM4s. Even more important, TI have even bigger processors that have 4 Cortex-A15 ARM cores and 8 DSPs and the same “ti” kernel is used for that processor.

Hopefully Robert can chime in on this issue and clear up this issue.

> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/C7759943-C3C3-475D-97E2-A57995AABEE1%40latencyzero.com.

[TJF]

@John3909:

Am Samstag, 25. Juni 2016 21:53:10 UTC+2 schrieb john3909:

Why don’t you use the “bone” kernel which pruss_uio as default.

That's what I do.
 

The “ti” kernel has RemoteProc/RPMSG as default. I don’t understand you problem here.

There'll be no more problem when we follow my proposal and remove the remoteproc framework from the mainstream. But in the current situation the problem is to find an answer when a user asks "How to test a ti-rt kernel with libpruio?".
 

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. 

Why should I spent time on that investigation? Better convince me by telling me: how much do you think your thingy can increase libpruio throughput?
 

I continue to say that you are using RemoteProc/RPMSG incorrectly.

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.)
 

These are generally toys. The vast majority of drivers are Kernel based drivers. 

 
I don't know all the other drivers you stated here. But in case of one-wire your "generally toys" (all four) do the heavy work in real world projects. Because your "vast majority" (I count one) isn't able to perform a simple broadcast trigger for multiple Dallas sensors, and misses lots of other features like setting limits, ... In my experience, and in case of one-wire usecase, the kernel driver is the toy. And there're much and good reasons why the userspace drivers are under continuous development (and the kernel driver isn't).

Try a little bit thinking outside your box.

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.  

My libpruio driver has lots of validations. Ie. you can find many posts at this forum regarding a validation bug, where the maximum sampling rate for ADC sampling was calculated too much on the save side. Do you really think that only kernel code can validate?

But please read my statement again. I'm not talking about physical security, nor about arbitrary periperals. I'm talking about the PRUSS and their firmware, which can access all CPU memory without any kernel protection. I'm talking about software 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. 

Right, whatever code it wants. Ie. a virus. And it's really hard to find a virus running on the PRUSS. Currently, I see no way how a kernel driver should validate if the firmware is free of virus. And when firmware is loaded from files and started by command line, it's much more easy to run a virus on the PRUSS, in contrast to loading and running it by prussdrv. With remoteproc, it even doesn't need any command line action: just copy the virus to /lib/firmware and name it am335x-pru$[0|1]-fw, and it will run at next boot time. This is a massive safety risc in the current remoteproc concept. It shouldn't be that easy to install and run malware.

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. 

How is this related to my statement you qouted?

This framework works for me so I certainly don’t want it removed.

Fine, go ahead. (BTW: which projects did you realise yet?)

Once you read my statements again, you'll find out that I only want to remove a dangerous software from the mainstream, but not completely. So you can still use your be-loved thingy. Just load it as an option.
 

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, I've problems with remoteproc. And I've problems with the framework and its design. It doesn't make sense to talk about details. In order to make this framework usable, it needs talk about general issues, like

Do we really need PRU access from kernel space?
If so, how to handle the additional riscs?
...

And this needs other than traditional thinking, since riscs regarding the PRUSS are different from riscs handled by any kernel driver before.

But this discussion is pointless, since Suman said that he don't want to start from scratch. (He may change his mind when he reconsiders the riscs of the current design.)
 

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. 

See my answer above. TI kernels do not only differ from remoteproc. Some of my users want to test the real-time features, which aren't in the bone channel. I try to help them. I try to find a way that prefers corporate development to mutual exclusion by downgrading.
 

The reason it was added to mainstream was to encourage support by other vendors which has already started. 

Obviously too early.
 

Since pruss_uio is only supported on one platform, it shouldn’t be included in mainstream. 

An unsave, experimental framework also shouldn't be included in mainstream. I'd try to make both optional and choise in device tree when enabling the PRUSS.

BR

[John Syne]

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.)

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. 

Regards,

John

[William Hermans]

I think there is a LOT of misconception as to what uio_pruss *is*. Or what *any* UIO driver is - period.

#1 a UIO driver is kernel side first. There is no userspace side driver with out a UIO kernel driver stub. So, if you create your own kernel side "stub"( as done with uio_pruss ) it can be as complex, or as simple as needed.

#2 I always treat security risks as if an intruder has already gained access to at least a regular user account. When you think of the problem from this angle, you start thinking how it's best to write programs that are hard to compromise. So, if you're concerned about uio_pruss being a security risk. Then write your userspace program in two halves. root / superviser service + regular user / worker program. Worker program can NOT do anything the supervisor service will not let it do. Passed that, if an intruder gains access to root. You're already screwed, so you can relax ;)

#3 Someone, or some people do not understand how fast userspace can be, when you write proper applications with performance in mind. *You* can tell me until you're blue in the face that implementations including, and using /dev/mem/ + mmap() are a bad idea, because of the "reindeer effect", or whatever. The thing is, I already know what the good, and bad implications of using /dev/mem/ + mmap() are. So why would I need anyone elses advice on it ? Hint: I don't. If you think it's a bad idea, then fine. Do not use it. Let the big boys write the performant applications. But do not try and pee on my leg, and tell me it's raining. Because I do have a brain of my own.

Passed that, sticking to API calls that do not copy data to, and from the kernel. Or otherwise stall an application because of context switching, or any number of reasons - is best practice. But you have to know this to begin with, and then bother in trying to make things work the way you need, or want them to work. Not just toss something together, and complaining when it does not live up to your performance standards. e.g. You should probably consider learning how to write code properly . . . Or let someone else do it.

So, what does /dev/mem/ + mmap() have to do with the PRU's ? Nothing really. Except if you expect to keep up with programmable high speed peripherals. You're going to need every bit of speed your application can muster. Then, if you can not trust me when I say that /dev/mem/ + mmap() is easily 100's or 1000's times faster than standard libc / POSIX calls / sysfs. Then go experiment on your own to prove to yourself. Me, again, I do not need any advice. I've already tested on my own.

--

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.

[John Syne]

So reading the UIO docs;

https://www.kernel.org/doc/htmldocs/uio-howto/about.html

"For some hardware that has more than one interrupt source internally, but not separate IRQ mask and status registers, there might be situations where userspace cannot determine what the interrupt source was if the kernel handler disables them by writing to the chip's IRQ register. In such a case, the kernel has to disable the IRQ completely to leave the chip's register untouched. Now the userspace part can determine the cause of the interrupt, but it cannot re-enable interrupts. Another cornercase is chips where re-enabling interrupts is a read-modify-write operation to a combined IRQ status/acknowledge register. This would be racy if a new interrupt occurred simultaneously.”

To address this issue, you are required to write a UIO Kernel Module:

https://www.kernel.org/doc/htmldocs/uio-howto/custom_kernel_module.html

Now with reference to handling interrupts:

https://www.kernel.org/doc/htmldocs/uio-howto/adding_irq_handler.html

"If, on the other hand, your hardware needs some action to be performed after each interrupt, then you must do it in your kernel module. Note that you cannot rely on the userspace part of your driver. Your userspace program can terminate at any time, possibly leaving your hardware in a state where proper interrupt handling is still required."

Regarding /dev/mem, how does a userspace app access /dev/mem? In a secure system, you shouldn’t be running your app as root and there should be no member of the kmem group. This feature is more for hacking and debugging purposes, not serious application development.  

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqAE7kF3hLPcL9ZUkwp1Cb30MBarCj7oW3FLd9FNv-VGQ%40mail.gmail.com.

[TJF]

@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

[John Syne]

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? 

 

... 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.

So how do you propose to modify the PRU firmware without root access? On the other hand, your libpruio app runs in userspace, so it is easy to swap out that app and bypass all security.

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.

Your childish antics say more about you and this isn’t helpful in this discussion. Keep the discussion professional and reframe from getting personal. You really are not listening, RemoteProc/RPMSG are here to say because of all the other processors TI support and several other vendors have decided to support this framework also. Nothing you say is going to change that. All you can do is request that it is improved to suite your needs, or you will have to build your own custom kernel without RemoteProc/RPMSG to support libpruio. RemoteProc/RPMSG will be the standard interprocessor communications framework in Linux. Take this chance to influence the development. Everything else is futile. 

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.

This is so silly and you should be better than this. 

Regards,

John

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.

[John Syne]

On Jun 27, 2016, at 1:49 AM, John Syne <john...@gmail.com> wrote:

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 ;-)

Regards,

John

[TJF]

@John3909:

Am Montag, 27. Juni 2016 11:19:13 UTC+2 schrieb john3909:

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 ;-)

Good John, you're closing up to this discussion. You're at this point now (three days ago):

[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:

• Reduce resource consumption on a small SoC.

And your advice is:

• Add a further module to a bloated framework.

Go ahead! Once you're on track, it wouldn't need any "childish antics" any more. I can hardly wait reading your opinion on the PRU virus issues.

BR

[Przemek Klosowski]

On Mon, Jun 27, 2016 at 3:51 AM, TJF <jeli.f...@gmail.com> wrote:
> 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.

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. The whole point of a kernel driver is that it abstracts the
hardware and presents the unified abstraction to the rest
(open/read/write/ioctl/skbuf/etc). Of course this costs performance,
and so the development identifies those bottlenecks and tries to come
up with more abstractions like no-copy networking, etc.
The challenge for those abstractions is to provide speed while still
maintaining security, e.g. by disallowing full control of the entire
physical address space. There have to be address space checks on those
kernel-userspace transitions, and they will use up some cycles; you
can optimize them but can't just not do them.

It seems to me that you just don't want the Linux machinery to
intervene: your design does feel like a bare metal, tight control
loop, using Linux mostly for setup, program loading and
administration.

Also, I would be personally obliged to you if you could refrain from
commenting on other people's motivations and abilities, and just keep
focused on the technical points everyone is making. The discussion is
much more productive this way.

[John Syne]

This message from Przemek didn’t get copied to everyone but I thought he had an interesting prospective to this discussion.

Regards,
John




> Begin forwarded message:

> --
> 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.

[William Hermans]

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.

I do not think the strategy I discussed would be pointless. If your worker application was required to speak with a supervisor service, and the supervisor was the only part that had direct access to the PRU. There would be no problem, unless your attacker gained root, at which point  you're already too far gone.

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.

--
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.

[William Hermans]

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.

By the way. You could lock down the PRUs the same way /dev/mem/ is locked down. /dev/mem/ requires root privileges.

[John Syne]

On Jun 27, 2016, at 11:16 AM, William Hermans <yyr...@gmail.com> wrote:

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.

By the way. You could lock down the PRUs the same way /dev/mem/ is locked down. /dev/mem/ requires root privileges.

Which is essentially the problem and why I do not like /dev/mem for application development. For testing out a concept or debugging kernel code, then it is a powerful tool.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrgvE6hHNTbp0mXhqML3%3DA2vJNRCgqjDMpg5Pcr8%3DoqbQ%40mail.gmail.com.

[William Hermans]

There are several points about security in this discussion, and I would like to make what I think is a good point. With Linux, you can specify how a system can be accessed. Meaning, if you're doing something that could potentially be considered a security hazard, then you can lock that system down tight as a drum.

You can do various things, such as:

• Completely disable root
• Limit access to a terminal( local access only )
• Run several different IPC mechanisms for system abstraction
• Run a chroot jail

And a lot more . . .

So in a case where you're using the PRU's and / or dev/mem/ for data acquisition. You do *NOT* allow remote logins - period. Then the data is perhaps saved to a remote NFS share. Then, to maintain your "IoT" system, you log in through a physical serial connection. Pretty simple.

But this is just one of many potential security strategies. However, it should be realized that when a system is internet facing. There will always be a risk . . .

[John Syne]

Reading virtio docs, I came across two sentences that may provide a way forward:

1) "Virtual queues, being virtual, are actually implemented as rings to traverse the guest-to-hypervisor transition. But this could be implemented any way, as long as both the guest and hypervisor implement it in the same way.”

2) "virtio has also been used in High-Performance Computing (HPC) research to develop inter-virtual machine (VM) communications through shared memory passing."

@Suman, would it be possible to configure the memory resource used by Vrings (possibly DDR memory) so that the PRU memory/shared memory can be reserved as direct shared memory between PRU and ARM processors? The traditional message transported over virtualqueues will be use to setup/configure the shared memory. My purpose is use zero copy techniques by using direct memory sharing between PRU and ARM and avoid the need for vring message passing which require (topic, src, dst, *data & len) parameters for each message transfer. In addition, pru_rpmsg_send does a lot of work, such as pru_virtqueue_get_avail_buf(), preparing the message buffer and then finally pru_virtqueue_kick(). Using direct shared memory, both PRU and ARM can define a message structure/protocol that solves this one use case without breaking the existing framework.

If RPMSG implements mmap(), then we might have a solution that should works for TJF. 

One additional thought; if RPMSG embraces zero copy, then this could be extended to eventually support vmsplice which would make for some very powerful features. 

Regards,

John

--
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.

[TJF]

Hello Przemek!

Thanks for joining this discussion.

Am Montag, 27. Juni 2016 18:00:16 UTC+2 schrieb Przemek Klosowski:

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.

What are you talking about here? Is it libpruio? libpruio isn't a kernel driver, it's a userspace library. Jason Kridner wanted to make it mainline, but nothing happened yet. Currently it's an optional OpenSource package.

... e.g. by disallowing full control of the entire physical address space.

 

How? We're talking about the PRUSS (= Programable Realtime Unit SubSystems). They haven't been designed with security in mind. There's no way to disallow control of any address space. Again, the PRUSS can access !ALL! CPU memory, indeed also kernel space.

The only way to protect a system against PRU malware is to disable the PRUSS. Not only once, the kernel has to disable them again and again on a regular basis, before any virus can get loaded and executed on any PRU. I don't see any other way to gain classic Linux security on a board with PRUSS. This is how a secure standard image should work: no PRUSS support at all.

Users who want to benefit from the PRUSS should get informed about the riscs and should install optional drivers to get PRUSS support. I cannot understand how a PRUSS driver can find its way to a standard installation. And I cannot understand how this driver can be enabled by default. And much more, I canot understand why this default driver wasn't designed with security in mind, in order to work around the hardware unsecurity. This is a massive safety risc, implemented in all TI kernels since major version 4, threatening all SoC families.

On BB it's pretty bad: the default cape_universal overlay enables the PRUSS and loads the remoteproc driver. And this driver autoloads any malware at boot time. Your system will be hacked before you see any prompt. An agressor only needs to copy a single file and the operation system in standard configuration does the rest, loading and starting the malware at boot time. Not just a simple userspace virus. No, well defined interfaces open doors for PRU malware to infect kernel space.

I'm no expert in virus development, but I'm sure it can work as simple as

1. PRU searches the CPU memory for RPMsg driver instructions.
2. PRU overrides these instructions by ARM malware.
3. PRU triggers a message.
4. Now the ARM malware is running in kernel space.

Each interface, like vring or even a simple interrupt handler, is an open door which a PRU virus can use to implement and trigger malware on the ARM side. With this in mind, we all should reconsider the question:

Do we really need PRU support from kernel space? If so, is it all of us?

From my point of view, currently some kernel developers endangers thousands of user systems by implementing unsafe features for a small group of developers, which are willing to take riscs. This is not worth discussing. Action is required, immediately.

William said:

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.

BR


@John

If RPMSG implements mmap(), then we might have a solution that should works for TJF.

You're again thinking in the wrong direction. It doesn't matter what you or anybody else add to this framework. It'll never work for me, since I care about security. The only way to gain a little bit of safety is to remove unsave features.

Regarding PRUSS, for me the best security strategy is that PRU code should never be able to estimate how the software on the ARM side is working. And the number of options to trigger software on the ARM by PRU should be as small as possible, in best case no options at all. (Even then a PRU virus can use brute force attacks to implement kernel or userspace malware, but such a virus activity is more likely to get found. A kernel space virus can work for a long period of time before you even notice it.)

BR

[John Syne]

@TJF, I didn’t copy the PRU developers because I believe there is nothing in your response that would be of interest to them. 

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 without root permission. This is what makes the PRU secure. Without root permission, you cannot replace the PRU firmware, period. Now it is up to the PRU firmware developer to make sure their code does not compromise system security and this is true of any kernel module developed to run on the ARM processor. 

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 and this seems to be the basis for all your arguments. With that goal in mind, you are using logic to try and back into that conclusion, but your logic doesn’t make sense.  I am trying to help you here, but you are not giving me anything I can work with. 

Regards,

John

--
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.

[TJF]

Good morning John!

Am Dienstag, 28. Juni 2016 17:48:24 UTC+2 schrieb john3909:

It is hard to keep up with your changing priorities.

My priorities are

1. Security
2. Speed
3. Resources

That didn't change for years.

What you mean is that my focus changed in this discussion. Before that discussion, I didn't know much about that framework. I read just enough to find out that it doesn't adress my needs, too slow, too bloated. Then, in this discussion, I learned more about the project and its features, and I found out that it also doesn't adress my first priority. So I changed my focus from minor to major priority. Since we're now at the highest priority, there wont be any further changes.
 

Addressing your security issues, you never answered my original question. How are you going to install PRU firmware ...

I wrote it several times, libpruio uses libprussdrv to load the firmware.
 

This is what makes the PRU secure. Without root permission, you cannot replace the PRU firmware, period.

Period? A standpoint is an intellectual horizon with the radius null.

An agressor needs physical access to the system, but no root permission on that system.

• When the BB boots from SD card, the agressor puts this card in his laptop where he has root permission to copy the malware to /lib/firmware/am335x-pru$[0|1]-fw on the SD partition.
• When the BB boots from EMMC, the agressor inserts a bootable SD card and presses the boot button on start up. The system boots from SD and it neither needs a monitor nor a keyboard, the copy process can get executed by a boot script to place the malware on the EMMC partition.

Welcome to reality!

Sure, any virus can get installed that way. But why should it be more easy to install a worst case kernel virus than to install a simple userspace malware? An why should the operationg system help to get it running?
 

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. 

 
This is a proposal on a detail. Currently it makes no sense to work on details. At the moment, it needs a management decision

1. General direction
2. Milestones
3. and then your important detail work.

It sounds like you are only interested in getting libpruio into mainline ...

Is this a bad scenario? Yes, because due to all that kernel changes I'd have to spend a lot of effort to keep it up to date.

What about you? You insists on keeping that framework in mainstreams default configuration, although you know that you could use it as an optional package as well. Why? This sounds like you're planing to use this weak point for your next malware. This sounds like you want to become an author of a Linux kernel virus.

But instead of listening to mystic sounds, we both should concentrate on facts and arguments.

BR

[John Syne]

@TJF

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. 

Regards,

John

--
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.

[TJF]

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

[John Syne]

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.

The only reason you can do this from userspace is because of uio_pruss. It is the UIO driver that exposes the PRU memory to user space that creates this security hole. With RPMSG/RemoteProc, there is no uio_pruss and so you cannot install custom code to the PRU without root permission. 

 

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.

You still haven’t explained how to load custom code onto PRU using RemoteProc without root permission. Looking in /lib/firmware, user and group permissions are always root. There are only two ways to load PRU firmware and that is at boot time because of DT PRUSS driver definition or via sysfs and this requires root permission. 

 

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.

I accept that you may have a way to do this that I have not thought of, but I have yet to see you prove this. 

 

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.

As I said before, on the BeagleBoard-x15, the DSP, CortexM4 and PRU all have access to the entire memory map, so loading firmware on any of these cores must be secure. It isn’t a PRUSS issue 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.

Why, because your argument would apply to any processor, namely DSP, CortexM4, other ARM cores running a different OS or perhaps barebones, etc. As long as you need root access to load firmware onto these other cores, there is no security issue. 

 

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

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. 

Regards,

John

--
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.

[William Hermans]

Personally, I could care less how many people use remoteproc, and I do not think it's all that important either. I do not recall ever seeing anyone ask how many people use uio_pruss either. But again, I think it's a moot point. The better software should win out, and for those who do not agree, they will use what they want anyhow. No one can stop them.

So who is this person that needs to stop fighting and conform to someone elses wishes ? Sorry pal, others beliefs aren't a dictatorship, *and* whose fighting ? Sounds like someone has built this up as something in their own mind, that it's not.

Also, it does not matter what is mainline, and what isn't. At least in this context to me it does not. I know that remoteproc really, has nothing to do specifically with TI hardware. I've seen really cool usages of remoteproc on multi core applications processors where 1 or more additional cores were used as bare metal cores. While 1 or more cores were running Linux. Personally, in my mind that's what remteproc is all about. But what doe this have to do with a specific bit of hardware that only one company has in their processors ? Nothing . . .

--

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.

[TJF]

Good morning John!

Am Donnerstag, 30. Juni 2016 17:13:34 UTC+2 schrieb john3909:

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.

Sorry, I disagree again. But this time it doesn't bother me, because your final proposal sounds like the solution most of us are looking for. Just some quotes:

Jason Kridner

I will work to enable uio_pruss functionality, and I think that is what you want, not just getting remoteproc out.

William Herman

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.

Rick Mann

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) ...

TJF

I'd try to make both optional and choise in device tree when enabling the PRUSS.

...


@All

From my point of view, we found a common solution and John proposed a way how to get it working, which sounds reasonable to me. Anybody contrary-minded? Any additional statements?

BR

[John Syne]

Here is a conversation I had with Robert about this issue:

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

I know this seemed like a painful process, but in the end it looks like this solution will work for everyone. Thank you everyone for your valuable input. 

Regards,

John

--
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.