Page Comparison

...

For further information, refer to official web site: FreeRTOS - Real-time operating system for microcontrollers

The startup of CM4 is controlled by the kernel through the use of remoteproc. Implemented control of each power domain when the system suspends/resumes. Includes polling wakeupkey to enter/exit deep-sleep mode. power down/up maindomain/ca55/npu/vcl power-domain and data communication with CA55 via virtIO.

Contents

Features

1. Output log at UART6 (set at 115,200 bps by x-boot).

2. Support SP7350 power manager

   • Detect wake-up key

   • Maindomain/CA55/NPU/VCL Power down/up control

   • Support DDR retention

   • Support PMIC control

3. Supports communication with CA55 via virtlOserial port

4. Support CmBacktrace to tracks and debug ARM Cortext-M4

5. Support arduino hardware interface, such as spi/i2c/uart/timer/gpio

6. Support Cunit test of spi/i2c/uart/timer/gpio driver

Default tasks

...

Linux remote processor framework

The Linux Remote Processor Framework is a framework that allows for managing(power on, load firmware, power off) and communicating with remote processors on Linux systems. This framework is typically used in embedded or multiprocessor systems where one processor (usually the main processor) is responsible for managing and controlling the other remote processors.In addition, this framework also adds rpmsg virtio devices for remote processors that supports this kind of communication. This way, platform-specific remoteproc drivers only need to provide a few low-level handlers, and then all rpmsg drivers will then just work

CM4 boot via CA55 cmd:

 echo start > /sys/class/remoteproc/remoteproc0/state

CM4 shutdown via CA55 cmd:

echo stop > /sys/class/remoteproc/remoteproc0/state

Linux remoteproc driver

The Remoteproc driver base on remote processor framework to implements firmware loading and booting, resource allocation and management, communication support, and other functions.

Enable remoteproc driver in kernel need to enable the configuration of (CONFIG_REMOTEPROC=y and CONFIG_SUNPLUS_REMOTEPROC=y)

Device-tree nodes for remoteproc driver

remoteproc0: remoteproc@f800817c {
		compatible = "sunplus,sp-rproc";
		firmware = "firmware";
		reg = <0 0xf800817c 0 4>, /* mbox G258.31, cpu0 to cpu2 direct reg07 */
		      <0 0xf8800250 0 4>,
		      <0 0xf80081fc 0 4>; /* mbox G259.31, cpu2 to cpu0 direct reg07 */
		interrupt-parent = <&gic>;
		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>; /* CPU2_TO_0_DIRECT_INT7 */
		resets = <&rstc RST_CM4>;
		memory-region = <&rproc_0_reserved>, <&rproc0runaddr>,<&vdev0buffer>, <&vdev0vring0>, <&vdev0vring1>;
	};

In the RemoteProc framework, vdev0vring0, vdev0vring1, and vdev0buffer are typically used in conjunction with Virtio devices for efficient data transfers between the host processor and the remote processor.

vring0 and vring1 represent the two virtual rings of a Virtio device, typically one for sending data and the other for receiving data. These two rings pass data and control information through a set of descriptors vbuffer represents the Virtio device's buffer, which is used to store data.

The remoteproc related dts configuration is as follows:

vdev0buffer: vdev0buffer@5be00000 {
	compatible = "shared-dma-pool";
	reg = <0x0 0x5be00000 0x0 0x100000>;
	no-map;
};
vdev0vring0: vdev0vring0@5bf00000 {
	compatible = "shared-dma-pool";
	reg = <0x0 0x5bf00000 0x0 0x10000>;
	no-map;
};
vdev0vring1: vdev0vring1@5bf10000 {
	compatible = "shared-dma-pool";
	reg = <0x0 0x5bf10000 0x0 0x10000>;
	no-map;
};

RPMSG and virtual IO

The RPMsg framework (Remote Processor Messaging Framework) is an implementation of remote processor messaging. It allows communication between different processors, including communication between the main processor and remote processors, and it is a VirtIO-based message bus that allows kernel drivers to communicate with remote processors in the system.

Enable RPMSG and VirtIO in kernel need to enable the configuration of (CONFIG_RPMSG=y and CONFIG_RPMSG_VIRTIO=y)

RPMSG：After CM4 is running, a device node /dev/ttyRPMSGx is generated on the kernel side, and the kernel side communicates with CM4 via /dev/ttyRPMSGx.

VirtIO：Virtio is a standard for high-performance virtual appliances in virtualized environments, CM4 write/read VirtioSerial to transfer data to /dev/ttyRPMSGX

Build image

Use “make firmware" in the root directory to compile the Freertos code，The output file after compilation is bin/firmware, need to copy this file to /linux/rootfs/initramfs/disk/lib/firmware under rootfs.

This project includes several code environments, including FREERTOS+Arduino(default), Arduino, and Cunit, and the different code environments are determined by the configuration of the Makefile.

• FREERTOS+Arduino: The default compiled image is based on the Freertos environment, Implemented power management function for suspend/resume process.

• Arduino: set FREERTOS ?=0 in Makefile will compile the code environment with only arduino, not FREERTOS. the entry function of the program is in /application/arduino_main.cpp

• Cunit：set CUNIT ?=1 in Makefile Compiled code contains only Cunit test code. include spi/i2c/uart/timer/gpio test units

Supported drivers for SP7350 platform

Source files

The source files of FreeRTOS are organized within the "firmware/arduino_core_sunplus/" directory at the top level of the project. Below is a breakdown of the main subdirectories:

Example files

CUnit is a C unit testing framework for unit testing C programs. It provides a set of libraries and macros for writing and executing test cases and reporting test results.CUnit tests include examples using the sp7350 peripheral interface driver. Includes examples for other drivers such as spi/i2c/uart/gpio/pwm.

the path is /application/Cunit_test. set CUNIT ?=1 in Makefile to build image. the code will run from Cuint_main.cpp