Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Here is a conversation I had with Robert about this issue: > From: Robert Nelson > Subject: Re: uio_pruss coexist with remoteproc > Date: June 30, 2016 at 11:43:29 AM PDT > To: John Syne > > Hi John, > > On Thu, Jun 30, 2016 at 12:57 PM, John Syne

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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.

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 30, 2016, at 2:11 AM, TJF 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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.

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 27, 2016, at 11:16 AM, William Hermans 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Fwd: [beagleboard] Ti's RPMsg Examples Significantly Changed

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: > > From: Przemek Klosowski <przemek.klosow...@gmail.com> > Subject: Re: [beagleboard] Ti's RPMsg Exam

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

On Mon, Jun 27, 2016 at 3:51 AM, TJF 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 >

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 27, 2016, at 1:49 AM, John Syne wrote: > > >> On Jun 27, 2016, at 12:51 AM, TJF > > wrote: >> >> @John3909: >> >> Am Sonntag, 26. Juni 2016 20:13:12 UTC+2 schrieb john3909: >> It makes no sense to discuss

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 27, 2016, at 12:51 AM, TJF 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 26, 2016, at 2:53 AM, TJF 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 25, 2016, at 7:45 PM, Rick Mann 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Been, seen. It's all the same ;) On Sat, Jun 25, 2016 at 8:51 PM, William Hermans wrote: > 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Doesn't it "discover" devices by looking at the device tree? > On Jun 25, 2016, at 18:32 , John Syne 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

#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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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 > On Jun 25, 2016, at 6:11 PM, Rick Mann

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 25, 2016, at 14:44 , John Syne wrote: > >> On Jun 25, 2016, at 2:20 PM, Rick Mann wrote: >> >> >>> On Jun 25, 2016, at 12:56 , John Syne wrote: >> On Jun 25, 2016, at 11:56 AM, Jason Kridner

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 25, 2016, at 2:20 PM, Rick Mann wrote: > > >> On Jun 25, 2016, at 12:56 , John Syne wrote: > >>> On Jun 25, 2016, at 11:56 AM, Jason Kridner >>> wrote: >>> >>> I will work to enable uio_pruss functionality, and

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 25, 2016, at 12:56 , John Syne wrote: >> On Jun 25, 2016, at 11:56 AM, Jason Kridner 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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 > On Jun 25, 2016, at 12:57 PM, William Hermans wrote: > > Also, instead of saying

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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. On Sat, Jun 25, 2016 at 12:35 PM, William

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 25, 2016, at 11:56 AM, Jason Kridner 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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 wrote: > > @John: > > ...

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

There, now everyone can clean their messy images . . . https://github.com/wphermans/bbb-cleanup/blob/master/beaglebone-cleanup.md On Sat, Jun 25, 2016 at 12:16 PM, William Hermans wrote: > @Jason Kridner > > I do not think anyone is asking to remove remoteproc, and replace

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

I will work to enable uio_pruss functionality, and I think that is what you want, not just getting remoteproc out. On Sat, Jun 25, 2016 at 10:39 AM TJF wrote: > @John: > > ... so what do you want removed? There is nothing left to be removed. >> > > I want removed: > > >

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 24, 2016, at 6:02 PM, Suman Anna wrote: > > 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,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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.

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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@0x1) and PRU DRAM = DRam

RE: [beagleboard] Ti's RPMsg Examples Significantly Changed

...@comcast.net] Sent: Thursday, June 16, 2016 8:07 PM To: BeagleBoard Cc: soapy-sm...@comcast.net; jkrid...@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. I am

RE: [beagleboard] Ti's RPMsg Examples Significantly Changed

Hi TJF, My responses inlined.. Regards Suman From: John Syne [mailto:john3...@gmail.com] Sent: Friday, June 17, 2016 12:44 PM To: beagleboard@googlegroups.com Cc: Reeder, Jason; jkrid...@beagleboard.org; Anna, Suman Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed On Jun 17

RE: [beagleboard] Ti's RPMsg Examples Significantly Changed

com> Cc: Reeder, Jason; jkrid...@beagleboard.org<mailto:jkrid...@beagleboard.org>; Anna, Suman Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed On Jun 17, 2016, at 7:17 AM, TJF <jeli.freih...@gmail.com<mailto:jeli.freih...@gmail.com>> wrote: @John Syne:

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

6 12:44 PM > To: beagleboard@googlegroups.com <mailto:beagleboard@googlegroups.com> > Cc: Reeder, Jason; jkrid...@beagleboard.org > <mailto:jkrid...@beagleboard.org>; Anna, Suman > Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed > > On Jun 17, 2016, at 7:17

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 17, 2016, at 7:17 AM, TJF 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!

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@John Syne: Correct, remoteproc is stabil since month. Stabil in the point that it isn't usable. And that's why it is and it should be experimental. And experimental features shouldn't polute the main stream images! @Jason Reeder and Suman Anna: Thanks for joining that discussion and for

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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 > On Jun 16, 2016, at 6:19 PM,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

On Thu, Jun 16, 2016 at 6:17 PM, Anna, Suman 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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. On Thu, Jun 16, 2016 at 6:19 PM, William Hermans wrote: > @ Jason Reeder > > I have seen much of your documentation

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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 > > > > *From:* Greg [mailto:soapy-sm...@comcast.net] > *Sent:* Thursday, June 16, 2016 6:01 PM > *To:* Bea

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

RE: [beagleboard] Ti's RPMsg Examples Significantly Changed

over interrupts). This is what Jason was referring to as v5.0.0. Regards Suman From: Greg [mailto:soapy-sm...@comcast.net] Sent: Thursday, June 16, 2016 6:01 PM To: BeagleBoard Cc: jkrid...@beagleboard.org; Anna, Suman; Reeder, Jason Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

>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 > On Jun 16, 2016, at 4:00 PM, Greg wrote: > > Hi Jason- >

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 16, 2016, at 2:42 PM, Jason Kridner 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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Regards, John > On Jun 16, 2016, at 2:40 PM, Jason Reeder 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,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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? On Thu, Jun 16,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Pollute away: https://github.com/wphermans/am335x_pru_package On Wed, Jun 15, 2016 at 5:23 PM, William Hermans wrote: > So in other words, Before you ruin a perfectly good git, someone needs to > fork it. > > On Wed, Jun 15, 2016 at 2:46 PM, Jason Kridner < >

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

So in other words, Before you ruin a perfectly good git, someone needs to fork it. On Wed, Jun 15, 2016 at 2:46 PM, Jason Kridner wrote: > How is it nonsense? > On Wed, Jun 15, 2016 at 10:59 AM William Hermans > wrote: > >> *Please don't

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

How is it nonsense? On Wed, Jun 15, 2016 at 10:59 AM William Hermans wrote: > *Please don't pollute the* *am335x_pru_package with remoteproc nonsense! >> Better create a separate package with a new name.* >> > > I second that. > > On Wed, Jun 15, 2016 at 7:44 AM, TJF

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> > *Please don't pollute the* *am335x_pru_package with remoteproc nonsense! > Better create a separate package with a new name.* > I second that. On Wed, Jun 15, 2016 at 7:44 AM, TJF wrote: > Am Mittwoch, 15. Juni 2016 14:35:12 UTC+2 schrieb Jason Kridner: >> >>

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

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

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Thanks for the tip! Anyone look at migrating these into the http://github.com/beagleboard/am335x_pru_package repo/package? On Tue, Jun 14, 2016 at 7:13 AM Greg wrote: > I've been experimenting with the PRU support package, and noted this > significant change to the

[beagleboard] Ti's RPMsg Examples Significantly Changed

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