pru + 4.4 kernel?

Hi, I was hoping to upgrade from 3.8.13 to the 4.4.x kernels and installed 4.4.30 on my BBB, my app fails on the following call:

/* Open PRU Interrupt */
if ((ret = prussdrv_open(PRU_EVTOUT_0))) {
printf(“prussdrv_open open failed\n”);

Any ideas or pointers on upgrading?

Jay, you have to do a minimal edit to the device tree and rebuild the blobs.
I’m pretty sure 4.4.x kernels will require this (not sure exactly when this was rolled out).

Clone this to your Beaglebone:

Look in the directory src/arm.
Find the file:




In the file, you need to uncomment a line like:

/* #include “am33xx-pruss-uio.dtsi” */

Then you need to create a very simple file


and include the following:

blacklist pruss
blacklist pruss_intc
blacklist pru-rproc

You will find instructions for the above in the dts file.

make install

Then see if it works! Good luck.

Sadly this did not work. I’m using the default kernel/setup from the image bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz. It uses kernel 4.4.30-ti-r64. Is there something better to start with? I’d like something newer than the 2012 build I previously had.

If that did not work, then you're doing something wrong, or you missed a
step. But you can not just do what Greg suggested and have it work. You
need to make sure you either replace the exact board file you load at boot,
or change the board file that loads at boot.

Anyway, I know what Greg suggest works, because I was the first person on
the list to test the changes, on the list. Once Robert posted to the list
about these changes. In fact, if you search my username on this google
group, with the additional keyword "uio_pruss", it probably won't take you
long to find the exact steps post I made.

I figured out what happened, it wasn’t am335x-boneblack.dts, but am335x-boneblack-wireless.dts. Seems like I can talk to the PRU, but I don’t see it doing what it should be doing. Need to grab a copy of prudebug and see if I can debug what the PRU is trying to do vs. is doing.


Hello Jay!

You need not adapt the device tree when you use a bone kernel. (The device tree fixup is for TI kernels only.)

Hi TJF: is there some place I can find more info on the DT’s across kernels? I’m using 4.4.30-ti-r64. I have access to the PRU, and I think my DT isn’t updating anything (even though it seems to install properly). My DT can be seen here:



If by “updating” you mean your overlay isn’t loading at boot. That would be because the overlay is not in the initramfs. Which is needed for the latest images. I actually posted on the groups about this a few days go, so I’ll find my post and copy paste the procedure here.

If this is not what you mean, post back and describe in more detail what you mean by “updating”.

So whatever way that works for you, is the right way. But yes, in my own opinion loading from uEnv.txt is the proper way. As the pin configurations take place the quickest possible after a boot.

I was grepping /sys/kernel/debug/pinctrl/44e10800.pinmux/pins for 994 -B 4 -A4

and loading my overlay manually: “echo openpegasus > /sys/devices/platform/bone_capemgr/slots”

According to dmesg it seems like it accepts my overlay without error.

I’ll keep the above in mind when I try to load it by default on boot.



Ok, so can you describe in more detail what the problem is ? Also pasting the output of the commands you’re running to test your overlay may help too.

Ya know, I figured out what happened, I wish things were a bit better documented, what you indicated above about creating the initramfs fixed it. I believe what happened was I modifed the uEnv.txt file and thought it took my changes, but it didn’t. I was running still with HDMI enabled and that conflicted with my DTS.

I’ll have to reassemble the machine now (I took the board out to put on a scope), but the values in the pinmux/pins file look correct now.


Ah, yeah, that'll do it. One thing I always do when working with various
things that take many commands to perform, and may easily be forgotten or
messed up. Is to create a text file of exact steps I've done to achieve my
end goal. Then when it comes to duplicating those steps, it turns into a
copy paste session that usually succeeds. Which also gives me an easy way
of creating a bash script later if needed. What just happened to you,
forgetting ti disable the HDMI pins has happened to me before many times in
the past . . .

Yeah, of course now the PRU died, which I had working before …time to debug that again :slight_smile:

I have no idea what I did, but I’m back to nothing working and have been unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my program), nor am I able to have my DTO configure the pinmux anymore. Is there a way to increase debug levels so I can see what is going on when it tries to load my DTO?


there's a handy script under:


sudo perl


Thanks, that is really sweet looking! No matter what I do when I load my DTO it doesn’t seem to change the pinmux/ctrl values unfortunately. Everything in dmesg, journalctl acts as if it worked successfully, but I see no change to the pinmux/ctlr. Is there a kernel (or bone_capemgr) level of debug?


I also just realized, I posted this in the BBB group, not the BBB wireless one. It is a wireless BBB I just received the other day.


So keep this in mind, 99% chance, what you’ve done, you’ve somehow screwed up. Don’t take this as a negative response please. But more or less a realistic response. I’ve done “similar” myself. the whole time, I might be thinking . … “I’m going to let x.y.z have it on the groups . . .” only to find that I totally screwed something up in the process.

Yeah do what I say, and completely 100% document what you do, as you do it. Trust me, if you do not thank me for that, you will at least thank yourself for it.

the google group, i get all mails from that group. No idea
of sub groups, or whatever. . . .quite honestly I don;t even care. If i
know the answer or can give some clues, I'll answer, or give some clues. .