"mailbox not free" error when initializing remoteproc driver at Linux boot

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

"mailbox not free" error when initializing remoteproc driver at Linux boot

Jump to solution
1,156 Views
v-bertin
Contributor II

Hello everyone,

I have an issue during the initialization of remoteproc driver while Linux boots.

The driver requests a mailbox channel using the mailbox interface (mbox_request_channel_byname), but it fails and I have this error "mailbox not free" (drivers/mailbox/mailbox.c:370).

The error appears because chan->cl is alread initialized ... which probably means the mailbox has already attributed this channel to some other components. I don't really know.

Has someone already encountered this error ?

Please find enclosed my device tree configuration.

Thank you in advance for your help

0 Kudos
Reply
1 Solution
1,122 Views
v-bertin
Contributor II

Hello everyone, Hello @Dhruvit ,

We manage to get over this error.

To write our RPMsg / remoteproc device tree configuration for my iMX8MP based board, we were using the device tree configuration Freescale suggests for the iMX8MP-EVK (in arch/arm64/boot/dts/freescale/{imx8mp.dtsi, imx8mp-evk-rpmsg.dts}).

In this configuration, they use the same channel numbers (channel number 1) both for remoteproc (imx8mp-cm7 dts node) and RPMsg (rpmsg dts node). For us, it did not work. The mailbox was allocating channels 1 to RPMsg and then it crashes (the kernel panic described in the original post) while trying to allocate those same channels for remoteproc ...

We had to change the channel numbers used by rpmsg : we have overwritten the channel numbers automatically given in imx8mp.dtsi by our own ones. We succesfully used channel numbers 3.

You can find below the final RPMsg and remoteproc dts configuration we used.

For RPMsg :

 

&rpmsg{
	/*
	 * 64K for one rpmsg instance:
	 * --0x55000000~0x5500ffff: pingpong
	 */
	vdev-nums = <1>;
	reg = <0x0 0x55000000 0x0 0x10000>;
	mbox-names = "tx", "rx", "rxdb";
	mboxes = <&mu 0 3
			&mu 1 3
			&mu 3 3>;
	memory-region = <&vdevbuffer>;
	status = "okay";
};

 

 For remoteproc :

imx8mp-cm7 {
	compatible = "fsl,imx8mn-cm7";
	rsc-da = <0x55000000>;
	clocks = <&clk IMX8MP_CLK_M7_DIV>;
	mbox-names = "tx", "rx", "rxdb";
	mboxes = <&mu 0 1
		  &mu 1 1
		  &mu 3 1>;
	memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
	status = "okay";
};

 Hope it can help other people !

Victor

View solution in original post

3 Replies
1,123 Views
v-bertin
Contributor II

Hello everyone, Hello @Dhruvit ,

We manage to get over this error.

To write our RPMsg / remoteproc device tree configuration for my iMX8MP based board, we were using the device tree configuration Freescale suggests for the iMX8MP-EVK (in arch/arm64/boot/dts/freescale/{imx8mp.dtsi, imx8mp-evk-rpmsg.dts}).

In this configuration, they use the same channel numbers (channel number 1) both for remoteproc (imx8mp-cm7 dts node) and RPMsg (rpmsg dts node). For us, it did not work. The mailbox was allocating channels 1 to RPMsg and then it crashes (the kernel panic described in the original post) while trying to allocate those same channels for remoteproc ...

We had to change the channel numbers used by rpmsg : we have overwritten the channel numbers automatically given in imx8mp.dtsi by our own ones. We succesfully used channel numbers 3.

You can find below the final RPMsg and remoteproc dts configuration we used.

For RPMsg :

 

&rpmsg{
	/*
	 * 64K for one rpmsg instance:
	 * --0x55000000~0x5500ffff: pingpong
	 */
	vdev-nums = <1>;
	reg = <0x0 0x55000000 0x0 0x10000>;
	mbox-names = "tx", "rx", "rxdb";
	mboxes = <&mu 0 3
			&mu 1 3
			&mu 3 3>;
	memory-region = <&vdevbuffer>;
	status = "okay";
};

 

 For remoteproc :

imx8mp-cm7 {
	compatible = "fsl,imx8mn-cm7";
	rsc-da = <0x55000000>;
	clocks = <&clk IMX8MP_CLK_M7_DIV>;
	mbox-names = "tx", "rx", "rxdb";
	mboxes = <&mu 0 1
		  &mu 1 1
		  &mu 3 1>;
	memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
	status = "okay";
};

 Hope it can help other people !

Victor

601 Views
Majidbahmani
Contributor II

Hi,

Your post was very helpful. Could you please explain what is the second argument in mboxes?

mboxes = <&mu 0 1
          &mu 1 1
          &mu 3 1>;
 
Thank you.
0 Kudos
Reply
1,130 Views
Dhruvit
NXP TechSupport
NXP TechSupport

Hi, @v-bertin,

Yes, you are right.
The mailbox may have already attributed this channel to some other components.

0 Kudos
Reply