ver0.1
前言
经过前面一篇文章的介绍，我们对ARM体系下电源的管理的软件方面的核心内容(Idle 管理与DVFS管理)已经有了基本的认知。在ARM的PSCA框架下，无论是对PE-Core的状态的管理还是Performance的管理都离不开一个重要的机制那就是SCMI(System Control and Management Interface)，本文将对SCMI从系统架构层面进行介绍，希望能够帮助大家加深对SCMI机制工作原理的理解。同样在阅读本文之前，希望大家读一读我们的前序文章，掌握一些基础，也顺便找找感觉：
(1)[V-02]虚拟化基础-CPU架构(基于AArch64)
(2)[A-03]ARMv8/ARMv9-多级Cache架构
(3)[A-21]ARMv8/v9-SMMU系统架构和功能概述
(4)[A-25]ARMv8/v9-GIC的系统架构(中断的硬件基础)
(5)[A-38]ARMv8/v9-Generic Timer系统架构
(6)[A-41]ARMv9/v8-电源管理系统架构(Power Management System Architecture)
(7)[A-42]ARMv9/v8-电源管理工作原理(SCP Service Overview)
(8)[A-43]ARMv9/v8-电源控制框架简介PCF(Power Control Framework Overview)
(9)[A-0x2c]ARMv9/v8-电源管理域(Voltage Domain/Power Domain)
(10)[A-45]ARMv9/v8-电源模式(Power Modes)
(11)[A-46]ARMv9/v8-电源状态(Power States)
(12)[V-05] 虚拟化基础-异常模型(Exception)(AArch64)
(13)[A-47]ARMv9/v8-电源状态管理软件架构(PSCI架构)
(14)[A-48]ARMv9/v8-电源状态管理机制(PSCI协调机制)
(15)[A-49]ARMv9/v8-PSCI接口规范与工作流程简介
(16)[A-50]ARMv9/v8-DVFS系统架构
正文
1.1 背景
1.1.1 ARM开发标准化
我们将花一点时间介绍一下SCMI这个机制是怎么来的? 应该说一切都是为了提高软围绕着ARM芯片软硬件的开发效率，从而搞出的标准化开发规范，如图1-1所示。
看一下手册中的描述：
The specifications are the basis of software compatibility. Building hardware according to the specifications means that software can be written to match it. Writing software according to the specifications means that it can run on compliant hardware. TheArm Architectureis the first layer, providing a common programmer’s model to software through Instruction Set Architecture (ISA) compatibility.
The Base System Architecture (BSA) specification describes a hardware system architecture that system software can rely on. The BSA covers aspects of the processor and system architecture, for example the interrupt controller, timers, and other common devices that an OS needs. This provides a reliable platform for standard operating systems, hypervisors, and firmware.
The Base Boot Requirements (BBR) specification covers requirements for systems that are based on Arm architecture and that operating systems and hypervisors can rely on. This specification establishes the firmware interface requirements, like PSCI, SMCCC, UEFI, ACPI, and SMBIOS.
我们对手册中的描述简答总结一下：
(1) ARM是靠着卖IP设计为全人类的芯片事业发展注入动力，这个和x86的架构就有着本质的商业模式方面的区别。那么购买这些IP设计实现芯片量产的是高通、MTK、小米、华为…等等。设计和生成的分离就带来了碎片化的风险，至少软件层面的碎片化风险就很大，这不方便IP设计的迭代，也不方便芯片厂商的产品迭代，解决的办法就是标准化。
System designers face a wide range of choices when developing computing systems. To make the process easier in common multi-vendor environments, various hardware and firmware standards ensure a consistent base level of compatibility across implementations. These standards leverage Arm-specific and industry-standard interfaces, defining market-specific profiles for both required and optional system-level capabilities.
(2) 标准化的第一个基石就是Arm Architecture。不管ARM的芯片怎么迭代升级，ARM得提供编程范式(具体参考各个手册的Programmers model章节)和标准化的指令集合方便软件开发。按照规范编写的代码可以无缝的在ARM的PE上跑起来(关于ARM指令集和CPU的微架构前面都有文章讨论，这里不展开)，如图1-2所示：
(2) 有了指令，芯片就有了灵魂，可是光有灵魂，没有肉体是不行的，这就是第二个层面的课题，硬件标准化，如图1-3所示。
ARM给出了标准化的硬件平台：
Arm ® Total Compute Reference Design describes and models the design choices for recommended configuration of typical Arm-based subsystems. RD-TC22 incorporates 2022-generation products from Arm, and other system IP, along with an OSS stack, targeted at the client markets such as smartphones, laptops, and set-top boxes.
芯片厂商可以根据自己的下游业务需求选择不同的基于arm的计算平台的解决方案的规范进行设计和生产。这个规范连软件都给你适配好了，不想做软件层面定制的话拿过来直接就可以用了，如图1-4所示：
(3) 芯片厂商拿到ARM的规范后，想做一些软件层面的定制，如把图1-4中的系统换成Linux吧Hypervisor换成另外QNX-Hyper怎么办呢？是否还需要做大规模的硬件适配呢？答案是不用。ARM早就想好了：
Many computing scenarios require a standard off-the-shelf operating system (OS), such as Microsoft Windows or Linux. The OS depends on a critical set of underlying hardware and firmware capabilities.
Traditionally, vendors of Arm-based systems have extensively customized the OS for each individual system, but this approach presents challenges. Creating and maintaining these bespoke OS versions is often not cost-effective or practical, especially considering the growing need for long-term security updates.
The standards described here help solve this problem by defining a consistent set of firmware and hardware capabilities that are required to support common operating systems. The focus is on enabling fundamental system operation, allowing OS-specific driver mechanisms to support more advanced platform capabilities. These standards underpin the bands in the SystemReady program which helps partners achieve and declare compliance.
那么ARM是如何解决适配ARM硬件平台的痛点呢? 如图1-5所示：
看一下手册的描述：
Firmware running on an application processor is essential to enable the system’s boot process and overall operation. Base Boot Requirements (BBR) (DEN0044), together with market-specific supplements, defines a standard minimal set of boot and runtime services that firmware must provide. Different recipes meet the needs of various operating systems and hypervisors. The most common recipes are:
• SBBR recipe: for operating systems which require UEFI, ACPI, and SMBIOS when running on BSA-compliant hardware
• EBBR recipe: typically used by operating systems which use UEFI and Devicetree for hardware discovery
In many secure environments, the operating system needs assurances that the boot process has not been tampered with. Base Boot Security Requirements (BBSR) (DEN0107) provides additional standardization and guidance about this situation, including support for UEFI secure boot, UEFI authenticated variables, and secure firmware update.
结合图1-5，从手册的描述可以看出，ARM给出的方案就是将能原来需要芯片厂商适配的工作全部标准化以固件的形式提供，尽量减少芯片厂商的适配工作。而这些适配的内容
• 从时间上划分主要集中在两个阶段：启动阶段和工作阶段。如Firmware(TFA)中对CPU启动流程相关的设计，如图1-6所示：
• 从空间中划分就是Firmware与硬件和上层软件之间的适配工作，当然根据不同的软件架构方案适配的工作还需要有针对性的延展，如图1-7所示。
这里我们稍微停顿一下做一下思考：
o 操作硬件的接口，ARM会通过Programmers model在各种各样的手册中把偏移量固定下来，芯片厂商固定好每个功能单元的基地址就好了，这个就实现了软硬件世界的解耦。
o 繁琐的初始化和配置，流程化针对的硬件各个子系统的管理工作被聚合为Firmware之后，就可以给软件世界的其他模块(Hypervisor、RichOS、SecOS等)提供服务，这可以实现软件世界之间的解耦。大家约定好好HVC和SMC的服务号就好了。
o 根据软件架构的不同，虚拟化架构下部分功能也需要通过陷入机制完成，当系统执行了一些敏感指令后访问了一些敏感地址，Hypervisor需要截获并做一些模拟或者透传到底层或者转发到其他VM进行处理。hypervisor通过对资源的控制(IPA地址的控制)，可以实现大部分子系统在GuestOS和Hypervisor之间的解耦。
o 注意上面说的解耦是目标，并不能实现绝对的解耦，各层级的软件维护者还是要有必要的适配工作。和之前各自为战比较起来，通过ARM搞的开发模型已经可以大大降低大家的工作量(我们的芯片供应商，有的时候发的资料直接就是ARM的开源文档，都不假装一下了，哈哈哈)。
1.1.2 PowerControl
经过前面一个小节介绍，我们搞清楚了一个事实，基于ARM体系的软件世界需要大量的Firmware的支撑才能够实现高效率的迭代，现在把图1-4简化一下，如图1-8所示：
我们看下手册的描述：
Platform firmware is low-level software that supports higher-level system software such as an OS or hypervisor. This section describes the standard interfaces provided by the Platform firmware, focusing on A-profile. Some of these interfaces are needed to meet the Base Boot Requirements (BBR) described in Base standards. Others extend beyond the BBR with additional capabilities.
通过这一段手册的描述，相信我们会对图1-7的理解更加的深刻：
• ARM体系下的Firmware通过接口的形式为软件系统中的其他软件模块提供服务。
• 从异常模型的角度出发，这些Firmware可以为各个EL等级的软件提供服务。
• 从安全模型的角度，这些Firmware需要为安全世界和非安全世界提供方服务。
• 从功能层面出发，不论是哪个权限等级或者那个安全等级的软件模块都要依赖Firmware对系统的控制。
Many SoC designs, including those built using Arm Compute Subsystems (CSS), feature additional hardware controllers dedicated to particular system management and security tasks. Typically, these are M-profile microcontrollers running their own specialized firmware.
To enable entities such as the host operating system to interoperate with the controller firmware, the following message-based interfaces are available:
• System Control and Management Interface (SCMI): Mainly used for managing system power, it also features interfaces for resetting domains, accessing sensors and controlling pins such as General Purpose IO (GPIO). For more information, see Power Control.
• MPAM Firmware-backed (Fb) Profile (DEN0144): MPAM enables partitioning of constrained memory resources between different software running on the application processor.
Messages are exchanged between entities using a variety of transport mechanisms, for example an area of shared memory.
For example, many systems use the standard ACPI Platform Communications Channel to exchange SCMI messages between the OS and the SCP, and DMTF-defined Management Component Transport Protocol (MTCP) messages between the OS and MCP.
通过手册的描述，我们心心念念的SCMI终于出来了，这一套接口的主要作用就是为了方便基于ARM的SOC进行电源管理，如图1-9所示：
看一下手册中描述：
The Arm architecture is designed to be highly energy efficient. However, simply using individually power-efficient components is not sufficient for best results. Minimizing system power requires intricate and coordinated clock, power, and thermal management.
The Power Control System Architecture (PSCA) defines a flexible framework for system power control integration using standard infrastructure components and low-power interfaces.
It enables a generic OS to delegate SoC-specific power and performance control to a specialized subsystem, while allowing the OS to remain responsible for asse Other entities, including the application processor system software, communicate with the SCP using the System Control and Management Interface (SCMI) (DEN0056) to perform various functions including:
• Discovery of power and performance domains in the platform
• Setting performance levels and power states for each domain
• Obtaining sensor information, for example temperature data
When the operating system power manager requires a change in CPU and system power states, such as shutting down a core, the application processor EL3/Monitor firmware should be called using PSCI. For more information about PSCI, see Secure and monitor firmware interfaces. This allows the firmware to perform additional operations before passing the request to the SCP using SCMI. This typically includes saving and restoring EL3 monitor context, and managing secure-world interrupts. The OS can use SCMI directly for other operations.
PSCA我们就不展开讨论了，大家可以看我们前序的文章，这里我们只需要关注SCMI即可。SCMI的接口串联起了PCSA体系下的各个电源域，OSPM通过这些接口可以完成系统状态的收集、性能管理和电源状态的管理，下面我们就正式的进入SCMI的世界。
1.2 SCMI系统架构
1.2.1 SCMI的系统架构与核心组件
有了前面的预备知识作为基础，下面再继续讨论SCMI，大家就不会感觉到空洞了(上面关于ARM体系开发的背景知识还是非常有意思的，值得研究，特别是TFA那一块，值得花些心思，这个后面我们也会慢慢的深入下去，感兴趣的小伙伴可以自行阅读相关手册)，下面我们直接上SCMI的系统架构，如图1-10所示。
从系统架构层面SCMI机制重要的几个概念如下：
System Control and Management Interface is intended to allow agents such as an operating system to manage various functions that are provided by the hardware platform it is running on, including power and performance functions. As described in the introduction, SCMI provides two levels of abstraction: protocols and transports. Some commonly used terms in this specification are described below.
•Protocolsdefine individual groups of system control and management messages. A protocol specification describes the messages that it supports.
•Agentis used to describe the caller of the System Control & Management Interface.
•Platformdescribes the set of hardware components that interpret the messages and provide the necessary functionality.
•Resourceis used to describe any component of the hardware platform which can be controlled using SCMI messages.
•Transportdescribes the method by which protocol messages are communicated between agents and the platform. Arm strongly recommends that transports be operating system independent and capable of being virtualized.
如果之前没有接触SCMI机制的小伙伴直接看图1-10应该是有一些陡了，所以我们帮助大家缓缓，先看下图1-11，我们将结合两幅图和手册的描述在一起阐述SCMI中的核心组件。
经过前面的背景介绍，我们应该建立一个认知，就是SCMI与其说是一套接口，不如说一套机制更加贴切。SCMI被设计出来首先是独立于特定软件系统的一套接口，不管是AP(ARM-A)侧还是SCP(ARM-M)侧甚至是GPU(ARM-R)等IP在做SOC设计的时候进行系统层面控制的时候更加快速的迭代升级。为了控制的实时性，SOC将一部分业务从AP中解耦出来放到一个单独的微控制器中运行就可以达到这个目的，而且还可以有效降低AP的运行负载和保证系统层面的安全性。典型的子系统就是Power子系统，也就是前文我们说的ARM体系的PSCA架构。有了这个认知再回过头来看一下SCMI，我们对其中的核心组件做一下介绍：
(1) 第一个就是要搞清楚SCMI为谁服务? AGENT。所有能够独立运行Software Stack的IP上的软件系统都可以称之为一个AGENT，应该是是一个偏向软件的组件。这个软件堆栈需要在底软适配SCMI的接口， 然后供上层OSPM模块使用。典型的就如运行在ARM CPU上的Software Stack，如图1-8所示。(这个也是我们后面研究的重点。)
(2) 通过谁来直接下达AGENT的指令？Platform。所有的Agent的指令(软件层面的要求)，都需要通过Platform进行解析转发到末端执行。这个Platform是连接Agent和其他各方的枢纽，如PSCA体系下的SCP节点的软硬件架构中的核心服务(图1-12)。这个枢纽不光是下发Agent的指令还需要上行系统的各个状态，而且它不是无脑的执行，紧急情况下可以忽略Agent的指令和省略上行状态，直接干预硬件系统的状态，最大程度的保证硬件基础设施安全。比如系统过热的时候的保护机制。
(3) Agent的指令需要靠谁来执行？Resources。要抓人就有派出所，要灭火就要有消防队…。治理硬件同样需要有各个具体的抓手，对于SOC来说，这些抓手就是时钟域、电压域、电源域、传感器域…。这些域内的基础设施，嵌入在各个功能单元的内部，收集一手信息，并执行来自Platform的指令，如前面我们介绍的DVFS技术(图1-13)，Agent通过电压域与时钟域的控制干预具体IP的执行状态。
(4) 服务于上面三方的指令来自于哪里？Protocol和Transport。为了实现各个Agent进行系统控制的标准化，解耦Agent内部软件栈和硬件的复杂控制逻辑。SCMI站了出来，它通过Protocol高度的抽象了系统控制的业务并把他们协议化，方便Agent内部底层软件的适配。而Transport则完成Protocol的序列化，方便在运行Agent的IP和Platform之间传递消息，只需要经过简单配置就可以解耦Agent底软和Platform通信，大家各自搞好自己的事情就可以了。需要注意的是Platform和Resources之间的通信控制逻辑需要参考ARM的PCF框架，如图1-14所示，这部分PSCA架构下的SOC设计(各个电源域电源模式的控制与管理、时钟域与电压域的配合控制与管理、LPI接口的作用与各个中断组件的集成等)，我们前面已经有文章做过讨论，注意和SCMI机制的区别。
1.2.2 Transports
上一个小节的介绍，我们介绍了SCMI的系统架构与组件。Platform与Resources，我们在前面的文章中大部分已经讨论过了，Agent在SCMI的机制下更多的是偏向软件层面的概念，我们会在后面的文章中讨论，本节我们将打通Agent到Platform这一段链路帮助大家从系统架构层面理清其中的关键技术点：Transport。
Transports describe how messages are exchanged between agents and the platform.
This form of transport relies on the use of shared memory between the platform and the agents. The transport optionally supports interrupt-based communication, where, on completion of the processing of a message, the caller receives an interrupt. Polling for completion is also supported.
The transport can be used to provide an agent to platform, or a platform to agent channel. Each channel in the transport includes:
• Shared memory area
This is an area of memory that is shared between the caller and the callee. At any point in time, the shared memory is owned by the caller or the callee. The ownership is reflected by a channel status word in the shared memory area. The channel is said to be free when the memory area is owned by the caller, and busy when it is passed to the callee. When a channel is free, the caller can write a message and associated payload to this shared memory area.
After this, the caller updates the status field, thereby relinquishing ownership of the shared memory and marking the channel as busy. The callee can then use the shared memory to pass return values that are associated with the processing of the message. When the callee has completed processing the message, it updates the channel status field to indicate that the channel is now free.
• Doorbell
This is a mechanism that the caller can use to alert the callee of the presence of a message. Typically, this mechanism is implemented as a register in caller, which, when written, raises an interrupt on the callee. In case the callee chooses to poll over the ‘Channel free’ bit in the Channel status field of the shared memory area to discover new messages from the caller, then the doorbell support is optional.
The doorbell can also be implemented through Secure Monitor Call (SMC) or Hypervisor Call (HVC) instructions if the callee is resident in the Secure or Root world or at a different exception level.
• Completion interrupts
This transport supports polling or interrupt driven modes of communication. In interrupt mode, when the callee completes processing a message, it raises an interrupt on the caller. Hardware support for completion interrupts is optional.
结合手册的描述，下面我们将从两个层面介绍Transport：MHU、共享内存。
1.2.2.1 MHU
Transport 从系统架构层面解决的作用就是在AP和SCP之间传递消息，在消息传递的过程中要借助SCMI中一个重要的概念：Channel。
A transport might support multiple channels. Each agent that communicates with the platform must have its own set of dedicated channels. In other words, channels cannot be shared between agents. This requirement removes the need for creating locking primitives across agents that are running entirely different software stacks, for example, a management controller and an operating system. In addition, dedicated channels provide a method for the platform to identify which agent is sending a message.
结合图1-10，我们可以这样理解通道，Channel是在SCMI工作时根据Agent侧(主要是ARM-CPU状态如图1-8)的运行状态在AP和Platform之间建立的Session，这个Session会根据业务场景的不同划分成不同的类型，例如从安全角度出发，就可以分为Non-Security Channel 和 Security Channel(Channel细节会在后面的文章中结合Protocol的展开)。这个Channel在传递消息的时候需要借助一个运行Agent的IP和Platform之外的一个IP：MHU。如图1-15所示：
通过上图可以看出MHU是一个在AP和SCP之间搭建SCMI Channel中传递消息的角色，在SCMI工作的框架下它的角色可以理解为SCP的一个外设，如图1-16所示：
看一下手册的介绍：
The SCP supports several peripherals that are connected through the non-coherent interconnect:
• Non-secure Message Handling Unit (MHU) for communication with the MCP and processor cores.
• Secure MHU for communication with the MCP and processor cores.
The compute subsystem contains multiple instances of the module that is shown in the preceding figure:
• One secure and one non-secure bi-directional MHU module to support messaging between application processor cores and the SCP
• One non-secure bi-directional MHU module to support messaging between the SCP and MCP
• One non-secure bi-directional MHU module to support messaging between all application processor cores and the MCP
The MHU asserts the following interrupts to be mapped between processors for message passing:
• A non-secure and secure interrupt mapped to one processor
• A non-secure and secure interrupt mapped to the other processor
通过手册的介绍，我们可以发现MHU不光可以在AP和SCP之间传递消息，而且可以在AP的PE-Cores之间传递消息，如图1-17所示：
关于MHU，我们不展开讨论了，想深入了解的小伙伴可以参考相关手册[Ref-32]，这里介绍的目的就是为了丰富SCMI机制的系统架构的细节，帮助大家完整的构建SCMI机制中通信的链路，我们可以简单把MHU理解为SCMI中的信使。(MHU这部分工作的flow，我们理解为软件层面的设计，如图1-12中的SCP软件栈中MHU模块的作用，这些我们将在后面的文章中进行介绍。)
1.2.2.2 共享内存
信使已经有了，那么本节将介绍SCMI中的信件长什么样子，如图1-18所示。
通过前面我们清楚了，Agent和Platform之间传递消息需要靠MHU这个信使完成，而信件本身则是Agent和Platform共享的一段内存，并且每一次传递消息的信件有这严格的格式限制，这样就方便了Agent和Platform的底软的驱动程序的标准化处理。这部分不展开讲解了，核心的部分比如Channel和Msg类型等等，我们会和Transports的Doorbell机制等一起在SCMI的软件架构的介绍中展开介绍。
结语
文章前面的背景介绍目的是为了能够让大家在更加宏观的角度下理解SCMI，让大家知其所以然。文章的后半部分，我们介绍了SCMI的系统架构以及系统架构中的核心组件。我们也花费了一些时间介绍了MHU，这个串联Agent和Platform之间的信使，以及信件本身的结构：SCMI通信的载体共享内存。限于篇幅，我们对SCMI系统架构的介绍就到这里，我们努力的抽出了SCMI机制中硬件相关的背景知识组成了此文，为我们后面介绍SCMI的软件架构打下基础。希望家能花一些时间仔细研究其中的知识点，这里我们只能算是抛砖引玉了，不过其中的很多点确实值得大家花时间研究，就比如TFA架构中的Boot相关内容。
感谢很多小伙伴的信任，大家能陪我坚持到这里，尤其是那些让我出书和写付费文章的朋友们，你们真的是太可爱了。最近一年，干了XTK的项目，真的是拥有了非一般的感受，每天都在填坑，大坑套小坑，坑坑不一样。好在和所有本公司及供应商同事们一起，坚持了下来，让项目交付并马上量产了。这种情况下就有些愧对那些信任我的读者朋友了，时间就那么一点，写文章的时间就少了，并且文章的构思、排版、校对等就更粗糙了。可是大家的支持和信任还是会激励着我找时间写下去，不管怎样希望能够帮助大家磨合自己的技术栈，打开更深层次的认知。
今天就到这里，谢谢大家，请关注、转发、评论。
Reference
[01] <DEN0050D_Power_Control_System_Architecture.pdf>
[02] <armv8_a_power_management_100960_0100_en.pdf>
[03] <Power_Policy_Unit_Architecture_Specification_0051E.pdf>
[04] <DEN0024A_v8_architecture_PG.pdf>
[05] <79-LX-LD-s003-Linux设备驱动开发详解4_0内核-3rd.pdf>
[06] <80-PGxxx-35_QNX_Thermal_Manager_Overview.pdf>
[07] <80-pgxxx-7_n_qnx_power_management_software_architecture_reference_manual.pdf>
[08] <80-ARM-POWER-HK0001_一文搞懂ARM_SoC功耗控制架构.pdf>
[09] <Arm_Power_and_Performance_Management_SCMI_White_Paper.pdf>
[10] <80-ARM-POWER-cs0001_Arm-SoC-power功耗控制架构.pdf>
[11] <80-LX-LK-cl0009_深入理解Linux电源管理.pdf>
[12] <DEN0056D_System_Control_and_Management_Interface_v3_1.pdf>
[13] <arm_total_compute_2021_reference_design_software_developer_guide_en.pdf>
[14] <arm_total_compute_2022_reference_design_software_developer_guide_en.pdf>
[15] <arm_cortex_m85_processor_trm_en.pdf>
[16] <DEN0108_00eac0_smcf-archl-Specification.pdf>
[17] <DEN0022F.b_Power_State_Coordination_Interface.pdf>
[18] <MTxxxx_SCP_User_Manual_V1.0.pdf>
[19] <learn_the_architecture_arm_system_architectures_en.pdf>
[20] <arm_dsu_110_trm_101381_0400_11_en.pdf>
[21] <DEN0077A_Firmware_Framework_Arm_A_profile_1.1_EAC0.pdf>
[22] <80-LX-POWER-PSCI-cs0001_Linux-PSCI框架.pdf>
[23] <learn_the_architecture_realm_management_extension_guide.pdf>
[24] <ISA_A64_xml_A_profile-2024-03.pdf>
[25] <learn_the_architecture_aarch64_memory_management_guide.pdf>
[26] <IHI0069H_gic_architecture_specification.pdf>
[27] <DEN0044H_ArmBBR_2.1Final.pdf>
[28] <LVC20-118-0-SCMI-server-in-TEE.pdf>
[29] <trustedfirmware-a-readthedocs-io-en-latest.pdf>
[30] <CLKSCREW-Exposing-the-Perils-of-Security-Oblivious-Energy-Management.pdf>
[31] <Armv9A_OS_Porting_Guide_on_TC2_v1.0.pdf>
[32] <ARM-AES-0072A.a_mhu_architecture.pdf>
Glossary
AP - application processor
OSPM - Operating System Power Management
WFI - Wait For Interrupt
WFE - Wait For Event
DVFS - Dynamic Voltage and Frequency Scaling
SCU - Snoop Control Unit
OPP - Operating Performance Point
PSCI - Power State Coordination Interface
PPU - Power Policy Unit
PCSA - Power Control System Architecture
SoC - System-on-Chip
PCF - Power Control Framework
SCP - System Control Processor
BSP - board support package
SCMI - System Control and Management Interface
EAS - Energy Aware Scheduling
IPA - Intelligent Power Allocation
ACPI - Advanced Configuration and Power Interface
LPI - Low-Power Idle
CPPC - Collaborative Processor Performance Control
PCSM - power control state machine
AOSS - Always-on subsystem
PMIC - Power Management Integrated Circuit
JM - job manager
AON - always on domain
SBSA - Server Base System Architecture
CLK_CTRL - Clock Controller
LPD - Low Power Distributor
LPC - Low Power Combiner
P2Q - P-Channel to Q-Channel Convertor
GPIO - General Purpose IO
RAS - Reliability, Availability, and Serviceability
STR - Suspend to RAM
SMCCC - SMC Calling Convention
RMM - Realm Management Monitor
BMC - board management controller
PPF - Privileged platform firmwarever
SPM - Secure Partition Manager
SP - Secure Partition
DCVS - Dynamic Clock and Voltage Scaling
V-BSA - Virtual Base System Architecture
BBR - Base Boot Requirements
MHU - Message Handling Unit
CSS - Arm Compute Subsystems
