. . . And my god, what is this supposed to be ? C ? https://github.com/dinuxbg/pru-gcc-examples/blob/master/blinking-led/pru/resource_table_0.h#L43-L72
On Sun, Dec 13, 2015 at 5:22 PM, William Hermans <[email protected]> wrote: > I actually think remoteproc / rpmsg is usefu for multi core systems. Say a > dual core ARM processor where one core is running Linux, and the other is > running bare metal for <whatever> deterministic purpose. I am however still > unconvinced how it is useful when you have multiple cores on die that are > not all application based processors. Such as the PRUs, or on die M4 / IPU > on the X15's processor. DSP . . . yeah I do not know enough about those to > make that call. > > On Sun, Dec 13, 2015 at 5: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.
