AM335X PRU_RPROC cannot boot any firmware PRU state offline

GoogleGroups
1

Hi, I’m trying to bring up the PRU on my BeagleBone Black. I was able to get it up using UIO method, but failed with PRU_RPROC driver.

The pru-software-support-package example compiled OK. I tried PRU_Direct_Connect0 and PRU_RPMsg_Echo_Interrupt1. I copied generated .out file to /lib/firmware. BTW, there was conflicting instructions online about how to place the .out file. One mentioned copying to FILE /lib/firmware/am335x-pru0(1)-fw, and another mentioned copy to under DIRECTORY /lib/firmware/am335x-pru0(1)-fw/. I tried both, and both failed with the same symptom.

I have the following output in dmesg, and it looks as if PRU_RPROC have not even tried to load the .out file.

[   77.864792] pruss 4a300000.pruss: creating PRU cores and other child platform devices
[   77.934664] remoteproc remoteproc1: 4a334000.pru is available
[   77.934794] pru-rproc 4a334000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[   77.936497] remoteproc remoteproc2: 4a338000.pru is available
[   77.936603] pru-rproc 4a338000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully



The state file under /sys/class/remoteproc/remoteproc2 is showing "offline"



my uEnv.txt file is below:
2

Pleae have a look at
https://groups.google.com/d/topic/beagleboard/b8W1W3z_xYA/discussion
regards

3

Thank you, Filippo! It was the exact same issue you mentioned in your post. I tried your solution and it worked like charm.

However, I have one more question. I actually tried to start the PRU using “sudo echo ‘start’ > /sys/class/remoteproc/remoteproc1/state” and it always failed with error “Permission denied”, while in your case, you used sudo sh -c "echo … Is there any significant difference between the two syntax?

4

On Mon, 24 Sep 2018 08:17:17 -0700 (PDT), Wei Shi
<weishisky@gmail.com> declaimed the
following:

However, I have one more question. I actually tried to start the PRU using "sudo
echo 'start' > /sys/class/remoteproc/remoteproc1/state" and it always
failed with error "Permission denied", while in your case, you used sudo sh
-c "echo ... Is there any significant difference between the two syntax?

  I believe the main difference is that the redirection is handled by
your user shell and only the command before it is passed to sudo.

5

This probably explained why my “sudo echo” got Permission denied.