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/7abf9a12-c3b6-4b40-8e16-f3687ce06b89%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
