Does anyone know what the remoteproc error codes are?
pru_rproc doesn’t start the pru’s at boot time, I assume this is the new behaviour in 4.14 with the uBoot overlays. I’ve updated initramfs since symlinking my binary to /lib/firmware/am335x-pru1-fw, that hasn’t helped. I’ve done an rmmod/modprobe cycle, that hasn’t helped either.
However, I would have expected it to start when I:
debian@beaglebone:/lib/firmware$ sudo echo ‘start’ > /sys/class/remoteproc/remoteproc2/state
-bash: /sys/class/remoteproc/remoteproc2/state: Permission denied
Looking at dmesg, I see:
[22251.654264] remoteproc remoteproc2: powering up 4a338000.pru
[22251.654353] remoteproc remoteproc2: Direct firmware load for am335x-pru1-fw failed with error -2
[22251.654371] remoteproc remoteproc2: request_firmware failed: -2
[22251.665903] remoteproc remoteproc2: Boot failed: -2
The .out file is built with Ti v2.1.5 compiler under CCS - do I need to update my pru-software-support-package?
It would be handy if I could figure out what the -2 error code was.
$ errno 2
ENOENT 2 No such file or directory
make sure am335x-pru1-fw is in /lib/firmware/ and the initramfs
sudo update-initramfs -uk `uname -r`
Regards,
Tried both those fixes Robert, no joy. Is it still acceptable practice to symlink am335x-pru1-fw to our .out file?
Google led me to this post:
http://e2e.ti.com/support/processors/f/791/t/783113?Linux-AM3358-remoteproc-remoteproc0-Direct-firmware-load-for-tmp-PRU-LED1-out-failed-with-error-2
Where the OP had a fix which involved echo’ing the path of the PRU binary from /lib/firmware into /sys/class/remoteproc/remoteproc2/firmware. I’ve tried that also…
Have things changed in the move to 4.14 and uBoot overlays or should the old ways still work?
Reading it now, I’ll be back… Cheers for all your help up till now
My takeaway from Mark’s excellent writeup is that I should be able to copy my .out file into /lib/firmware with the correct naming convention.
I should then be able to echo ‘start’ or ‘stop’ to the correct state file. Which seems to be located at:
debian@beaglebone:/sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a300000.pruss/4a338000.pru/remoteproc/remoteproc2$ cat state
offline
For PRU1
Hmmm…
Fixed it…
sudo sh -c “echo ‘start’ > state” from within /sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a300000.pruss/4a338000.pru/remoteproc/remoteproc2
If anyone stumbles upon this thread - the attached script will allow init.d to start the PRU at boot time which the new pru_rproc driver doesn’t seem to do. In debian 8.7 with 4.4 kernels, it needed a reboot once the kernel module had loaded because of a bug creating the rpmsg entry in /dev. I’ve modified my pru-rebooting script to instead start the PRU.
Configure the script to start with the following:
-
Copy script to /etc/init.d
-
chmod 755 script
-
sudo update-rc.d start-pru.sh defaults
start-pru.sh (436 Bytes)