How to reliably activate PRUSS on beaglebone?

GoogleGroups
1

Hello,

I start to experiment with programming PRUs on beaglebone, but I can't
find a way to reliably enable the subsystem with 3.8 kernels. Since it
is disabled in the default device tree, I used
cape-bone-nixie-00A0.dts from the kernel firmware as a template to
created my own DT overlay. Unfortunately loading the uio_pruss module
and applying the overlay though the cape manager does not always
result in UIO being enabled. A few times, using magical combinations
of rmmods and modprobes and applications and removals of my overlay
and the original overlay for NIXIE cape I managed to activate PRU and
successfully run examples from am335x_pru_package, but I can't find a
pattern when it works and when it doesn't. More often than uioX
devices appearing in /dev I can see error messages from the kernel
about incorrect state transision in PRUSS, unbalanced
pm_runtime_enable and an oops similar to this one:
http://pastebin.com/R94TsQnq
Is there a way to enable PRUs without casting magical spells?

Thank you,
j.

2

I am having similar problems on the Beagle Bone Black… I’m seeing these two messages during boot:

`
[ 3.129749] omap_hwmod: pruss: failed to hardreset
[ 7.125974] pruss_uio 4a300000.pruss: No children

`

I have my own overlay that is basically exactly like the nixie cape overlay just with the pwm bits removed. The overlay and pinmuxes are loaded correctly but something is going wrong with initializing the pruss subsystem. /sys/class/uio is empty as the driver is failing to load.

Anyone have any ideas?

3

Also FWIW this was working fine on the beaglebone with 3.8.6…

4

I found a magical combination that seems to work every time:

export slots=/sys/devices/bone_capemgr.7/slots
set -x
modprobe uio_pruss
sleep 2
rmmod uio_pruss
sleep 2
echo cape-bone-nixie > $slots
sleep 2
modprobe uio_pruss
sleep 2
echo cape-bone-nixie > $slots
sleep 2
rmmod uio_pruss
sleep 2
modprobe uio_pruss
sleep 2

An attempt to remove the overlay prior to inserting again results in
an OOPS: http://pastebin.com/i61rCrBR

j.

5

PRUSS works fine with kernel 3.2.42. from Angstrom 2012.05.
Well, nobody said that living on the bleeding edge of development was safe.

j.

6

Yeah - I am thinking something has regressed between 3.8.6 and 3.8.11… 3.8.6 was working great for me, and now I can’t get it to work at all on .11

7

3.8 series has also problems with USB. As much as like DT and
capemanager, I'll have to stick with 3.2 for a while.

j.

8

I'd like to confirm that with Chrises fix PRU works well in 3.8.13
kernel on Angstrom.
Thanks for great job!

j.

9

Hello Jacek,

Curious what your DTO file looked like for enabling PRU functionality. Why was this necessary?

I too am having trouble with the PRU. I tried a script using your modprobe/rmmod/echo recipe above, but it didn’t work. No matter what I do, I can’t see any uio* files in /dev.

I am running with kernel 3.8.12-bone17.

Thanks.

10

This was just fixed this week:
https://github.com/beagleboard/kernel/issues/37

However to get the fix, you need "3.8.13-bone18"..

Regards,

11

Upgrade the kernel. 3.8.12-bone17 is borked.

j.

12

Stumbled upon this thread, is the uio_pruss still borked? Trying to get this working on my BBB 3.8.13-bone20.

-Jesse

13

It’s fixed - working great for me on latest kernel

14

It works for me but before modprobe uio_pruss you have to load device tree overlay by something like echo BB-PRU… > /sys…/cape… Sorry I can’t provide exact form as I’m typing on a tiny keyboard underwater in Florida:)

15

It should not even be necessary to manually load the module. Whenever
I load an overlay with PRUSS enabled, the device files appear in /dev/
automagically.

j.

16

I second that. I spent a week pulling my hair out over PRUSS earlier this year only to discover they weren’t enabled in the device tree overlay. After that, they worked flawlessly