Beaglebone Black PRU Troubles

I have spent a solid 12 hours trying to get the PRU’s on the beaglebone to work. So far I seem to be completely stuck at the getting the device overlay to work as well as enabling the remoteproc. I have tried to piece together all of the information I have found on the internet but it is either out of date or extremely fragmented. I can’t seem to find a current working example or I hit a wall when following along as said previously.

Setup/Environment
I have updated the kernel on the beaglebone followed by multiple “updates”, “upgrades” and “dist-upgrades”. As far as I can tell I am using the most recent version of everything.

  • Beaglebone Black
  • Debian 8.6
  • kernel 4.4.30-ti-r64
  • dtc 1.4.1
    Sample Code
    Device Overlay File [PRU-GPIO-BLINK-00A0.dts]:

`
// Setup file for basic PRU GPIO Blinking LED

/dts-v1/;
/plugin/;

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

part-number = “PRU-GPIO-BLINK”;
version = “00A0”;

// This overlay uses the following resources
exclusive-use = “P8.12”;

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

gpio_pins: pinmux_gpio_pins {
pinctrl-single,pins = <
0x034 0x06

;
};
};
};

fragment@1 {
target = <&pruss>;
overlay {
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&gpio_pins>;
};
};
};
`

The above code compiles using:

root@beaglebone:/lib/firmware# dtc -O dts -o /lib/firmware/PRU-GPIO-BLINK-00A0.dtbo -b 0 -@ PRU-GPIO-BLINK.dts

When I go to add this to the bone_capemgr using:

root@beaglebone:/lib/firmware# echo "PRU-GPIO-BLINK" > /sys/devices/platform/bone_capemgr/slots

I end up getting either a “No Such File or Directory” error or a “File Exists” error. I have disabled the HDMI in uEnvt.txt like many people have recommended by simply uncommenting the line:


dtb=am335x-boneblack-emmc-overlay.dtb

On top of the above I tried following the exercise here: http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg
I make it through most of that exercise, up until I hit the enabling the remoteproc portion. When I go to “uncomment”
#include "am33xx-pruss-rproc.dtsi
I can’t seem to find it anywhere in the file. When I simply add the line to the file and try calling make the compiler complains that it can’t find the file and fails the build.

If anyone is curious here is the output when I run
cat /sys/devices/platform/bone_capemgr/slots

0: PF---- -1 1: PF---- -1 2: PF---- -1 3: PF---- -1 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,univ-emmc

Question
Does anyone have any suggestions as to why my device overlay is not working and I can’t follow along with the exercise on elinux? I am pretty much stuck at this point and most of the examples online reference out of date pathing or approaches. Is there a package that I am missing? From what I have read it seems like all of the compilers and loaders come built into the new beaglebone distributions now. If anyone needs clarification or I forgot to mention something I will be happy to provide it.

With the elinux article, make sure /opt/source/dtb-4.4-ti is up-to-date..

cd /opt/source/dtb-4.4-ti ; git pull

Regards,

I think I know exactly what is wrong. You need to activate the Remoteproc PRU framework. This is no longer active by default.
Robert Nelson’s script which is available via Github repository will fix the problem.

I have been working on detailed documentation of the entire process to activate the framework and set up the C compiler:

https://github.com/Greg-R/pruadc1

More specifically, look at this PDF file:

https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf

Go to the chapter “Setting Up the Remoteproc PRU and Compiler on the Beaglebone Green”.

Now, the chapter is not completely finished. I am still seeing a problem with the configuration
At boot, the PRU firmwares are not starting correctly. I don’t understand why this is.

However, you can do this:

rmmod pru_rproc

and then

modprobe pru_rproc

The firmwares will start running.
More investigation, required, but at least there is some path to getting things working for now.

I will do some more work on this later today.

Regards,
Greg

Thanks Robert! I’ll give that a try when I get a chance later today. Will that possibly also solve my issue with my device overlay not applying to the slot. Everything I have looked at says that there should be no error messages when applying the overlay but that’s all I get.

Zach

I think I know exactly what is wrong. You need to activate the Remoteproc
PRU framework. This is no longer active by default.
Robert Nelson's script which is available via Github repository will fix
the problem.

I have been working on detailed documentation of the entire process to
activate the framework and set up the C compiler:

GitHub - Greg-R/pruadc1: Beaglebone Green and PRU "Programmable Real-Time Unit" Interface to ADC using RemoteProc and RPMsg Framework

More specifically, look at this PDF file:

pruadc1/doc/PRUADC1latex/PRUADC1.pdf at master · Greg-R/pruadc1 · GitHub

Go to the chapter "Setting Up the Remoteproc PRU and Compiler on the
Beaglebone Green".

Now, the chapter is not completely finished. I am still seeing a problem
with the configuration
At boot, the PRU firmwares are not starting correctly. I don't understand
why this is.

Probably because the device tree file you're trying to load at boot is not
in the initramfs.

The problem is common to both boards, one with kernel a few months old, and another newer one:

Older:
4.4.12-ti-r31

Newer:
4.4.27-ti-r62

The older board I have used for many hours of experimentation with the Remoteproc/PRUs, and never had a problem.
I never noticed the firmwares were not starting at boot!

Looking at dmesg, these lines stand out:

[ 4.746736] ti-pruss 4a300000.pruss: creating PRU cores and other child platform devices
[ 4.747946] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 !
[ 4.748539] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 !

And then a bunch of lines indicating that the firmwares did not load and start, here are the lines for PRU0:

[ 4.796962] remoteproc1: 4a334000.pru0 is available
[ 4.796990] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 4.796999] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 4.797306] remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -2
[ 4.797326] remoteproc1: failed to load am335x-pru0-fw
[ 4.832461] pru-rproc 4a334000.pru0: booting the PRU core manually
[ 4.832497] remoteproc1: powering up 4a334000.pru0
[ 4.832614] remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -2
[ 4.832630] remoteproc1: request_firmware failed: -2
[ 4.837857] pru-rproc 4a334000.pru0: rproc_boot failed
[ 4.959415] remoteproc1: releasing 4a334000.pru0
[ 4.959590] pru-rproc: probe of 4a334000.pru0 failed with error -2

There was a change a while back from “mailboxes” to system interrupts. Hmmmmm…

But even after all of this, the PRUs can be started up using either modprobe pru_rproc, or commands to sysfs:

echo “4a334000.pru0” > /sys/bus/platform/drivers/pru-rproc/bind
echo “4a338000.pru1” > /sys/bus/platform/drivers/pru-rproc/bind

So the above commands could be put in .profile or other start-up sequence, but still would like to root cause the kernel log messages.

Regards,
Greg

I think your device tree overlay is not quite right, I see P8.11 set as mode 6 with internal pull down, but you’ve set exclusive use on P8.12.

I usually use http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator to look up pinmux settings because it’s easier and less error prone than doing it manually.

For reference because it’s not especially easy to find, the pinmux register bits are defined in the AM335x TRM section 9.2.2, page 1356. My version is dated Feb. 2015, TI doc # SPRUH73L.

Hey everyone, I wanted to give an update. I got the remote_proc to turn on last night. It was as simple as updating my repo like Robert had mentioned. I also made the correction that Brett mentioned about the pins. There is still something wrong in my device overlay file that is causing an “invalid arguement” error but I am going to try and sort that out tonight. I’ll post again with the corrected version once I get it working and can use the PRU.

Thanks again for your help.

Once you get everything solid, please take a look at dmesg after boot.
I’m curious to see if you get successful PRU firmware start-up.

Greg

Hi everyone,

So I messed around with my beaglebone a little bit last night. I worked out the issues in my device tree source file so it is now compiled but I can’t seem to get anything to echo properly to “slots”
I compile my “.dtb” file but when I go to call the comman:
`
echo PRU-GPIO-BLINK > /sys/devices/platform/bone_capemgr/slots

`
I continually get the error:

`
-bash: echo: write error: No such file or directory

`
Is there are a different way to enable my device overlay or set the pins to the correct mode for the PRU? I have even tried copying, compiling and attempting to export the device tree overlay example from adafruit and still no luck.

The names of my files in /lib/firmware are as follows:

`
PRU-GPIO-BLINK.dts
PRU-GPIO-BLINK-00A0.dtb

`
The part-number name in the .dts file is “PRU-GPIO-BLINK”. Am I still missing something? I can post the updated “.dts” file if it would help.

P.S. I have two questions since I am still relatively new at this:

  1. What is a blacklist and why was it necessary to export to the .conf file to enable the remote_proc?
  2. What is dmesg and where do I check them? Are you referring to “/var/log/syslog”?

Zach

I wanted to add on to this that when I switch the Device Tree Blob file extension to “.dtbo” instead of “.dtb” I get the error:

`
-bash: echo: write error: File exists

`
instead of the file not found error I was getting previously.

if you type "dmesg" after that, the kernel should give you a hint of
what happend..

Regards,

wow that is incredible useful, I didn’t even realize that is what dmesg did. Here is the output I got:

`
[ 2117.571792] bone_capemgr bone_capemgr: part_number ‘PRU-GPIO-BLINK’, version ‘N/A’
[ 2117.571876] bone_capemgr bone_capemgr: slot #10: override
[ 2117.571920] bone_capemgr bone_capemgr: Using override eeprom data at slot 10
[ 2117.571967] bone_capemgr bone_capemgr: slot #10: ‘Override Board Name,00A0,Override Manuf,PRU-GPIO-BLINK’
[ 2117.573674] bone_capemgr bone_capemgr: slot #10: PRU-GPIO-BLINK conflict P8.11 (#4:univ-emmc)
[ 2117.582657] bone_capemgr bone_capemgr: slot #10: Failed verification

`

It looks like I am having a conflict with the emmc on the beaglebone, so I assumes that means I should disable the emmc in my uEnv.txt? Also I am a bit confused as to why it says the version is ‘N/A’ when I have it set to ‘00A0’ in my dts file.

I just tried the various combinations of enabling and disabling the HDMI, emmc, both and neither and regardless of what it is set to I get a conflict on P8.11 every time. Is there a key component that I am missing somewhere or a different way I should be going about this?

univ-emmc is the userspace overlay we automatically load on bootup

open /boot/uEnv.txt

you'll notice a cape_universal=enable

remove that and reboot

Regards,

What does that actually do Robert ? I've done this myself in the past, and
haven't noticed a difference one way or another. Granted, I am using a
heavily modified universal overlay. . . but with only specific pins muxed
the way I need it, and everything else stripped out.

univ-emmc is the userspace overlay we automatically load on bootup

open /boot/uEnv.txt

you'll notice a cape_universal=enable

remove that and reboot

Regards,

What does that actually do Robert ? I've done this myself in the past, and
haven't noticed a difference one way or another. Granted, I am using a
heavily modified universal overlay. . . but with only specific pins muxed
the way I need it, and everything else stripped out.

It's the hint to load it on bootup:

Regards,

Thanks Robert! That solved the problem I have been having. The overlay loaded and everything looks to be working. One follow up question I do have is what is the proper way to load a custom overlay on startup? Is there a way to enable multiple overlays as long as they don’t try to use the same pins?

Add it /boot/uEnv.txt:

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=PRU-GPIO-BLINK

You'll need to copy PRU-GPIO-BLINK-00A0.dtbo to /lib/firmware/

then run:

sudo /opt/scripts/tools/developers/update_initrd.sh

To copy the new *.dtbo object into the initrd..

Then just reboot, and you should see your overlay loaded..

Regards,

Great, thanks! And not to be a pest but I assume in order to undo that change I simply comment the line that I add to the uEnv.txt and that’s it? Should I worry about removing the *.dtbo object from the initrd?