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?
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?
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!