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 mo

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 PRU system event

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 on the ti wiki pages,

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

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

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

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] Mini jack port disable

> > 1. Disable serial port and networking comms through this port -- HOW? > The driver that accomplishes serial and USB networking is known as g_multi. You simply make sure the module does not load. > 2. Disable the hardware port altogether (best option) -- HOW? This part, I'm not so sure abo

Re: [beagleboard] uio_pruss on linux-ti 4.4.12

> > Anyway, I would be glad if someone provided some clarity how am I > supposed to configure DT and uio_pruss driver properly for PRU to work. > Use a *bone* kernel, and not a *ti* kernel. This has already been discussed on these forums several times. It has to do with how the kernels are configu

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

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 som

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- > > I'm confused and I hop

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 an assembler. > > More resp

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 5

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, but I hadn’t noticed the

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 wrote: > L

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 i

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

[beagleboard] Re: Crontab

On Thursday, June 16, 2016 at 3:31:18 PM UTC-4, Akash Gajeshwar wrote: > > Hello everyone, I have been trying to execute cronjobs with same time of > execution, but it does not work that way since they run in parallel. So is > there a way can perform sequential execution of tasks with same time

[beagleboard] uio_pruss on linux-ti 4.4.12

Hi all, I am building a distro for beaglebone based on openembedded, I am using kernel from meta-ti, which I want to configure to support uio_pruss driver. I am applying following patch to kernel [1]. With this, when DT node for pruss is enabled, the driver loads correctly, only displaying one m

[beagleboard] uio_pruss on linux-ti 4.4.12

Hi all, I am building a distro for beaglebone based on openembedded, I am using kernel from meta-ti, which I want to configure to support uio_pruss driver. I am applying following patch to kernel [1]. With this, when DT node for pruss is enabled, the driver loads correctly, only displaying one mes

[beagleboard] Mini jack port disable

I have a need to disable communications on the mini-jack USB port on the BBB. We've had some folks actually epoxy the port to make sure no one could use it (a security thing). However, I'd like to just disable it through software. Note, I still need to use the full sized USB port for other

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 alrea

Re: [beagleboard] Crontab

On Thu, Jun 16, 2016 at 2:31 PM, Akash Gajeshwar wrote: > Hello everyone, I have been trying to execute cronjobs with same time of > execution, but it does not work that way since they run in parallel. So is > there a way can perform sequential execution of tasks with same time of > execution? > I

[beagleboard] Crontab

Hello everyone, I have been trying to execute cronjobs with same time of execution, but it does not work that way since they run in parallel. So is there a way can perform sequential execution of tasks with same time of execution? I did add the same time in crontab, but that makes it execute in

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

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 of

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

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 fir

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 t

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 ho

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

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 c

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 Virtio/R

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 am335x_pru_pa

Re: [beagleboard] Re: Is there Beaglebone Black Guide for LED diagnostics?

oh ok! thanks. I'll buy it! On Wednesday, June 15, 2016 at 12:37:46 PM UTC-6, William Hermans wrote: > > *Flash using one of the official images to make sure everything is working >> fine.* >> >> *Gerald* > > > And then buy a serial debug cable. That's what they are for. > Troubleshooting . . .

Re: [beagleboard] getting timestamp in kernel

Hi I am no Kernel Programmer;), however I guess what u are looking for is: gettimeofday() e.g. #include #include void main() { struct timeval tv; gettimeofday(&tv, NULL); unsigned long long millisecondsSinceEpoch = (unsigned long long)(tv.tv_sec) * 1000 + (unsigned long long)(tv.tv_usec

Re: [beagleboard] New eMMC with 3.8.13 kernel

At first I was disappointed that the BBG circuit board revision had not changed. However, it was really a software issue and the boards can be differentiated by the eMMC chip marking: Part Number FBGA Code (Marking) OLDMTFC4GACAAAM-1M WT JWA57 NEW

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 of