ARM SCP电源管理解析：SCMI、DVFS与固件实现的底层原理

1. 从[A-42]说起一个编号背后的系统设计第一次看到[A-42]ARMv9/v8-电源管理工作原理(SCP Service Overview)这个标题时我的第一反应是这是哪家芯片公司内部技术文档的编号风格。A-42这种带中括号的命名很像是内部Wiki或代码仓里某个模块的代号前面是系统分类后面才是真正的技术主题ARMv9/v8平台上的电源管理以及SCP服务全景。先说结论如果你想弄清楚手机、服务器或者嵌入式设备上待机一晚上不掉电、按一下电源键快速唤醒、大核小核自动切换这些现象背后的原理那你迟早会撞上SCP。SCP全称是System Control Processor系统控制处理器它不跑Linux不跑Android甚至不跑RTOS它跑的是一个独立的小固件专门替主CPU打理电源、时钟、复位、温控这些脏活累活。ARMv9和ARMv8的很多低功耗特性比如CPU idle状态的进入和退出、DVFS动态调频调压、热插拔CPU、系统休眠唤醒看着是内核在操作实际上是内核通过协议把请求发给SCP由SCP真正去控制硬件寄存器。这篇文章不打算逐行读代码而是想把SCP这套服务的全貌讲清楚为什么需要它、它和主CPU怎么分工、内核和它之间用什么语言通信、常见的服务有哪些、实际调试中会遇到哪些坑。适合正在做ARM平台BSP或功耗调优的工程师也适合对底层系统好奇、想摸清电源管理到底谁在管的读者。2. 为什么ARM平台非要养一个看门人处理器2.1 主CPU管不了自己的电源很多人第一次接触SCP时都有个疑问CPU不是自己就能执行WFIWait For Interrupt指令进入低功耗状态吗为什么还需要一个额外的处理器来管电源这个问题的本质在于当CPU进入WFI之后它只是停止了执行指令但架构上它依然可以被中断唤醒马上恢复到原来的执行流。可如果我们要让CPU彻底断电问题就来了——断电路径上任何一步操作出错这颗CPU就再也醒不过来了而那时候主CPU自己已经处于半睡半醒的状态根本没有能力自救。有个很形象的类比主CPU就像一个正在值夜班的人他可以闭目养神WFI但真要把整栋楼的电闸拉掉再合上他得先找另一个清醒的人在旁边看着确保拉闸的顺序正确、合闸的时候不会出事故。SCP就是这个永远清醒的看门人。它独立于主CPU运行有自己的小内核、小RAM、小Flash即使所有应用处理器AP都断电了SCP依然活着负责监控唤醒源、管理电源轨、维护系统状态。2.2 Cache与中断的两难困境再往深一层说主CPU直接管理电源还有一个架构上的死结中断与Cache。当一个CPU core进入idle状态时它的L1 Cache可能已经被清空flush了因为不清空的话断电瞬间会有数据丢失的风险。但问题是如果想要唤醒这个core就得给它发送一个中断而中断控制器比如GIC向core发送中断时需要core处于能接收中断的状态。如果core已经断电GIC连中断信号都送达不了唤醒就无从谈起。这就形成了一个循环依赖core要断电就必须清Cache清完Cache后又能被中断唤醒但当中断来的那一刻core已经在断电状态硬件上无法接收中断。SCP把这个问题解决得很干净它不依赖主CPU的Cache和中断状态它自己有一套独立的时钟源和中断控制器。主CPU想睡觉时把需求告诉SCPSCP负责协调各电源域下电的时序并且在主CPU断电期间保留一小部分系统状态在SCP自己的内存里。等唤醒条件满足时SCP先把主CPU的电源恢复、release掉复位信号主CPU再像开机一样从启动地址跳出来恢复上下文。2.3 多核异构场景下SCP成为仲裁者现代ARM芯片几乎没有单核的少则八核多则几十核而且往往是大小核异构。这意味着系统里同时存在多种性能特性的CPU对应多个DVFS域和多个电源域。谁来决定某个时刻应该让大核跑1.8GHz还是小核跑1.2GHz内核的cpufreq驱动可以提出我想要更高性能的建议但硬件上切换PLL分频、调整LDO输出电压、等待时钟稳定这些时序敏感的活儿由主CPU的软件来做非常危险——因为调整频率的瞬间主CPU核心时钟可能是不稳定的极端情况下连执行指令都会出错。SCP作为独立的处理器它不受主CPU调频过程的影响可以在主CPU频率切换的空窗期里自己稳稳当当地完成PLL切换、电压变更然后才告诉主CPU可以继续跑了。这种请求-执行-确认的模式让SCP成了电源管理领域的仲裁者。所有电源相关操作无论来自内核、来自安全世界还是来自外设最终都汇总到SCP统一调度避免多个主CPU核同时操作电源寄存器导致的状态错乱。3. SCP的软件栈不只是一个小固件那么简单3.1 SCP-FirmwareArm官方的开源实现ARM官方提供了一个参考实现叫SCP-Firmware托管在GitHub上。它不是一个完整操作系统而是一个framewework式的固件工程。你可以在里面看到对ARM自家参考平台比如Juno、FVP模拟器的支持也可以看到像TC2、RD-N2这类开发者平台的配置。很多芯片厂商比如联发科、高通不会直接拿开源的SCP-Firmware用到量产芯片上但基本都参考了它的架构设计——模块化、事件驱动、与具体硬件隔离的接口层。SCP-Firmware的代码组织很值得学习。核心是建立在一个事件循环之上的类似于一个简单的RTOS改成了协作式调度。各个功能模块互相之间不直接调用API而是通过事件event来交互。这样做的好处是模块A在处理一个事件时可以快速把另一个事件发给模块B然后立刻返回避免长时间占住CPU。在SCP这种资源非常有限的系统里一般只有几百KB的Flash和SRAM事件驱动模型比多线程栈方案要节省非常多内存。3.2 SCMI协议内核和SCP之间的普通话SCP对内核开放的服务不是靠一堆私有寄存器实现的而是通过一套标准化的消息协议叫SCMISystem Control and Management Interface。这套协议由ARM和多家半导体厂商共同定义现在已经成为ACPI和Device Tree之外ARM平台侧系统控制的标准接口。SCMI定义了很多协议簇Base协议用于协议版本的协商、设备属性的查询相当于握手环节。Power Domain Management协议控制电源域的on/off。Performance Management协议这是最核心的用来请求PERF域工作在某个性能等级也就是频率/电压调节。Clock Management协议管理非CPU外设的时钟比如GPU、NPU、ISP的时钟。Sensor Management协议读取温度、电压等传感器数据。System Power协议管理系统级的休眠、重启流程。内核侧的协议栈在drivers/firmware/arm_scmi/下通过scmi_perf、scmi_clock等框架向cpufreq、clk等公共子系统提供服务。也就是说Linux的cpufreq驱动根本不需要知道SCP长什么样它只要通过ARM SCMI驱动发一条MSG_PERF_LEVEL_SET的消息SCP那边自然会把频率和电压都调好。提示在调试SCMI问题时第一件事就是确认内核和设备树中SCMI节点是否使能以及firmware里是否编译了对应的协议。很多SCP不响应的问题其实是最初版本号协商就没有通过。3.3 SCMP更底层的私有通道除了SCMI这种面向内核的标准化协议SCP还有一种和自身特定功能相关的接口叫SCMPSCP Messaging Protocol。它通常被用作与SCP固件内部模块之间的交互比如在安全固件和SCP之间、以及芯片厂商自研模块之间。SCMP的消息格式更紧凑效率更高但不像SCMI那样有统一ID定义厂商可以根据自己的需求扩展。对大多数开发者来说接触SCMI的机会远多于SCMP但如果调试的是厂商自己的BSP代码遇到SCMP也不奇怪。图大概是这样一层一层的Linux内核cpufreq框架 - SCMI驱动 - 消息传输层MHU/共享内存 - SCP固件中的SCMI模块 - 性能/电源域服务模块 - 具体硬件寄存器。SCP内部没有Linux那种复杂的进程概念各个服务模块直接在事件循环里调度执行。由于SCP运行在安全世界和普通世界之外内核发给SCP的请求实际上是请求性质而非命令SCP有权利拒绝或延迟执行——理解这一点对排查为什么SCP不听话很有帮助。4. SCP的电源管理核心服务与实现机制4.1 DVFS让大核跑得快、小核省电的关键DVFSDynamic Voltage and Frequency Scaling动态电压频率调节是SCP最引以为傲的能力之一。很多人误以为DVFS就是CPU频率跟着负载走比如重负载时频率升高轻负载时降低。物理上做到这件事需要三个环节配合由内核策略决定该调了、由SCP执行调频率和电压、由硬件保证调的过程不出错。SCP内部实现DVFS的典型流程是这样的内核cpufreq governor比如schedutil根据调度器负载算出目标频率。通过SCMI perf协议发送PERF_LEVEL_SET到SCP参数是performance level值。SCP收到后性能管理模块先判断当前电源域状态如果正在transition就先把请求排队。SCP对时钟控制器和电源管理IC写寄存器。频率调整是先加电压、后升频率的顺序降频时反过来先降频率、后降电压。完成操作后SCP通过共享内存更新性能状态。内核看到状态更新才真正认定调频完成。这个过程中最容易被忽视的是第4步为什么要先加电压再升频率因为芯片内部每个晶体管都有最小工作电压频率越高需要的电压越高。如果在电压还没升到位的情况下直接把频率抬高就可能导致setup time违例、逻辑采样错误表现出来就是随机死机或者指令执行错误。SCP固件里的驱动表opp表通常来自芯片厂商的实测数据最大的坑是厂商给的电压表中存在电压余量不足的项导致某些批次芯片高频运行时不稳定——这类问题在量产阶段发现排查起来极其痛苦。还有一个实际经验SCP实现的DVFS往往支持异步模式也就是SCP可以先回一个已接受等操作完成后再发通知。内核侧如果使用异步模式性能会好很多但回调处理要写严谨否则会出现频率已经改了但内核不知道的状态错位。4.2 CPU idle与低功耗状态WFI只是开始ARM架构定义的电源状态从浅到深分别是WFIWait for Interrupt、WFEWait for Event、以及架构扩展引入的LPILow Power Idle状态。LPI状态需要由平台固件配合而且ARM通过LPI让OS可以表达我希望这个CPU核进入多深的睡眠状态。如果仅靠WFICPU核其实只是把流水线停了时钟还在跑漏电还在持续而进入LPI更深状态时可以把CPU核的时钟关掉甚至把电源域切断。传统做法是Linux的cpuidle框架会调用CPU上的PSCIPower State Coordination Interface固件接口请求core进入某个状态。但在最近的ARM系统设计中PSCI调用只是第一层跳板真正执行下电逻辑的是SCP。展开说明一下PSCI是Linux和ATFARM Trusted Firmware之间的接口它消费一个状态ID然后ATF通过一定的机制把这个请求转发给SCP。SCP中对应的电源域管理模块会检查这个状态ID翻译成对电源控制器、隔离单元、时钟和内存保持单元的序列操作。简化的状态转换是这样的OS通过CPU_SUSPEND调用PSCI。ATF保存上下文后把请求发给SCP借助SCMI power domain协议或私有通道。SCP把目标电源域的ref count减一判断是否真可以下电。如果可以被下电SCP按顺序执行关缓存维护如果需要、关闭core时钟、切断core电源、激活memory保持。发生唤醒事件时比如GIC收到中断、GPIO唤醒、定时器到期SCP检测到按逆序恢复电源、时钟然后发送事件给ATF/OS。真正的坑在于电源域下电的过程中cache和中断必须被妥善处理。有些芯片的L2 cache是cluster级别的如果只是想在core级别睡眠但整个cluster的电源域被切了那所有core的cache都没了唤醒后会有大量的cache miss甚至某些核心回不到正常工作状态。所以在阅读SCP固件代码时特别要注意它处理WMWake-up Mask和Memory保持域Retention Domain的代码路径厂商如果改错了这部分最典型的问题就是某个核睡下去就醒不来。4.3 系统Suspend/ResumeSCP的全盘接管手机息屏后、PC睡眠时整个AP子系统几乎都处于断电状态RAM运行在自刷新模式只保留一部分唤醒源。这个场景是SCP发挥最大作用的地方之一。当系统进入suspend-to-RAM时主CPU完成最后一次状态保存后会一步步关闭自身和外设的电源最后由SCP接管一切。SCP自己运行在极其低功耗的模式下它的时钟可以降到低频大部分模块关闭只保留唤醒检测逻辑。GPIO唤醒、调制解调器唤醒、USB唤醒等信号到来时SCP不需要主CPU帮忙就能自动识别唤醒源然后执行上电时序。这里有个很多BSP工程师都会遇到的问题系统suspend后无法唤醒或者一唤醒就死机。究其原因往往是SCP和ATF之间对唤醒源路由的配置不一致。比如内核在device tree里声明了某个GPIO可以作为唤醒源但SCP里对应的唤醒配置没有被同步更新导致SCP不认识这个信号。排查路径很清晰先确认唤醒信号能否到达SCP的电源管理单元再确认SCP是否识别并打开了唤醒掩码最后确认唤醒后主CPU的启动流程是否被ATF正确接管。4.4 Thermal管理散热这件事SCP也有份很多人不知道SCP还参与芯片的散热控制。现代芯片发热严重尤其是手机SoC大核全开几秒钟就可能温度报警。温度传感器每时每刻都在上报数据内核的thermal框架会读取这些数据并做出降频决策。但内核读取温度得有通道这个通道通常是SCMI的sensor协议。SCP里实现了一套thermal管理服务它周期性地从内部温度传感器读取die温度即芯片表面温度缓存夹在共享内存区域内核通过SCMI sensor消息读取温度值。在更高级的实现里SCP可以直接给DVFS模块发事件把最高频率限制在一个安全范围内这叫紧急降频它不需要内核参与响应速度更快。对开发者来说调试thermal问题时除了查看内核的/sys/class/thermal/目录之外记得也要关注SCP侧是否施加了硬性降频。我遇到过不止一次内核怎么看负载都不高但CPU频率就是上不去一查才发现SCP因为温度过高已经锁死了PERF上限而SCP侧没打日志导致排查走了很多弯路。5. 实操中的调试方法、常用命令与避坑经验5.1 如何确认SCP的固件版本与状态拿到一块新的ARM开发板第一件事不是跑压力测试而是确认SCP固件是否正常工作。最直接的方法是在内核启动日志里搜索与SCP、SCMI相关的dmesg信息。正常情况下你会在启动早期看到类似这样的打印scmi_protocol scmi_dev.0: SCMI Protocol v2.0 initialized scmi_protocol scmi_dev.0: Supported protocols: base(0x10) perf(0x13) power(0x11) sensor(0x15)这说明内核已经成功枚举了SCMI协议。如果这里直接报错或者没有输出那就极其可能是SCP固件没有加载成功或者共享内存地址配置错误或者MHU中断路由有问题。你还可以通过下面的方式触发一次SCP通信验证链路是否干净手动切换CPU频率echo performance /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference或cpufreq-set -f 1400000。手动读温度cat /sys/class/thermal/thermal_zone0/temp。手动控制CPU offlineecho 0 /sys/devices/system/cpu/cpu4/online。只要这些操作有响应、系统不崩SCP基本工作正常。如果响应异常比如offline后该核无法重新online问题范围几乎锁定在SCP的电源域状态机和内核的PSCI调用之间。5.2 日志插桩与Synchronous模式调试SCP固件里有一套日志框架可以输出到UART或者保存在内存环形缓冲里。它支持不同等级的调试打印INFO、WARN、ERROR以及更细粒度的状态机跟踪。如果你拿到的是厂商BSP可以在SCP工程配置中打开build option里的SCP_LOG_ENABLE相关的宏看到电源域状态机的切换记录。有一个很实用的调试技巧SCMI请求默认是异步的。也就是说内核发一条perf请求SCP处理完以后内核不一定立刻感知。为了核对时序可以把SCMI驱动切到synchronous模式主要在开发阶段使用即内核发出请求后进入一个等待循环直到SCP给出response才继续。这样做牺牲了一些性能但能在第一时间暴露SCP迟迟不回包的问题。我之前排查一个DVFS偶发卡死的bug时就是靠着synchronous模式发现是SCP在处理PLL切换时发生了缓存一致性问题——SCP自己的代码访问了主CPU的cache导致数据不一致。定位到这一步后在SCP侧增加了memory barrier问题就解决了。这种问题在异步模式下极难复现因为时间窗口被隐藏了。5.3 常见故障速查表我把自己踩过的坑和同行们常遇到的问题整理成了一个速查表症状CPU offline后无法online。原因SCP对电源域下电不完整或者唤醒掩码没有正确设置。对策查看SCP日志确认core的电源状态机是否真正达到了OFF状态检查ATF的PSCI处理是否错误地return了错误码。症状频繁伏频时系统随机crash。原因查OPP表中电压是否足够或SCP在调压过程中时序是否过短。对策加长PLL lock时间或调高对应频率点的电压。症状dmesg中SCMI clock协议加载失败。原因大多数情况下是共享内存size配置不正确或者MHU中断号不对。对策对比设备树与SCP固件的内存布局描述。症状suspend后无法resume且串口无输出。原因SCP唤醒逻辑中GPIO唤醒源判断失败。对策检查唤醒源的注册在SCP固件中打开wakeup debug打印。注意调试SCP问题时不要只看Linux内核侧的打印。SCP的日志输出往往在自己的UART口或内存缓冲区里如果一个串口看不到任何输出不要立刻认定是SCP固件死机先确认日志通道是否连对。5.4 关于热词中scp命令和scp基金会的澄清顺带做个澄清很多人搜索scp首先看到的是Linux下用scp命令传文件或者SCP基金会这种收容怪谈题材的内容。这些和ARM平台的SCP完全不是一回事。Linux的scp命令本质是Secure Copy走的SSH协议封装用来把文件夹或文件复制到远程机器SCP基金会则是一个虚构世界观中的组织代号。而本文讲的SCP指System Control Processor是芯片内部的一块处理子系统。如果在搜索引擎里找ARM SCP的资料最好加上ARM、System Control Processor这类限定词否则前几页大概率全是传文件教程和怪谈故事信任我我拿这些血泪教训换来的。5.5 一个实用的小技巧使用FTrace跟踪SCMI交互SCMI驱动支持与Linux的ftrace事件框架集成。在开发阶段你可以启用tracefs中的SCMI相关事件点。具体说在/sys/kernel/tracing/events/scmi/目录下编译内核时打开CONFIG_ARM_SCMI和CONFIG_TRACEPOINTS选项就可以跟踪每条SCMI消息的ID、Agent、Protocol、往返时间。使用方法很简单mount -t tracefs nodev /sys/kernel/tracing echo 1 /sys/kernel/tracing/events/scmi/enable echo 0 /sys/kernel/tracing/trace # 触发一下调频操作然后查看 trace cat /sys/kernel/tracing/trace打开后的输出能看到类似kworker/u16:3-170 [005] .... 1234.5678: scmi_msg_send: proto0x13 msg0x05 kworker/u16:3-170 [005] .... 1234.5679: scmi_msg_recv: proto0x13 msg0x05用这种方式看DVFS请求是否被SCP快速响应比用仪器量信号还方便。尤其是在多核调度频繁的场景下能直观看到perf请求的rate判断SCP是否成为了调频瓶颈。6. 写在最后SCP是ARM平台功耗的灵魂ARMv9/v8平台上做功耗优化绕不开对SCP的理解。它像一个大管家内核只是把需求写在纸条上递给它真正的理电、调频、下电、唤醒全由它打理。对BSP工程师来说掌握SCP的工作原理不只是会调几个freq节点而已而是能看懂整个系统的电源拓扑和状态流转。根据我个人的工程经验投入时间去读一遍SCP-Firmware里DVFS模块和电源域管理的代码绝对是值得的。不需要全部读懂只要理解了事件处理、状态机、共享内存和传输层再回到实际项目里做调试你会发现很多之前觉得玄学的问题答案其实就藏在SCP的状态转换路径上。最后分享一个小经验如果你在排查一个与调频、睡眠相关的疑难bug时别急着折腾内核侧先花半小时把SCP日志打开、把SCMI请求跟踪打开让问题先现形再动手改代码。谋定而后动比盲目打怪要有效得多。