Using PRU with PocketBeagle: remoteproc problems

[Ken Shirriff]

I got a PocketBeagle and I want to try out the PRU on it. Everything seems different from the PRUSSDRV stuff I'm used to. I can't get remoteproc to work, so I wanted to know which kernel and interfaces I should use.

Specifically, I'm running the 2017-10-10 Stretch IoT build from http://beagleboard.org/latest-images

I tried running the remoteproc "Hello world" from here.

First, I ran into problems with stdint.h not found; I eventually found it in /usr/share/ti/cgt-pru/include - is that the right include path to use?

When I ran the program, I got a bunch of warnings:

Note: remoteproc is still under development and considered experimental.

THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

And then the program died with "Failed to open /dev/rpmsg_pru31"

So: is remoteproc what I should be using, or is it still "experimental"? Am I using the right kernel? And what is "resource_table.h"?

Thanks for any suggestions,

Ken

[Kumar Abhishek]

Which kernel version are you using? If it's the 4.9 version (most likely as it is the Stretch image), some additional steps are required because the binary won't start up automatically at boot as it does in kernel version 4.4. 

This is a change that happened done going from 4.4-4.9.

To boot the binary, once you build and put it into /lib/firmware you would have to manually boot it.

• Go to /sys/class/remoteproc in a root shell
• There should be 3 directories, remoteproc0, remoteproc1, remoteproc2. To find which is the correct one for PRU0 for example, do: cat /sys/class/remoteproc/remoteproc1/device/of_node/label . It should say "pru0" (at least it does on my board)
• Once you have found the correct remoteproc directory, cd into it. Let's for example assume for PRU0 the directory is /sys/class/remoteproc/remoteproc1
• Then you have to set the name for the firmware you have copied into /lib/firmware using: echo am335x-pru0-fw > firmware .
• Then you have to start the device using: echo start > state . To stop the PRU, do: echo stop > state .

I hope this should get the rpmsg driver to show up. Pastebin your kernel logs so that I can take a look.

Resource table is a way of signifying to the remoteproc driver:

• the PRU interrupts it should configure on PRU boot,
  
• virtqueues used for PRU<->Kernel communication

The resource table is placed in an ELF section that the remoteproc kernel driver reads before it loads the firmware into the PRUs.

Regards

Abhishek

[Alex Bagehot]

Hi Ken,

Having recently also bought a pocket beagle(my first), I ran through these steps from Jason, as he suggested in another thread recently, successfully : https://gist.github.com/jadonk/2ecf864e1b3f250bad82c0eae12b7b64

I thought it would be instructive to work out how to run the example you tried also though. Basically taking the working gist and resolving issues with your example as they appear.

Resulting in:

Received 100 messages, closing /dev/rpmsg_pru31

ie. success. It did a thing.

Thanks,

Alex

On Tue, Nov 14, 2017 at 7:10 AM, Ken Shirriff <ken.sh...@gmail.com> wrote:

I got a PocketBeagle and I want to try out the PRU on it. Everything seems different from the PRUSSDRV stuff I'm used to. I can't get remoteproc to work, so I wanted to know which kernel and interfaces I should use.

Specifically, I'm running the 2017-10-10 Stretch IoT build from http://beagleboard.org/latest-images

Yep. which is:

debian@beaglebone:~/hello$ uname -a

Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l GNU/Linux

 

I tried running the remoteproc "Hello world" from here.

First, I ran into problems with stdint.h not found; I eventually found it in /usr/share/ti/cgt-pru/include - is that the right include path to use?

Yes based on the gist.

I also got some linking errors:

/usr/bin/clpru -z hello.cmd -o /home/debian/hello/pru0/am335x-pru0-fw /home/debian/hello/pru0//main0.object -l/usr/lib/ti/pru-software-support-package/lib/rpmsg_lib.lib

<Linking>

warning: automatic RTS selection:  attempt to automatically link in index

   library "libc.a" failed; file not found

warning: entry-point symbol "_c_int00" undefined

warning: no suitable entry-point found; setting to 0

Adding in another include based on the gist fixed them.

/usr/bin/clpru -z hello.cmd -i/usr/share/ti/cgt-pru/lib -o /home/debian/hello/pru1/am335x-pru1-fw /home/debian/hello/pru1//main1.object -l/usr/lib/ti/pru-software-support-package/lib/rpmsg_lib.lib

<Linking>

Now built it needs to be deployed:

Initially I got an error deploying to pru1 as I just changed 4a334000.pru0 to 4a334000.pru1.

It wasn't hard to find the right ID:

debian@beaglebone:~/hello$ grep pru1 /var/log/messages |head -1

Oct 10 12:07:05 beaglebone kernel: [   11.700167]  remoteproc1: 4a338000.pru1 is available

With this in hand I just wrote a quick sudoable script :

debian@beaglebone:~/hello$ cat a.sh 

set -x

dmesg --clear

echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/unbind

echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind

echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/unbind

echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/bind

Which produced:

debian@beaglebone:~/hello$ sudo ./a.sh && dmesg

+ dmesg --clear

+ echo 4a334000.pru0

+ echo 4a334000.pru0

+ echo 4a338000.pru1

+ echo 4a338000.pru1

[ 7750.734933] pru-rproc 4a334000.pru0: pru_rproc_remove: removing rproc 4a334000.pru0

[ 7750.744148] ti-pruss 4a300000.pruss: unconfigured system_events = 0x0000000000030000 host_intr = 0x00000005

[ 7750.744179]  remoteproc2: stopped remote processor 4a334000.pru0

[ 7750.744387]  remoteproc2: releasing 4a334000.pru0

[ 7750.751046]  remoteproc2: 4a334000.pru0 is available

[ 7750.751076]  remoteproc2: Note: remoteproc is still under development and considered experimental.

[ 7750.751085]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

[ 7750.755059]  remoteproc2: powering up 4a334000.pru0

[ 7750.755101]  remoteproc2: Booting fw image am335x-pru0-fw, size 73588

[ 7750.755362] ti-pruss 4a300000.pruss: configured system_events = 0x0000000000030000 intr_channels = 0x00000005 host_intr = 0x00000005

[ 7750.761686]  remoteproc2: remote processor 4a334000.pru0 is now up

[ 7750.762068] virtio_rpmsg_bus virtio0: rpmsg host is online

[ 7750.762127] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1e

[ 7750.763089] rpmsg_pru rpmsg5: new rpmsg_pru device: /dev/rpmsg_pru30

[ 7750.763232]  remoteproc2: registered virtio0 (type 7)

[ 7750.763325] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss@4a300000/pru0@4a334000 probed successfully

[ 7750.767206] pru-rproc 4a338000.pru1: pru_rproc_remove: removing rproc 4a338000.pru1

[ 7750.767237] pru-rproc 4a338000.pru1: stopping the manually booted PRU core

[ 7750.767353] ti-pruss 4a300000.pruss: unconfigured system_events = 0xffffffffffffffff host_intr = 0x00000001

[ 7750.767368]  remoteproc1: stopped remote processor 4a338000.pru1

[ 7750.767476]  remoteproc1: releasing 4a338000.pru1

[ 7750.774260]  remoteproc1: 4a338000.pru1 is available

[ 7750.774289]  remoteproc1: Note: remoteproc is still under development and considered experimental.

[ 7750.774298]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

[ 7750.775770]  remoteproc1: powering up 4a338000.pru1

[ 7750.775800]  remoteproc1: Booting fw image am335x-pru1-fw, size 73588

[ 7750.776046] ti-pruss 4a300000.pruss: configured system_events = 0x00000000000c0000 intr_channels = 0x0000000a host_intr = 0x0000000a

[ 7750.778533]  remoteproc1: remote processor 4a338000.pru1 is now up

[ 7750.778875] virtio_rpmsg_bus virtio1: rpmsg host is online

[ 7750.778933] virtio_rpmsg_bus virtio1: creating channel rpmsg-pru addr 0x1f

[ 7750.779852] rpmsg_pru rpmsg6: new rpmsg_pru device: /dev/rpmsg_pru31

[ 7750.779982]  remoteproc1: registered virtio1 (type 7)

[ 7750.780083] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss@4a300000/pru1@4a338000 probed successfully

We can see the rpmsg's in /dev

debian@beaglebone:~/hello$ ls -l /dev/rpmsg_pru3*

crw------- 1 root root 243, 0 Oct 10 14:15 /dev/rpmsg_pru30

crw------- 1 root root 243, 1 Oct 10 14:15 /dev/rpmsg_pru31

Makefile diff:

debian@beaglebone:~/hello$ diff Makefile.BAK Makefile

5c5,8

< PRU_INCLUDE:= --include_path=/usr/include/arm-linux-gnueabihf/ --include_path=$(PRU_RPMSG_ROOT)include/ --include_path=$(PRU_RPMSG_ROOT)include/am335x/

---

> PRU_CGT:=/usr/share/ti/cgt-pru

> PRU_SUPPORT:=/usr/lib/ti/pru-software-support-package

> 

> PRU_INCLUDE:= --include_path=/usr/include/arm-linux-gnueabihf/ --include_path=$(PRU_RPMSG_ROOT)include/ --include_path=$(PRU_RPMSG_ROOT)include/am335x/ --include_path=$(PRU_SUPPORT)/include --include_path=$(PRU_CGT)/include 

19c22

< $(PRU_TOOLS)clpru -z $(LINKER_CMD_FILE) -o $(PRU0_ROOT)am335x-pru0-fw $(PRU0_ROOT)/main0.object -l$(PRU_RPMSG_ROOT)lib/rpmsg_lib.lib

---

> $(PRU_TOOLS)clpru -z $(LINKER_CMD_FILE) -i$(PRU_CGT)/lib -o $(PRU0_ROOT)am335x-pru0-fw $(PRU0_ROOT)/main0.object -l$(PRU_RPMSG_ROOT)lib/rpmsg_lib.lib

23c26

< $(PRU_TOOLS)clpru -z $(LINKER_CMD_FILE) -o $(PRU1_ROOT)am335x-pru1-fw $(PRU1_ROOT)/main1.object -l$(PRU_RPMSG_ROOT)lib/rpmsg_lib.lib

---

> $(PRU_TOOLS)clpru -z $(LINKER_CMD_FILE) -i$(PRU_CGT)/lib -o $(PRU1_ROOT)am335x-pru1-fw $(PRU1_ROOT)/main1.object -l$(PRU_RPMSG_ROOT)lib/rpmsg_lib.lib

 

When I ran the program, I got a bunch of warnings:

Note: remoteproc is still under development and considered experimental.

THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

The above happens in the gist version also - so guess it's ok!

And then the program died with "Failed to open /dev/rpmsg_pru31"

Looks like the Makefile wasn't up to date on how to load the program into the pru's.

So: is remoteproc what I should be using, or is it still "experimental"? Am I using the right kernel? And what is "resource_table.h"?

The above worked for me. I would be interested if it is the "right" or best way to do it. Hopefully it works for you also.

From what I can tell from Abhishek's comments it looks like there are further changes in 4.9 in the future, ie. in 4.4 I get:

debian@beaglebone:~/hello$ sudo ls -l  /sys/class/remoteproc

ls: cannot access '/sys/class/remoteproc': No such file or directory

Thanks,

Alex

 

Thanks for any suggestions,

Ken

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fac3f548-800b-4522-86d8-7e49d9b58c21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ken Shirriff]

Alex, thank you for such a detailed response. Your answer solved all my problems.

Ken

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[fluerat...@gmail.com]

Hi Kumar,

I am also having some troubles with rpmsg, having migrated from 4.4 to 4.9.

Your instructions seem to work fine, at least when I run my program for the first time. If I want to change the firmware for the PRU, I have to remove the pru_rproc module, but when I load the module again I no longer have the 3 directories remoteproc0, remoteproc1 and remoteproc2, but instead I have remoteproc0, remoteproc3 and remoteproc4. If I ignore that and try to run my program again I get a bunch of messages from syslogd@beaglebone and everything ends with a segmentation fault.

If I try to use the new files, remoteproc3 and remoteproc4, I get the following errors (output of dmesg):

[ 1765.434025] remoteproc remoteproc3: 4a334000.pru0 is available
[ 1765.434147] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a334000 probed successfully
[ 1765.441036] remoteproc remoteproc4: 4a338000.pru1 is available
[ 1765.441157] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a338000 probed successfully
[ 1765.685583] remoteproc remoteproc3: powering up 4a334000.pru0
[ 1765.686156] remoteproc remoteproc3: Booting fw image am335x-pru0-fw, size 80748
[ 1765.686896] ti-pruss 4a300000.pruss: event 16 (req. channel 2) already assigned to channel 2
[ 1765.700540] pru-rproc 4a334000.pru0: failed to configure pruss intc -17
[ 1765.709720] remoteproc remoteproc3: Failed to process post-loading resources: -17
[ 1765.719518] remoteproc remoteproc3: Boot failed: -17
[ 1765.796012] remoteproc remoteproc4: powering up 4a338000.pru1
[ 1765.796519] remoteproc remoteproc4: Booting fw image am335x-pru1-fw, size 80748
[ 1765.801629] ti-pruss 4a300000.pruss: event 18 (req. channel 3) already assigned to channel 3
[ 1765.810696] pru-rproc 4a338000.pru1: failed to configure pruss intc -17
[ 1765.821230] remoteproc remoteproc4: Failed to process post-loading resources: -17
[ 1765.831046] remoteproc remoteproc4: Boot failed: -17

So the events are still assigned to the previous channels?
Can you please help me understand what's happening? First of all, what are these remoteproc1,2,etc. files (are they somehow related to the channels used to communicate with the PRU?), why do remoteproc1/2 disappear from /sys/class/remoteproc but the events are still assigned to them? And finally, how can I reload the firmware in case of a change?

Best regards,
Laura

[Robert Nelson]

TI changed a few things, if you were using the v4.4.x-ti remoteproc
pru option, it's best to downgrade to v4.4.x..

It'll takes us a while to adapt to those changes.

Regards,

--
Robert Nelson
https://rcn-ee.com/

[dr.rolan...@gmail.com]

Am Mittwoch, 15. November 2017 00:58:12 UTC+1 schrieb Alex Bagehot:

Hi Ken,

Having recently also bought a pocket beagle(my first), I ran through these steps from Jason, as he suggested in another thread recently, successfully : https://gist.github.com/jadonk/2ecf864e1b3f250bad82c0eae12b7b64

I thought it would be instructive to work out how to run the example you tried also though. Basically taking the working gist and resolving issues with your example as they appear.

Resulting in:

Received 100 messages, closing /dev/rpmsg_pru31

ie. success. It did a thing.

Thanks,

Alex

 

Hi Alex,

thank you for your recommendations, got an adaption of the project remoteproc "Hello World" working on Debian 2017/10/10.

If somebody is interested, here is a running version on Github.

https://github.com/RoSchmi/Beaglebone-PRU-RPMsg-HelloWorld

Kind regards

RoSchmi