So I finally got some time to work with the PRUs again. I still seem to be having some issues with remoteproc. I got the c code for PRU0 to compile and I moved it to /lib/firmware under the correct name. I also followed the steps outlined in the e-linux exercise for enabling remote_proc as well as the steps outlined in greg's PDF. I can't seem to get the remoteproc to activate. Whenever I pole "/sys/bus/platform/devices" the only pru related name I get out is "ocp:pruss@4a300000". The device not showing up also means when I try to echo the enable command to bind I get a "No such device" error.
Any suggestions on how to get remote_proc activated and working? Also the program flow as I understand is the pru code needs to be compiled and placed in /lib/firmware under the correct name. Once the remote_proc is activated once by doing a small device tree alteration I just have to call modprobe pru_rpoc to turn it on. From there I can echo "4a334000.pru0" to the bind folder and the code that was loaded onto the pru when remote_proc was enabled will execute? Zach On Tuesday, November 15, 2016 at 2:29:46 PM UTC-5, Greg wrote: > > Remoteproc and RPMsg are kernel modules. Remoteproc/RPMsg live in the > kernel, but they can communicate with user space via character device files > and the sysfs virtual file system. > > The PRUSSDRV is totally different, not related to Remoteproc in any way to > my knowledge. > > Best introductory page on Remoteproc and RPMsg is: > > http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg > > If you look at the Remoteproc examples, the "user space" C program > reads/writes to a character device file in /dev. > > I'm not sure what is going on with the GPIO coming out of boot high. If > you look at the C code for the example firmwares, a lot of them set __R30 = > 0 right away and this would pull out the pruouts to low. If the PRUs are > inactive, not sure what defines the state. You could switch the pin mode > to pruout after the firmware is running and the pruout is deterministically > set to LOW. Might work, easy enough to try. > > On Tuesday, November 15, 2016 at 1:16:43 PM UTC-5, Zach B wrote: >> >> I understand that bringing up GPIOs low is good practice. I meant when I >> set the P8_11 using "config-pin P8_11 pruout" the pin is automatically >> pulled high it appears. Is there a way to set it as a "pruout" but as a low >> pruout to start. It appears to be defaulting to "HI" mode when set to >> "pruout" >> >> Also I had thought that remoteproc was a program with an interface that >> allowed the user to load a compiled program to the PRU when the host c >> script was run, I didn't realize it only kicked in at initialization and >> loaded specific files in /lib/firmware. I was origianlly under the >> assumption that I needed to enable the remote_proc and uio_pruss and then >> use the following API in order to load and run the PRU program. >> >> >> http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide#prussdrv_map_prumem >> >> >> Am I over complicating things? Also I have been avoiding use CCS because >> I wanted to avoid dependencies on automatic tools that abstract away what >> is running and how. >> >> -- 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/4480a92b-03b7-45b5-aea7-b5fafda20fc4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
