PRU rpmsg issues with IOT 2016-11-06

GoogleGroups
1

Hello,

I have been developping something for a while now. I started on a BBB rev A, migrated to rev C and have now switched to BBG (no need for HDMI.

For the OS, I have migrated from angstrom to Debian 7, to 8, kernel 3.X to 4.4. Now I need advice on choosing a version.

I am running a bunch of code (mostly python) in user-space, some web services, external SPI, I2C and CANBus peripherals and also running code on PRU0. When I started all this, UIO_PRUSS looked like the most popular way of doing things out there byt remote-proc looked like the future so I chose it.

Everything was all when and good until I switch my base image from 2016-04-21 to the latest 2016-11-06 IOT image. I am trying to get the latest @stable@ and @standard@ version before releasing my project. (Am I justified in doing this?) Now it appears that remote proc is not enabled by default.
I had to follow the steps from Greg here: https://github.com/Greg-R/pruadc1 (ref taken from this thread: https://groups.google.com/forum/#!topic/beagleboard/tQW4ZLcncF8 )to reenable-it. Even then, my /dev/rpmsg_pru30 device file just will not be created!

here is my boot dmesg:

[ 4.785011] remoteproc1: 4a334000.pru0 is available
[ 4.785035] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 4.785045] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 4.785341] remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -2
[ 4.785360] remoteproc1: failed to load am335x-pru0-fw
[ 4.824044] pru-rproc 4a334000.pru0: booting the PRU core manually
[ 4.824075] remoteproc1: powering up 4a334000.pru0
[ 4.824182] remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -2
[ 4.824199] remoteproc1: request_firmware failed: -2
[ 4.829423] pru-rproc 4a334000.pru0: rproc_boot failed
[ 4.928466] remoteproc1: releasing 4a334000.pru0
[ 4.928634] pru-rproc: probe of 4a334000.pru0 failed with error -2
[ 4.929025] remoteproc1: 4a338000.pru1 is available
[ 4.929038] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 4.929047] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 4.929318] remoteproc1: Direct firmware load for am335x-pru1-fw failed with error -2
[ 4.929337] remoteproc1: failed to load am335x-pru1-fw
[ 4.939607] pru-rproc 4a338000.pru1: booting the PRU core manually
[ 4.939637] remoteproc1: powering up 4a338000.pru1
[ 4.939736] remoteproc1: Direct firmware load for am335x-pru1-fw failed with error -2
[ 4.939750] remoteproc1: request_firmware failed: -2
[ 4.944962] pru-rproc 4a338000.pru1: rproc_boot failed
[ 5.052392] remoteproc1: releasing 4a338000.pru1
[ 5.052550] pru-rproc: probe of 4a338000.pru1 failed with error -2

lsmod after boot:

Module Size Used by
spidev 8860 0
c_can_platform 7581 0
c_can 12220 1 c_can_platform
can_dev 14358 1 c_can
spi_omap2_mcspi 12952 0
pwm_tiehrpwm 5883 0
pwm_tiecap 4571 0
tieqep 9981 0
omap_aes_driver 23889 0
omap_sham 26513 0
omap_rng 5544 0
rng_core 9066 1 omap_rng
evdev 13511 1
uio_pdrv_genirq 3923 0
uio 10524 1 uio_pdrv_genirq
8021q 22979 0
garp 7049 1 8021q
mrp 8903 1 8021q
stp 2430 1 garp
llc 5903 2 stp,garp
usb_f_acm 8361 1
u_serial 13753 3 usb_f_acm
usb_f_rndis 25865 1
g_multi 6010 0
usb_f_mass_storage 49849 2 g_multi
u_ether 14413 2 usb_f_rndis,g_multi
libcomposite 53554 4 usb_f_acm,usb_f_rndis,g_multi,usb_f_mass_storage
pru_rproc 15431 0
pruss_intc 8603 1 pru_rproc
pruss 12026 1 pru_rproc

I manually load the rpmsg module with modprobe rpmsg_pru. I then see 2 new modules loaded:

rpmsg_pru 5543 0
virtio_rpmsg_bus 16076 1 rpmsg_pru

I then bind the PRU:
echo “4a334000.pru0” > /sys/bus/platform/drivers/pru-rproc/bind

dmesg shows the following:

[ 312.954382] remoteproc1: 4a334000.pru0 is available
[ 312.954444] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 312.954471] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 312.971682] remoteproc1: powering up 4a334000.pru0
[ 312.971775] remoteproc1: Booting fw image am335x-pru0-fw, size 86724
[ 312.972162] ti-pruss 4a300000.pruss: configured system_events = 0x1000000000000000 intr_channels = 0x00000001 host_intr = 0x00000001
[ 312.981283] remoteproc1: remote processor 4a334000.pru0 is now up
[ 312.981944] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 312.982123] remoteproc1: registered virtio0 (type 7)
[ 312.982339] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss@4a300000/pru0@4a334000 probed successfully

but still no device file!

Surely someone had that functionnality working! please share!

2

You are very close!!!

One thing to try right away is to:

rmmod pru_rproc

and then

modprobe pru_rproc

I don’t think you are removing pru_rproc before re-probing it.
In my latest Debian image this works, and you don’t need to do the bind in addition to this.
Of course the bind should work as well.

Now, based on the dates you show, you may be using the old Remoteproc framework which uses the mailboxes.
Look in your code for the PRUs and see if you see the numbers like 58 or 59.
The new system flags should be like 18 or 19.

If you have the old mailboxes you can convert your code easily enough. In fact, it will probably be simplified.
Get the latest PRU Support package and look at the examples directory:

https://git.ti.com/pru-software-support-package

I’m pretty sure if you have the old mailboxes code you will get the behavior you are observing.

Regards,
Greg

3

Firstly: Thank you very much for your quick reply! So much stuff to keep track of!
Zerothly: Your ADC article is simply Amazing! I wish i’d found it sooner!

I am indeed using mailboxes in my PRU code, compiled with ti-cgt-pru_2.1.2 from code samples in the processor sdk pru-icss-4.0.2 package.

I will look at the package you references and gie it a whirl!

Am I correct in assuming that this is the way of the future ie: everyone will not fall-back to UIO and leave me and my code stranded?
To have everything started automatically at boot time I guess I will have to create another systemd service right?

4

Thank you so very much! Everything working fine now!

Took awhile to realize that the resource_table_0.h file was also modified!

So I guess I will not have to download the whole >2GB Platform_sdk again and just use the pru-software-support-package !

Thank you again!