m4ctrl for IMX8M Mini EVK 5.4.24-2.1.0

[sergei_p]

Hello all,

I started to port the m4ctrl utility which we used successfully to control M4 applications on IMX8M-MINI/4.14.78, to 5.4.14-2.1.0 release and stuck on building the m4ctrl_dev kernel module:

kernel-module-m4ctrl/kernel/m4ctrl_dev.c:32:1: error: unknown type name 'sc_ipc_t'
..
kernel-module-m4ctrl/m4ctrl_dev.c:33:1: error: unknown type name 'sc_rm_pt_t'

Respectively,  the functions which used these types in 4.14.78 (sc_pm_set_resource_power_mode(), etc) are not present in 5.4.24.

I checked with the m4ctrl repo on codeaurora, there are no updates.

Is there any way to get m4ctrl and m4ctrl_dev.ko for 5.4.24?

Thanks!

Regards,

Sergei

[igorpadykov]

Hi Sergei

I will check internally and update.

Best regards
igor

[igorpadykov]

Hi Sergei

I was adviced below:

------------------------

What about remoteproc driver?

  On 5.4.x kernel, there's a remoteproc driver which can be used to send firmware to M4 from A9 user space.

  User needs to change default dtb to xxx-m4.dtb.

  For details, see 4.1.1 in https://wiki.st.com/stm32mpu/wiki/Linux_remoteproc_framework_overview

  Some notes on using remoteproc on i.MX soc:

1. firmware must be put under /lib/firmware.
2. We don't recommend to use stop, which needs M4 to enter IDLE mode itself.
3. The image file must be in elf format.

------------------------

Regarding m4ctrl tool, developer answered:

"The plan is to publish on codeaurora when bandwidth will allow ..."

Best regards
igor

[craigmcqueenir]

You said, "We don't recommend to use stop, which needs M4 to enter IDLE mode itself."

Using stop is useful during development, so we don't have to reboot the system every time we make a change. Is it possible to add a feature to my M4 code to make the M4 enter IDLE mode? What would be the procedure for doing that?

[andreasbuchner]

Hello Igor,

thanks for pointing out that the remoteproc framework is integrated in the 5.4.24 kernel. With your steps I could load and start the M4 with sysfs commands (https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-remoteproc).

I also tested to stop ($> echo stop >/sys/class/remoteproc/remoteproc0/state) and restart the M4, which you did not recommend. This works as well (M4 really stops). However, if I stop, then load a different firmware and then start again, the old firmware will restart even if the linux console printout and sysfs response indicates that a different firmware was loaded. Possibly the reason is that the driver does not put the M4 to idle.

So my question: Would it be possible to add that feature in a later kernel release? From a user point of view this would improve usability a lot. Also this means that the driver follows the expected behavior:

* see link above "To change the running firmware, ensure the remote processor is stopped (using /sys/class/remoteproc/.../state) and write a new filename."

* in the link of ST you pasted it is allowed to use stop as well.

Bonus question: Is there a better way to request that feature than through this forum?

Thanks for your response,

Andreas

[craigmcqueenir]

I have much the same question. I'm doing a Yocto build for i.MX8MM, with kernel 5.4.83. I have modified the kernel configuration and the device tree to support remoteproc and rpmsg. I am able to load the imx8mm_m4_TCM_rpmsg_lite_str_echo_rtos.elf demo binary into the M4, and load the imx_rpmsg_tty.ko module to talk to it. So that is all good.

I have also been able to modify the source code for the M4 code, build it, and copy the binary to the target board. But if I try to stop then restart the M4, it runs the old M4 binary. If I reboot the whole system, then it starts running the new M4 binary.

What can be done to load and run a new M4 binary, without restarting the whole system?

[sergei_p]

Thanks Igor. Is remoteproc supported by the NXP releases for IMX8M Mini? In the documentation, I only see the references to the "bootaux" M4 loading method.