John, make your own post and post there. On Mon, Dec 14, 2015 at 2:27 AM, William Hermans <[email protected]> wrote:
> *Is there a new branch of the am335x_pru_package using remoteproc that >> I've missed? alternatively does anyone know what i would have to include to >> get uio back up and running again without changing kernels? I'm trying to >> keep my software package as a fairly simple install that runs on all stable >> "latest-images." It's already a bit of a fuss having to modify and >> recompile the am335x-boneblack.dtb file for each image just to tweak i2c >> speeds.* >> >> *thank you for any and all help!* > > > You have to change kernels. You *may* be able to recompile a TI kernel to > do the same thing as I've shown above, but I know for a fact a *bone image > will work. I recall someone saying previously that TI's kernel can no > longer be made to use uio_pruss, but perhaps that's within the context of > .config options ? > > Another thing. version numbers between these kernels means nothing. There > are a few things the TI kernel does thatthe bone kernel does not. But > unless you're using thee features, who cares ? > > On Mon, Dec 14, 2015 at 2:11 AM, John Syne <[email protected]> wrote: > >> William, you are over thinking this. It isn’t that complicated. If you >> don’t want to take the time to learn something new, then don’t, but don’t >> bad mouth something you don’t understand. There are enough examples and >> documentation out there if you only take the time to look, which is the >> advise you give all the time. RemoteProc/Virtio/RPMSG are a standardized >> way to load code into a remote processor, start/stop that code and exchange >> events/messages between processors. Once you understand that, you can >> create code that can do almost anything, including the examples you listed. >> >> >> Regards, >> John >> >> >> >> >> On Dec 13, 2015, at 4:05 PM, William Hermans <[email protected]> wrote: >> >> It's a BS example because it does not illustrate how remoteproc and rpmsg >> are useful. It also does not illustrate how to access the hardware modules >> through this technology. Here . . . >> >> Something useful -> https://github.com/boxysean/beaglebone-DMX >> Something else useful -> https://github.com/pgmmpk/beaglebone_pru_adc >> Yet another something useful -> >> https://github.com/abhishek-kakkar/BeagleLogic >> >> All these have been in the wild for a long time. They work, and the >> hardware / software paradigm is well known, and explained many times all >> over the web. >> >> Show us how to blink USR0, then explain how that works. Or even show us >> how to use any on die hardware module, or something that can be "plugged >> in" to demonstrate an immediate result. Without having to hook up external >> electronics / circuits. >> >> That is why uio_pruss is better than remoteproc. People understand it, or >> if they do not, they can read about it, and grasp the concept fairly >> quickly. Because there is a lot of good documentation, and many, many good >> examples that cover just about any on die hardware module. >> >> Anyway, I think the burden is actually on you, to explain to me, and >> others why remoteproc / rpmsg is any good and should be used. Since, >> uio_pruss has been around since 2011 or earlier, and is perfectly >> functional. With that said, regurgitating sentiments such as "bla blah blah >> has adopted x.y.z" is going to do you no good. We do not care who as >> adopted what, and why. We want to know why remoteproc, and rpmsg is worth >> out time investment. Especially considering we already have a large time >> investment with uio_pruss. >> >> On Sun, Dec 13, 2015 at 4:40 PM, John Syne <[email protected]> wrote: >> >>> How is that a BS example? The example shows an ARM kernel module sending >>> a message to the PRU, which interrupts the PRU, which then copies the >>> message from the PRU rx buffer to the PRU tx buffer, which then executes a >>> callback on the ARM kernel module. You should be able to take that code and >>> make it do anything you need. >>> >>> Regards, >>> John >>> >>> >>> >>> >>> On Dec 13, 2015, at 3:21 PM, William Hermans <[email protected]> wrote: >>> >>> By real world I mean a real world useful example. Not some BS spit 100 >>> "hello" messages out into dmesg. >>> >>> On Sun, Dec 13, 2015 at 4:19 PM, William Hermans <[email protected]> >>> wrote: >>> >>>> OK, so show us a real world example of rpmsg. >>>> >>>> On Sun, Dec 13, 2015 at 3:53 PM, John Syne <[email protected]> wrote: >>>> >>>>> OK, so maybe you can explain why you think there is a difference >>>>> between writing PRU firmware targeting PRUSS vs PRU firmware targeting >>>>> remoteproc? The only difference is the API. You can build the firmware for >>>>> each in the same way. The only reference to CCSV6 is the examples TI >>>>> created for remoteproc. Someone updated those examples to build with GCC. >>>>> So I don’t understand what you mean by forced to use “close source tools”. >>>>> Nothing in remoteproc is closed source. All remoteproc does is load the >>>>> firmware on the PRU and then start the code. virtio_rpmsg_bus handles the >>>>> communications between ARM and the PRU. >>>>> >>>>> Regards, >>>>> John >>>>> >>>>> >>>>> >>>>> >>>>> On Dec 13, 2015, at 12:43 PM, William Hermans <[email protected]> >>>>> wrote: >>>>> >>>>> We're not talking about the X15 in this post, and personally, I >>>>> probably won't be using an X15 for a long, long time. Too much board, for >>>>> too much money. >>>>> >>>>> On Sun, Dec 13, 2015 at 1:30 PM, John Syne <[email protected]> wrote: >>>>> >>>>>> Remoteproc/RPMSG is a standard in mainline for interfacing ARM to >>>>>> other processors on the same SOC. On the x15, this will be the only way >>>>>> you >>>>>> can interface to the DSP, M4’s, etc. Other vendors have adopted this >>>>>> solutions as well. >>>>>> >>>>>> Regards, >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Dec 13, 2015, at 12:25 PM, William Hermans <[email protected]> >>>>>> wrote: >>>>>> >>>>>> So, not to argue, but my point of view. I have no problem with people >>>>>> using remoteproc, *if* that's what they want to do. At the same time, I >>>>>> feel that it should not be "forced down our throats", because right now, >>>>>> it >>>>>> is not ready for prime time. uio_pruss is a known quantity, lots of >>>>>> people >>>>>> have documented their use of it, and remoteproc is barely documented at >>>>>> all. Passed that, from what I've seen so far, only closed source tools >>>>>> can >>>>>> be used with remoteproc, on the beaglebones. >>>>>> >>>>>> I did see someone post a gcc "port" of one of Jason Reeders guides . >>>>>> . . but no mention of toolchain setup, or anything else. >>>>>> >>>>>> So until documentation is up to snuff, and we're not forced to use >>>>>> close source tools. I'll always consider remoteproc as something not to >>>>>> be >>>>>> used seriously. I'm sure I'm also not alone. >>>>>> >>>>>> On Sun, Dec 13, 2015 at 1:17 PM, William Hermans <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> *With newer kernels, you need to use the standard Linux remote-proc* >>>>>>>> * interface, rather than the legacy UIO driver.* >>>>>>> >>>>>>> >>>>>>> Not exactly. Only if you're using the *TI kernels. The *bone kernels >>>>>>> have uio_pruss enabled. >>>>>>> >>>>>>> >>>>>>> william@beaglebone:~$ *uname -r* >>>>>>> 4.1.12-bone-rt-r16 >>>>>>> william@beaglebone:~$ *sudo sh -c "echo 'pru_enable' > >>>>>>> /sys/devices/platform/bone_capemgr/slots"* >>>>>>> william@beaglebone:~$ *./ti/lsuio-0.2.0/lsuio* >>>>>>> uio7: name=pruss_evt7, version=1.0, events=0 >>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>> uio6: name=pruss_evt6, version=1.0, events=0 >>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>> uio5: name=pruss_evt5, version=1.0, events=0 >>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>> uio4: name=pruss_evt4, version=1.0, events=0 >>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>> uio3: name=pruss_evt3, version=1.0, events=0 >>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>> uio2: name=pruss_evt2, version=1.0, events=0 >>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>> uio1: name=pruss_evt1, version=1.0, events=0 >>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>> uio0: name=pruss_evt0, version=1.0, events=0 >>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>> >>>>>>> The pru_enable device tree file is pretty simple too: >>>>>>> >>>>>>> /dts-v1/; >>>>>>> /plugin/; >>>>>>> >>>>>>> / { >>>>>>> compatible = "ti,beaglebone", "ti,beaglebone-black"; >>>>>>> >>>>>>> /* identification */ >>>>>>> part-number = "pruss_enable"; >>>>>>> version = "00A0"; >>>>>>> >>>>>>> fragment@0 { >>>>>>> target = <&pruss>; >>>>>>> __overlay__ { >>>>>>> status = "okay"; >>>>>>> >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> }; >>>>>>> >>>>>>> Also, yes, everything works fine. I've tested various PRU git >>>>>>> projects, and they all seem to work fine. >>>>>>> >>>>>>> >>>>>>> On Sun, Dec 13, 2015 at 9:30 AM, Charles Steinkuehler < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> On 12/13/2015 4:37 AM, Strawson wrote: >>>>>>>> > Sadly I'm running into the same missing uio directories now that >>>>>>>> I'm trying >>>>>>>> > to get my beaglebone code that was stable on the 3.8 kernel and >>>>>>>> Wheezy >>>>>>>> > image. My old compiled dtbo wouldn't load with a 4.1 kernel until >>>>>>>> it was >>>>>>>> > recompiled. Even with it loaded, the following modules don't >>>>>>>> load: PRU, >>>>>>>> > eQEP, PWM, and GPIO_buttons. I spent today hacking together >>>>>>>> workarounds for >>>>>>>> > the latter 3, but the PRU still has me stumped. >>>>>>>> > >>>>>>>> > Looking closely, the am335x-boneblack.dtb file has changed quite >>>>>>>> a bit. >>>>>>>> > Once decompiled I have the following entries for the PRUSS: >>>>>>>> >>>>>>>> With newer kernels, you need to use the standard Linux remote-proc >>>>>>>> interface, rather than the legacy UIO driver. >>>>>>>> >>>>>>>> -- >>>>>>>> Charles Steinkuehler >>>>>>>> [email protected] >>>>>>>> >>>>>>>> -- >>>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "BeagleBoard" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "BeagleBoard" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "BeagleBoard" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
