Use remoteproc to start M7 core on Verdin iMX8M-Plus

In the past few months I’ve been able to start M7 coreof Verdin iMX8M-Plus (or Mini) loading the firmware and running it from u-boot.
The following topics:

Last week I talked to @stefano.tx and he told me that now (November 2023), remoteproc approach should work.
And so I tried.
I followed the steps here and this paragraph in particular.
But it doesn’t work.
Here is what happens

# echo start > /sys/class/remoteproc/remoteproc0/state
[   644.366723] remoteproc remoteproc0: powering up imx-rproc                                                                              [   644.366844] remoteproc remoteproc0: Direct firmware load for firmware_imxcm7.elf failed with error -2
[   644.366857] remoteproc remoteproc0: request_firmware failed: -2
[   644.372849] remoteproc remoteproc0: Boot failed: -2

What could be the issue?

Hi @vix !

I just answered a related question here:

As you can see, it worked for me.

Could you please follow each step of the article How to Use RemoteProc | Toradex Developer Center and share the output here?

Also, please share the output of tdx-info.

Best regards,

Hi @henrique.tx
I think I didn’t explain well what happens.
If I follow the Toradex steps (that you described in your post) everything works.
No problem.
The method to load the firmware is EXT4LOAD Loading Method. This means from U-Boot.

Some months ago, loading the firmware using remoteproc kernel module

$ sudo -s
$ cd /sys/class/remotreproc/remoteproc0/
$ echo stop > state
$ echo rpmsg_lite_str_echo_rtos_imxcm4.elf > firmware
$ echo start > state

was not 100% reliable.
With some firmware it worked, with some other it didn’t work.
If U-Boot has already loaded and started a firmware, sometimes it works.
If U-Booot hasn’t loaded and started a firmware, it doesn’t work.
Or it seems so.

As I wrote, when I talk to @stefano.tx a couple of weeks ago, he told me that this method should work now. And he asked me to try, and to report any issue.

This is the reason of this topic.

Hi @vix !

Thanks for the explanation.

I just tried it on Verdin iMX8MP Q 4GB WB IT V1.0B with Torizon OS 6.5.0-devel-202311+build.14.

Indeed when previously starting Cortex-M7 with the firmware on U-Boot, seems like remoteproc works more reliably.

If the Cortex-M7 is not started on U-Boot, remoteproc fails.

I will bring this up internally.

Thanks for reporting!

Best regards,

Hi @vix !

By the way, is this currently blocking you in any way?

Always starting the Cortex-M7 from U-Boot seems to be a good workaround to make remoteproc work reliably. Is this workaround suitable for you at the moment?

Best regards,

Hi @henrique.tx

if U-Boot is used to start the firmware, the .bin must be included in the Torizon OS build.
And so every firmware update requires a Torizon OS update.
For this reason, this an acceptable short-term solution.
For the long term we would prefer using remoteproc so that the firmware can be deployed and updates in its own container.

Hi @vix !

This is indeed a way of doing it, but please keep in mind that you can use the Torizon Subsystem Update to avoid performing an OS update. Please take a look at this article about Subsystem Updates Overview | Toradex Developer Center

An article with an actual example of how to use it is currently in the works and should be available soon.

Best regards,

Do you have any news on this issue @henrique.tx?
I’ve been creating an automated pipeline to build and deploy TorizonCore + my containers.
And I don’t find a way to automate the deploying of a u-boot firmware.

Now this is a blocking task for my project.

Hi @vix !

Thanks for letting us know how this affects your project.

In my last message, I told you about Torizon Subsystem Update, so the Cortex-M firmware can be loaded during boot, therefore remoteproc is not needed to start Cortex-M. Not to mention that Cortex-M will start earlier, which can be advantageous.

Doesn’t it help you?

Hi @henrique.tx
it can be, but I’m not sure if I will use Torizon Cloud in the project (it’s under investigattion at the moment).
The task is setup the pipeline(s) to produce a TEZI image for my project.
Do you have an idea on how a pipleine can pull a specific binary (produced by another pipeline)?
I use Azure DevOps Péipelines, but if you can provide an example for GitHub or Gitlab I can take inspiration.

Hi @vix !

Could you explicitly point out where/what is the issue?

I am not experienced with CI/CD pipelines, but since you are using this approach (very nice! :slight_smile: ) I expect you to have:

  1. a repository with the code for your Cortex-M and a pipeline built in there which can build the Cortex-M binary and create releases, and
  2. a repository to build your customized Torizon OS (using TorizonCore Builder), which would get (wget, curl, etc) the binary released from the Cortex-M repository.
    2.1. the binary should be placed in the right path in your tcbuild.yaml by using the filesystem from customization (see more about it in TorizonCore Builder Tool “build” command | Toradex Developer Center).

Since we are talking about repositories and CI/CD, please also check the tips in the section
Version Controlling of the tab Detailed manual of the link above.

After asking internally for some tips, I was pointed to Job artifacts | GitLab documentation.

Here is the idea of a possible implementation (not tested, of course) that was shared with me.

# project that creates the M4 binary
# the project ID is 1234556
build-m4-fw:
  script: my-script.sh -o path/to/artifact/m4.bin
  artifacts:
    paths:
      - path/to/artifact/m4.bin

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

# project that builds the custom image with TCB
build-tcb:
  scripts: |
             wget https://gitlab.com/api/v4/projects/1234556/jobs/artifacts/main/download?job=build-m4-fw
             torizoncore-builder build

Let us know if this helps you.

Best regards,