firmware loads fail, remoteproc error codes

[Hugh Frater]

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.

[Robert Nelson]

$ 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,

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

[Hugh Frater]

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?

[Robert Nelson]

On Tue, May 28, 2019 at 10:41 AM Hugh Frater <hugh....@gmail.com> wrote:
>
> 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?

Take a look at Mark's writeup:

https://markayoder.github.io/PRUCookbook/

[Hugh Frater]

Reading it now, I'll be back... Cheers for all your help up till now

[Hugh Frater]

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.... 

[Hugh Frater]

Fixed it...

sudo sh -c "echo 'start' > state" from within /sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a300000.pruss/4a338000.pru/remoteproc/remoteproc2

[Hugh Frater]

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:

1. Copy script to /etc/init.d

2. chmod 755 script

3. sudo update-rc.d start-pru.sh defaults