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, such 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 the 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 (v2021.01 and up) and Linux (v4.17 and up) implement an SCMI agent driver, some of the SCMI protocols and several communication transports: mailbox, smc, optee, ffa. OP-TEE (v3.9.0 and up) and TF-A (v2.5 and up) implement some SCMI protocols used by the few boards that embed SCMI host services. The Linux kernel Device Tree bindings documentation clearly defines how to describe an SCMI agent using DT technology.
An illustrative example of the use of SCMI when a system hosts a normal world (U-Boot/Linux OS) and a secure world (such as OP-TEE) executing on the very same CPU, is the CPU dynamic clock scaling (Linux' DVFS) feature. As the secure world executes on the CPU, the normal world cannot freely manipulate the CPU clock configuration. In such systems, it is recommended to give full control of the CPU clock configuration to the secure world, which exposes restricted controls that the normal world can use to request CPU clock changes. SCMI provides this interface on the 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. SCMI in OpenSTLinux BSP[edit source]
The OpenSTLinux BSP implements a part of the SCMI specification (v2.0 and up) [2] to create a server/client path between the secure and non-secure worlds. The exposed resources are related to resources that are possibly used by U-Boot or the Linux kernel, but are under exclusive control of the Cortex-A secure world because of peripheral access firewall considerations.
STM32MP13x lines 
software deliveries embed OP-TEE in the secure world. OP-TEE exposes SCMI services for the clock, a reset controller, voltage regulator resources, and a performance management service for CPU DVFS support.
STM32MP15x lines software deliveries embed 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.
Depending on the configuration of the secure world, not all exposed services can be used by the SCMI client. Requests for a disallowed service return an SCMI access denied return code, like when a reset control line is fully assigned to secure world services, meaning the normal world will not be able to act on that reset line through the exposed SCMI reset protocol.
Devices exposed by SCMI protocols are used by generic Linux device frameworks such as the regulator framework and the clock framework.
3.1. STM32MP13x lines [edit source]
The OpenSTLinux BSP implements an SCMI agent in both U-Boot and the Linux kernel, and implements an SCMI server in OP-TEE.
For STM32MP13x lines , the secure world exposes clock, reset, performance management, and voltage regulator services for related peripheral interfaces assigned to the secure world as per the platform security configuration and for voltage regulators provided by a companion STPMIC1 device.
STM32MP13 DT clock bindings[3] define the clock identifier values used by SCMI agents in SCMI clock protocol communication.
STM32MP13 DT reset bindings[4] define the domain identifier values used by the SCMI agent in SCMI Reset Domain protocol communication.
OP-TEE 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 [edit source]
The OpenSTLinux BSP implements an SCMI agent in both U-Boot and the Linux kernel, and implements an SCMI server in the 2 alternative secure world images, TF-A SP-MIN or OP-TEE.
When the secure world is TF-A SP-MIN, SCMI integration requires the SCMI SMC transport. When the secure world is OP-TEE, SCMI integration requires the SCMI OP-TEE transport. Check the related Linux kernel and U-Boot configuration and their associated Device tree scmi node.
For STM32MP15x lines , the secure world exposes clock and reset services for the related peripheral interface assigned to the secure world as per the RCC TZEN ("security support" chapter) configuration. For example, the I2C4 clock and reset controllers in the RCC subsystem can only be accessed from the secure world when RCC[TZEN]=1. If the overall system architecture assigns the I2C4 bus to the nonsecure world, both Linux OS and U-Boot bootloader shall access the I2C4 clock and reset controllers through the SCMI clock device driver and the SCMI reset device driver. Alternatively, if the overall system architecture assigns the I2C4 bus to the secure world, Linux and U-Boot will still see the I2C4 clock and reset through SCMI devices, but they will be unable to reset the bus or disable the bus clock.
STM32MP15 DT clock bindings[5] define the clock identifier values used by SCMI agents in SCMI clock protocol communication.
STM32MP15 DT reset bindings[6] define the domain identifier values used by SCMI agent in SCMI Reset Domain protocol communication.
4. Device Tree description[edit source]
The SCMI service Device Tree bindings are defined in the Linux kernel source tree in the Arm SCMI DT bindings[7] documentation.
The Device Tree bindings for SCMI on STM32MP are detailed in the SCMI device tree configuration article.
5. Source code location[edit source]
6. How to go further[edit source]
One can follow SCMI developments through TF-A mailing list[8], OP-TEE OS issues[9], and pull request[10] forums.
7. References[edit source]
- ↑ https://developer.arm.com/documentation/den0056
- ↑ https://developer.arm.com/docs/den0056/latest
- ↑ include/dt-bindings/clock/stm32mp13-clks.h stm32mp13 DT clocks bindings
- ↑ include/dt-bindings/reset/stm32mp13-resets.h stm32mp13 DT reset bindings
- ↑ include/dt-bindings/clock/stm32mp1-clks.h stm32mp15 DT clocks bindings
- ↑ include/dt-bindings/reset/stm32mp1-resets.h stm32mp15 DT reset bindings
- ↑ Documentation/devicetree/bindings/firmware/arm,scmi.yaml Arm SCMI DT bindings
- ↑ https://lists.trustedfirmware.org/mailman3/lists/tf-a.lists.trustedfirmware.org/
- ↑ https://github.com/OP-TEE/optee_os/issues
- ↑ https://github.com/OP-TEE/optee_os/pulls
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.