1. Article Purpose[edit source]
The purpose of this article is to explain the SCMI services in STM32MPU.
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 where specific SCMI protocols expose stantdard services to control system resources.
SCMI is a set of protocols based on message exchanged to discover resources, control devices and get notification. It allows a resource owner to expose device services to a client entity. The resource owner, exposing service, is called a platform server in SCMI literature, the client is an SCMI agent. The communication, SCMI messages exchange, is handled by a SCMI transport.
SCMI allows to expose device service in a generic manner portable to various environment.
For example, the CPU clock cannot be freely manipulated by the non-secure world. Yet, Linux kernel executing in non-secure world may need to get or set the DDR frequency. Implementing a SCMI agent in non-secure world (Linux kernel, U-Boot bootloader) and a SCMI server in secure firmware (TF-A, OP-TEE) allows non-secure Linux kernel and U-Boot to nattily discover the DDR clock as a standard clock device.
3. STM32MP use of SCMI[edit source]
STM32MP implements features from the SCMI specification (v2.0 or above) [2] to create server/client paths between secure and non-secure worlds to offer device driver services for chip resources when some firewall configurations are hardened.
In STM32MP software release, the secure world is TF-A or OP-TEE. They both embed a SCMI server that exposes devices as clock and reset controllers.
In secure world, peripherals assigned to secure world acquire resource that can strict access to the resource exposed as described above. Article How to assign an internal peripheral to a runtime context provide details on peripheral assignment. SCMI resources exposed to non-secure world that are refused resource access get an denied error status, but system description should not have non-secure world depending on a unreachable resource.
In non-secure world, SCMI allows a generic SCMI implementation (I.e. Linux and U-Boot SCMI drivers) to discover, identify and register system resources. For example the Linux SCMI clock driver clk-scmi.c[3] and SCMI reset controller driver reset-scmi.c[4].
The Device Tree technology is used to describe to Linux and U-Boot the SCMI resources, those use to realize SCMI communiaction and the system resources exposed through SCMI protocols.
3.1. STM32MP15[edit source]
STM32MP15 defines 2 SCMI agents:
- Agent SCMI0 exposes RCC resource (clocks, reset controllers) related to RCC TZEN hardening
- Agent SCMI1 exposes RCC clocks related to RCC MCKPROT hardening.
Each agent (SCMI0 and SCMI1) interface the secure SCMI server using a shared memory at top (higher addresses) in SYSRAM internal memory. Message notification and processing is invoke with CPU SMC/HVC instructions (see SMCCC). The device tree technology is used to fully describe SCMI resources in the Linux kernel or U-Boot firmware.
STM32MP15 DT clock bindings[5] defines clock_id identifier values used by SCMI agents in SCMI clock protocol communication.
STM32MP15 DT reset bindings[6] defines the domain_id identifiers used by SCMI agent in SCMI Reset Domain protocol communication.
Directly or Indirectly Linux kernel, U-Boot firmware as well as Device Tree technology reference a SCMI clock or a reset controller with the SCMI agent reference and the SCMI identifier (clock_id, domain_id)..
SCMI devices exposed to agent SCMI0 on STM32MP15:
- Clock and reset controllers for CRYP1, HASH1, RNG1, GPIOZ bank, I2C4 and I2C6, SPI6 and USART1.
- Clock controller for IWDG1, RTC, BSEC.
- Reset controller for MDMA
- MCU reset controller and MCU hold-on-boot controller. See also Linux remoteproc framework or U-Boot bootloader.
- System internal root clocks LSI, HSI and CSI, external root clocks LSE and HSE and PLL2 output clocks PLL2Q.
SCMI devices exposed to agent SCMI1 on STM32MP15:
- MCU clock. See also Linux remoteproc framework or U-Boot bootloader
- PLL3 output clocks PLL3Q and PLL3R.
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[7] 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[8] and OP-TEE OS issues[9] and pull requests[10] forums.
6. References[edit source]
- ↑ https://developer.arm.com/architectures/system-architectures/software-standards/scmi
- ↑ https://developer.arm.com/docs/den0056/latest
- ↑ Linux drivers/clk/clk-scmi.c
- ↑ Linux drivers/reset/reset-scmi.c
- ↑ include/dt-bindings/clock/stm32mp1-clks.h stm32mp1 DT clocks bindings
- ↑ include/dt-bindings/reset/stm32mp1-resets.h stm32mp1 DT reset bindings
- ↑ Documentation/devicetree/bindings/arm/arm,scmi.txt Arm SCMI DT bindings
- ↑ https://lists.trustedfirmware.org/mailman/listinfo/tf-a
- ↑ 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. 