Personal tools

Running a Cortex-M4 application on visionsom-stm32mp1

From SomLabs Wiki

Revision as of 10:51, 19 October 2020 by KrzysztofChojnowski (talk | contribs) (Created page with "{{PageHeader|Running a Cortex-M4 application on VisionSOM-STM32MP1}} __toc__ This article explains how to configure the OpenSTLinux system for running a Cortex-M4 application...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Running a Cortex-M4 application on VisionSOM-STM32MP1


This article explains how to configure the OpenSTLinux system for running a Cortex-M4 application. In this tutorial an example code as well as the required kernel modules from STMicroelectronics will be used. This tutorial was prepared for the openstlinux-5.4-dunfell-mp1-20-06-24 with the SoMLabs dunfell meta-layer available on github: https://github.com/SoMLabs/openst-meta-somlabs/tree/dunfell

Modifying the device tree

To configure the Cortex-M4 access from Linux some changes in the SoMlabs meta-layer device tree are required. The following device tree sections need to be added in the following files, depending on the used display version (RGB or DSI):

  • mx/visionsom-dsi-mx/kernel/stm32mp157a-visionsom-dsi-mx.dts
  • mx/visionsom-dsi-mx/u-boot/stm32mp157a-visionsom-dsi-mx.dts

or

  • mx/visionsom-mx/kernel/stm32mp157a-visionsom-mx.dts
  • mx/visionsom-mx/u-boot/stm32mp157a-visionsom-mx.dts

All changed need to be done in both files - the u-boot and kernel dts. After applying the changes a new system image needs to be built and installed. Alternatively only the dtb file may be copied to the target system by replacing the previous one.

Memory regions definitions

Add the following reserved memory sections (mcuram2, vdev0vring0, vdev0vring1, vdev0buffer, mcuram, retram) in the main device tree node.


        reserved-memory {
                #address-cells = <1>;
                #size-cells = <1>;
                ranges;

                /* USER CODE BEGIN reserved-memory */

                fb_reserved: fb@fd000000 {
                        reg = <0xfd000000 0x8000000>;
                        no-map;
                };

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

                vdev0vring0: vdev0vring0@10040000 {
                        compatible = "shared-dma-pool";
                        reg = <0x10040000 0x1000>;
                        no-map;
                };

                vdev0vring1: vdev0vring1@10041000 {
                        compatible = "shared-dma-pool";
                        reg = <0x10041000 0x1000>;
                        no-map;
                };

                vdev0buffer: vdev0buffer@10042000 {
                        compatible = "shared-dma-pool";
                        reg = <0x10042000 0x4000>;
                        no-map;
                };

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

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

                /* USER CODE END reserved-memory */
        };
  

M4 remote processor

Modify the &m4_rproc node by setting the mboxes, memory regions and interrupts.


&m4_rproc{
        status = "okay";

        /* USER CODE BEGIN 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>;
        wakeup-source;

        /* USER CODE END m4_rproc */

        m4_system_resources{
                status = "okay";

                /* USER CODE BEGIN m4_system_resources */
                /* USER CODE END m4_system_resources */
        };
};

DMA1

Add the memory in the &dma1 node.


&dma1{
        status = "okay";

        /* USER CODE BEGIN dma1 */

        sram = <&dma_pool>;

        /* USER CODE END dma1 */
};

IPCC

Add the new &ipcc node.


&ipcc {
       status = "okay";
};

SRAM

Add the new &sram node with dma_pool.


&sram {
       dma_pool: dma_pool@0 {
                reg = <0x50000 0x10000>;
               pool;
       };
};

Running the Cortex-M4 example

A ready to run Cortex-M4 application is available to download from here: OpenAMP_TTY_echo.zip. This file should be extracted to the /lib/firmware/ directory of the target system. In order to run it, the following commands should be executed:

cd /sys/class/remoteproc/remoteproc0
echo "OpenAMP_TTY_echo.elf" > firmware
echo start > state

This example creates two new devices in /dev directory: ttyRPMSG0 and ttyRPMSG1. They may be used to communicate witn the Cortex-M4 application.

stty -onlcr -echo -F /dev/ttyRPMSG0
cat /dev/ttyRPMSG0 &
stty -onlcr -echo -F /dev/ttyRPMSG1
cat /dev/ttyRPMSG1 &
echo "Hello Virtual UART0" >/dev/ttyRPMSG0
echo "Hello Virtual UART1" >/dev/ttyRPMSG1

The Cortex-M4 logging is redirected to the shared memory which can be read from the trace file:

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

This example is taken from the STM32CubeMP1-1.2.0 code package available on STMicroelectronics website: https://www.st.com/en/embedded-software/stm32cubemp1.html.

For more information regarding the Cortex-M4 application building please refer to the official STMicroelectronics docummentation: https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP1_boards/STM32MP157x-EV1/Develop_on_Arm%C2%AE_Cortex%C2%AE-M4/Modify,_rebuild_and_reload_a_firmware