Surefire PRU Example

GoogleGroups
1

Hi All,

I have BBB rev c recently flashed to Debian 8 - kernel 4.4. I have been struggling to get code into the PRUs since many of the demos on the web are fragmented in methods and dependencies which make it difficult to have a winning combination. My goal is to have a configuration script that can setup all the requirements for the PRU to work.

I also noticed that many users appear to be using uio_pruss for their loader and not remote_proc. That said what img is the last known working image with uio_pruss ?

In the latest site listed image, uio_pruss module seems not to be included, is there a separate package we need to install for this support?

I am able to compile using gcc-pru and build elf files form the various demos. In general I am trying to do this basic one https://github.com/Neil-Jubinville/pru-gcc-examples/tree/master/blinking-led and use my init script here: https://github.com/Neil-Jubinville/pru/blob/master/prep_pru.sh

Using the uio_pruss method:

  • I get uio_pruss not found for the module. Therefore subsequent commands yield:

root@beaglebone:~/pru-gcc-examples/blinking-led/host-uio# ./out/pload …/pru/out/pru-core0.elf …/pru/out/pru-core1.elf
Initializing the PRUs…
pload: prussdrv_open open failed ( how to get uio_pruss ? Do I have to compile this module? )

Using the remote_proc method:

The below commands fail with the module not found**.**

sudo rmmod pruss_remoteproc
sudo modprobe pruss_remoteproc

So I am not having success with either method, each having missing dependencies. The startup log below indicates also some availability and failing of default PRU loading from the /lib/firmware copies of the remote proc method.

Any ideas? Is there a surfire version / image that will 100% resulting gcc-pru compiled example loading into PRU. I will certainly document it once I discover it.

BeagleBoard.org Debian Image 2016-05-13

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@beaglebone:~# uname -a
Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux
root@beaglebone:~# lsmod
Module Size Used by
c_can_platform 6602 0
c_can 9577 1 c_can_platform
can_dev 11663 1 c_can
spidev 7523 0
pwm_tiecap 3652 0
pwm_tiehrpwm 4706 0
tieqep 8758 0
pruss_intc 3571 0
snd_soc_hdmi_codec 5842 1
snd_soc_simple_card 8449 0
8021q 17930 0
garp 5769 1 8021q
mrp 7239 1 8021q
stp 2219 1 garp
llc 5123 2 stp,garp
pru_rproc 11359 0
omap_aes_driver 19045 0
omap_sham 21340 0
pruss 11679 1 pru_rproc
omap_rng 4423 0
snd_soc_davinci_mcasp 16653 2
snd_soc_edma 1290 1 snd_soc_davinci_mcasp
snd_soc_omap 3058 1 snd_soc_davinci_mcasp
rng_core 7703 1 omap_rng
tilcdc 26338 0
usb_f_acm 7209 1
snd_soc_core 155549 5 snd_soc_hdmi_codec,snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap,snd_soc_simple_card
u_serial 11366 3 usb_f_acm
snd_pcm_dmaengine 5209 2 snd_soc_core,snd_soc_omap
usb_f_rndis 22191 1
g_multi 5524 0
usb_f_mass_storage 42370 2 g_multi
u_ether 11898 2 usb_f_rndis,g_multi
libcomposite 43717 4 usb_f_acm,usb_f_rndis,g_multi,usb_f_mass_storage
snd_pcm 83341 5 snd_soc_hdmi_codec,snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
snd_timer 19788 1 snd_pcm
spi_omap2_mcspi 11148 0
snd 59495 3 snd_soc_core,snd_timer,snd_pcm
soundcore 7637 1 snd
evdev 10695 2
tda998x 12523 0
uio_pdrv_genirq 3539 0
uio 8822 1 uio_pdrv_genirq

root@beaglebone:~# modprobe uio_pruss
modprobe: FATAL: Module uio_pruss not found.
root@beaglebone:~#

2

Hi Neil,

I think that for UIO you’ll need to switch your kernel. See https://groups.google.com/d/msg/beagleboard/6vKLJpJoPGY/kc-iW_fbAgAJ .

For remoteproc, here are some points to check:

  1. For loading PRU GCC ELF firmware you will need a kernel with this patch applied: 0001-Fix-remoteproc-to-work-with-the-PRU-GNU-Binutils-por.patch. Looks like your kernel 4.4.9-ti-rt-r25 is missing it. The Jessie testing images come with 4.4.27-ti-rt-r62 , which has this patch integrated.

  2. If you are using RPMSG communication, then please be aware that there are two remoteproc drivers circulating around :frowning: The older one uses mailboxes for RPC (corresponding pru-gcc-examples branch “master”). If your kernel is newer, it probably runs the remoteproc driver that instead uses interrupts for RPC. You’ll want to use the dev-for-v5-rpmsg branch of pru-gcc-example, which is based on the updated “5.0.0” pru-software-support-package from TI.

Regards,
Dimitar

3

http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg is the best summary I’ve found for the remoteproc method and it definitely answered some questions that I didn’t see anywhere else I looked. Definitely works on 4.4.23-ti-r52.

4

I am trying to avoid buying that TI cape :slight_smile:

OK update: Indeed running the updatekernel.sh brought me to 4.4.27 This gave me the ability to run modprobe uio_pruss

When I go to run the loader I am still getting the prussdrv_open failed message. This tells me that normally the PRUs may not be enabled and to look for the HDMI pin conflict? Chatting in the #beagle irc states that the default open pin is not in conflict to open the PRU after the init so I am not sure what is going on. Maybe this has to do with the base cap-universal tree loaded at the start.

I have removed all DT from the slots till it was empty then loaded a variety of BB-BONE-PRU * and to no avail would it open/load. So it is something more obscure. I suspect the default DT.

I’ll look into the remoteproc method after hacking DTs for a bit.

Thx for the notes.

Neil

5

On the TI branch, we don't ship a default PRU driver, it's up to you
to configure it..

git clone https://github.com/RobertCNelson/dtb-rebuilder
cd ./dtb-rebuilder/

You have the "black", so edit one of the following:

#default: emmc + hdmi enabled:
nano src/arm/am335x-boneblack.dts

#: all overlays (emmc/hdmi disabled)
nano src/arm/am335x-boneblack-overlay.dts

#emmc enabled: hdmi disabled
src/arm/am335x-boneblack-emmc-overlay.dts

then look:

uio_pruss (3.8.x compabitl)

/*
* /etc/modprobe.d/pruss-blacklist.conf

6

Opps reversed them:

uio_pruss (3.8.x compatible)

/*
* /etc/modprobe.d/pruss-blacklist.conf

7

If you do come back around to RemoteProc and RPMsg and want to run some of the cape examples… the schematic for the PRU Cape is posted here: http://www.ti.com/lit/df/tidr938/tidr938.pdf

You could breadboard some of the circuits (LEDs, switches, etc) without having to spend the full $39.

8

Brett:
Thanks for the feedback on the eLinux page. I have more examples to develop when time permits.

–Mark

9

OK This worked for the loading:

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# ./out/pload …/pru/out/pru-core0.elf …/pru/out/pru-core1.elf
Initializing the PRUs…
AM33XX
The code is 0Starting …
Stopping PRU… done.

The I/O does not seem to toggle just yet, I am loading the simple BB-BONE-PRU that has one pin for output enabled → P9.27

Getting close though.

When the message says stopping PRU in the pruss driver is it stopping the cpu/core execution ? or is that indicating the end of the load?

Neil

10

It means the Pru core is being stopped and reset. You may want to open pload.c and adjust the amount of time PRU is allowed to execute. By default it is 30 seconds.

Regards,
Dimitar

11

Thx Dimitar,

Ok so still no voltage toggle / led lighting on that P9_27. Any idea why the PRU will load but I am not seeing any I/O work?

I am using this overlay :

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat /lib/firmware/BB-BONE-PRU-00A0.dts
/*

  • Copyright © 2013 Matt Ranostay
12

Could you double check that your pin mux is correct? On my kernel I can do it with this command:
$ cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep -i 44e109a4

Which kernel are you using?

You may also try the “md5-check” example. If md5-check passes, then the PRU firmware is loaded and executed just fine. In such case you’ll know that your “blinking-led” has an issue with the pin mux or LED wiring.

Regards,
Dimitar

13

Looks like a pinmux issue - I know the LED wiring is good - tested that.

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/pru# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep -i 44e109a4
pin 105 (44e109a4.0) 00000027 pinctrl-single

root@beaglebone:~/pru/pru-gcc-examples/md5-check/host-uio# ./out/pload …/pru/out/pru-core0.elf …/pru/out/pru-core1.elf

Initializing the PRUs…
AM33XX
Starting …
Stopping PRU… _md5res: 0000100c
MD5 sum has been successfully calculated by PRU1.
done.

14

I am using 4.4.27-ti-r62.

15

Does this look right?

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

pru_gpio_pins: pinmux_pru_gpio_pins {
pinctrl-single,pins = <
0x1a4 0x0f /* P9 27 GPIO3_19: mcasp0_fsr.gpio3[19] | MODE7 | OUTPUT */

;
};

pru_pru_pins: pinmux_pru_pru_pins {
pinctrl-single,pins = <
0x1a4 0x25 /* mcasp0_fsr.pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU */

;
};
};
};

0x1a4 is same memory address, are they supposed to be defined twice there?

16

I’m not sure what the first one i trying to do other than put the pin in GPIO mux mode.

The second seems to be the correct one. I’d have to look up what 0x20 is ( probably pull up or down ) but mux mode 5, and 6 is generally PRU mux mode. DO also keep in mind mode 5, and 6, one mode is input, whiel the other mode is output. I forget which is which. There is plenty of info on the web about this.

17

Ah, I think I see. Perhaps the left most bit is to indicate input( 0 ) or output( 1 ).

18

5 is for output I recall…

To add

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat $PINS | grep 9a4
pin 105 (44e109a4.0) 00000027 pinctrl-single

Still no toggle. Tonight I’ll try to get the pin mode to change and see it in the pin debug.

Neil

19

I’m also using 4.4.27-ti-r62. In particular, the IOT distribution.

I’m seeing strange behavior attempting to run Remoteproc. It’s like the PRUs are missing from the device tree. I think.

I’m comparing a working board built with 4.4.12-ti-r31 from a few months ago. This one works perfectly.

So I am comparing the contents of this directory:

/sys/bus/platform/devices

I believe the above contains a listing of the “non-discoverable” devices which are present in the device tree blobs.
I’m still not getting the device tree that well, so my guess here could be totally incorrect.

So on the working board (4.4.12-ti-r31), I see these entries for the PRU in the above directory:

4a300000.pruss
4a320000.intc
4a334000.pru0
4a338000.pru1

For the badly behaving board (4.4.27-ti-r62):

ocp:pruss@4a300000

Why would these be different?

If I cat slots on the badly behaving board:

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

This seems OK. I see the same after running the PRUs on the working board.

I have not made any changes to uEnv.txt.
Very baffled by this and not making progress.

Regards,
Greg

20

william@beaglebone:~$ *uname -r*
4.4.14-ti-r34
william@beaglebone:~$ *ls /sys/bus/platform/devices |grep pru*
4a300000.pruss
william@beaglebone:~$ *lsmod |grep pru*
uio_pruss 4928 0
uio 8822 2 uio_pruss,uio_pdrv_genirq

It sound as though perhaps the remotproc driver is not loaded, or you have
the UIO driver loaded. You made the proper adjustment to the board file for
the second board ?