为什么ARM Server要用ACPI？ACPI vs DeviceTree

近期除了新冠疫情泛滥的新闻之外，最吸引人们注意力的莫过于乌克兰的战争了。出乎大多数人的意料以外，曾经以为会一边倒的战争，变得拖沓不堪，恰如上海的“短暂”隔离——没完没了。无论结果如何，这场战争让曾经老大哥科技上的软肋暴露无遗，在美国和欧洲的高科技武器和信息战助力下，俄军不但没有风卷残云，反倒随着时间的推进，落入被动挨打的局面。对于看似置身局外的中国来讲，这次“特别军事行动”，在某种程度上是个好事，它是一次真实的沙盘演练，在不损失什么的情况下，看看对方出招的方向在哪里。相信今后，追求科技进步，尤其是芯片产业完全自主可控，更成为国家的当务之急。

国内芯片设计热已经有一段时间了，我不时可以获知这家或者那家在做芯片。有些公司非常有名，有些则在百度上也搜不到，只有在企查查之类的软件上管窥一下。其中不少公司还找上门来，让帮忙搞定BIOS。这些新芯片大部分基于成熟ARM的架构，也有时下新宠RISC-V。这其中有一个规律：RISC-V芯片族还在忙着进入嵌入式系统，而ARM芯片们则从嵌入式系统中向上生长，不断侵蚀桌面和笔电系统，更是向x86占据绝对优势的服务器领域发起第三波冲击。在和这些新伙伴交流的时候，一个问题总是被反复提及：为什么嵌入式系统中运行良好的uboot + DeviceTree模式固件，在台式机，特别是服务器市场中，不能照方抓药呢？

在客户闪烁的眼神背后，我听出了客户的弦外之音：uboot+DeviceTree模式没有BIOS厂商什么事，为什么ARM服务器不行？相当于客户问S4店，你们能带来什么价值？为什么要给中间商赚差价的意思。听到这个事关商业模式是否可行的终极问题，我是病中惊坐起，强打十二分精神，来回答一下这个问题：为什么通用服务器要用UEFI + ACPI？

前一阵，我花了点时间，介绍了ARM SystemReady的由来和目的：

我在其中介绍了uboot的种种局限，和传统ARM在软件上的封闭与x86的开放（尽管硬件上恰恰相反）。今天咱们从另一个角度来看一下这个问题。

嵌入式产品 vs 服务器产品

我们分别在两者中各挑选一个典型产品，看看他们的客群和商业模式有什么区别。手机是典型的嵌入式产品，它和云服务器的客户有什么不同？

手机的客户是终端消费者，它是一种高度定制化产品。它的硬件和软件一经出厂，则不能轻易改变。用户既不能随便更换主板上的各种硬件，也不能更换软件。不信可以试试看能不能在苹果手机刷入华为手机固件（包括操作系统），是不是就可以得到一个苹果样子的华为手机？不但不同厂商不能互刷，同一个厂商不同的产品线一般也不能互刷。如此的高度定制，让通用需求极大削弱，对硬件和操作系统的互操作性需求也相应减弱了。

云服务器的客户是云服务厂商和企业IT等专业用户。这些客户一个根本诉求是兼容性，包括硬件的和软件的。因为带有芯片和BIOS的主板只是拼图的一小部分，各种外围板卡、操作系统、中间件、数据库和上层软件则是拼图中更大一块。这些部分往往从不同的厂商采购，甚至有些板卡和软件是祖传的，没人敢改。服务器超级复杂，不能垂直整合，只能采用生态圈的模式。这对硬件和操作系统的互操作性提出了很高的要求。 要通用和互操作，这就要标准化，各个部件也要各自产品化，而不能是整个产品是一个产品就好了 。操作系统只有一份，是一个单独的产品；PCIe板卡也是一个产品，单独售卖；尽管主板和CPU千奇百怪， 但这些硬件和软件的各种产品都可以在上面顺利运行，主板上的BIOS定制起到了关键作用 。BIOS起到了遮蔽硬件区别，提供统一界面的作用。

UEFI的标准化让它相对uboot，更加适合服务器和个人电脑。它初始化了硬件，并 主要通过ACPI来描述硬件，提供一个硬件抽象表述（另外一个是SMBIOS） 。但DeviceTree也是标准化 ^[1] 和开源 ^[2] 的数据格式，它也能隐藏和汇报硬件的差异，为什么服务器必须使用ACPI呢？为什么前文介绍的ARM SystemReady中仅有面向嵌入式的IR标准用推荐用DeviceTree，而服务器的基线SBBR （Server Base Boot Requirements）中明确要求ACPI呢？

DeviceTree简介

早期Linux和硬件芯片与平台绑定严重，在arch/arm下有着众多名字叫march-xxxx（芯片微架构）和plat-xxx（平台）的目录，里面有着众多各个芯片和平台的代码。基本上每加入一个芯片和平台，就要加入一个目录和一组代码，可扩展性十分差。而相较而言，i386等目录就清爽了很多。这种情况不能持续，随着支持Linux开始支持越来越多的平台和芯片，矛盾爆发了（Linus发飙了）。

支持PowerPC和SPARC的Open Firmware有一种不错的硬件抽象模型：DeviceTree（DT）。顾名思义，也就是用设备树的方式，将系统中的硬件设备组织和继承关系描述出来。Linux在支持这两种架构的CPU的时候，也加入了对DT的支持。在ARM Linux这种C语言硬编码模式支持芯片和平台出现瓶颈后，自然而然，DT就被借鉴过来，从此目录清爽了很多（后期做过清理）。

DT的文本模式叫做DTS（Device Tree Source），它是文本的可以方便阅读的版本，相当于c语言的.c文件，可以用任何文本编辑器编辑它。它采用树状描述系统的设备。让我们看一个例子，如BeagleBone Black ^[3]

我们把它的设备抽象成：

一个对应的DTS文件为：

{
   model = "TI AM335x BeagleBone Black"; 
   compatible = "ti,beaglebone-black", "ti,am335x-boneblack", "ti,am335x-bone", "ti,am33xx"; 
      cpu@0 { cpu0-supply = <&dcdc2_reg>;  };