PRUSS under Debian beta

Hello. I’m trying to get PRUSS working with the new Debian beta image. I’ve got things working on Angstrom, but not on Debian. I’m using kernel 3.8.13-bone50, is anybody else using PRUSS on this kernel?

Yes. Did you enable the PRU ?

if you do the following: cat /sys/devices/bone_capemgr.9/slots
Does it show the PRU enabled?

If not, look in /lib/firmware for a dtbo that has the PRU , and do an:echo PRUDTBOFILE > /sys/devices/bone_capemgr.9/slots

It’s not showing as enabled:

lsmod

Module Size Used by
uio_pruss 4066 0
g_multi 50407 2
libcomposite 15028 1 g_multi
mt7601Usta 641118 0

cat /sys/devices/bone_capemgr.9/slots

0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

echo /lib/firmware/BB-BONE-PRU-01-00A0.dtbo > /sys/devices/bone_capemgr.9/slots

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

But the command doesn’t work. Am I doing it right?

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Privileged_echo

sudo sh -c "echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.9/slots"

Regards,

Thank you.

root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots 0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
root@beaglebone:~# modprobe uio_pruss
root@beaglebone:~# echo BB-BONE-PRU-01 >/sys/devices/bone_capemgr.9/slots
root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots 0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU-01

We have been using the PRUSS’s extensively on bone70; with mostly success, but every so often, memory gets corrupted, and we have to reboot. This behavior is aperiodic and we have not been able to track it down yet (the PRUSS’s can write anywhere in memory - they could be a significant security risk - for example changing some bytes loaded at PRUSS startup could be used to take over the BBB). That is until today (see my recent post), where some input connections to the header that we want to use as PRUSS inputs is causing the BBB to freeze at boot. Generally, however, the PRUSS’s seem to work as expected (make sure you assemble with -V2)

(the PRUSS’s can write anywhere in memory - they could be a significant security risk - for example changing some bytes loaded at PRUSS startup could be used to take over the BBB).

Only if you’re incompetent where system security is concerned.