Linux AMP基础组件可用性获肯定，测试生态仍待补强

在2026年欧洲嵌入式Linux开发者大会上，Linux内核开发者、I2C子系统维护者Wolfram Sang分享了对非对称多处理（AMP）基础组件的评估。他认为相关组件总体基础稳固，已经可以继续开展开发，但贡献者覆盖不足、测试体系碎片化等问题需要优先改善。这次演讲源于他尝试将硬件自旋锁驱动合入主线内核，并由此重新审视Linux侧AMP软件栈；他也建议听众结合Zephyr、可信固件和设备树等主题的演讲进行参考。

典型AMP系统会让Linux应用处理器与小型实时内核运行在同一颗SoC中，通过邮箱传递“数据已准备好”的信号，再利用共享SRAM或DDR存放数据。系统复杂度上升后，还必须协调共享资源的所有权。Sang重点介绍了SCMI：Linux可借助它与专用系统控制处理器协同管理时钟等资源，而不是独立负责全部硬件资源。邮箱通信也并非简单的单向门铃：两个单向邮箱可以组成请求—应答通道，完整的双向SCMI通常需要四个邮箱。不同固件实现并不统一，例如Keystone固件用两个单向邮箱完成双向SCMI，却没有为通知预留确认路径，这会影响协议兼容性。

AMP栈中的其他组件承担不同职责。remoteproc可加载固件、启动或停止远端处理器，固件二进制还能够描述所需资源；配置共享内存和触发对端的驱动回调后，它便可支持RPMsg通信。Virtio则通过共享内存中的虚拟队列建立开放通信标准，并在有任务处理时发送通知。Sang还区分了用于处理器间通信的RPMsg与尚未进入上游的virtio-over-message方案，后者计划通过消息通道承载Virtio流量。

从代码提交情况看，remoteproc核心代码提交数已由Linux 5.0时期的175次增至约1550次，但经历早期快速增长后，近期增速放缓。邮箱代码和驱动的活跃度是近年才提升，贡献超过5个补丁的开发者大约只有4人。硬件自旋锁的情况更突出：约7年间核心提交数仅从19次增至30次，驱动数量几乎没有变化。Sang没有据此认定组件存在缺陷，而是呼吁扩大代码评审和测试参与者范围。

他的自旋锁驱动开发也体现了维护成本：一次看似有限的改动最终牵涉头文件和生命周期管理，拟议的调试优化还受到已废弃API影响；有时测试一个驱动甚至需要同步修改固件和U-Boot。OpenAMP虽然提供构建文档与测试用例，但示例目前仍无法在全部支持的开发板上统一运行。Sang认为，降低这些开发与验证门槛，是支撑更复杂AMP系统持续发展的关键。