Starting the cortex-M7 firmware of my IM8MP

[ababatola]

Hello,

I followed the AN5317 on how to start the Cortex M7 of my IMX8MP custom board.  The result is mixed and I need some clarifications on this

i. Starting firmware automatically by remote PROC driver during Linux Kernel boot time does not work for me.  I tried all I can and read up similar issues on the formn but it still did not work.

After building the images and starting ´he linux image of my board, the cortex M7 is not started.  It's state is offline. But the firmware name is the name of my binary as an elf format. 

I checked the logs and extract from the log file is below:

Jan 1 00:00:06 vmr5-vlp4 user.err kernel: imx-rproc imx8mp-cm7: failed to find syscon
Jan 1 00:00:06 vmr5-vlp4 user.err kernel: imx-rproc imx8mp-cm7: mbox_request_channel_byname() could not locate channel named "txdb"
Jan 1 00:00:06 vmr5-vlp4 user.info kernel: imx-rproc imx8mp-cm7: No txdb, ret 0
Jan 1 00:00:06 vmr5-vlp4 user.info kernel: remoteproc remoteproc0: imx-rproc is available
Jan 1 00:00:06 vmr5-vlp4 user.warn kernel: remoteproc remoteproc0: Direct firmware load for spi_int_transfer_master.elf failed with error -2
Jan 1 00:00:06 vmr5-vlp4 user.info kernel: remoteproc remoteproc0: powering up imx-rproc
Jan 1 00:00:06 vmr5-vlp4 user.warn kernel: remoteproc remoteproc0: Direct firmware load for spi_int_transfer_master.elf failed with error -2
Jan 1 00:00:06 vmr5-vlp4 user.err kernel: remoteproc remoteproc0: request_firmware failed: -2

I tried looking into this log messages but I could not get the solution.

Please How can I start the firmware of the cortex M7 remotely using the PROC driver.

ii Booting firmware early using U-Boot and controlling firmware using SysFS interface :- this method works fine however I want to clarify, the command below 

$ echo start > /sys/class/remoteproc/remoteproc0/state

It only works when the firmware was already started in the Cortex M7 using u-boot command?  That means if the firmware is not started using u-boot command this option would not work?  And why was this designed like this?

iii  I need some clarity on the following instructions 

cp.b ${loadaddr} 0x7e0000 0x3f938
bootaux 0x7e0000

According to section 6.1 of the application note the address 0x7e0000 is in the Cortext-A53, why do we copy the binary to cortex-A53 and not to the Cortex-M7?

Also the bootaux command communicates with the cortex-A53 and not Cortex-M7?

Thanks

[Chavira]

Hi @ababatola!

Please check the chapter "9.1 9.1 i.MX Linux RPROC support" This chapter explains step by step the procedure to enable PROC support on iMX devices.

After the changes in dts enable the feature on the kernel and compile the new image, please check the chapter "9.1.1.1 Starting firmware using SYSFS interface", that chapter explains how to export the RPROC functionalities to UserSpace using SysFS.

Best Regards!
Chavira

[ababatola]

Hi,

Thanks for the reply. I would like to clarify:

The &rpmsg node status in my device tree

&rpmsg{
/*
* 64K for one rpmsg instance:
* --0x55800000~0x5580ffff: pingpong
*/
vdev-nums = <1>;
reg = <0x0 0x55800000 0x0 0x10000>;
status = "disabled";
};

is disabled.  Is the normal and would this not affect my the operation of my remoteproc? 

Thanks

[Chavira · Accepted solution]

Hi @ababatola!

"disable" in a node of the device tree means that the node is disabled.