How to Use RemoteProc
Introduction
The goal of this article is to provide information on how to configure and use the remote processor framework, also known as RemoteProc (rproc), to exchange data between two cores of different architectures.
The use of *.elf binaries is only supported on RemoteProc, in other words, if you want to control the Cortex-M cores from the Linux side. To load and run *.bin files, you must do it from U-boot as described in How to Load Compiled Binaries into Cortex-M.
Why RemoteProc
The remote processor (rproc) framework serves as a robust solution for managing remote processor devices within modern System-on-Chips (SoCs) and is particularly geared towards heterogeneous multicore processing (HMP) setups. This innovative framework provides the means to control various aspects of remote processors, such as loading and executing firmware, all while effectively abstracting the underlying hardware differences. Furthermore, it extends its utility by offering services for monitoring remote coprocessors, thereby ensuring management and operation.
Prerequisites
- Follow the steps at Setting Up MCUXpresso SDK and Toolchain for Cortex-M development.
- Understanding of how to load compiled binaries into Cortex-M.
- Understanding of how to debug Cortex-M using JTAG (Cortex-M JTAG Debugging).
Setting up and Enabling the Remoteproc
Toradex provides a series of device tree overlays to help you with an out-of-the-box experience with Heterogeneous Multicore Processing, including the remoteproc framework.
Check the following table for information about the status of the overlays:
| Overlay | Status | Device Tree Overlays Repository Branch |
|---|---|---|
| verdin-imx8mp_hmp_overlay.dts | Available | toradex_5.15-2.2.x-imx |
| verdin-imx8mp_hmp_overlay.dts | Coming soon | master |
| verdin-imx8mm_hmp_overlay.dts | Available | toradex_5.15-2.2.x-imx |
| verdin-imx8mm_hmp_overlay.dts | Available | master |
| verdin-am62_hmp_overlay.dts | Available | toradex_ti-linux-6.1.y |
| apalis-imx8_hmp_overlay.dts | Coming soon | toradex_5.15-2.2.x-imx |
| colibri-imx8x_hmp_overlay.dts(*1) | Available | toradex_5.15-2.2.x-imx |
| colibri-imx7_hmp_overlay.dts | Coming soon | master |
(*1): Note that this overlay only works to enable RPMsg.
For overlays marked as available, they are pre-compiled (*.dtbo) into Torizon OS and our BSP reference images. Their source code is also available on Toradex device-tree-overlays.git repository under the specific branch.
If you are interested in the DTOs marked as "coming soon", get in touch with us on the Toradex Community.
Enable the related device tree overlay by replacing the right *.dtbo on the overlays.txt file. For more information on this topic, refer to First Steps with Device Tree Overlays.
You can check if it was correctly enabled using dmesg:
# dmesg | grep -E "remote|rproc"
[ 1.629455] remoteproc remoteproc0: imx-rproc is available
You need a special kernel command line argument for remoteproc to be functional.
Add either clk-imx8mp.mcore_booted=1 or clk-imx8mm.mcore_booted=1 to the kernel command line and reboot before following the rest of this document.
You can add the command-line argument using the fw_setenv command from the Linux user space, as shown in the following example:
fw_setenv tdxargs "clk-imx8mm.mcore_booted=1"
Starting and Using Remoteproc from Sysfs
Remoteproc exports the rproc functionalities to userspace using sysfs:
# ls /sys/class/remoteproc/remoteproc0/
consumers device firmware name power state subsystem suppliers uevent
By default, remoteproc driver looks for a *.elf firmware stored inside /lib/firmware. In other words, you can copy and store the binary for your application under the /lib/firmware directory.
$ scp hello_world.elf root@<board-ip>:/lib/firmware
hello_world.elf 100% 235KB 1.4MB/s 00:00
However, if the firmware is not stored at the default location, its location can be updated by changing the parameter path.
# echo -n new_path > /sys/module/firmware_class/parameters/path
Since Torizon OS has a Read Only filesystem, it will not allow the firmware to be stored at the default location. In this case, copy it to another location (for example, /tmp/) and update the path accordingly.
Before starting to work with the remote processor, make sure it's state is offline. If you try to perform the next steps with the core running, it will give you an error.
# echo stop > /sys/class/remoteproc/remoteproc0/state
# cat /sys/class/remoteproc/remoteproc0/state
offline
To load the uploaded firmware, write its name to /remoteproc/remoteprocX/firmware.
# echo <firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
Make sure to run a *.elf firmware, otherwise it will not work.
To start the remote processor with the new firmware, write start to the state file:
# echo start > /sys/class/remoteproc/remoteproc0/state
[12594.692880] remoteproc remoteproc0: powering up imx-rproc
[12594.698629] remoteproc remoteproc0: Booting fw image hello_world.elf, size 240736
[12594.706192] remoteproc remoteproc0: no dtb rsrc-table
[12594.761474] remoteproc remoteproc0: remote processor imx-rproc is now up
To stop the remote processor, just write stop to the state file.
# echo stop > /sys/class/remoteproc/remoteproc0/state
[12730.280168] remoteproc remoteproc0: stopped remote processor imx-rproc
The state of the remote processor can be offline or running. To check it, read the content of the file state:
# cat /sys/class/remoteproc/remoteproc0/state
offline
# echo start > /sys/class/remoteproc/remoteproc0/state
[ 1459.598770] remoteproc remoteproc0: powering up imx-rproc
[ 1459.604504] remoteproc remoteproc0: Booting fw image hello_world.elf, size 240736
[ 1459.612841] remoteproc remoteproc0: no dtb rsrc-table
[ 1459.668208] remoteproc remoteproc0: remote processor imx-rproc is now up
# cat /sys/class/remoteproc/remoteproc0/state
running