IPMB接口协议总结

 

智能平台管理总线（IPMB）的设计是为了在mission-critical服务器平台支持“Server Platform Management”（服务器平台管理）的，该总线也可以用来支持外围机架和非服务器系统的平台管理。

IPMB协议要实现下列目标：

1、支持分布式管理机制。传感器和控制器分布在各个管理模块上，它们的信息通过IPMB传输。

2、支持异步事件通知机制和危机事件日志机制。IPMB应用多主协议，这样可以允许控制器抢占总线来发送事件消息到一个事件接收器（Event Receiver）节点。

3、             提供一个可扩展的平台管理结构。新的管理信息资源可以很容易的加入到平台管理总线上，而不会影响总线上的其他控制器。

4、             多主操作。IPMB应用多主操作来支持分布式管理机制、异步事件通知机制以及平台扩展功能，这种机制支持任何两个智能设备之间的通信。

5、             支持非智能I2C设备。

6、             支持“Out-of-Band”访问。IPMB是独立于系统处理器和内存总线的，这样，即使是在系统失败的情况下还可以访问。

7、             降低系统管理布线的复杂程度以及成本。

8、             为机架外部管提供途径。

 

l       IPMB总线平台管理网络架构

我们用微控制器（也叫做管理控制器“management controllers”或者节点“nodes”），独立于系统软件收集系统状态和事件信息，这些信息包括：单板电压、温度、风扇转速、处理器或者总线失败、FRU（现场可替换单元）信息等，来提高提高系统可靠性（RAS）。

 

IPMB协议所使用的物理层主要是I2C总线，下面是I2C 总线的一些特征：

1、I2C传输的起始和停止条件

在I2C总线中唯一出现的是被定义为起始S和停止P条件见图5的情况。其中一种情况是在SCL线是高电平时，SDA线从高电平向低电平切换，这个情况表示起始条件，当SCL是高电平时SDA线由低电平向高电平切换表示停止条件。起始和停止条件一般由主机产生总线在起始条件后被认为处于忙的状态，在停止条件的某段时间后总线被认为再次处于空闲状态。

如果产生重复起始Sr条件而不产生停止条件，总线会一直处于忙的状态。此时的起始条件S和重复起始Sr条件在功能上是一样的。如果连接到总线的器件合并了必要的接口硬件。那么用它们检测起始和停止条件十分简便，但是没有这种接口的微控制器在每个时钟周期至少要采样SDA 线两次来判别有没有发生电平切换。

 

图5 起始和停止条件

 

2、I2C传输数据

2.1 字节格式

发送到SDA线上的每个字节必须为8位，每次传输可以发送的字节数量不受限制。每个字节后必须跟一个响应位首先传输的是数据的最高位MSB。如果从机要完成一些其他功能后例如一个内部中断服务程序才能接收或发送下一个完整的数据字节，可以使时钟线SCL 保持低电平迫使主机进入等待状态。当从机准备好接收下一个数据字节并释放时钟线SCL 后，数据传输继续。在一些情况下可以用与I2C 总线格式不一样的格式例如兼容CBUS的器件，甚至在传输一个字节时用这样的地址起始的报文可以通过产生停止条件来终止此时不会产生响应。

2.2 响应

数据传输必须带响应，相关的响应时钟脉冲由主机产生，在响应的时钟脉冲期间发送器释放SDA线高，在响应的时钟脉冲期间接收器必须将SDA线拉低，使它在这个时钟脉冲的高电平期间保持稳定的低电平，当然必须考虑建立和保持时间。通常被寻址的接收器在接收到的每个字节后除了用CBUS地址开头的报文必须产生一个响应。

当从机不能响应从机地址时，例如它正在执行一些实时函数不能接收或发送从机必须使数据线保持高电平，主机然后产生一个停止条件终止传输或者产生重复起始条件开始新的传输，如果从机接收器响应了从机地址但是在传输了一段时间后不能接收更多数据字节，主机必须再一次终止传输，这个情况用从机在第一个字节后没有产生响应来表示，从机使数据线保持高电平主机产生一个停止或重复起始条件。

如果传输中有主机接收器，它必须通过在从机不产生时钟的最后一个字节不产生一个响应，向从机发送器通知数据结束，从机发送器必须释放数据线允许主机产生一个停止或重复起始条件。

 

IPMB支持两类I2C设备，非智能和智能的。典型的非智能设备如温度传感器，通过I2C总线可以读到当前的温度读数。非智能设备只能作为一个从设备，缺少IPMB通信协议的应用。非智能从设备可以和运行IPMB协议的智能设备同时存在与同一个IPMB总线上，地址冲突避免在I2C总线级，只要分配一个独一无二的从地址给总线上的所有设备即可。IPMB协议也可以支持SMBus从设备，不过要有一些限制。

下图为IPMB总线的连接架构：

  

典型的智能设备如服务器底板上的管理控制器。在智能设备中装有实现IPMB协议的固件和底板相关的其他功能固件，下面讲的IPMB请求应答通信协议是指在智能设备间的通信。

l   Request / ResponseProtocol （请求/应答协议）

IPMB使用“请求——应答”协议，发送一条请求消息给一个智能设备，该设备会返回一个独立的应答消息。任何传输协议都是有限制的，IPMB总线直接支持有15个内部节点的系统，系统应用应该努力减轻总线的占用时间，例如，每秒钟少于6条消息，这样做，可以确保节点可以成功在要求的重试次数内抢占总线。

请求消息和应答消息都是通过I2C总线的“主写”（Master Write）模式传输的，也就是说，一条请求消息是从一个作为I2C主端（Master）的节点发出，被一个作为I2C从端（slave）的节点接收；对应的应答消息是从一个作为I2C主端的应答设备（ responding intelligentdevice）发出，被一个作为I2C从端的请求发起者接收。

请求消息的一个重要性质是要能够指导应答消息能够准确返回给请求者，请求者在请求消息里提供它的Requester's Slave Address (rqSA)和Requester’s LUN (rqLUN)来引导应答返回请求者。

每个应答者的接口协议都定义了一些支持的命令字，应答者在这个特定的域位置必须提供至少一个命令字，任何其他和命令域相关的参数字节必须紧跟着第一个字节。应用程序向一个节点发送请求消息，必须能够通过解析命令域来识别应答。

有效的请求是指使用节点支持的命令的cmd号、netFn号和LUN并且能够通过数据完整性计算的请求消息，所有有效请求必须提供相应的应答。对这一要求的例外就是当节点接收到请求时正在处理一个命令，或者在等待另一个节点的应答。这时候节点可以选择用NAK通知请求方，也可以封装一个包含C0h完成码的应答消息来告诉请求方节点忙。

IPMB不要求对消息进行列队处理，也就是说接口是单线的，节点一旦接到某个节点的请求会清除所有等待发送到该节点的应答消息。但是桥节点除外。如果节点接收到请求包的数据checksum不对，将直接丢弃该数据包。

 

1、如何区分请求消息和应答消息：

请求消息和应答消息的网络功能号（network functions）不同，请求消息使用的是偶数，应答消息用的是奇数的网络功能号。由于有可能同时存在不止一条请求消息，那么区分一个应答消息到底是对应那一个请求就非常重要了。这是通过下列机制来实现的：

1、应答消息中包含Responder's Slave Address (rsSA) 和 Responder’s LUN (rsLUN)，这回告诉请求者（Requester）应答是从哪里来的。

2、请求消息中的命令域（Command (cmd) field）也包含在应答消息里面，这可以让请求者核实应答是针对具体那一个请求的。

3、请求消息中的序列号（Seq）也会包含在应答消息中，这可以使请求者核实应答是针对那一次请求的。

 

2、丢失应答消息由下面的机制来处理：

1、请求方超时等待应答。

2、请求方重试并超时等待知道超过超时次数限制。

3、请求方可以发送“Get Device ID”命令来看看应答方是否仍在工作，如果有应答，则发送“Warm Reset”命令来将其IPMB通信接口返回到一个可知的状态，如果没有应答，则可以认为应答方已经死掉。

IPMB接口使用序列号域来区分从发的请求消息，但是当请求方重启，就有可能产生和上一次发送的序列号相同的请求消息来，例如序列号刚超界，或者是刚刚只发送了一条消息。为了避免这些，我们使用序列号期满机制，当接收端接收到同一个节点的序列号相同但超过了序列号期满间隔就被看做是一条新的请求消息。

 

3、 Response Time-outs（应答超时）

请求方不可能认为所有的请求都会有应答，有可能在某种情况下应答方可能不会提供应答消息。这时候，请求方就要实现超时等待机制。

 

4、  Unexpected Request Messages（不希望的请求消息）

请求消息和应答消息不是自动成对传输的，在一个请求消息和应答消息的间隔，允许其他的总线传输，因此，节点必须容忍意外请求发生。例如，节点A发送请求消息给节点B，A正在等待应答的时候，自己可能会接到来自节点C的请求，节点A有多种方式来处理，第一，节点A可以接受并处理它，这是最可取的方法；如果不可以做到这一点，节点可以选择丢弃这个意外消息。

另外，任何应答消息如果没等待的请求有与之匹配的话，将被丢弃。任何希望得到的应答消息如果corrupted或者不遵从协议的话，也将被丢弃。

 

 

l       LinkLayer Addressing（链路层处理）

 

1、Connection Header（链路数据头）

这是一种链路层和网络层结合的数据头，成功传输该数据头就会在节点间建立连接，为传输后面的消息主体的字节准备好通路，下图为链路数据头的格式：

链路数据头包含一个7位的从地址，之后的一位是I2C读写位，由于IPMB协议只使用I2C的主写模式，所以这个读写位一直是0。这个字节之后的是网络功能号（）和LUN字节，和一个checksum字节。如果这个checksum不对，节点可以拒绝接收后面的数据。

 

2、Message Transaction Formats（消息传输格式）

IPMB点对点传输，数据包包含IPMB connection headers、command、和data字节。如下图所示：

 

3、除此之外，链路层还要处理一下对非智能设备的读写问题。

 

 

l      Design Objectives（设计目标）

 

协议的基本设计符合下列目标和原则：

（1）、设计能在处理能力有限和RAM和ROM资源有限的微处理器运行的应用。

（2）、展现高度对称性，例如：对节点的访问方法要和节点的具体应用相独立。

（3）、展现高度的相似性，例如机架寻址自然要和基本的I2C寻址一致。

（4）、桥接功能的处理和存储负担最小化。

（5）、展现清晰的功能层次，例如：消息数据不要差杂有协议数据，不同方面的协议数据也要相应的保持独立。

 

l      Protocol Use of I2C Services（协议对I2C服务的使用）

 

IPMB总线协议中I2C是用作媒介和物理层的。协议严格按照下列条件使用I2C服务：

1、只使用主写模式（Master Write）（I2C从地址的R/W位一直是0）.

2、不使用10_bit寻址。

3、每次传输只用一个从地址。

4、不使用repeated starts，repeated starts是I2C协议为了在传输的过程中改变总线方向而定义的。由于IPMB协议只用到主写模式，所以就不需要repeated starts 了，不过在非IPMB协议的设备中还是要继续使用repeatedstarts 的。

5、I2C的通知机制（ACK bit）只表示字节被从端接收，不能保证接收的数据的完整性和正确性。