IPMB接口协议总结
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 / Response Protocol （请求/应答协议）
IPMB使用“请求——应答”协议，发送一条请求消息给一个智能设备，该设备会返回一个独立的应答消息。任何传输协议都是有限制的，IPMB总线直接支持有15个内部节点的系统，系统应用应该努力减轻总线的占用时间，例如，每秒钟少于6条消息，这样做，可以确保节点可以成功在要求的重试次数内抢占总线。
请求消息和应答消息都是通过I2C总线的“主写”（Master Write）模式传输的，也就是说，一条请求消息是从一个作为I2C主端（Master）的节点发出，被一个作为I2C从端（slave）的节点接收；对应的应答消息是从一个作为I2C主端的应答设备（ responding intelligent device）发出，被一个作为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）也会包含在应答消息中，这可以使请求者核实应答是针对那一次请求的。
