RFC: SCMI server for OP-TEE, Zephyr and Vhost User
Created by: vingu-linaro
This P-R integrates the changes that we have made in SCP firmware in order to make it run as a SCMI server in:
-
OP-TEE env. This has been tested on FVP arm64 and stm32. SCP-Firmware is integrated as a sub-module of op_tee-os. this PR has been tested with : https://github.com/vingu-linaro/optee_os/tree/scmi-over-optee. The product/optee-fvp is used with fvp platform.
-
Vhost user virtio SCMI backend. The SCP-firmware handles virtio-scmi request over a vhost user socket. This has been tested with a Linux image VM with Qemu. The product/vhost-user is built to monitor vscmi.ospm0.sock and vscmi.ospm1.sock. Additional Qemu parameter to provides: qemu-system-aarch64 <usual qemu parameters to run rou linux image ..> -chardev socket,path=vscmi-ospm0.sock,id=vscmi -device vhost-user-scmi-device,chardev=vscmi,id=scmi -object memory-backend-file,id=mem,size=1G,mem-path=/dev/shm,share=on -numa node,memdev=mem -dtb /home/vingu/Linaro/Kernel/out/binaries/arm64/virt-scmi.dtb -global virtio-mmio.force-legacy=false. You have to create your own dtb file based on Qemu's one in order to add the scmi protocol that you want to enable in Linux.
-
Virtio MMIO/ virtio SCMI device in zephyr. The SCP-firmware is used as a submodule of a zephyr app : https://github.com/vingu-linaro/mySCP-zephyr. It handles virtio-mmio request through a new virtio mmio zephyr device. This full setup is a bit more complex to put in place as it needs some changes in several other repo but i can provides the details if you are interested in. This one uses CMake
I don't expect this P-R to be merged as it is but appreciate some feedback about the way the new arch have been added in arch/none. The P-R also add 2 new features:
- add a framework stop stage to let module and element to cleanly destroy and release resource and memory. This is useful for the vhost user backend as it delete cleanly host resources
- add a context in mono threading mode. Enable to create an event list per channel. The goal is to be able to handle simultaneously and independently the requests from 2 differents channels which don't access the same resources.