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 https://github.com/STMicroelectronics/oe-manifest.git -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/envsetup.sh
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:

. meta-toolchain-openstlinux-weston-stm32mp1-x86_64-toolchain-3.1-snapshot.sh

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 127.0.0.1:3334 # look at the output of the above openocd to determine the correct port to control Cortex-M4
monitor soft_reset_halt
step
c

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.

To do

to display m4 logs from linux user space here

References

[1] https://visualgdb.com/tutorials/arm/stm32/stm32mp1/
[2] https://community.st.com/s/question/0D50X0000B6QncT/debugging-m4-with-gdb-from-command-line
[3] https://events19.linuxfoundation.org/wp-content/uploads/2017/12/Linux-and-Zephyr-%E2%80%9CTalking%E2%80%9D-to-Each-Other-in-the-Same-SoC-Diego-Sueiro-Sepura-Embarcados.pdf