pru remoteproc development examples for debian?

Hi All,

Is there a good example of developing using remoteproc on the beaglebone using only open source/free software? The docs at TI are really good, but rely on Code Composer Studio or PRU code generation tools etc.

I was hoping for something like this:



Yes there is:

The above support package includes two directories: examples and labs.
The examples are a bunch of “building blocks” which illustrate how to do various important sub-tasks with the PRU + remoteproc/rpmsg/virtio.

The instructions on the labs:

Use the above only as a general guide on the labs. The Beaglebone images already have the “CLI” (command line interface) PRU tools (C compiler etc) installed.

Look for the compiler named clpru. There are a couple of small hacks to get the Labs to “make” and run:

  1. You will need to add a bin directory and a soft link to the clpru binary from the CLI package directory. You need to find a directory like: /usr/share/ti/cgt-pru.
    The make file is looking for a bin with the clpru executable in it, but there isn’t one. So mkdir bin and ln -s (path to clpru).
  2. The make file will look for an environment variable PRU_CGT which points to /usr/share/ti/cgt-pru. I recommend adding this to your login set-up in .profile or however you do it.

You can set-up the GPIOs for PRU direct access using the Universal IO, an example command: config-pin P8.44 pruout

When you start up your board with the Debian image, try the lsmod command and see if you already have remoteproc drivers running.
You will need to use the commands dmesg, lsmod, rmmod -f, and insmod a lot.
I’m using one of Robert Nelson’s TI images, some of the details above may be slightly different with the “recommended” Debian image, but they will be similar.
I’ve noticed the remoteproc (and friends) driver names may different depending on which flavor and version of distribution you are using.

Good luck, the PRUs are very challenging, but I think very entertaining to program!

One thing I forgot:

I think the above is the latest-and-greatest (v2.1.2 November 2015) of the PRU tools.
You have to scroll down and look for

PRU Code Generation Tools Downloads

Get the Linux version which is a file:

This should get you all the stuff to develop on the command line, no IDE, no cross-compiler,
right on the Beaglebone!


Also almost forgot about the above, however, I have not tried using it.


Thanks Greg!

I did get the file at:

but got a little weirded out with the HUGE, legally binding contract that seems to say that you can’t distribute your source code, only executables when using that package.

I’ll definitely look over the other links you provided very carefully.

Many thanks for the direction!


That’s certainly discouraging! I haven’t got far enough along to share any code, so I don’t think I’m going to land in jail yet.

I think we should ask for clarification from the Beagleboard TI people.


It’s TI’s standard license… It’s referencing the “Licensed Materials” which include the compiler, it’s lib’s and header files…

But it is funny to read, if TI had not requested that i ship it by default in the image. There would be no way i could…


Ok, thanks-- no insurmountable legal issues for sharing your own PRU code. Beagleboard PRU fans, please start your code sharing engines!


Alright, I’m making some progress, but am having some issues:

  1. I can’t seem to get my device tree to change the mode of pins associated with the pruss, but other pins are configured correctly. Is there some kind of order that the PRU firmware and device tree has to load in?

/* Start EBB-PRU-Example.dts */


/ {
compatible = “ti,beaglebone”, “ti,beaglebone-black”;

part-number = “EBB-PRU-Example”;
version = “00A0”;

/* This overlay uses the following resources */
exclusive-use =
“P9.11”, “P9.13”, “P9.27”, “P9.28”, “pru0”;

fragment@0 {
target = <&am33xx_pinmux>;
overlay {

gpio_pins: pinmux_gpio_pins { // The GPIO pins
pinctrl-single,pins = <
0x070 0x07 // P9_11 MODE7 | OUTPUT | GPIO pull-down
0x074 0x27 // P9_13 MODE7 | INPUT | GPIO pull-down


pru_pru_pins: pinmux_pru_pru_pins { // The PRU pin modes
pinctrl-single,pins = <
0x1a4 0x05 // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU
0x19c 0x26 // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT | PRU


fragment@1 { // Enable the PRUSS
target = <&pruss>;
overlay {
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&pru_pru_pins>;

fragment@2 { // Enable the GPIOs
target = <&ocp>;
overlay {
gpio_helper {
compatible = “gpio-of-helper”;
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&gpio_pins>;

/* End EBB-PRU-Example.dts */

  1. I’ve got one of the TI examples compiled running as /lib/firmware/am335x-pru0-fw

dmesg seems to show that it loads successfully, without errors.

#include <stdint.h>
#include <pru_cfg.h>
#include “resource_table_empty.h”

volatile register uint32_t __R30;
volatile register uint32_t __R31;

void main(void)

uint32_t gpio;

/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */

/* gpio = 0x000F; /
gpio = (1 << 5); */
gpio = 0x0010;

__R30 = 0x0;

/* Toggle the LEDs /
TODO: Create stop condition, else it will toggle indefinitely */
while (1) {
__R30 ^= gpio;



As you can see, main is an infinite loop. This means that if I try to rmmod pru-rproc, I get the following error:
rmmod: ERROR: Module pru_rproc is in use

This means that I have to reboot in order to update the code. How do I either force the pru to unload or send it signals to stop so I don’t have to reboot everytime?

Thanks again!


Regarding the device tree, I’m using the “Universal IO” and the accompanying shell script config-pin and I haven’t had any configuration problems with the PRU pins.
There is an option for config-pin which reads a file and sets all of the pins per a list of the pins in the file. It works very well. You can put this command in your .profile or
whatever you do at boot time to set up the pins. I’ve found this system works flawlessly and saves a lot of time and confusion.

I have had to tweak the device tree source if a different pull-up/down resistor is required on a PRU input pin.

Regarding the rmmod problem, use the “force” option -f. This is actually recommended by TI.

I highly recommend creating simple bash scripts or aliases called “prumodout” and “prumodin” which execute the rmmod and insmod commands to remove
and insert your PRU firmwares. Taking it to the next step, you can use your prumod and prumodin commands in your build script so that the firmwares
are copied to the /lib/firmware directory, old firmwares removed and new firmwares loaded and started all in a single command.

You should be able to go through a modify-build cycle without reboot, and very quickly.


Good suggestions Greg! I didn’t know about rmmod -f. You learn something new every day!

I didn’t even know about config-pin until yesterday, since I’ve only ever used device trees in the past. I guess config-pin might actually be the best option for my stage of development, but I would like to get the PRU pins configured with device trees eventually, since that feels more like the right “embedded” thing to do :wink:


To clarify question 1 of my original post, I’m checking the pin mode settings with ‘cat $PINS’ and the PRU pins always show 0x27. I’m asking whether there are any other PRUSS specific requirements in the device tree itself or if the load order of the device tree overlay and firmware matter in order for the ‘$PINS’ file to show that the mode was changed to pru_r30_blah_blah.


I had the same problem with you. My device tree overlay won’t set the PRUSS. So I tried recompiling the the main boneblack overlay where my PRUSS pinmuxing is included and that solve the problem. However, I had to separate the GPIO and the PRU overlays because I can’t make the GPIO (OCP) overlay work when it is in the main boneblack overlay.


There are better ways then rmmod -f.

To reload a new firmware to PRU, you can just use /sys bindings.

Demonstrated here :

The same repository has some examples. And I am working on a few more.
Further, there are some tutorials on and there will be more soon.

As for the pin configuration problem,
‘Universal IO’ owns all the pins of the board, so your the pins in your device tree file must be conflicting with the Universal IO. You may check this in your dmesg.
To configure a pin you can mostly use config-pin
I have described its use here in the 2nd point under ‘startes’

Good Luck with PRUs. I will keep adding content and example to the above mentioned links as I move along with my project.

PS : you should probably disable the hdmi cape, if its not being used.

Nice! I will continue to monitor your pages for updates.
Do you know of other sources of how to use the /sys virtual files?


Hi Greg,

Yes, virtual file entries mounted at debugfs can be used to debug pru codes.

root@beaglebone:~# tree /sys/kernel/debug/remoteproc/remoteproc*

– name
– recovery
– state
– trace0
-- version /sys/kernel/debug/remoteproc/remoteproc1 -- name -- recovery -- regs -- single_step -- state – version
– name
– recovery
– regs
– single_step
– state
-- version

Though I haven’t tried it yet, will get into it soon :slight_smile:

  • ZeekHuge

Great! Thanks for the info, All. I’m getting somewhere now :slight_smile:

I’ve got more PRU questions, but will start a new thread since it’s not exactly related.

@ZeekHuge: Nice info on your website! It’s the website I wish I would have made after all of my stumbling around with PRUs.


Thanks for the great examples. They worked out of the box with the “4.4.11-ti-r29” kernel after I ran

export PRU_CGT=/usr/share/ti/cgt-pru

mkdir bin
cd bin
ln -s which clpru .
ln -s which lnkpru .

to get the paths to the compiler/linker right.

Nice web site too. When do you estimate having the other examples posted?