About this project

System Control and Management Interface (SCMI) has been designed to standardize the interface between a power coprocessor and other parts of a SoC. That includes the application processor (AP) on which we can have both rich OS like Linux but also a TEE like OP-TEE.

Each client of the power coprocessor has its own access points with specific control permissions on the power resources. But on some “medium/small” systems, the power coprocessor may not be present or doesn’t provide enough access points. In such a case, the AP itself has to control and filter the access to the power resources.

For security reason, the TEE must have the control of shared resources and populates the authorized resources to the non secure world. In this case, the TEE acts as a power coprocessor from Linux PoV and we can keep using the same SCMI interface.

Even if OP-TEE is our first target, similar requirements arise when several guest VMs have to manage share resources like a system PLL or a shared power domain. The configuration used with OP-TEE can be extended to any Execution Environment on the system and a SCMI backend can run in a VM acting as a proxy between guest VMs and shared resources an example. The VM can even be replaced by a Secure Partition which enables to handle shared resources of both Non secure and Secure world. The based control protocol enables the hypervisor and the SPMC to dynamically grant access to the resources of a device to a VM (or a SP) when the device is assigned to it.

Open

Wherever it runs, the core of the SCMI server remains the same and only the execution environment interface will change. In order to ease the port of the SCMI server in different contexts, several features need to be enabled like new transport methods or easing the port on a different OSes.

Open

Get Involved

• Meetings/Calls

Meetings