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 <[email protected]>
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
> <http://theduchy.ualr.edu/?p=996>.
> 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/fac3f548-800b-4522-86d8-7e49d9b58c21%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/fac3f548-800b-4522-86d8-7e49d9b58c21%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHeneC8w%2BuZJkH8WkUgbk_ovNmC8GSDeR-JkSqp_GCTBeF05mQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to