Simple OpenAMP application for stm32mp157

Simple OpenAMP application for stm32mp157

The stm32mp157 is SOC from STMicroelectronics , and it has within it a dual-core Cortex-A7 MPU and Cortex-M4 MCU. The Cortex-A7 is the application processor that operates Linux, and the Cortex-m4 runs RTOS or bare-metal application. The Cortex-M4 can be used for real-time tasks, such as creating a periodic and accurate control signal without jitter. In this kind of application, the Cortex-aA7 will run the master application and control the application of the Cortex-m4 using RPMsg Messaging Protocol. I have used STM32MP157C-DK2 evaluation kit to create a simple hello world messaging application between Cortex-a7 (Linux) to Cortex-M4 (bare metal)

install necessary tools

The working environment is Linux and usually and I had to install repo tool (Gentoo)

emerge dev-vcs/repo

I had followed the instruction in this manual ref.

mkdir yocto
cd yocto
repo init -u -b refs/tags/openstlinux-5.4-dunfell-mp1-20-06-24
repo sync

Build yocto image and toolchain:

DISTRO=openstlinux-weston MACHINE=stm32mp1 source layers/meta-st/scripts/
bitbake core-image-base
bitbake meta-toolchain
bitbake st-image-weston

To install the tool can make sure that you are in the build directory (build-openstlinuxweston-stm32mp1 - by default) and type:


ST recommends installing STM32CubeIDE, which is basically an eclipse environment with pre-installed GCC and other useful tools like openocd. I usually work without IDE, and GCC was downloaded from here

kernel & u-boot & sd image

I have used the default image that gets with the development kit, so everything was there and defined correctly. I will write a post on creating an adapted image for the stm32mp1, including kernel, u-boot, and file system. I also used a default application given by STM32Cube_FW_MP1_V1.2.0 .

debug Cortex-M4

The board has two modes: engineering mode where it can work on the Cortex-M4 using JTAG as it has done in any other ST microcontroller. The Cortex-M4 core will be automatically started in engineering mode once you power the board, and the Cortex-A core will not run the regular SD card boot process. This allows quickly prototyping Cortex-M4 firmware without configuring the Linux-level settings. The device boots from Cortex-A7 in the production mode and the Cortex-M4 are disabled and only can be accessed from the Linux OS. To load and activate the Cortex-M4 firmware in production mode it has to type.

echo stop > /sys/class/remoteproc/remoteproc0/state                    # power down Cortex-M4
echo test2_CM4.elf  > /sys/class/remoteproc/remoteproc0/firmware       # loads firmware to Cortex-M4 - it can also be done using openocd after power up of Cortex-M4
echo start > /sys/class/remoteproc/remoteproc0/state                   # power up Cortex-M4

Before applying the commands, the file test2_CM4.elf must be copied into /lib/firmware. Refer here for more details on the remote processor framework.

if both modes the debuggeing procedure is the same using openocd:

$ . /opt/st/stm32mp1/3.1-snapshot/environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi 
$ $OECORE_NATIVE_SYSROOT/usr/bin/openocd -s $OECORE_NATIVE_SYSROOT/usr/share/scripts -f board/stm32mp15x_dk2.cfg

In gdb session typw the following commands:

arm-none-eabi-gdb test2_CM4.elf

In the gdb prompt command type:

target remote # look at the output of the above openocd to determine the correct port to control Cortex-M4
monitor soft_reset_halt

ST provides IDE, which based on eclipse and has all the needed facilities to support debugging with IDE. Usually, I’m using cgdb, and the following figure displays a Cortex-M4 debug session using cgdb (in the left window) and output log of Linux kernel (right window) with hello messages they were sent from the Cortext-M4 using OpenMP.

Linux kernel log: Hello message commining from Cortex-M4 to Cortex-A9

Linux kernel log: Hello message commining from Cortex-M4 to Cortex-A9

To do

to display m4 logs from linux user space here



comments powered by Disqus