pru-rproc failing on boot, working manually

[Hugh Frater]

Despite googling the heck out of this simple problem, I can't find anything...

Problem is:

[   34.358783]  remoteproc1: 4a338000.pru1 is available
[   34.358802]  remoteproc1: Note: remoteproc is still under development and considered experimental.
[   34.358811]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[   34.359092]  remoteproc1: Direct firmware load for am335x-pru1-fw failed with error -2
[   34.359113]  remoteproc1: failed to load am335x-pru1-fw
[   34.371827] pru-rproc 4a338000.pru1: booting the PRU core manually
[   34.371857]  remoteproc1: powering up 4a338000.pru1
[   34.371968]  remoteproc1: Direct firmware load for am335x-pru1-fw failed with error -2
[   34.371985]  remoteproc1: request_firmware failed: -2
[   34.377200] pru-rproc 4a338000.pru1: rproc_boot failed
[   34.493128]  remoteproc1: releasing 4a338000.pru1
[   34.493310] pru-rproc: probe of 4a338000.pru1 failed with error -2

The firmware file is present, it works - I just have to load it manually once I've booted with:

sudo rmmod -f pru_rproc
sudo modprobe pru_rproc

Is there a known issue with enabling the PRU's at boot?

[Robert Nelson]

Thanks for the bug, the firmware wasn't getting copied to the
initramfs, just pushed a fix, and should hit the apt repo shortly:

https://github.com/rcn-ee/repos/commit/2922f56ce8ab70771944f7eb99d7fd10f8a52b6a

[ 10.478212] ti-pruss 4a300000.pruss: creating PRU cores and other
child platform devices
[ 10.478410] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 !
[ 10.499594] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 !
[ 10.562246] remoteproc1: 4a338000.pru1 is available
[ 10.599505] pru-rproc 4a338000.pru1: booting the PRU core manually
[ 10.599538] remoteproc1: powering up 4a338000.pru1
[ 10.599836] remoteproc1: Booting fw image am335x-pru1-fw, size 35392
[ 10.599913] remoteproc1: remote processor 4a338000.pru1 is now up
[ 10.599951] pru-rproc 4a338000.pru1: PRU rproc node
/ocp/pruss@4a300000/pru1@4a338000 probed successfully
[ 10.602814] remoteproc2: 4a334000.pru0 is available
[ 10.604856] pru-rproc 4a334000.pru0: booting the PRU core manually
[ 10.604883] remoteproc2: powering up 4a334000.pru0
[ 10.605156] remoteproc2: Booting fw image am335x-pru0-fw, size 36296
[ 10.605225] remoteproc2: remote processor 4a334000.pru0 is now up
[ 10.605260] pru-rproc 4a334000.pru0: PRU rproc node
/ocp/pruss@4a300000/pru0@4a334000 probed successfully

Regards,

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

[Hugh Frater]

Looks like this kind-of works now... dmesg doesn't show any errors, but a /dev entry for rpmsg_pru31 is only created if I manually cycle an rrmod -f pru_rproc, modprobe pru_rproc...

Is this because the pru's are booting before the /dev filesystem kernel modules are loaded?

[Greg]

This behavior started, I think when the Debian Jessie distribution appeared.

Prior to that, the PRUs started up at boot perfectly as far as I could tell.

Later, post-Jessie, I worked around it with similar methods to what you are doing.

I didn't consider it a serious problem since I could start up with either .profile or .bashrc.  

My projects are hobby/learning so not for serious embedded deployment.  It would be good to understand what is going on!

You can also try this:

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

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

and this

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

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

If the above commands work, this might provide an additional clue as to what is going on at boot.

I'm hoping to get back on another PRU project soon, would be nice to get this mystery resolved!

Regards,

Greg