硬件总线基础04：LPC & eSPI总线（3）

说在开头：关于关于科学是什么（3）

尽管证伪主义能很好地检验科学和非科学，但它依旧有漏洞。我们现在已经知道爱因斯坦的理论比牛顿更牛B了，因为“相对论”比“牛顿力学”能更准确的描述我们所处世界的现象。假如有一个时光机，将相对论带到300年前的牛顿时代，那个时代的科学家们见到了更准确的“相对论”，会有如何感想呢？可能会有两种情况：

1. 当时的观测技术可以通过观测，发现两种理论的区别；

2. 当时的观测技术无法区分两者。

关于第一种情况，我们可能会认为如果当年人类已经发现了观测结果与牛顿力学不符，那为什么还会这么坚定地信奉牛顿力学两个世纪呢？事实上在1859年，当时的人们就已经发现了“水星进动”现象了，但他们并没有怀疑牛爵爷，而是想当然地认为是由一颗没被发现的水星卫星所吸引导致的偏差，他们根据牛顿理论计算出了该未知卫星的大小和位置，还给这颗不存在的卫星起了一个名字。所以，他们并不会怀疑牛顿，而是会提出一个新情况来解释为什么找不到这颗卫星。所以如果相对论来到牛顿时代，并完美解决了水星进动问题，也不过是众多解释中一种，而且其它假说还是基于被无数实验验证的经典理论：牛顿力学之上的；那凭什么要选择相信相对论呢？

科学哲学家拉卡托斯假设过一个类似的场景：假如天文学家们观测到一颗星星的运转与牛顿力学的计算结果不符，会怎么办？他们会认为有一颗未知的星球干扰了这颗星星的运动，于是就开始动手计算那个未知的星球，但星球太小普通望远镜观测不到，于是他们就申请一笔资金，花上三年时间造了台天文望远镜；如果他们仍然没发现那颗星球，还是不会怀疑牛顿，会认为宇宙尘埃挡住了位置的星球，于是又申请造一颗卫星去发现那片尘埃，如果还是没有发现那片尘埃，他们会认为宇宙中的磁场干扰了卫星的仪器……，直到人们彻底将这件事情整个忘了为止。

所以实际上科学家们不仅喜欢找理由，而且无时不刻在找理由，因为在现实世界中找不到绝对理想的实验环境，所有的实验结果和观测数据永远都是有误差的。科学家们可以改进技术以减少误差，但永远没法真正消除误差，也没法精确地认定数值的某一部分肯定属于误差。而且宇宙中的确可能存在未知的星球，尘埃以及磁场，它们也确实干扰过数据，以往这样的事情也发生过（天王星的位置跟牛顿力学计算偏差，最终找到了海王星），而且科学家们给异常数据找的理由也都挺靠谱。所以在第一种情况下，当时的科学家还是会选择相信牛顿力学。

第二个假设说当时的观测无法区别牛顿力学和相对论的差别，那怎么办？非常明显，相对论要引入更多的假设还会产生让人匪夷所思的结论，根据奥卡姆剃刀原则，那时候的科学家们会更毫不犹豫地选择相信牛爵爷了。

科学不是追求真理的么？奥卡姆的剃刀能证明那条隐形的巨龙不存在么？没有，它只当那条巨龙不存在。根据奥卡姆剃刀原则，我们选择科学理论的原则不是哪一个更接近真理，而是哪一个更加简洁、实用。而相对论之所以会被后来的人们所接受，是因为背离牛顿力学而符合相对论的证据越来越多，多到人们觉得宁可选择复杂的相对论，也比不断给牛顿理论打补丁要更简洁、更省事。那么，科学理论相互取代，依据的是什么原则呢？是看哪个理论更实用，实用主义！那个市侩的、庸俗的、让我们瞧不起的实用主义，竟然是整个科学的核心。（大家还记得霍金对“日心说”和“地心说”的说法么？两个理论的差别就在于“日心说”更简单和实用。）

好，前面的种种栗子都表明了，科学是个只讲究实用与否的工具，我们在筛选科学理论时的唯一标准就是：实用。我们首先要求科学理论能够指导我们工作，不能出错；其次在不出错的基础上越简单易用越好。比如牛顿力学理论其实是错的，但是它在我们日常生活已经够用，所以我们普通人还是在学牛顿力学，而不是直接去了解相对论。那么科学的定义是：科学是建立在经验注意基础上的，以实用主义为原则筛选出来的，可以被证伪的理论。即，科学是在一堆科学假设中，挑出一个能够解释已有的实验和观测数据，而且表述尽量简单，还可以被证伪的理论。（参考自：林欣浩-哲学家们都干了些什么）

4，eSPI总线传输层

传输层的内容比较多，主要涉及到：Cycle Type and Packet Format，Channel，Slave Buffer Management以及传输顺序规则；

包格式如下所示，Cycle Type的具体定义参考eSPI总线规范5.1.1章节。

其中关于Channel，是eSPI中的一个非常重要的概念，它提供了允许多个彼此独立数据流共享同一条物理总线的一种方法。

1. 每一组Put/Get/Avail对应Channel的Command和Response；

2. 每个channel都有专属于自己的资源（举个栗子：Queue和流控），在不同channel之间并没有Ordering规则。

3. Master可以在初始化期间通过发送Get Configuration命令的方式获知Slave所支持的Channel；

4. Channel Type和Number都是固定的，Slave只能宣称支持哪个Channel。

接下来章节对不同Channel的概念展开分析：

4.1 Peripheral Channel

eSPI Peripheral Channel用于沟通位于eSPI Master内部的Host Bridge和位于Slave内部的 endpoint ，在软件上是不可见的。 如之前所分析，X86是独立编址的方式，I/O和Memory进行分开编址，I/O端口地址（举个栗子：64KB）不占用Memory地址（4GB）范围，将外设寄存器看成是有一个独立的地址空间，所以访问Memory的指令不能用来访问I/O寄存器。随着I/O设备的越来越多，64KB的地址空间就不够用了，PCI总线规范引入了Memory-Mapped I/O概念，将寄存器地址映射到memory空间中（实现了统一编址），同时PCI规范中还保留了I/O Cycle的操作，可以访问I/O空间。

但是考虑到前向兼容的要求，原先ISA总线上的I/O设备也还需要操作，所以设计了一个PCI-ISA Bridge，只需要将PCI总线负责将I/O Cycle打到PCI-ISA Bridge上就可以直接操作I/O端口了。但是ISA总线数量多，所占PCB面积太大，已经被淘汰，所以PCI-ISA Bridge这个功能就变成了LPC的Subtractive Decode Agent，LPC总线继承了ISA总线的功能和外设管理了起来。而现在eSPI的Perpheral Channel在PCI架构体系中扮演了同样的角色。

eSPI 总线会连接SuperIO作为Devcie，上面有很多类似KB/MS（鼠标键盘等），UART之类的低速IO设备；假如现在CPU去访问I/O 60h，这个I/O Port在BIOS里是分配给KB用的，如果没有内置的KB Controller的话，这笔I/O Cycle就会被打到Subtractive Decode Agent上，然后交给eSPI来解码。这就是eSPI Peripheral Channel 负责的事务了；即之前LPC BUS可以做的事，例如I/O Read/Write, Memory Read/Write，在eSPI里基本上都交给Peripheral Channel负责全面兼容了。

Peripheral Channel的具体操作如下：

1. 当Host Bridge被PLTRST复位的时候，Peripheral Channel也会被复位；

2. 在PLTRST 信号有效之前，Master和Slave完成HOST-RST-WARN和HOST-RST-ACK的VW（Virtual Wire）握手；

——在发送完HOST-RST-ACK之后，Slave不可以发出任何Peripheral Channel的传输，也不可以发出任何Host Domain的VW（例如：SMI/RCIN/IOQ）。

3. 在PLTRST 失效之前，Peripheral Channel上不可以存在任何传输，VW通道上没有任何的Host Domain的VW。

4. PLTRST之后，Peripheral Channel会被默认开启。

4.2 Virtual Wire Channel

Virtual Wire Channel用于将通过eSPI通信的Sideband Pin和GPIO的状态转换成Inband message；Serial IRQ中断通过此channel按照Inband message的方式通信（上报中断）。格式如下图所示。

——例如PCI Power Management所需的PME#信号，SCI#/SMI#硬件中断线，CPU INIT#，无特殊意义的GPIO等。

Virtual Wires Channel的Packet格式：

1. 一个6bit的header，表征在这个packet里要传递多少个Virtual Wire Group；

2. Virtual Wire Group有2byte数据，一个packet中最多可传输64个Group，由两部分构成：

——Virtual Wire Packet并不受制于流控，只要VW Channel开启则可以在任意时刻接收Packet；同时为了保证其最小时延，给于了VW Channel最高的优先级。

3. Virtual Wire Index ：由Spec预先设定；

4. Virtual Wire Data：通过Index可以查询到当前Group所传递的是什么类型的Virtual Message，通过查询Data Field就可以知道Message里面传递的数值是多少。

——举个栗子：通过如下定义，0x0181的Virtual Wire Group代表IRQ1 is high。

VW的大致定义如下，具体请参考eSPI总线规范Table9。

0-1：interrupt event；

2-7：system event；

8-63：保留；

64-127：平台特定；

128-255：GPIO。

4.2 Run-Time Flash Access Channel

X86芯片组和EC/BMC之间有实时共享Flash部件的需求，flash channel为它们提供了一条合适的路径。 一旦在芯片组端的Flash控制器完成了初始化，Slave端的flash channel就会被打开。

eSPI涵盖的device包括BMC/EC/SuperIO和80 Port Debug Card，并没有使用Flash的需求。EC的内部一般都运行着一颗MCU（单片机），而BMC基本都是采用ARM做为控制内核，二者都需要FW配合才能正常工作，也有能力也有需求去访问Flash，所以针对Flash Channel所能涵盖的eSPI Slave仅限于EC和BMC。

PCH（Platform Controller Hub）和EC上各自都挂了一颗SPI Flash，从功能上来讲，PCH的那颗Flash用于存放BIOS和FW（例如ME），EC那颗Flash用于存放自己启动和运转所需的EC FW。BMC的情况也是类似，Server Chipset和BMC最起码都需要各自挂一块Flash，用于存在BIOS和BMC FW。那么共享Flash操作是指PCH或EC/BMC能够通过eSPI总线直接去操作SPI Flash么？还是将所有的FW/BIOS放在一个Flash中，可以允许PCH/EC/BMC来进行操作？

1. 通过上面对eSPI总线协议的介绍，我们应该确定的是eSPI总线协议并不能用来直接 操作SPI Flash，所以PCH或EC/BMC并不能通过eSPI总线去读写SPI Flash；

2. 将PCH/EC/BMC的FW/BIOS存在在一个SPI Flash中，存在很大的可靠性风险。

这里所谓实时共享的就是放BIOS这颗Flash了，Chipset对这颗Flash的需求还是存放BIOS和Chipset FW，而EC/BMC这边的需求就不尽相同了；对于BMC来说，在IPMI Spec中为其定义了一个叫做Non-volatile Storage的部件，如下图所示。

按照定义，系统日志/传感器数据和FRU信息（可替换部件的信息，比如插了多少根内存条，挂了多少块硬盘）都会存储到这个Non-volatile Storage。这样的话，除了载有BMC FW的那块Flash，BMC还需要另外一块Flash充当这个Non-volatile Storage的角色。EC也是差不多的道理，在某种情况下EC可能需要一块额外的Flash存放一些非易失的数据。eSPI BUS的Flash Channel为Chipset和EC/BMC提供了一条可以实时共享Flash部件的通路。根据这颗被共享的Flash挂在eSPI Master Side(Chipset)还是eSPI Slave Side（EC/BMC），eSPI Spec将Flash Channel的工作模式划分为Master Attached Flash Sharing和Slave Attached Flash Sharing。

1. Master Attached Flash Sharing：在该工作模式下，被共享的Flash是挂载在eSPI Master Side（不是直接挂载在eSPI Master下面），如下图所示；

——如果这是一块SPI Flash，那它应该挂在Chipset的SPI Controller下面，不存在一种叫做eSPI Flash的东西，可以直接挂在eSPI Master下面，eSPI Protocol里也没有相关command可以直接用来Read/Write/Erase Flash。

2. 共享Flash挂在Chipset的SPI Controller下面，走SPI协议和Chipset进行交互，EC/BMC/SIO等挂在eSPI Controller下面，走eSPI协议和Chipset进行交互；

3. Chipset需要进行Flash访问的时候，直接打Cycle到SPI Controller上，然后SPI Controller再把相关的Read/Write/Erase Command打到SPI 总线上；

4. EC/BMC想进行Flash访问的时候，通过eSPI 总线向eSPI Master发起Flash Channel Cycle，然后eSPI Master向SPI Controller发起数据请求，SPI Controller收到后，再把相关请求转换成对应的Read/Write/Erase Command打到SPI 总线。

——从Flash那边拿到的数据还是需要通过SPI Controller传递给eSPI Master，然后eSPI Master再通过eSPI Flash Channel的Cycle传回给EC/BMC。

如果eSPI和SPI在总线上共用了I/O和CLK等管脚，但从本质上来说，SPI和eSPI是两个完全不同的总线协议，操作流程上跟上述是一样的。拓扑结构如下图所示。

1. Slave Attached Flash Sharing：该模式是针对Server平台的，所以这里的Slave Attached指的是被共享的这块Flash挂在BMC Side（挂在BMC的SPI Controller下），如下图所示。

2. 当BMC想进行Flash访问的时候，直接向自己的SPI Controller下发指令，然后SPI Controller把对应Read/Write/Erase打到图中的BMC SPI总线上；

3. 当Chipset想进行Flash访问的时候，先向Chipset的SPI Controller下发指令，然后Chipset SPI Controller向Chipset eSPI Master发起数据请求，Chipset eSPI Master收到后，把相关数据请求转化对应的eSPI Flash Channel Cycle打到eSPI 总线上，BMC里面eSPI Slave看到eSPI 总线上的Flash Channel Cycle，会再向BMC SPI Controller发起数据请求，然后是BMC SPI Controller把请求转换成Read/Write/Erase command打到BMC SPI 总线上。

——共享Flash看到command后再把数据原路传给BMC SPI Controller-->BMC eSPI Slave-->Chipset eSPI Master-->Chipset SPI Controller。

4.3 OOB Message Channel

OOB：Out of Band Management（带外管理），这是计算机系统管理里面的一个名词，对应的还有In-Band Management，也就是带内管理。带外管理通过与带内管理数据通道物理上相互独立的管理通路进行系统管理和监控。无论被管理是否处于开机状态，只要通电并且联网，就可以远程监控和管理设备，包括远程开关机，远程重新启动，远程修改BIOS菜单设置，远程安装操作系统等，功能强大到超乎你的想象。

在服务器领域，带外管理是通过BMC进行的，它借助IPMI总线进行带外管理，它是一颗独立于CPU和Chipset的芯片，有着自己的处理器（通常采用ARM内核）和FW，在其上运行着一个嵌入式Linux操作系统。上电后BMC就可以独自运行，然后通过各种总线管理和监控服务器主板。

可能受到BMC的启发，Intel在PC领域也引入了类似概念：在Chipset内部集成一个专门用于带外管理的处理器，官方称其为Management Engine，也就是ME。和BMC一样，它是脱离于CPU独自运行的，有自己的操作系统。只要计算机主板的AC Power插着，ME就可以接管这台计算机。

——举个栗子： IT人员可以通过ME将原本关机的电脑开机，并用管理员账号登陆系统，然后把最新的Windows patch打到电脑里。

eSPI规范中的Out of Band Processor如下图所示，如之前所述，EC/BMC/SIO除了使用LPC BUS跟chipset进行In-Band通信以外，还需通过SMBUS和Chipset集成的OOB Processor（比如ME）进行Out of Band通信。但是它俩之间并不是普通的SMBUS Master和Slave之间的关系，而是MCTP通信模型中不同的两个Management Controllers之间的关系。

SMBUS是一个三层通信协议（物理层/数据链路层/网络层），MCTP全称Management Component Transport Protocol，是一个传输层的协议，SMBUS Block Write只是MCTP的实现形式之一。除了SMBUS Block Write以外，MCTP还可以基于PCIe Vendor Defined Messages (VDMs)进行实现。在MCTP通信模型中，定义了两种通信方式，而OOB Processor和EC/BMC就在第一种通信方式所定义的范围内：

1. Management controllers and other management controllers

2. Management controllers and management devices

所以，所谓的eSPI OOB Channel的本质，就是把本来在SMBUS上流通的MTCP Packet，从Out of Band Packet变成了In-Band Message，这样Chipset和EC/BMC进行MTCP通信的时候就不需要占用SMBUS的带宽和管脚了。如下图所示。

5，其它内容

其它更多有关eSPI总线的相关内容：链路层协议，Slave寄存器，电气规范/时序，中断/错误检测及处理，复位，上电时序和初始化等等内容请参考eSPI总线规范《Enhanced Serial Peripheral Interface (eSPI) Interface Base Specification. Revision 1.0》。

写在最后

本章内容很多，我们粗略的介绍了LPC和eSPI总线规范，大家通过本章的内容可以大致了解这两个有继承关系的总线；如果胖友们有更深入学习的需求，则需要研读总线规范文档，同时还需要了解X86架构以及PCI总线规范。

本章部分相关内容和图片参考自：LPC总线规范-Intel-《Low Pin Count (LPC) Interface Specification. Revision 1.1》；eSPI总线规范-Intel-《Enhanced Serial Peripheral Interface (eSPI) Interface Base Specification. Revision 1.0》；第五位面壁者-知乎-《eSPI接口规范翻译与导读》。下一章《PCI总线基础》。