This guide refers to Images built with Yocto Zeus.

Our Yocto Images support different features of the module.


Sleep Mode

You can suspend the system to RAM sleep mode.

Suspend to RAM

echo mem > /sys/power/state


To wake up the system different wakeup sources can be defined.

To find all wakeup properties run:

find /sys -name wakeup

EXAMPLE - Waking up after 15 seconds using RTC wakealarm:

echo +15 > /sys/class/rtc/rtc0/wakealarm; echo mem > /sys/power/state


Test the GPU

GLmark2 will only run smooth on processors having a GPU.

XDG_RUNTIME_DIR=/run/user/$UID glmark2-es2-wayland --fullscreen

Play a Video

Run the test screen of gstreamer:

XDG_RUNTIME_DIR=/run/user/$UID gst-launch-1.0 videotestsrc ! waylandsink

Cortex®-M4 development

Coprocessor Firmware Development

STM provides the STM32MP1 Developer Package to develop on Arm® Cortex®-M4 side.

For using this software, read the STM documentation provided here.


The following contents were only tested with Yocto Thud, Zeus is not tested yet.

Coprocessor Management Overview

  • The STM32 MPU multiprocessor system allows to run independent firmwares on each CPU core.
  • Basicly, on the Cortex®-A7 core a Linux OS is running.
  • The Linux OS is loading the firmware on the Cortex®-M4 core and controls it (start/stop). Therefore, the Linux OS integrates the RemoteProc framework.
  • Inter-processor communication of the two cores is based on RPMsg framework and Mailbox mechanisms.
  • For communication between the LinuxOs and the Cortex®-M4 software, virtual UARTs are implemented by the RPMsg framework.

Kernel Configurations needed

To use the RemoteProc and the RPMsg frameworks, be sure that they are enabled in your Linux kernel configuration using the Linux Menuconfig tool:

Device drivers  --->
    -*- Mailbox Hardware Support  --->
    <*> STM32 IPCC Mailbox
Device Drivers  --->
    Remoteproc drivers  --->
        <*> Support for Remote Processor subsystem
            -*-   Remoteproc System Resource Manager core
            -*-     Remoteproc System Resource Manager device
            <*>   STM32 remoteproc support
Device Drivers  --->
    Rpmsg drivers  --->
        <*> Virtio RPMSG driver
        <*> RPMSG tty driver

Device Tree Modifications needed

Some features must be configured in the Linux device tree:

  • reserved memory buffers, used by the RemoteProc framework
  • the Cortex®-M4
  • the mailbox registers
reserved-memory {
        #address-cells = <1>;
        #size-cells = <1>;

        retram: retram@0x38000000 {
                compatible = "shared-dma-pool";
                reg = <0x38000000 0x10000>;

        mcuram: mcuram@0x30000000 {
                compatible = "shared-dma-pool";
                reg = <0x30000000 0x40000>;

        mcuram2: mcuram2@0x10000000 {
                compatible = "shared-dma-pool";
                reg = <0x10000000 0x40000>;

        vdev0vring0: vdev0vring0@10040000 {
                compatible = "shared-dma-pool";
                reg = <0x10040000 0x2000>;

        vdev0vring1: vdev0vring1@10042000 {
                compatible = "shared-dma-pool";
                reg = <0x10042000 0x2000>;

        vdev0buffer: vdev0buffer@10044000 {
                compatible = "shared-dma-pool";
                reg = <0x10044000 0x4000>;

        gpu_reserved: gpu@d4000000 {
                reg = <0xd4000000 0x4000000>;

&m4_rproc {
        memory-region = <&retram>, <&mcuram>, <&mcuram2>, <&vdev0vring0>,
                <&vdev0vring1>, <&vdev0buffer>;
        mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
        mbox-names = "vq0", "vq1", "shutdown";
        interrupt-parent = <&exti>;
        interrupts = <68 1>;
        interrupt-names = "wdg";
        status = "okay";
&ipcc {
        status = "okay";

How to Control the Coprocessor

Basicly the Linux framework expects the firmware for the Cortex®-M4 coprocessor stored in the file system, by default in the /lib/firmware/ folder. Optionally another location can be set. In this case the remoteproc framework parses this new path in priority.

Below the command for adding a new path for firmware parsing:

echo -n <firmware_path> > /sys/module/firmware_class/parameters/path

To load the firmware into the coprocessor by the remoteproc framework, use this command:

echo -n <firmware_name.elf> > /sys/class/remoteproc/remoteproc0/firmware

Start the firmware with this comand:

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

This stops the remote processor:

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

For debugging the remote processor you can get debug messages via the remoteproc framework:

cat /sys/kernel/debug/remoteproc/remoteproc0/trace0