PRU RPMsg device file missing

[JD Morise]

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

[uwem...@web.de]

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

[John Syne]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/76b36f24-f8ef-4541-b949-1528a750b523%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg]

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

[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

 *

 * Using the name 'rpmsg-pru' will probe the rpmsg_pru driver found

 * at linux-x.y.z/drivers/rpmsg/rpmsg_pru.c

 */

//#define CHAN_NAME                                     "rpmsg-client-sample"

#define CHAN_NAME                                       "rpmsg-pru"

The above is how it should be modified to get the virtual device file to appear.

I am using the exact same TI based kernel, lab 5 works and yields two-way PRU<->ARM messages.

Regards,

Greg

[Torben]

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

[Greg]

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

[John Syne]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/cd96dc91-60ec-4763-aaf0-45c66b575ff3%40googlegroups.com.

[uwem...@web.de]

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

[Greg]

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

[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

[John Syne]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/daa94402-d23c-4a09-a2e9-0673a1c4cc55%40googlegroups.com.

[Greg]

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

[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 ro...@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"

11.  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

12.  Reboot

13.  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

[uwem...@web.de]

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

[Greg]

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

[benjamin...@googlemail.com]

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 

[engka...@gmail.com]

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.

[Mark A. Yoder]

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

[Greg]

Thank you Mark, I have updated my notes.

Greg