> On Nov 15, 2016, at 8:06 AM, Greg <[email protected]> wrote: > > > Just my advice, especially for a newbie PRU person (maybe even an experienced > one too), don't touch the Device Tree! At least not directly: > > https://github.com/cdsteinkuehler/beaglebone-universal-io > > (Note the path to slots is not the same for 4x kernels) > > I've been using the Debian 8.6 IOT image and the "Universal IO" is already > installed, ready to work its magic. > Follow the directions at the above repository. This will save you much time > fiddling with the Device Tree stuff, highly recommended! > The config-pin utility is AWESOME, try it! > > One thing config-pin can't do. And that is change the pull-up/pull-down > settings on the pads. In that case you may have to tweak a device tree. > But this is relatively simple and won't waste piles of your time debugging. > > Another something to be aware of which can burn time like no tomorrow: > Header P8. There are pins on this header which determine how > the boot process proceeds. Not all of them, but some of the overlap possible > PRU IO. I would avoid these if you can! Use config-pin and > set your PRU IO to pins on header P9 as required. Some pins on P8 are safe, > but proceed with caution. > Even light resistive loading on these pins will corrupt the boot process! > > You can go to the Beaglebone Black system reference manual to see this: > > http://elinux.org/Beagleboard:BeagleBoneBlack#Hardware_Files > > Check out page 68, diagram Figure 38. Note the "LCD_DATA" pins. > Then go to page 84, and you can see which pins on P8 to avoid. > There are probably enough PRU IO possible to route to P9 for many projects. > > I think prussdrv is a UIO related kernel module, not Remoteproc related. I > don't recall seeing that one. > Activation of Remoteproc may not have happened. Use lsmod and look for > pru_rproc, pruss, and pruss_intc. > > With regards to manually running Remoteproc, you can > > modprobe pru_rproc > > to insert and start Remoteproc and > > rmmod pru_rproc > > to remove it (using root privilege). > > To stop and start firmwares already loaded into the PRUs: > > echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind > echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/bind > > echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/unbind > echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/unbind > > So this is the Debian image I am using successfully: > > bone-debian-8.6-iot-armhf-2016-10-30-4gb.img
Shouldn't be any deltas, but can you use 2016-11-06 from https://beagleboard.org/latest-images because we are standardizing on that image for a while and pushing manufacturers to shift to it in production. > > Get that here: > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian > > Once again, using the above image, don't touch device tree files (except one > very trivial change to activate Remoteproc) and use config-pin to change pin > modes to PRU. All ready to go on this image. > Get Remoteproc activated and see if you can get the Remoteproc related kernel > modules to appear in lsmod. > > I've attempted to very carefully describe the process in the PDF file here > and did a bunch of updates last weekend: > https://github.com/Greg-R/pruadc1/tree/master/doc/PRUADC1latex > > Regards, > Greg > >> On Monday, November 14, 2016 at 10:17:40 PM UTC-5, Zach B wrote: >> Hey everyone so I took one step forward and one step back. With the last bit >> of help from Robert I was able to properly disable the universal overlay and >> load my own. It appears that my device overlay loads correctly. When I went >> to test things today however I can't seem to get the remote_proc to turn on >> by following the elinux example like last time. I follow all of the steps. I >> get no errors, but nothing happens. I haven't looked through the boot dmesg >> yet so it could be in there. Is there another way to manually turn on the >> remote_proc? >> >> On a different note after reading some of your comments I am a bit confused. >> Is the device tree overlay the proper way to go about setting the header >> pins to the PRU or not? Also is there a command line method to working with >> the PRUs that would let me test the pins to ensure they are working? >> >> I tried compiling a simple c script to run the PRU but I keep getting the >> error pruss/prussdrv.h: no such file or directory. Are the pruss files >> something that needs to be included on my LIBRARY path or LD_LIBRARY path or >> is it an extra package I need to download? >> >>> > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/3fbe8061-3943-4180-b56a-d8998af92af9%40googlegroups.com. > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/28F47E10-5A1A-4782-B75B-77B593B7AF17%40gmail.com. For more options, visit https://groups.google.com/d/optout.
