1. Overview

This project provides support for the RPMGS-based communication between Linux (uClinux) running on the Cortex-M7 processor core and an application running on the Cortex-M4 processor core, in the i.MX RT1170 uClinux BSP.

RPMsg is a virtio-based messaging bus, which allows kernel drivers to communicate with remote processors available on the system. In turn, drivers could then expose appropriate user space interfaces if needed. Every RPMsg device is a communication channel with a remote processor (so the RPMsg devices are called channels). Channels are identified by a textual name and have a local ("source") RPMsg address, and remote ("destination") RPMsg address. For more information, see www.kernel.org/doc/Documentation/rpmsg.txt.

1.1. Requirements

1.2. Detailed Requirements

The following are the requirements for this project:

1. Support loading and starting applications to the i.MXRT1170 CM4 core.

   • Rationale: To allow loading CM4 binaries from Linux session.
     Implementation: Section: "Design: Support Loading and Starting Applications on the i.MX RT1170 CM4 Core".
     Test: Section: "Test Plan: Support Loading and Starting Applications on the CM4 Core".
     
     

2. Support RPMSG-based communications between Linux and an application running on the CM4 processor core.

   • Rationale: Pre-requisite to porting customer's RTOS application.
     Implementation: Section: "Design: Support RPMSG-based Communications Between Linux and an CM4 Application".
     Test: Section: "Test Plan: Support RPMSG-based Communications Between Linux and a Application".
     
     

3. Develop a demo application for the CM4 core. Document build workflow for the CM4 core.

   • Rationale: Pre-requisite to support RPMSG.
     Implementation: Section: "Design: Develop a Demo Application for the CM4 Core".
     Test: Section: "Test Plan: Develop a Demo Application for the CM4 Core".

1.3. Detailed Non-Requirements

The following are the non-requirements for this project that may otherwise not be obvious:

1. Multiple Cortex-M4 reset/load cycle from a single Linux session is not supported.

   • Rationale: i.MRT1170 does not allow to stop CM4 core once it has been started.

2. Design

2.1.

Design: Support Loading and Starting Applications on the i.MX RT1170 CM4 Core

The Linux Remote Processor framework (remoteproc) will be used to run an application on the CM4 Core. The remoteproc framework allows different platforms/architectures to control subordinate processor cores (power on, load firmware, power off). It provides user-space interface via the sysfs file system to specify the firmware image for the the remote core and run it.

The following Linux command will be used to point out to the remoteproc framework a specific CM4 binary in /lib/firmware:

• echo -n <application_name.elf> > /sys/class/remoteproc/remoteprocX/firmware

The following Linux command will be used to load and start the application binary on the CM4 core:

• echo start > /sys/class/remoteproc/remoteprocX/state

The stop command will not be implemented since i.MXRT1170 processor doesn't allow to stop the CM4 Core.

NXP provides drivers/remoteproc/imx_rproc.c driver to support remoteproc on the IMX SoCs for such as i.MX6/7, i.MX8/9 families. This driver will be updated to support i.MXRT1170 as well:

• the specific to i.MXRT1170 method to start the remote core will be added

• i.MXRT1170 CM4 OCRAM (CM4 TCM) region will be configured in the address translation table to be used as a shared memory for CM7 and CM4 cores

The driver depends on other components, such as Clock Controller, Reset Controller, IOMUXC LPSR GRP, Messaging Unit and requires reserving specific memory regions. The corresponding drivers be enabled and configured in the kernel, and used in the rpoc device node as follows:

• clocks: CCM's M4 root and gate clocks will be implemented in the i.MXRT1170 clock driver and passed to the rproc driver

• mboxes: the compatible with i.MXRT1170 Messaging Unit driver for i.MX6SX will be used to provide message boxes

• memory-region: a phandle for a reserved memory area that used for vdev buffer, resource table, vring region and others used by remote processor

• syscon: the regmap for the System Reset Controller will be passed to the rproc driver to support booting the CM4 Core

• lpsr_gpr: the regmap for the IOMUXC LPSR General Porpose Registers will be passed to the rproc driver to support specifying the start address for the CM4 Core boot

Also the dts file for the imxrt1170 BSP will be updated to define the following nodes to provide support for the RPMSG framework:

• vdev0vring0 - vring buffer used for RPMGS communication;

• vdev0vring1 - vring buffer used for RPMGS communication;

• vdevbuffer - vdev buffer used for communication with remote processor;

• rsc_table - resources table used for checking by the imx_rproc.c driver.

2.2.

Design: Support RPMSG-based Communications Between Linux and an CM4 Application

NXP provides the kernel module imx_rpmsg_pingpong for Linux to demonstrate RPMSG-based communications between Linux and an application running on the co-processor core. The module is common for the i.MX Processors and is applicable for i.MXRT1170 as is. It implements a simple pingpong demo in which the CM7 application sends a number to CM4 through RPMSG, CM4 increments this number and send the result back to CM7, CM7 prints the number to console, increments and repeats again.

The rootfs demo project will be configured to build the imx_rpmsg_pingpong module automatically and include it to initramfs in uImage to /lib/modules/. On the target board the insmod command can be used to run the demo on the Linux (CM7) side:

2.3.

Design: Develop a Demo Application for the CM4 Core

NXP doesn't provide a firmware for i.MXRT1170 CM4 core compatible with their Linux module imx_rpmsg_pingpong, but there is the analogous demo for FreeRTOS in MCUX SDK v 2.16. CM4 part of this demo i.e. rpmsg_lite_pingpong_rtos_cm4 application the will be used as a firmware to be run on the CM4 core.

Since protocols used in NXP examples for Linux and FreeRTOS differ, the rpmsg_lite_pingpong_rtos_cm4 application will be updated to allow working with Linux. Namely, the following changes will to be done:

• excluded usage of MCMGR framework in the application code

• defined the shared memory address (RPMSG_LITE_SHMEM_BASE macro)

• added the resource table to the application code

arm-none-eabi toolchain must be used on the development host for building the demos from the MCUX SDK v 2.16.

To install the arm-none-eabi toolchain:

• On a Fedora development host, use sudo dnf install arm-none-eabi-gcc-cs arm-none-eabi-gcc-cs-c++.

• On a Ubuntu host version prior to 18, use sudo apt-get install arm-none-eabi.

To build the Demo Application go to the rpmsg_lite_pingpong_rtos_cm4 directory and perform the following:

For the convenience, the Demo Application for the CM4 Core will be integrated into the rootfs project and will be resided in the firmware/CM4 directory. To build the demo, go to the rootfs project and run the make command:

The CM4 demo application is developed to run from CM4 TCM, refer to the linker script firmware/CM4/rpmsg_lite_pingpong_rtos_cm4/MIMXRT1176/gcc/MIMXRT1176xxxxx_cm4_ram.ld for details. The shared buffers for the RPMSG communications are allocated at the end of CM4 TCM (OCRAM M4 in terms of the CM7 memory map) using the RPMSG_LITE_SHMEM_BASE macro in the source/main_remote.c file as follows: