Skip to content
Arnaud Pouliquen edited this page Feb 3, 2022 · 17 revisions

Table of Contents

What is OpenAMP System Reference / End-to-end example ?

This working group aims to put together end-to-end system reference material showcasing all the different aspects of OpenAMP, on multiple vendor platforms.

Communications

  • To sign up for the mailing list and to see the archives, visit this page
  • Meetings: Small group who is working on the project is meeting meeting weekly on Wednesday during Aug-Oct 2021 & then will decide on frequency.

Repository

GitHub repository openamp-system-reference

Documentation

WIP documentation folder on Google Drive (Note: Google doc access is currently restricted to working group members. Will publish documents once they are sufficiently ready)

Milestones

Echo test

ST Echo Test Example

Intruction to install the yocto environement, build and load an image, run the echo exemple is available here: https://github.com/arnopo/oe-manifest/blob/OpenAMP/README.md

For more information and help on the stm32mp15 platform and environment, please refer to stm32mpu wiki.

Xilinx Echo Test Example

WIP document (Note: Google doc access is currently restricted to working group members. To publish once it is sufficiently ready)

Multi RPMSG services demo

STM32MP157C/F-DK2 board

Based on:

Prerequisite

TBC

Installation

Create the structure of the project

mkdir stm32mp15-demo
cd stm32mp15-demo
mkdir zephy_distrib
mkdir stm32mp1_distrib_oss
At this step you should see following folder hierarchy:
stm32mp15-demo
    |___ stm32mp1_distrib_oss
    |___ zephy_distrib

Generate the stm32mp15 image

Install stm32mp1_distrib_oss dunfell

From the stm32mp15-demo directory

cd stm32mp1_distrib_oss

mkdir -p layers/meta-st
git clone https://github.com/openembedded/openembedded-core.git layers/openembedded-core
cd layers/openembedded-core
git checkout -b WORKING origin/dunfell
cd -

git clone https://github.com/openembedded/bitbake.git layers/openembedded-core/bitbake
cd layers/openembedded-core/bitbake
git checkout -b WORKING  origin/1.46
cd -

git clone git://github.com/openembedded/meta-openembedded.git layers/meta-openembedded
cd layers/meta-openembedded
git checkout -b WORKING origin/dunfell
cd -

git clone https://github.com/arnopo/meta-st-stm32mp-oss.git layers/meta-st/meta-st-stm32mp-oss
cd layers/meta-st/meta-st-stm32mp-oss
git checkout -b WORKING origin/dunfell
cd -
Initialize the OpenEmbedded build environment

The OpenEmbedded environment setup script must be run once in each new working terminal in which you use the BitBake or devtool tools (see later) from stm32mp15-demo/stm32mp1_distrib_oss directory:

 source ./layers/openembedded-core/oe-init-build-env build-stm32mp15-disco-oss

 bitbake-layers add-layer ../layers/meta-openembedded/meta-oe
 bitbake-layers add-layer ../layers/meta-openembedded/meta-perl
 bitbake-layers add-layer ../layers/meta-openembedded/meta-python
 bitbake-layers add-layer ../layers/meta-st/meta-st-stm32mp-oss

 echo "MACHINE = \"stm32mp15-disco-oss\"" >> conf/local.conf
 echo "DISTRO = \"nodistro\"" >> conf/local.conf
 echo "PACKAGE_CLASSES = \"package_deb\" " >> conf/local.conf
Build stm32mp1_distrib_oss image

From stm32mp15-demo/stm32mp1_distrib_oss/build-stm32mp15-disco-oss/ directory

 bitbake core-image-base
Note that:
  • to build around 30 GB is needed
  • building the distribution can take more than 2 hours depending on performance of the PC.
Flash stm32mp1_distrib_oss

From 'stm32mp15-demo/stm32mp1_distrib_oss/build-stm32mp15-disco-oss/' directory,populate your microSD card inserted on your HOST PC using command:

 cd tmp-glibc/deploy/images/stm32mp15-disco-oss/
 # flash wic image on your sdcar. replace <device> by mmcblk<X> (X = 0,1..) or sd<Y> ( Y = b,c,d,..) depending on the connection 
 dd if=core-image-base-stm32mp15-disco-oss.wic of=/dev/<device> bs=8M conv=fdatasync

Generate the Zephyr firmware image

Install meta-zephyr Honister version

From stm32mp15-demo directory

cd zephy_distrib

git clone https://github.com/openembedded/openembedded-core.git layers/openembedded-core
cd layers/openembedded-core
git checkout -b WORKING origin/honister
cd -

git clone https://github.com/openembedded/bitbake.git layers/openembedded-core/bitbake
cd layers/openembedded-core/bitbake
git checkout -b WORKING  origin/1.46
cd -

git clone git://github.com/openembedded/meta-openembedded.git layers/meta-openembedded
cd layers/meta-openembedded
git checkout -b WORKING origin/honister
cd -

git clone https://github.com/arnopo/meta-zephyr.git layers/meta-zephyr
cd layers/meta-zephyr
git checkout -b WORKING origin/OpenAMP_demo
cd -
Initialize the OpenEmbedded build environment

The OpenEmbedded environment setup script must be run once in each new working terminal in which you use the BitBake or devtool tools (see later) from the stm32mp15-demo/zephy_distrib directory:

MACHINE="stm32mp157c-dk2" DISTRO="zephyr" source layers/openembedded-core/oe-init-build-env build-zephyr
bitbake-layers add-layer ../layers/meta-openembedded/meta-oe/
bitbake-layers add-layer ../layers/meta-openembedded/meta-python/
bitbake-layers add-layer ../layers/meta-zephyr/
Build the Zephyr image

For instance to build the zephyr-openamp-rsc-table example which answers to the Linux rpmsg sample client example: From the stm32mp15-demo/zephy_distrib/build-zephyr directory:

MACHINE="stm32mp157c-dk2" DISTRO="zephyr" bitbake zephyr-openamp-rsc-table
Note that:
  • to build around 30 GB is needed
  • building the distribution can take 1 or 2 hours depending on performance of the PC.
Install the Zephyr binary on the sdcard

The Zephyr sample binary is available in the sub-folder of build directory stm32mp15-demo/zephy_distrib/build-zephyr/tmp-newlib/deploy/images/stm32mp157c-dk2/. It needs to be installed on the "rootfs" partition of the sdcard

sudo cp tmp-newlib/deploy/images/stm32mp157c-dk2/zephyr-openamp-rsc-table.elf <mount point>/rootfs/lib/firmware/
Don't forget to properly unoumt the sdcard partitions.

Demos

Start the demo environment
stm32mp15-disco-oss login: root
  • start the Cortex-M4 firmware
echo zephyr-openamp-rsc-table.elf > /sys/class/remoteproc/remoteproc0/firmware 
echo start >/sys/class/remoteproc/remoteproc0/state 
you should observe following traces on console
root@stm32mp15-disco-oss:~#
[   54.495343] virtio_rpmsg_bus virtio0: rpmsg host is online
[   54.500044] virtio_rpmsg_bus virtio0: creating channel rpmsg-client-sample addr 0x400
[   54.507923] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x401
[   54.514795] virtio_rpmsg_bus virtio0: creating channel rpmsg-raw addr 0x402
[   54.548954] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: new channel: 0x402 -> 0x400!
[   54.557337] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 1 (src: 0x400)
[   54.565532] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 2 (src: 0x400)
[   54.581090] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 3 (src: 0x400)
[   54.588699] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 4 (src: 0x400)
[   54.599424] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 5 (src: 0x400)
...
This inform that following rpmsg channels devices have been created:
  • a rpmsg-client-sample device
  • a rpmsg-tty device
  • a rpmsg-raw device
Demo 1: rpmsg-client-sample device
  • Principle:
This demo is automatic run when the coprocessor firmware is started. It allows to confirm that the rpmsg and virtios protocols are working properly.
  • The Zephyr requests the creation of the rpmsg-client-sample channel to the Linux rpmsg framework using the "name service announcement" rpmsg.
  • On message reception the Linux rpmsg bus create an associted device and probe the rpmsg-client-sample driver
  • The Linux rpmsg-client-sample driver sent 100 rpmsg to the remote processor, which answer to each message
  • After answering to each rpmsg the Zephy destroy the channel
  • Associated traces:
[   54.548954] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: new channel: 0x402 -> 0x400!
[   54.557337] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 1 (src: 0x400)
[   54.565532] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 2 (src: 0x400)
...
[   55.436401] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 99 (src: 0x400)
[   55.445343] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: incoming msg 100 (src: 0x400)
[   55.454280] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: goodbye!
[   55.461424] virtio_rpmsg_bus virtio0: destroying channel rpmsg-client-sample addr 0x400
[   55.469707] rpmsg_client_sample virtio0.rpmsg-client-sample.-1.1024: rpmsg sample client driver is removed
Demo 2: rpmsg-tty device
  • Principle:
This channel allows to create a /dev/ttyRPMSGx for terminal based communication with Zephyr.
  • Demo
1- Check presence of the /dev/ttyRPMSG0
By default the Zephyr has created a rpmsg-tty channel
[   54.507923] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x401
2- Check device exists
root@stm32mp15-disco-oss:~# ls /dev/ttyRPMSG*
/dev/ttyRPMSG0
3- Send and receive messages on /dev/ttyRPMSG0
The zephyr is programmed to resent received message with a prefixed "TTY 0: ", 0 is the instance of the tty link
root@stm32mp15-disco-oss:~# cat /dev/ttyRPMSG0 &
root@stm32mp15-disco-oss:~# echo " hello Zephyr" >/dev/ttyRPMSG0
TTY 0:  hello Zephyr
root@stm32mp15-disco-oss:~# echo " goodbye Zephyr" >/dev/ttyRPMSG0
TTY 0:  goodbye Zephyr
Demo 3: dynamic creation/release of a rpmsg-tty device
  • Principle
This demo is based on the rpmsg_char restructuring series not yet upstreamed. this correlated the
/dev/rpmsg_ctrl from the rpmsg_char device and then introduce 2 new rpmsg IOctrl:
  • RPMSG_CREATE_DEV_IOCTL : create a local rpmsg device and send an ns annoucement to the remote processor
  • RPMSG_RELEASE_DEV_IOCTL: release a local rpmsg device
  • Demo
1- Prerequisite
  • Due to a limitation in the rpmsg protocol, the zephyr does not know the existence of the /dev/ttyRPMG0 until the Linux sends it a first message. creating a new channel before this one is well establish will lead to bad endpoints association. To avoid this just send a message on /dev/ttyRPMSG0
root@stm32mp15-disco-oss:~# cat /dev/ttyRPMSG0 &
root@stm32mp15-disco-oss:~# echo " hello Zephyr" >/dev/ttyRPMSG0
TTY 0:  hello Zephyr
  • Download rpmsgexport tools relying on the /dev/rpmsg_ctrl, an compile it in an arm environment unsing make instruction and install it on target
  • optional enable rpmsg bus trace to observe rp messages in kernel trace:
echo -n 'file virtio_rpmsg_bus.c +p' > /sys/kernel/debug/dynamic_debug/control
2- create a new tty channel Create a rpmsg-tty channnel with local address set to 257 and undifined remote address -1.
root@stm32mp15-disco-oss:~# ./rpmsgexportdev /dev/rpmsg_ctrl0 rpmsg-tty 257 -1
The /dev/ttyRPMSG1 is created
root@stm32mp15-disco-oss:~# ls /dev/ttyRPMSG*
/dev/ttyRPMSG0  /dev/ttyRPMSG1
A name service announcement has been sent to Zephyr, which have created a local endpoint (@ 0x400), and send "bound" message to the /dev/ttyRPMG1 (@ 257)
root@stm32mp15-disco-oss:~# dmesg
[  115.757439] rpmsg_tty virtio0.rpmsg-tty.257.-1: TX From 0x101, To 0x35, Len 40, Flags 0, Reserved 0
[  115.757497] rpmsg_virtio TX: 01 01 00 00 35 00 00 00 00 00 00 00 28 00 00 00  ....5.......(...
[  115.757514] rpmsg_virtio TX: 72 70 6d 73 67 2d 74 74 79 00 00 00 00 00 00 00  rpmsg-tty.......
[  115.757528] rpmsg_virtio TX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[  115.757540] rpmsg_virtio TX: 01 01 00 00 00 00 00 00                          ........
[  115.757568] remoteproc remoteproc0: kicking vq index: 1
[  115.757590] stm32-ipcc 4c001000.mailbox: stm32_ipcc_send_data: chan:1
[  115.757850] stm32-ipcc 4c001000.mailbox: stm32_ipcc_tx_irq: chan:1 tx
[  115.757906] stm32-ipcc 4c001000.mailbox: stm32_ipcc_rx_irq: chan:0 rx
[  115.757969] remoteproc remoteproc0: vq index 0 is interrupted
[  115.757994] virtio_rpmsg_bus virtio0: From: 0x400, To: 0x101, Len: 6, Flags: 0, Reserved: 0
[  115.758022] rpmsg_virtio RX: 00 04 00 00 01 01 00 00 00 00 00 00 06 00 00 00  ................
[  115.758035] rpmsg_virtio RX: 62 6f 75 6e 64 00                                bound.
[  115.758077] virtio_rpmsg_bus virtio0: Received 1 messages
2- Play with /dev/ttyRPMSG0 and /dev/ttyRPMSG1
root@stm32mp15-disco-oss:~# cat /dev/ttyRPMSG0 &
root@stm32mp15-disco-oss:~# cat /dev/ttyRPMSG0 &
root@stm32mp15-disco-oss:~# echo hello dev0 >/dev/ttyRPMSG0
TTY 0: hello dev0
root@stm32mp15-disco-oss:~# echo hello dev1 >/dev/ttyRPMSG1
TTY 1: hello dev1
3- Destroy RPMSG TTY devices
  • destroy the /dev/ttyRPMSG0
root@stm32mp15-disco-oss:~# ./rpmsgexportdev /dev/rpmsg_ctrl0 -d rpmsg-tty 257 -1
  • Destroy the /dev/ttyRPMSG1
Get the source address
root@stm32mp15-disco-oss:~# cat /sys/bus/rpmsg/devices/virtio0.rpmsg-tty.-1.*/src
0x402
Destroy the /dev/ttyRPMSG1 specifying the address 1026 (0x402)
root@stm32mp15-disco-oss:~# ./rpmsgexportdev /dev/rpmsg_ctrl0 -d rpmsg-tty 1026 -1
The /dev/ttyRPMGx devices no more exists
Demo 4: rpmsg-char device
  • Principle:
This channel allows to create a /dev/rpmsgX for sysfs based communication with Zephyr.
  • Demo
1- Check presence of the /dev/rpmsg0
By default the Zephyr has created a rpmsg-raw channel
[   54.514795] virtio_rpmsg_bus virtio0: creating channel rpmsg-raw addr 0x402
2- Check device exists
root@stm32mp15-disco-oss:~# ls /dev/rpmsg*
/dev/rpmsg0       /dev/rpmsg_ctrl0
3- Send and receive messages on /dev/rpmsg0
The zephyr is programmed to resent received message with a prefixed "from ept 0x0402: ", 0x0402 is the zephyr endpoint address
root@stm32mp15-disco-oss:~# ./ping2 /dev/rpmsg0
message for /dev/rpmsg0: "from ept 0x0402: ping /dev/rpmsg0"

Future work

Efforts

  • Baremetal-baremetal
  • RTOS-RTOS

High level plan for Xilinx Software Stack

  • QEMU & initial doc – Mid Sept.
  • Userspace & kernel space demos – Sept end
  • Hardware demo – End - Oct.
  • System-dt flow (Without using Xilinx tools) – End-Nov
  • Advanced app – End-Jan
  • Completely upstream flow – (Based on When Xilinx driver is merged in upstream kernel)