pruss_remoteproc silently fails to install

Bob,

I'm sorry to hear you are having trouble. What dts file are you using? There are rproc entries needed in the dts/dtb file as well. This is the first thing I can think of that might cause this issue. This should have been in one of the patches provided with the package, but if you didn't rebuild the dts/dtb file, you wouldn't have them.

As you mentioned, the first 4 insmods don't provide any feedback as shipped, but the last, pruss_remoteproc.ko, should spit out all kinds of cool stuff.

Hi Ron,

Thanks.  You seem to have been right that the device tree was not correct.  I verified that the patch had been installed to the am33xx.dtsi file and then re-compiled my device tree.  Now I get one error message. 

platform data (reset configuration information) missing.

Here is the relevant part of the device tree...

resets = <&prcm 1>;
};

pruss: pruss@4a300000 {
	compatible = "ti,am335x-pruss";
	ti,hwmods = "pruss";
	reg = <0x4a300000 0x2000>,
	      <0x4a302000 0x2000>,
	      <0x4a310000 0x3000>,
	      <0x4a320000 0x2000>,
	      <0x4a326000 0x2000>;
	reg-names = "dram0", "dram1", "shrdram2", "intc", "cfg";
	interrupts = <20 21 22 23 24 25 26 27>;
	#address-cells = <1>;
	#size-cells = <1>;
	ranges;
		pru0: pru@4a334000 {
		compatible = "ti,pru-rproc";
		reg = <0x4a334000 0x2000>,
		      <0x4a322000 0x400>,
		      <0x4a322400 0x100>;
		reg-names = "iram", "control", "debug";
	};

	pru1: pru@4a338000 {
		compatible = "ti,pru-rproc";
		reg = <0x4a338000 0x2000>,
		      <0x4a324000 0x400>,
		      <0x4a324400 0x100>;
		reg-names = "iram", "control", "debug";
	};
};

elm: elm@48080000 {
	compatible = "ti,am3352-elm";

Bob,

Hmmm, yours looks different than mine. Did you get any failures when you applied the patch? I'm also assuming you are applying patch 0010-ARM-dts-AM33xx-Add-the-PRUSS-DT-node.patch?

Hi Ron,

I did apply patch 10.  Thats how I got what I have shown you.  I downloaded the patches maybe a week ago, so I should have the latest.  Can you post what the differences are between yours and mine?

However, I have now managed to get the remoteproc driver to start working.  The problem seemed to be that there were dependencies in the kernel for remoteproc.  I rebuilt the kernel and got further.  Now I get this...

[ 23.565021] pruss-rproc 4a300000.pruss: creating platform devices for PRU cores
[ 23.574773] remoteproc0: 4a334000.pru0 is available
[ 23.580119] remoteproc0: Note: remoteproc is still under development and considered experimental.
[ 23.589627] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 83.682599] remoteproc0: failed to load rproc-pru0-fw
[ 83.688139] pru-rproc 4a334000.pru0: booting the PRU core manually
[ 83.694697] remoteproc0: powering up 4a334000.pru0
[ 143.842592] remoteproc0: request_firmware failed: -2
[ 143.848123] pru-rproc 4a334000.pru0: rproc_boot failed
[ 143.853679] pru-rproc: probe of 4a334000.pru0 failed with error -2
[ 143.860595] remoteproc1: 4a338000.pru1 is available
[ 143.865866] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 143.875308] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 143.889890] pru-rproc 4a338000.pru1: booting the PRU core manually
[ 143.896566] remoteproc1: powering up 4a338000.pru1
[ 143.902071] pru-rproc 4a338000.pru1: rproc_boot failed
[ 143.907680] pru-rproc: probe of 4a338000.pru1 failed with error -12

I only have a firmware load for PRU1.  It is just a compile  and link of the button_led_0 example so I don't expect it to work properly in PRU1 anyway.  The next task is to get something to actually work.

A couple of questions though.

1) Do I need to have a load for PRU0 in order to get past the 120 second delay before it even tries to load PRU1?

2) Is there any good documentation that you can point me to that explains remoteproc and the virtio mechanism for communicating between the arm core and the PRUs?

Thanks for all your help.

Bob

Glad to see you made some progress.

Bob Koen said:

1) Do I need to have a load for PRU0 in order to get past the 120 second delay before it even tries to load PRU1?

That would be the easiest way, yes. It can simply just halt.

Bob Koen said:

2) Is there any good documentation that you can point me to that explains remoteproc and the virtio mechanism for communicating between the arm core and the PRUs?

Unfortunately, not yet. We are working on an example and a new rpmsg client driver to expose the buffers to userspace. You can read the kernel docs for remoteproc, rpmsg, and virtio, but a lot of that capability is not yet there for PRU.

So what is the recommended way today to communicate between a PRU and a user space application in Linux?

Can you comment on the differences between the device tree for the PRUs that I have and the device tree that you have? You mentioned that mine did not look like yours, yet I got mine from a recent download of patch 0010.