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:
https://github.com/beagleboard/am335x_pru_package
Thanks!
–David
Yes there is:
https://git.ti.com/pru-software-support-package
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:
http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_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:
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!
Greg
One thing I forgot:
http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#PRU
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
Get the Linux version which is a file:
ti_cgt_pru_2.1.1_linux_installer_x86.bin
This should get you all the stuff to develop on the command line, no IDE, no cross-compiler,
right on the Beaglebone!
Greg
https://github.com/dinuxbg/gnupru
Also almost forgot about the above, however, I have not tried using it.
Greg
Thanks Greg!
I did get the file at:
http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#PRU
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!
–David
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.
Greg
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…
Regards,
Ok, thanks-- no insurmountable legal issues for sharing your own PRU code. Beagleboard PRU fans, please start your code sharing engines!
Greg
Alright, I’m making some progress, but am having some issues:
/* Start EBB-PRU-Example.dts */
/dts-v1/;
/plugin/;
/ {
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 */
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 */
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
/* 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;
__delay_cycles(100000000);
}
}
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!
–David
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.
Regards,
Greg
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 
–David
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.
Thanks!
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.
Hi,
There are better ways then rmmod -f.
To reload a new firmware to PRU, you can just use /sys bindings.
Demonstrated here :
https://github.com/ZeekHuge/BeagleScope/blob/master/examples/firmware_exmples/pru_blinky/deploy.sh#L66
The same repository has some examples. And I am working on a few more.
Further, there are some tutorials on https://zeekhuge.github.io 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’
https://zeekhuge.github.io/post/a_handfull_of_commands_and_scripts_to_get_started_with_beagleboneblack/#k_dev:01d25bfd2399ec47b9c04f156786eab8
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?
Regards,
Greg
Hi Greg,
Yes, virtual file entries mounted at debugfs can be used to debug pru codes.
https://github.com/ZeekHuge/BeagleScope/blob/master/docs/current_remoteproc_drivers.notes#L212
`
root@beaglebone:~# tree /sys/kernel/debug/remoteproc/remoteproc*
/sys/kernel/debug/remoteproc/remoteproc0
– name
– recovery
– state
– trace0
-- version /sys/kernel/debug/remoteproc/remoteproc1 -- name -- recovery -- regs -- single_step -- state– version
/sys/kernel/debug/remoteproc/remoteproc2
– name
– recovery
– regs
– single_step
– state
-- version
Though I haven’t tried it yet, will get into it soon 
Great! Thanks for the info, All. I’m getting somewhere now
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.
–David
ZeekHuge:
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
cd $PRU_CGT
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?
–Mark