PRU RPMsg device file missing

Hi,

I would like to get communication up and running between ARM and PRU, by following the TI Example 5 “RPMsg communication between ARM and PRU”.

The system is a BBB with debian, kernel 4.1.15-ti-rt-r43. All 3 modules are loaded, here is the snippet of the lsmod:

pruss_remoteproc 15296 2
rpmsg_pru 4683 0
virtio_rpmsg_bus 13437 1 rpmsg_pru

dmesg ourput is posted below, I however don’t see any problems or errors.However the device file /dev/rpmsg_pru* is not created at all, although the rpmsg_host seems to be online. What am I missing? Where to look for error messages or problems?

Could it be a problem with the device tree? I don’t have any device tree overlays loaded, apart from the cape_universaln

Best Regards, JD

[ 137.089974] pruss-rproc 4a300000.pruss: 8 PRU interrupts parsed
[ 137.090107] pruss-rproc 4a300000.pruss: memory dram0: pa 0x4a300000 size 0x2000 va e0b68000
[ 137.090153] pruss-rproc 4a300000.pruss: memory dram1: pa 0x4a302000 size 0x2000 va e0b6c000
[ 137.090193] pruss-rproc 4a300000.pruss: memory shrdram2: pa 0x4a310000 size 0x3000 va e0b70000
[ 137.090231] pruss-rproc 4a300000.pruss: memory intc: pa 0x4a320000 size 0x2000 va e0b74000
[ 137.090270] pruss-rproc 4a300000.pruss: memory cfg: pa 0x4a326000 size 0x2000 va e0b78000
[ 137.106091] pruss-rproc 4a300000.pruss: creating platform devices for PRU cores
[ 137.117092] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 size 0x2000 va e0b7c000
[ 137.117188] pru-rproc 4a334000.pru0: memory control: pa 0x4a322000 size 0x400 va e0b80000
[ 137.117231] pru-rproc 4a334000.pru0: memory debug: pa 0x4a322400 size 0x100 va e0b82400
[ 137.128119] remoteproc1: 4a334000.pru0 is available
[ 137.128152] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 137.128169] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 137.137153] remoteproc1: powering up 4a334000.pru0
[ 137.137211] remoteproc1: Booting fw image am335x-pru0-fw, size 79096
[ 137.137332] pru-rproc 4a334000.pru0: version 0 event_chnl_map_size 1 event_chnl_map 00000394
[ 137.137356] pru-rproc 4a334000.pru0: sysevt-to-ch[59] → 1
[ 137.137375] pru-rproc 4a334000.pru0: skip intr mapping for chnl 0
[ 137.137395] pru-rproc 4a334000.pru0: chnl-to-host[1] → 1
[ 137.137413] pru-rproc 4a334000.pru0: skip intr mapping for chnl 2
[ 137.137431] pru-rproc 4a334000.pru0: skip intr mapping for chnl 3
[ 137.137449] pru-rproc 4a334000.pru0: skip intr mapping for chnl 4
[ 137.137467] pru-rproc 4a334000.pru0: skip intr mapping for chnl 5
[ 137.137485] pru-rproc 4a334000.pru0: skip intr mapping for chnl 6
[ 137.137503] pru-rproc 4a334000.pru0: skip intr mapping for chnl 7
[ 137.137520] pru-rproc 4a334000.pru0: skip intr mapping for chnl 8
[ 137.137538] pru-rproc 4a334000.pru0: skip intr mapping for chnl 9
[ 137.137563] pruss-rproc 4a300000.pruss: SYSEV59 → CH1 (CMR14 0x01000000)
[ 137.137584] pruss-rproc 4a300000.pruss: CH1 → HOST1 (HMR0 0x00000100)
[ 137.137607] pruss-rproc 4a300000.pruss: configured system_events = 0x0800000000000000 intr_channels = 0x00000002 host_intr = 0x00000002
[ 137.137626] remoteproc1: starting PRU0: entry-point = 0x0
[ 137.137642] remoteproc1: remote processor 4a334000.pru0 is now up
[ 137.137798] remoteproc1: kicking vqid 0 on PRU0
[ 137.137965] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 137.138120] remoteproc1: registered virtio0 (type 7)
[ 137.138351] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss@4a300000/pru@4a334000 probed successfully
[ 137.138733] pru-rproc 4a338000.pru1: memory iram: pa 0x4a338000 size 0x2000 va e0b9c000
[ 137.138813] pru-rproc 4a338000.pru1: memory control: pa 0x4a324000 size 0x400 va e0b9a000
[ 137.138855] pru-rproc 4a338000.pru1: memory debug: pa 0x4a324400 size 0x100 va e0ba0400
[ 137.160141] remoteproc2: 4a338000.pru1 is available
[ 137.160177] remoteproc2: Note: remoteproc is still under development and considered experimental.
[ 137.160194] remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 137.163512] pru-rproc 4a338000.pru1: booting the PRU core manually
[ 137.163552] remoteproc2: powering up 4a338000.pru1
[ 137.163871] remoteproc2: Booting fw image am335x-pru1-fw, size 33580
[ 137.163953] remoteproc2: starting PRU1: entry-point = 0x0
[ 137.163972] remoteproc2: remote processor 4a338000.pru1 is now up
[ 137.164033] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss@4a300000/pru@4a338000 probed successfully

I am running into the same problem with 4.4.9-ti-r25 (debian), using the Makefile.

Probably something to do with the am335x-pru0-fw and am335x-pru1-fw. Did you generate these yourself and are they derived from V4 of the PRU Software Support Package? Here is what the log should look like

[ 17.730877] pruss-rproc 4a300000.pruss: 8 PRU interrupts parsed
[ 17.730963] pruss-rproc 4a300000.pruss: memory dram0: pa 0x4a300000 size 0x2000 va e0cfc000
[ 17.730992] pruss-rproc 4a300000.pruss: memory dram1: pa 0x4a302000 size 0x2000 va e0d00000
[ 17.731016] pruss-rproc 4a300000.pruss: memory shrdram2: pa 0x4a310000 size 0x3000 va e0d04000
[ 17.731061] pruss-rproc 4a300000.pruss: memory intc: pa 0x4a320000 size 0x2000 va e0d08000
[ 17.731085] pruss-rproc 4a300000.pruss: memory cfg: pa 0x4a326000 size 0x2000 va e0d0c000
[ 17.739291] pruss-rproc 4a300000.pruss: creating platform devices for PRU cores
[ 17.838694] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 size 0x2000 va e0d10000
[ 17.838750] pru-rproc 4a334000.pru0: memory control: pa 0x4a322000 size 0x400 va e0876000
[ 17.838807] pru-rproc 4a334000.pru0: memory debug: pa 0x4a322400 size 0x100 va e09fe400
[ 17.839055] remoteproc1: 4a334000.pru0 is available
[ 17.889681] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 17.976790] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 18.110269] remoteproc1: registered virtio0 (type 7)
[ 18.117784] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss@4a300000/pru@4a334000 probed successfully
[ 18.179627] pru-rproc 4a338000.pru1: memory iram: pa 0x4a338000 size 0x2000 va e0d40000
[ 18.179703] pru-rproc 4a338000.pru1: memory control: pa 0x4a324000 size 0x400 va e0cfa000
[ 18.179731] pru-rproc 4a338000.pru1: memory debug: pa 0x4a324400 size 0x100 va e0d44400
[ 18.179991] remoteproc2: 4a338000.pru1 is available
[ 18.238845] remoteproc2: Note: remoteproc is still under development and considered experimental.
[ 18.379910] remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 18.632315] remoteproc2: registered virtio1 (type 7)
[ 18.650550] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss@4a300000/pru@4a338000 probed successfully
[ 20.207007] remoteproc1: powering up 4a334000.pru0
[ 20.494385] remoteproc1: Booting fw image am335x-pru0-fw, size 78652
[ 20.500992] pru-rproc 4a334000.pru0: version 0 event_chnl_map_size 1 event_chnl_map 0000039c
[ 20.501012] pru-rproc 4a334000.pru0: sysevt-to-ch[60] → 0
[ 20.501027] pru-rproc 4a334000.pru0: chnl-to-host[0] → 0
[ 20.501040] pru-rproc 4a334000.pru0: skip intr mapping for chnl 1
[ 20.501052] pru-rproc 4a334000.pru0: skip intr mapping for chnl 2
[ 20.501064] pru-rproc 4a334000.pru0: skip intr mapping for chnl 3
[ 20.501076] pru-rproc 4a334000.pru0: skip intr mapping for chnl 4
[ 20.501088] pru-rproc 4a334000.pru0: skip intr mapping for chnl 5
[ 20.501100] pru-rproc 4a334000.pru0: skip intr mapping for chnl 6
[ 20.501112] pru-rproc 4a334000.pru0: skip intr mapping for chnl 7
[ 20.501124] pru-rproc 4a334000.pru0: skip intr mapping for chnl 8
[ 20.501136] pru-rproc 4a334000.pru0: skip intr mapping for chnl 9
[ 20.501153] pruss-rproc 4a300000.pruss: SYSEV60 → CH0 (CMR15 0x00000000)
[ 20.501168] pruss-rproc 4a300000.pruss: CH0 → HOST0 (HMR0 0x00000000)
[ 20.501183] pruss-rproc 4a300000.pruss: configured system_events = 0x1000000000000000 intr_channels = 0x00000001 host_intr = 0x00000001
[ 20.736524] remoteproc1: starting PRU0: entry-point = 0x0
[ 20.767050] remoteproc1: remote processor 4a334000.pru0 is now up
[ 20.873912] remoteproc1: mbox msg: 0x0
[ 20.873976] virtio_rpmsg_bus virtio0: creating channel rpmsg-client-sample addr 0x1e
[ 20.914002] remoteproc1: kicking vqid 0 on PRU0
[ 20.914078] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 20.989597] remoteproc1: kicking vqid 0 on PRU0
[ 21.071282] remoteproc2: powering up 4a338000.pru1
[ 21.247641] remoteproc2: Booting fw image am335x-pru1-fw, size 78644
[ 21.335040] pru-rproc 4a338000.pru1: version 0 event_chnl_map_size 1 event_chnl_map 00000394
[ 21.335079] pru-rproc 4a338000.pru1: sysevt-to-ch[59] → 1
[ 21.335094] pru-rproc 4a338000.pru1: skip intr mapping for chnl 0
[ 21.335108] pru-rproc 4a338000.pru1: chnl-to-host[1] → 1
[ 21.335120] pru-rproc 4a338000.pru1: skip intr mapping for chnl 2
[ 21.335132] pru-rproc 4a338000.pru1: skip intr mapping for chnl 3
[ 21.335144] pru-rproc 4a338000.pru1: skip intr mapping for chnl 4
[ 21.335156] pru-rproc 4a338000.pru1: skip intr mapping for chnl 5
[ 21.335168] pru-rproc 4a338000.pru1: skip intr mapping for chnl 6
[ 21.335180] pru-rproc 4a338000.pru1: skip intr mapping for chnl 7
[ 21.335192] pru-rproc 4a338000.pru1: skip intr mapping for chnl 8
[ 21.335204] pru-rproc 4a338000.pru1: skip intr mapping for chnl 9
[ 21.335222] pruss-rproc 4a300000.pruss: SYSEV59 → CH1 (CMR14 0x01000000)
[ 21.335236] pruss-rproc 4a300000.pruss: SYSEV60 → CH0 (CMR15 0x00000000)
[ 21.335251] pruss-rproc 4a300000.pruss: CH0 → HOST0 (HMR0 0x00000000)
[ 21.335265] pruss-rproc 4a300000.pruss: CH1 → HOST1 (HMR0 0x00000100)
[ 21.335281] pruss-rproc 4a300000.pruss: configured system_events = 0x1800000000000000 intr_channels = 0x00000003 host_intr = 0x00000003
[ 21.508227] remoteproc2: starting PRU1: entry-point = 0x0
[ 21.508264] remoteproc2: remote processor 4a338000.pru1 is now up
[ 21.615803] remoteproc2: mbox msg: 0x0
[ 21.615861] virtio_rpmsg_bus virtio1: creating channel rpmsg-pru addr 0x1f
[ 21.627159] remoteproc2: kicking vqid 0 on PRU1
[ 21.627220] virtio_rpmsg_bus virtio1: rpmsg host is online
[ 21.640975] remoteproc2: kicking vqid 0 on PRU1
[ 22.905600] rpmsg_pru rpmsg1: new rpmsg_pru device: /dev/rpmsg_pru31

Regards,
John

I may not be remembering this correctly. In one of the labs, and it may be #5, you have to uncomment/comment some lines in the C file to cause the rpmsg driver to be “probed”.

This will cause the virtual device file to appear in the /dev directory.
I have got it functioning correctly and I think I have the same version you are working with.

I’ll double-check when I get home later this evening.

Regards,
Greg

Here is the section of main.c which must be changed:

/*

  • Using the name ‘rpmsg-client-sample’ will probe the RPMsg sample driver
  • found at linux-x.y.z/samples/rpmsg/rpmsg_client_sample.c

No success for me.

I am compiling on the BBB with the preinstalled clpru (debian iot image).
The PRU Software Support Package is up to date (ahead of tag: v4.0.2).

First I followed:
https://groups.google.com/d/msg/beagleboard/IKVmIjvXnIs/uT9BLmTfAQAJ

  • In the lab_5/solution/PRU_RPMsg_Echo_Interrupt1/Makefile:
    To
    INCLUDE=–include_path=…/…/…/include --include_path=…/…/…/include/am335x
    I added
    –include_path=/usr/include/arm-linux-gnueabihf

  • In /usr/include/arm-linux-gnueabihf/gnu/stubs.h I replaced
    <gnu/stubs-soft.h> with <gnu/stubs-hard.h>.
    (stubs-soft.h does not exist)

  • To lab_5/solution/PRU_RPMsg_Echo_Interrupt1/main.c I added
    #include <err.h>

and replaced
//#define CHAN_NAME “rpmsg-client-sample”
#define CHAN_NAME “rpmsg-pru”

  • After the above steps
    make
    cp gen/*.out /lib/firmware/am335x-pru1-fw
    rmmod -f /lib/modules/4.4.9-ti-r25/kernel/drivers/remoteproc/pru_rproc.ko
    insmod /lib/modules/4.4.9-ti-r25/kernel/drivers/remoteproc/pru_rproc.ko

  • dmesg -wH:
    [ +11.888878] remoteproc1: 4a334000.pru0 is available
    [ +0.000033] remoteproc1: Note: remoteproc is still under development and considered experimental.
    [ +0.000014] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
    [ +0.000599] pru-rproc 4a334000.pru0: booting the PRU core manually
    [ +0.000025] remoteproc1: powering up 4a334000.pru0
    [ +0.000174] remoteproc1: Booting fw image am335x-pru0-fw, size 32664
    [ +0.000073] remoteproc1: remote processor 4a334000.pru0 is now up
    [ +0.000034] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss@4a300000/pru0@4a334000 probed successfully
    [ +0.001184] remoteproc2: 4a338000.pru1 is available
    [ +0.000045] remoteproc2: Note: remoteproc is still under development and considered experimental.
    [ +0.000014] remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
    [ +0.005725] bone_capemgr bone_capemgr: Baseboard: ‘A335BNLT,00C0,0816BBBK0456’
    [ +0.000052] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4
    [ +0.000049] bone_capemgr bone_capemgr: Failed to add slot #1
    [ +0.011166] remoteproc2: powering up 4a338000.pru1
    [ +0.000046] remoteproc2: Booting fw image am335x-pru1-fw, size 79172
    [ +0.000187] ti-pruss 4a300000.pruss: configured system_events = 0x0800000000000000 intr_channels = 0x00000002 host_intr = 0x00000002
    [ +0.000018] remoteproc2: remote processor 4a338000.pru1 is now up
    [ +0.000843] virtio_rpmsg_bus virtio0: rpmsg host is online
    [ +0.000053] remoteproc2: registered virtio0 (type 7)
    [ +0.004341] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss@4a300000/pru1@4a338000 probed successfully
    [ +0.024956] bone_capemgr bone_capemgr: Baseboard: ‘A335BNLT,00C0,0816BBBK0456’
    [ +0.000056] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4
    [ +0.000051] bone_capemgr bone_capemgr: Failed to add slot #1

  • And then (partly redundant)
    modprobe pru_rproc
    modprobe virtio_rpmsg_bus
    modprobe rpmsg_pru

Howevern no /dev/rpmsg_pru* appears. What am I doing wrong?
Hoping to get some hints
Torben

Hi Torben, I’m puzzled by the extra steps with the stubs.h and err.h include files.
I did not have to do this.

Which distribution are you using and which kernel is installed?

I recommend creating these two simple scripts:
This one I call prumodin:

#!/bin/bash
insmod /lib/modules/4.1.18-ti-r53/kernel/drivers/remoteproc/pru_rproc.ko

This one I call prumodout:

#!/bin/bash
rmmod -f /lib/modules/4.1.18-ti-r53/kernel/drivers/remoteproc/pru_rproc.ko

Of course you will probably have to modify the paths to the kernel modules.
I have found the above is all that is required to re-start after modifying and copying
the am335x-pruX-fw firmwares to /lib/firmware. Copy new firmwares, then prumodout and then prumodin
and the remoteproc loads the firmwares to the PRUs and starts them. Other modules like the rpmsg
get loaded automatically.

Regards,
Greg

Hi Greg,

i am running the 2015-05-13 microSD/Standalone: (iot) (BeagleBone/BeagleBone Black/BeagleBone Green)
from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian with 4.4.9-ti-r25.

The first thing that seems strange to me is:

When running make without any modifications i get
“/usr/include/features.h”, line 374: fatal error #1965: cannot open source file “sys/cdefs.h”

find / -name “cdefs.h” gives me
/usr/include/arm-linux-gnueabihf/sys/cdefs.h

Following the above I change the Makefile:

To
INCLUDE=–include_path=…/…/…/include --include_path=…/…/…/include/am335x
I add
–include_path=/usr/include/arm-linux-gnueabihf

Did you have to to that? I am compiling on the BBB.

Regards
Torben

Why not use modprobe so you don’t have to bother with paths and dependencies?

To install
modprobe pru_rproc

To remove
modprobe -r pru_rproc

Regards,
John

I did not see those errors when running the make file.

Here are the changes I made to get the make file to run successfully:

export PRU_CGT=/usr/share/ti/cgt-pru

This directory includes the PRU includes and libraries which the compiler should be using
to create the PRU firmwares.

I am surprised you did not report an error for this, as the make file looks for the $PRU_CGT
environment variable, and reports if it is not found.

The above is the environment variable which has the path to the pru compiler directory.
The make file looks for a bin directory in this directory containing the clpru executable.
However, in the distribution I am using it is not included there, and the bin directory does not exist.
With this command:
which clpru
I get:
/usr/bin/clpru

To fix this problem:
mkdir bin
cd bin
ln -s /usr/bin/clpru clpru

I believe these 2 changes are what was required to get the Labs make files to compile the PRU executables.
Hopefully I am not forgetting a step.

The instructions for the labs includes many more steps, as it is assumed none of the set-up is done as with the recent BBB/BBG distributions with the remoteproc.

Regards,
Greg

That’s a good question. It doesn’t work. I am running as root.
Here is what I see:

modprobe -r pru_rproc
modprobe: FATAL: Module pru_rproc is in use.

However, this works perfectly:
rmmod -f /lib/modules/4.1.18-ti-r53/kernel/drivers/remoteproc/pru_rproc.ko

Also, to insert the modules:
modprobe pru_rproc

Does indeed work.
modprobe -r seems to be a problem. Others have reported this same behavior.

Greg

Hi Greg,

It has been quite a while since I’ve worked on PRU, but with the TI kernel, are you not talking about pruss_remoteproc? I don’t have a pru_rproc in my remoteproc folder.

root@beaglebone:/lib/modules/4.1.13-ti-r33/kernel/drivers/remoteproc# ls
omap_remoteproc.ko pruss_remoteproc.ko

Also, the reason why you cannot remove the KM is because it is still in use. When you use rmmod, you are using the force option which just yanks the KM irrespective of whether it is running or has dependencies, which can cause all kinds of problems. Here is how to do this safely.

oot@beaglebone:~# modprobe -r pruss_remoteproc
modprobe: FATAL: Module pruss_remoteproc is in use.
root@beaglebone:~# lsmod |grep pru
rpmsg_pru 5295 0
virtio_rpmsg_bus 15318 1 rpmsg_pru
pruss_remoteproc 17160 2
root@beaglebone:~# modprobe -r rpmsg_pru
root@beaglebone:~# modprobe -r virtio_rpmsg_bus
root@beaglebone:~# modprobe -r pruss_remoteproc

Regards,
John

Hi John-

I’m pretty sure there are some issues with these modules. Very experimental stuff.
Here’s what happens. I am using a TI based kernel compiled using Robert Nelson’s instructions.
There are 4 modules involved:

root@beaglebone:/home/debian# lsmod | grep pru
rpmsg_pru 4650 0
virtio_rpmsg_bus 13251 1 rpmsg_pru
pru_rproc 10937 2
pruss 14469 1 pru_rproc

So rpmsg_pru has 0 dependencies, so remove that one first:

modprobe -r rpmsg_pru

Seems to have worked. Now look at the modules again:

root@beaglebone:/home/debian# lsmod | grep pru
pru_rproc 10937 1
pruss 14469 1 pru_rproc

So the virtio_rpmsg_bus got removed in the same command.
Now try to get the remaining modules removed:

root@beaglebone:/home/debian# modprobe -r pru_rproc
modprobe: FATAL: Module pru_rproc is in use.

Ok, try to remove the other one:

root@beaglebone:/home/debian# modprobe -r pruss
modprobe: FATAL: Module pruss is in use.

So that is why I am forcing them out. So far, I have not seen any ill effects.
I’ve been working on a PRU project which pulls in data from an ADC. I’ve probably
force removed the modules and then reinserted them 50 times in a single session
and nothing crashed that I could detect. I was able to continue to develop code without issue.

Now my code is relatively simple and is not interacting with the ARM host significantly yet.
I’ll keep your note of caution in mind if I start to see any unusual behavior.

Regards,
Greg

Hi Torben-

I got that image to work. Here is a summary of the steps. Note that I am ssh-ing to a BBG as root.

  1. Flash IOT image to micro-sd.
  2. Insert micro-sd into BBG slot, press boot and power buttons and release.
  3. ssh root@192.168.1.7
  4. uname -r to verify kernel → 4.4.9-ti-r25 YES, it is the correct kernel.
  5. apt-get update
  6. cd / and then find . -name cgt-pru, and the path is /usr/share/ti/cgt-pru. This is the location of the PRU library and includes.
    However, the clpru compiler binary is not there:
    which clpru
    /usr/bin/clpru
    So the compiler binary is in a different location. This is a problem for the labs make files.
    cd /usr/share/ti/cgt-pru
    mkdir bin
    ln -s /usr/bin/clpru clpru
    So now the make files will find the compiler executable in the correct location via the link.
  7. cd /home/debian
    git clone git://git.ti.com/pru-software-support-package/pru-software-support-package.git
    This will clone a copy of the latest pru support package.
  8. cd into lab_5 in the package:
    cd lab_5/solution/PRU_Halt
    make
    This will fail, it is looking for environment variable $PRU_CGT
    export PRU_CGT=/usr/share/ti/cgt-pru
    Now try make again. It should succeed.
  9. cd gen
    cp PRU_Halt.out am335x-pru0-fw
    cp am335x-pru0-fw /lib/firmware
  10. Now cd into the PRU_RPMsg_Echo_Interrupt1 directory in the same lab_5.
    Edit main.c as follows:

//#define CHAN_NAME “rpmsg-client-sample”
#define CHAN_NAME “rpmsg-pru”

  1. Now almost the same as #9, this time for pru1:
    cd gen

cp PRU_RPMsg_Echo_Interrupt1.out am335x-pru1-fw
cp am335x-pru1-fw /lib/firmware

  1. Reboot
  2. cd /dev look for rpmsg_pru31 device file. It will be there!

Hopefully I did not miss any of the steps. Let me know if this helps.

Regards,
Greg

Hi Greg,

I followed yout guide - rpmsg_pru31 appears!
My mistake must have been that I set the PRU_CGT incorrectly to /usr.

Thanks for taking the time!

Torben, a happy camper

Excellent! I am glad the “guide” helps. I have wanted to type up the process before I forget the many details.

Good luck with your PRU programming. It is challenging, but I think a perfect laboratory for learning embedded Linux + bare metal programming.

Have you seen this video?:
https://training.ti.com/pru-compiler-tips-tricks

Highly recommended-- Note that the slides are can be downloaded at the above link.
Look in upper right “Course documents for download:”.

Regards,
Greg

Hi,

now it’s working;-)
I recompiled with newer headers, but the main problem actually was that the FW was loaded to the pru0 instead of pru1.

BR, JD

I have the same problem and using kernel 4.4.9-ti-rt-r26.

In my case, the rpmsg_pru is not loaded when booting or when you modprobe pru_rproc. I can’t see the added device in /dev.

Greg:
Many thanks for your “guide”. I too have had success with it. One minor correction was needed:

cd /usr/share/ti/cgt-pru
mkdir bin
cd bin
ln -s /usr/bin/clpru clpru

The cd bin is needed to get clpru in the right place.

–Mark

Thank you Mark, I have updated my notes.

Greg