SCMI overview

Revision as of 18:47, 10 March 2023 by Registered User (→‎STM32MP use of SCMI)
Applicable for STM32MP13x lines, STM32MP15x lines

1. Article Purpose[edit source]

The purpose of this article is to explain the SCMI services in STM32 MPU.

2. What is SCMI and what is it used for[edit source]

SCMI stands for System Control and Management Interface. It refers to Arm SCMI specification[1]. SCMI is a message driven interface between an SCMI agent (client) and an SCMI host (server). Specific SCMI protocols expose standard services to control system resources. SCMI can be used when there are resources hosted in an enclave, as an isolated co-processor or the CPU secure world, and they need to be exposed to the normal world where U-Boot and Linux execute.


SCMI protocols allow discovery of protocols and exposed resources can provide asynchronous notifications from distant resource events. The SCMI integration includes a transport layer in charge of the communication between the client (SCMI agent) and the server (SCMI host).

U-Boot (since v2021.01) and Linux (since v4.17) implement an SCMI agent driver, some of the SCMI protocols and several communication transports: mailbox, smc, optee, ffa. OP-TEE (since 3.9.0) and TF-A (since v2.5) implement some SCMI protocols and few boards embed SCMI host services. Linux kernel Device tree bindings documentation clearly defines how to describe an SCMI agent using DT technology.

An illustrative example of use of SCMI when a system hosts a normal world (U-Boot/Linux OS) and a secure world (e.g. OP-TEE) is CPU dynamic clock scaling (Linux' DVFS). As secure world executes on the CPU, normal world cannot freely manipulate the CPU clock configuration. In such systems, it is recommended to give full control on CPU clock configuration to the secure world which exposes restricted controls that normal world can use to request CPU clock changes. SCMI provides this interface on basis of a reviewed, evolutive and well established specification with active maintainers in the open source communities, especially Linux kernel, U-Boot, TF-A and OP-TEE.

3. STM32MP use of SCMI[edit source]

STM32MP implements a part of the SCMI specification (v2.0 and later) [2] to create a server/client path between secure and non-secure worlds. The resources exposed are related to resources possibly used by U-Boot or the Linux kernel but that are under exclusive control of the Cortex-A secure world because of peripheral access firewall considerations.

The architecture of STM32MP15 software deliveries embeds either TF-A or OP-TEE in the secure world. They both embed SCMI services and expose a set of clock and reset controller resources.

STM32MP13 software deliveries embeds either OP-TEE in the secure world that exposes SCMI services clock, reset controller, voltage regulator resource and a performance management service for CPU DVFS support.

Depending on the configuration of the secure world, not all services are supported for the exposed resources. SCMI protocols do specifically report when operation on a resource is not permitted (DENIED in SCMI specification).



3.1. STM32MP13x lines More info.png[edit source]

STM32MP13 implements an SCMI agent in both U-Boot and Linux kernel and implements an SCMI server in OP-TEE.

In STM32MP13, secure world exposes clock, reset, performance management and voltage regulator services for related peripheral interface assigned to secure world as per RCC TZEN ("security support" chapter) configuration and for voltage regulators provided by companion STPMIC1 device.


STM32MP13 DT clock bindings[3] defines the clock identifier values used by SCMI agents in SCMI clock protocol communication.

STM32MP13 DT reset bindings[4] defines the domain identifier values used by SCMI agent in SCMI Reset Domain protocol communication.

STM32MP13 DT regulator bindings[5] defines the regulator identifier values used by SCMI agents in SCMI voltage domain protocol communication.

STM32MP13 also exposes an SCMI performance domain for CPU DFVS services. This performance domain is identified with domain ID value 0 in SCMI performance domain management protocol communication.


3.2. STM32MP15x lines More info.png[edit source]

STM32MP15 implements an SCMI agent in both U-Boot and Linux kernel and implements an SCMI server in the 2 alternative secure world images, TF-A/SP_MIN or OP-TEE.

When secure world is TF-A/SP_MIN, SCMI integration requires the SCMI SMC transport. When secure world is OP-TEE, SCMI message use the SCMI OP-TEE transport. Check related Linux kernel and U-Boot configuration and their relative Device tree scmi node.

In STM32MP15, secure world exposes clock and reset services for related peripheral interface assigned to secure world as per RCC TZEN ("security support" chapter) configuration. For example, I2C4 clock and reset controllers in RCC subsystem can only be accessed from secure world when RCC[TZEN]=1. If the overall system architecture assigned I2C4 bus to non-secure world, Linux OS as U-Boot access I2C4 clock and reset controllers through the SCMI clock device driver and the SCMI reset device driver. Alternatively, if the overall system architecture assigns I2C4 bus to secure world, Linux and U-Boot will still see the I2C4 clock and reset through SCMI devices but they will fail to reset the bus or disable the bus clock.

STM32MP15 DT clock bindings[6] defines the clock identifier values used by SCMI agents in SCMI clock protocol communication.

STM32MP15 DT reset bindings[7] defines the domain identifier values used by SCMI agent in SCMI Reset Domain protocol communication.

4. Device Tree description[edit source]

The SCMI services device tree bindings are defined in the Linux kernel source tree in Arm SCMI DT bindings[8] documentation.

Device Tree bindings for SCMI on STM32MP are detailed in the SCMI device tree configuration article.

5. How to go further[edit source]

One can follow SCMI developments through TF-A mailing list[9] and OP-TEE OS issues[10] and pull requests[11] forums.

6. References[edit source]