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
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.
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?
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.
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.
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.
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.
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.
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! ) I expect you to have:
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
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
) I expect you to have: