文档中心
IEU CSR配置指导书
更新时间： 2026/03/16
在Gitcode上查看源码

一个完整的SR文件，包含硬件的版本描述信息、硬件的管理拓扑信息、硬件的传感器和状态信息、告警和时间信息、装备测试信息。

SR数据为json格式，完整的SR数据结构包含4部分数据：FormatVersion、DataVersion、ManagementTopology和Objects。

1 CSR的版本描述信息 ​

FormatVersion、DataVersion分别为CSR代次版本号和固件版本号，其定义规则具体如下:

  • FormatVersion：定义了SR数据格式及整体结构；
  • DataVersion：跟随SR数据内容变化而变化，作用与CPLD版本号相同，高位为大版本号，低位为小版本号；
  • FormatVersion、DataVersion为A.BC样式（A取值范围为1-255， B、C取值范围是0-9）；范围约束：A为大版本，范围：1-255，BC为小版本，范围：01-99，小版本固定两位，不足两位需要补0；
  • Unit：定义当前SR描述的组件类型“Type”和单板名称“Name”，组件类型包括基础板BCU、扩展板EXU、硬盘背板SEU、风扇板SLU等，按照天池架构规范定义；单板名称需要与后续单板描述信息的对象对应起来；

以XXX机型 IEU单板为例进行说明：

json
  "FormatVersion": "3.00", // 3.00为CSR代次版本
  "DataVersion": "3.05",   // 1.17为固件对外的版本，即BMC显示的CSR版本号，3为大版本号，05为小版本号
  "Unit": {
    "Type": "IEU",
    "Name": "RiserCard_1"
  }

2 硬件的管理拓扑信息 ​

  1. ManagementTopology作为管理拓扑的关键字，按照树结构根节点开始，以层序遍历的方式平铺列出Bus/Chip/Connector的连接关系；
  2. 管理拓扑是SR中描述组件上的管理树模型，包括单板上的管理根链路I2C，hisport_over_I2C通道，以及单板上存在和内存、TPM、UBC连接器和软件虚拟的状态连接器；
  3. Anchor，Buses，Chips，Connectors作为拓扑信息中的关键字， 硬件自发现组件解析CSR时需要匹配这些关键字，其中Anchor表示拓扑结构的入口，为固定命名，Buses中的对象不需要重命名，Connectors下面的对象不需要传递给硬件访问代理组件;

以xx机型IEU为例进行说明：

json
"ManagementTopology": {
  "Anchor": {
    "Buses": [
      "Hisport_0"
    ]
  },
  "Hisport_0": {
    "Chips": [
      "Pca9545_PCA9545"
    ]
  },
  "Pca9545_PCA9545": {
    "Buses": [
      "I2cMux_Pca9545_PCA9545_4",
      "I2cMux_Pca9545_PCA9545_1",
      "I2cMux_Pca9545_PCA9545_2",
      "I2cMux_Pca9545_PCA9545_3"
    ]
  },
  "I2cMux_Pca9545_PCA9545_4": {
    "Chips": [
      "Pca9555_IO",
      "Chip_MCU1"
    ]
  },
  "I2cMux_Pca9545_PCA9545_1": {
    "Connectors": []
  },
  "I2cMux_Pca9545_PCA9545_2": {
    "Connectors": [
      "Connector_PCIE_SLOT2"
    ]
  },
  "I2cMux_Pca9545_PCA9545_3": {
    "Connectors": [
      "Connector_PCIE_SLOT3"
    ]
  },
  "Chip_MCU1": {
    "Buses": [
      "I2cMux_McuSwitch"
    ]
  },
  "I2cMux_McuSwitch": {
    "Chips": [
      "Eeprom_IEU"
    ]
  }
}

注意：

  • Buses、Chips、Connectors不管下级有多少个对象，都不能删掉s/es，这三个字段是固定的，不能写做Bus、Chip、Connector。
  • 拓扑的配置根据原理图的拓扑来配置，建议配置前先根据原理图画出管理方案图。

3 组件信息获取和管理 ​

3.1 单板信息 ​

3.1.1 RiserCard信息 ​

CSR是单板自描述信息，首先应当描述本板的基本信息。IEU使用RiserCard对象来配置一下信息：

1、单板身份信息：单板UID、单板板名、厂商信息、单板类型、类型描述、单板部件编码、PCB版本、BoardID；

2、单板管理信息：板上CPLD的位号和版本号、CSR的版本号、MCU版本号；

3、注意此处对单板信息描述的对象名称需要与第一章节中单板名称保持一致；

1.CSR常用语法

1、对象引用：有两种在Object的字段中引用其他Object数据的方式，#/称为引用，<=/称为同步，#/指的是当需要引用到这个属性的时候，转去访问这个符号指定的属性，一般与Accessor绑定使用，用于读写指定寄存器的值；<=/指的是监听原字段的值，当被同步的数值发生改变时，触发信号变更该属性的值。通常与Scanner绑定使用，用于周期性读取指定寄存器的值。

2、数据引用：${}称为数据引用，表示引用其他已定义的字段数值

2. IEU配置举例

json
"RiserCard_1": {
      "Slot": 1,                        // 槽位号，为上一层级Connector传下来的值
      "UID": "00000001040302052854",    // 单板UID，vendor(00000001)+组件类型（01）+0302编码（0302057042）
      "Name": "<=/FruData_IEU.BoardProductName|> expr($1 == '' ? 'IT51PRUA' : $1)",        // 单板名称
      "Manufacturer": "<=/FruData_IEU.BoardManufacturer|> expr($1 == '' ? 'XXX' : $1)",    // 厂家信息，BP配置为--，其余可以同步FruData对象的BoardManufacturer属性
      "Type": "IEU",                    // 单板类型，IEU
      "Description": "Riser(X16*1)",    // 描述信息
      "PartNumber": "<=/FruData_IEU.BoardPartNumber|> expr($1 == '' ? '0302052854' : $1)", // 单板0302编码
      "PcbID": "#/Accessor_PcbID.Value",// Pcb版本
      "PcbVersion": "",                 // 单板的PCB版本,BMC从CPLD中获取单板的PCB版本
      "LogicVersion": "N/A",            //CPLD的版本信息，Riser一般不涉及
      "SRVersion": "${DataVersion}",    //CSR的版本信息，引用DataVersion属性
      "MCUVersion": "",                 //MCU的版本信息，不需要配置，自动获取
      "BoardID": 65535,                 //单板的BoardID，天池架构不涉及，默认配置为65535
      "BoardType": "RiserCard",         //单板类型：RiserCard
      "Number": 1,                      //根据整机配置更新逻辑编号，目前仅背板使用，使用SlotConfigs配置属性，IEU默认配置为1
      "DeviceName": "PCIeRiser${Slot}", //板卡丝印信息，格式为单板描述+槽位号，原则上采用大驼峰命名风格，不带下划线，提供给Redfish接口使用
      "Position": "IEU${Slot}",         //单板位置，格式为组件类型+槽位号，提供给Redfish接口使用
      "NodeId": "chassisPCIeRiser${Slot}", //资源id,这里由位置Position和设备丝印名称DeviceName拼接而成，提供给Redfish接口使用
      "FruID": "<=/Fru_IEU.FruId",      //单板的Fruid信息，具有唯一性
      "SerialNumber": "<=/FruData_IEU.BoardSerialNumber",  //序列号，关联FruData的BoardSerialNumber属性
      "RefMCUChip": "#/Chip_MCU1",      //参考的MCU对象，关联Chip_MCU，给RunningStatus使用，在bmc启动后例测60s检测mcu和cpld关联信息是否获取正常
      "CpldStatus": 0                   //Riser上一般是MCU的状态，用来反应MCU通信是否正常，MCU自检异常告警需要引用该属性配置
    }

3.1.2 单板上的器件 ​

单板上有很多关键器件和资源，需要先定义，再调用。

  1. IEU为IO扩展组件，会对接很多不同的Pcie设备，需要配置Connector来加载连接器对接的下级组件，下级组件分为天池标准组件、非天池标准组件三种，每种组件对应的Connector有不同的配置方法；
  2. IEU每个对接下级组件的连接器，都需要配置对应的Connector对象，按照拓扑将传到下级组件的信号配置在Connector的Buses中；
  3. 如果IEU的一个槽位存在对接天池标准组件和非天池标准组件的场景，需要针对该槽位配置两个不同的Connector。

对接天池标准组件

json
{
    "Objects": {
        "Connector_Exu_1": {
            "Bom": "14100513",      //表示下级组件Bom Id，仅作为一个标识，需要在BMC内部代码定义，一般是使用对接下级组件连接器的器件编码 
            "Slot": 1,              //给下级单板分配的槽位号，不同硬件槽位需要不同
            "Position": 1,          //为保证SR定义对象名称全局唯一，需要对每个（SR）硬件组件中自描述对象进行重命名，重命名后的对象名称由SR定义的对象名+_${Position}后缀组成
            "Presence": "<=/Scanner_Presence_1.Value",     //在位信息，只有为1时，才会加载下一级sr；天池标准组件类型需要指定在位状态获取方式，一般通过同步属性语法通过硬件代理读取指定器件寄存器数据
            "Id": "",              //表示下级组件Board id，天池标准组件的BoardId通过Chip属性关联的器件对象，调用对应的读写接口获取Eeprom数据中的Board Id信息。
            "AuxId": "",           //AuxId是副ID，和ID配合在一起加载SR用的，sr文件命名是bom_id_auxid，如果id不够用，就配置auxid
            "Buses": [             //本级连接器的总线
                "I2c_2"
            ],
            "SystemId": 1,         //host的id，多host场景下会有多个配置，默认1
            "SilkText": "RiserCard${Slot}",   //丝印信息
            "IdentifyMode": 3      //表示下级组件识别方式，3对应下级组件识别方式为天池标准类型组件，从下级组件的Eeprom读取CSR；2对应下级组件识别方式为BoardId不可读（上报）类型组件，根据bom_id_auxid的组合会去BMC内置的sr中寻找对应命名的sr文件
        }
    }
}

对接非天池标准组件

json
{
    "Objects": {
        "Connector_IdReport_1": {
            "Bom": "14100513",      //表示下级组件Bom Id，仅作为一个标识，需要在BMC内部代码定义，一般是使用对接下级组件连接器的器件编码
            "Slot": 1,              //给下级单板分配的槽位号，不同硬件槽位需要不同
            "Position": 1,          //为保证SR定义对象名称全局唯一，需要对每个（SR）硬件组件中自描述对象进行重命名，重命名后的对象名称由SR定义的对象名+_${Position}后缀组成
            "Presence": 0,          //表示初始Presence状态，BoardId不可读类型由多样化硬件上报设置，值必须配置为0，否则会导致下级组件无法正确触发自发现逻辑。
            "Id": "19e50222",       //表示下级组件board id，BoardId不可读类型由多样化硬件上报设置，无需配置
            "AuxId": "19e5005a",    //AuxId是副ID，和ID配合在一起加载SR用的
            "Buses": [              //本级连接器的总线
                "I2c_2"
            ],
            "SystemId": 1,          //host的id，多host场景下会有多个配置，默认1
            "SilkText": "RiserCard${Slot}",      //丝印信息
            "IdentifyMode": 2,      //表示下级组件识别方式，3对应下级组件识别方式为天池标准类型组件，从下级组件的Eeprom读取CSR；2对应下级组件识别方式为BoardId不可读（上报）类型组件，根据bom_id_auxid的组合会去BMC内置的sr中寻找对应命名的sr文件
        }
    }
}

IEU配置举例

json
"Connector_PCIE_SLOT2": {
  "Bom": "14140130",
  "Slot": 2,
  "Position": 2,
  "Presence": 0,
  "Buses": [
    "I2cMux_Pca9545_PCA9545_2"
  ],
  "SystemId": 1,
  "SilkText": "RiserCard${Slot}",
  "IdentifyMode": 2,
  "Container": "Component_RiserCard",
  "Type": "PCIe"
}

说明：

  • "Bom": "14140130" 表示下级组件Bom Id，即连接器的部件编码
  • "Presence": 0 表示初始Presence状态，BoardId不可读类型由多样化硬件上报设置，值必须配置为0
  • "IdentifyMode": 2 表示下级组件识别方式，2表示sr文件从BMC内置的文件加载。

注意：Connector需要在拓扑中配置

json
"I2cMux_Pca9545_PCA9545_2": {
  "Connectors": [
    "Connector_PCIE_SLOT2"
  ]
}

说明：I2cMux_Pca9545_PCA9545_2为通过Connector_PCIE_SLOT2传到下级的管理I2c信号

Chip是使用最广泛的类，当前可表示MCU、Raid、Hi822、SSD等众多部件的芯片器件。

1. 属性说明

属性名类型描述默认值
ReadRetryTimesU8描述读取寄存器的重试次数0
WriteRetryTimesU8描述写入寄存器的重试次数0
DrvWriteDelayU8Riser Mcu老版本需要在内核驱动写数据后进行延时，防止出现升级错误帧失败问题，单位ms0
SupportedBooleanChip是否具备汇聚数据访问能力 true: 具备 false: 不具备false
BaseOffsetU32汇聚资源起始偏移/汇聚命令字, Smc场景下为汇聚命令字; 其他块设备场景为起始偏移, 连续读取一段数据
LengthU32汇聚资源总长度，同SmcDfxInfo的Size
PeriodU32汇聚资源扫描间隔，单位ms程序默认值1000

2. IEU配置举例

Riser卡涉及的Chip为MCU，MCU共用代码，地址一致，可以直接和下列示例保持一致

json
"Chip_MCU1": {
      "OffsetWidth": 1,     // 偏移宽度
      "AddrWidth": 1,       // 位宽
      "Address": 200,       //描述器件在总线的地址信息，U32类型
      "WriteTmout": 100,    // 写入寄存器的超时时间，单位ms
      "ReadTmout": 100,     // 读取寄存器的超时时间，单位ms
      "HealthStatus":0,     // 器件健康状态，U8类型
      "WriteRetryTimes": 2, //描述写入寄存器的重试次数
      "ReadRetryTimes": 0,  //描述读取寄存器的重试次数
      "DrvWriteDelay": "<=/RiserCard_1.MCUVersion |> string.sub($1, 1, 4) |> expr($1 >= '1.12' ? 0 : 1)"  //Riser Mcu需要在内核驱动写数据后进行延时，防止出现升级错误帧失败问题，单位ms
    }
  1. Pca9545是I2c多路复用器，用于扩展总线的通道，能够扩展4通道，每个通道可以连接不同的从设备。通过写入内部寄存器的特定位，可以启用其中一个通道，同时只能启用一个通道；
  2. Pca9545可以认为是从Chip中独立出来的对象，属性含义同Chip对象，一般只需要根据原理图修改Address的配置，其余属性均可和示例保持一致；
  3. 在CSR中，需要配置9545和后级通道，9545对应的CSR中对象为Pca9545，后级通道使用I2cMux定义；
  4. Pca9545的后级通道I2cMux需要配置通道号，配置建议是0-3，1-4是错误的。

1. 9545配置举例

json
"Pca9545_PCA9545": {
      "OffsetWidth": 0,     //偏移宽度
      "AddrWidth": 1,       //位宽
      "Address": 226,       //描述器件在总线的地址信息，U32类型
      "WriteTmout": 100,    //写入寄存器的超时时间，单位ms
      "ReadTmout": 100,     //读取寄存器的超时时间，单位ms
      "HealthStatus": 0     //器件健康状态，默认配置成0，由软件自动更新
    }

注意：

  • 地址根据原理图设计修改
  • 9545需要在拓扑中配置上级总线
json
"Hisport_0": {
      "Chips": [
        "Pca9545_PCA9545"
      ]
    }

2. 9545通道配置举例

9545拓展通道为：I2cMux

首先需要在拓扑中配置，配置方法如下：

json
"Pca9545_PCA9545": {
      "Buses": [
        "I2cMux_Pca9545_PCA9545_4",
        "I2cMux_Pca9545_PCA9545_1"
      ]
    }

其次需要在Object中定义9545下挂Bus的通道id

json
"I2cMux_Pca9545_PCA9545_4": {
      "ChannelId": 3
    },
"I2cMux_Pca9545_PCA9545_1": {
      "ChannelId": 0
    }
  1. Pca9555是用来提供I2C/SMBus来扩展访问GPIO的，可实现16Bit GPIO的扩展访问。
  2. Pca9555可以认为是从Chip中独立出来的对象，属性含义同Chip对象，一般只需要根据原理图修改Address的配置，其余属性均可和示例保持一致；

1. 9555配置举例

json
"Pca9555_IO": {
      "OffsetWidth": 1,     //偏移宽度
      "AddrWidth": 1,       //位宽
      "Address": 64,        //描述器件在总线的地址信息，U32类型
      "WriteTmout": 100,    //写入寄存器的超时时间，单位ms
      "ReadTmout": 100,     //读取寄存器的超时时间，单位ms
      "HealthStatus": 0     //器件健康状态，默认配置成0，由软件自动更新
    }

注意：

  • 地址根据原理图设计修改

  • 9555需要在拓扑中配置，是在bus下的chip

json
"I2cMux_Pca9545_PCA9545_4": {
      "Chips": [
        "Pca9555_IO"
      ]
    }

2. 9555读取配置说明

Accessor可以用来读取或写入9555的IO管脚（Accessor的具体说明见3.1.7节），Riser卡9555配合Accessor一般实现两种功能：

  • 读取单板PcbID
json
"Accessor_PcbID": {
      "Chip": "#/Pca9555_IO",
      "Offset": 1,
      "Size": 1,
      "Mask": 192,
      "Type": 0,
      "Value": 0
    }
  • 控制Eeprom写保护信号
json
"Accessor_IEUWP": {
      "Chip": "#/Pca9555_IO",
      "Size": 1,
      "Offset": 1,
      "Mask": 8,
      "Type": 0,
      "Value": 0
    }

注意：

Chip：引用对象，固定语法格式

Offset：9555的IO0管脚配置为0、IO1管脚配置为1

Size：数据大小，固定配置为1

Mask：根据需要读写的管脚进行配置，例如读写IO1_6和IO1_7，Mask配置为192（对应二进制：11000000）

  1. LM75是一款集成了温度传感器、数模转换器和过温检测功能的芯片，支持I2C通信；
  2. Lm75可以认为是从Chip中独立出来的对象，属性含义同Chip对象，一般仅需要配置Address属性，其余属性可和示例一致。

1. 配置说明

json
"Lm75_RISER": {
      "OffsetWidth": 1,     //偏移宽度
      "AddrWidth": 1,       //位宽
      "Address": 144,       //描述器件在总线的地址信息，U32类型
      "WriteTmout": 0,      //写入寄存器的超时时间，单位ms
      "ReadTmout": 0,       //读取寄存器的超时时间，单位ms
      "HealthStatus": 0     //器件健康状态，默认配置成0，由软件自动更新
    }

注意：Lm75需要在拓扑中配置

json
"I2cMux_Pca9545_PCA9545_4": {
      "Chips": [
        "Lm75_RISER"
      ]
    }

2. 温感读取配置

通过配置Scanner来实现BMC对Riser温感温度的监控，Scanner的具体说明见3.1.8节。

json
"Scanner_Lm75_RISER": {
      "Chip": "#/Lm75_RISER",
      "Size": 1,
      "Offset": 0,
      "Mask": 255,
      "Type": 0,
      "Period": 1000,
      "Debounce": "#/MidAvg_Riser"
    }

​ 天池架构规范规定每个组件上必须存在一个在I2C总线上地址为0xAE的存储器件，当前均为Eeprom器件，用于保存硬件自描述信息，包含头部、电子标签、组件自描述信息（CSR）以及扩展信息等；

​ Eeprom的配置可和示例保持一致

1. IEU配置举例

json
"Eeprom_IEU": {
  "OffsetWidth": 2,         // 偏移宽度，单位byte
  "AddrWidth": 1,           // EEPROM的I2C地址位宽，单位byte
  "Address": 174,           // EEPROM的I2C地址，0xAE即10进制的174
  "WriteTmout": 100,        // 写超时，单位ms
  "ReadTmout": 100,         // 读超时，单位ms
  "RwBlockSize": 32,        // 分页读写Eeprom的数据大小，单位Byte，U16类型，最大允许取值1024，默认值32
  "WriteInterval": 20,      // 分页写延时间隔，单位ms，最大允许取值500
  "HealthStatus": 0         // 器件健康状态，默认配置为0，由软件更新
}

注意：Eeprom对象需要有上层总线

json
"Hisport_0": {
      "Chips": [
        "Eeprom_IEU"
      ]
    }

3.2 硬件资源获取 ​

​ CSR中承载了所描述硬件对象(单板)的关键硬件资源，包括软件可获取的电压、温度、告警等传感器信息，和软件可以操作的比如复位、清除告警等能力。对于IEU组件，由于当前MCU并未支持SMC命令字，因此本章节所描述的Scanner、Accessor和其余单板从SMC获取数据不同，而是从硬件的实体器件去获取，例如温感、9555。

3.2.1 Accessor ​

  1. Accessor也可以理解为硬件传感器，与Scanner不同，Accessor适用于不需要随时读硬件寄存器的场景；
  2. Accessor对象是BMC可以写入的传感器，BMC能够往Accessor配置的寄存器写入数据；
  3. Accessor读的时候不会去轮询寄存器，而是通过感知寄存器值的变动来更新Value。

1. 属性说明

属性名类型描述
Chipro关联的Chip
StatusU8Accessor状态 0: 正常获取值 1: 获取值失败 2: 获取值预失败，正在进行防抖 3: 处于无效状态 4: 初始状态，暂未开始扫描，无需配置
ValueU64读值
SizeU8读数据长度
OffsetU32偏移
TypeU8读类型 0：位读/位写 1：块读/块写和SMC命令字相关
MaskU32位读时有效，从硬件读取数据后与掩码进行按位与操作
FailureDebounceCountU8Accessor扫描获取失败时Status的防抖次数，失败超过防抖次数时将Status置为1
SuccessDebounceCountU8Accessor扫描获取失败时Status的防抖次数，失败状态下成功次数超过防抖次数时将Status置为0

2. IEU配置举例

在IEU中，Accessor可以用来读取或写入9555的IO管脚，Riser卡9555配合Accessor一般实现两种功能：

  • 读取单板PcbID
json
"Accessor_PcbID": {
      "Chip": "#/Pca9555_IO",       //关联的Chip
      "Offset": 1,                  //偏移
      "Size": 1,                    //读数据长度
      "Mask": 192,                  //位读时有效，从硬件读取数据后与掩码进行按位与操作
      "Type": 0,                    //读类型 0：位读/位写  1：块读/块写和SMC命令字相关
      "Value": 0                    //读值
    }
  • 控制Eeprom写保护信号
json
"Accessor_IEUWP": {
      "Chip": "#/Pca9555_IO",       //关联的Chip
      "Size": 1,                    //偏移
      "Offset": 1,                  //读数据长度
      "Mask": 8,                    //位读时有效，从硬件读取数据后与掩码进行按位与操作
      "Type": 0,                    //读类型 0：位读/位写  1：块读/块写和SMC命令字相关
      "Value": 0                    //读值
    }

注意：

Chip：引用对象，固定语法格式

Offset：9555的IO0管脚配置为0、IO1管脚配置为1

Size：数据大小，固定配置为1

Mask：根据需要读写的管脚进行配置，例如读写IO1_6和IO1_7，Mask配置为192（对应二进制：11000000）

3.2.2 Scanner ​

  1. 硬件SR文件中包含硬件对象的描述，其中scanner可以理解为硬件传感器，用于BMC软件扫描对应的传感器，获取硬件状态信息。在天池组件设计规范中，为了更好的做到软硬件解耦，组件上的传感器都是由硬件获取，并且通过SMC标准命令字上报给BMC，所以scanner对象可以简单理解为BMC通过SMC读取的硬件信息。
  2. 硬件代理对所有配置的Scanner，按照Period指定的周期进行扫描，并将值更新到资源树。

1. 属性说明

属性名类型描述
Chipro关联的Chip
ScanEnabledU8Scanner扫描使能状态 0：未使能 1：使能，不配置默认为1
StatusU8Scanner状态 0: 正常获取值 1: 获取值失败 2: 获取值预失败,正在进行防抖 3: 处于无效状态，未使能 4: 初始状态, 暂未开始扫描，无需配置
ValueU64读值
NominalValueU64扫描无效（初次扫描，扫描失败，禁用扫描）之后的默认值， 注意此值不能产生告警
SizeU8读数据长度
OffsetU32偏移
PeriodU32扫描周期 单位ms，最小配置值100， 小于100按100处理
TypeU8读类型 0：位读 1：块读
MaskU32位读时有效，从硬件读取数据后与掩码进行按位与操作
Debouncero防抖对象
FailureDebounceCountU8Scanner扫描获取失败时Status的防抖次数，失败超过防抖次数时将Status置为1
SuccessDebounceCountU8Scanner扫描获取失败时Status的防抖次数，失败状态下成功次数超过防抖次数时将Status置为0
AggregateStatusBooleanScanner是否从汇聚数据中读取到, 由hwproxy动态设置结果
AggregateOffsetU32Scanner在汇聚数据中的相对偏移

2. Scanner的配置说明

  • 对于Chip、Type、Mask、Offset、Size取值均一样的两个Scanner配置，表征的是同一硬件扫描对象，必然存在对象重复配置或属性值配置错误的情况；
  • 存在SmcDfxInfo对象生效并且关联到Scanner对象时，AggregateStatus会被程序设置为true，并且按照Scanner的Period指定的周期更新Status和Value取值
  • Debounce防抖对象的DefaultValue取值需要和Scanner的NominalValue取值一致，避免出现默认取值导致误告警等问题；
  • 对于预期使用Value=1来判断读取失败依据的，这里确认失败的时间并非为FailureDebounceCount*Period。硬件代理为降低连续读取失败的花销，对周期做如下调整：
    • 扫描间隔小于1000ms时,每次失败增加100ms间隔, 否则间隔时间 * 2
    • 间隔时间最长不超过60s

3. IEU配置举例

json
"Scanner_Lm75_RISER": {
      "Chip": "#/Lm75_RISER",       // 数据来源对象
      "Size": 1,                    // 数据的字节长度
      "Offset": 0,                  // 偏移
      "Mask": 255,                  // 数据的掩码
      "Type": 0,                    // 数据获取的方式，其中0是位操作，1是块操作
      "Period": 1000,               // 扫描周期，单位为ms
      "Debounce": "#/MidAvg_Riser"  //防抖对象
    }

说明：从器件（Lm75_RISER）的偏移（Offset）为0的地址去读一个长度（Size）为1个字节的数据，周期（Period）为1000ms。

3.3 信号处理策略 ​

读取物理寄存器数据时，不可避免会遇到因器件抖动而产生误报等现象，需要采取一些防抖措施来过滤误报场景。 ​在通过硬件代理Scanner对象读取硬件数据的时候，可以通过debounce属性配置防抖对象，目前支持的防抖类型有中值滤波，均值防抖，持续一致，二值持续一致，无防抖等类型，不同防抖类型的说明如下：

BMC推荐的CSR硬件监控防抖机制详见：官方链接

在通过硬件代理Scanner对象读取硬件数据的时候，可以通过Debounce属性配置防抖对象，目前支持的防抖类型有中值滤波，均值防抖，持续一致，二值持续一致，无防抖等类型。

防抖策略在SR配置中非常重要，大量的误告警、FIT告警等问题，都与SR中配置的告警防抖策略息息相关。

CSR文件中定义的Debounce对象必须至少被一个Scanner对象引用

对IEU而言，主要有以下数据需要配置防抖：

1、均值滤波：IEU板温

目前支持的防抖类型有中值滤波，均值防抖，持续一致，二值持续一致，无防抖等类型，不同防抖类型的说明如下：

  • 中值滤波 ​

Median代表中值滤波防抖策略

json
"Median": {
    "WindowSize": 6,        //WindowSize代表窗口大小，可以理解为数组长度
    "DefaultValue": 11      //DefaultValue为默认值
}

  • 持续一致 ​

Cont代表持续一致防抖策略，当持续多次读到同一值时认为信号稳定，则属性取值更新为当前读值

json
"Cont": {
    "Num": 6,           //Num代表防抖次数，即连续出现多少次同样读值时，认为数据有效
    "DefaultValue": 11  //DefaultValue为默认值
}

  • 二值持续一致 ​

ContBin代表二值持续一致防抖策略

json
"ContBin": {
    "NumH": 6,          //NumH代表高电平防抖次数，即出现多少次读值为1认为有效
    "NumL": 6,          //NumL低电平防抖次数，即出现多少次读值为0认为有效
    "DefaultValue": 1   //DefaultValue为默认值
}

  • 均值平均 ​

MidAvg代表均值防抖策略，读值为去除最大、最小值后的平均值

json
"MidAvg": {
    "WindowSize": 6,       //WindowSize代表窗口大小
    "DefaultValue": 11,    //DefaultValue为默认值
    "IsSigned": true         // 是否为有符号数，对获取温度进行滤波时需填true
}

3.4 组件管理 ​

3.4.1 升级管理 ​

SRUpgrade是用于实现CSR固件升级的对象，主要包括：

  • 单板UID
  • 板卡类型
  • CSR data版本
  • 关联的对象
  • 软件ID
  • 关联的EEPROM写保护事件

配置举例：

json
"SRUpgrade_1": {
      "UID": "00000001040302052854",    //单板的UID
      "Type": "IEU",                    //单板类型，IEU
      "Version": "${DataVersion}",      //CSR版本号，引用DataVersion字段（每个CSR开头定义）
      "StorageChip": "#/Eeprom_IEU",    //CSR的存储Chip，关联Eeprom对象
      "SoftwareId": "XXX-YYYY",         //编码信息，格式为固件类型+单板名称
      "WriteProtect": "#/Accessor_IEUWP.Value"  //写保护，关联控制写保护信号的Accessor
    }

MCUFirmwa是用于MCU的升级对象，通过CSR将配置下发到固件并保存，后续即可支持对应MCU固件的带外升级。

配置举例：

json
"MCUFirmware_1": {
  "UID": "000000010402580311",   //单板UID
  "RefChip": "#/Chip_MCU1",      //升级关联的Chip
  "LockChip": "#/Chip_MCU1",     //并行升级会使用，调用总线锁，关联MCU对象
  "Address": 200,                //MCU地址
  "SoftwareId": "MCU-YYYY", //升级使用的协议，SMC或SMBus，默认使用SMBus，Riser的MCU升级都是SMBus协议，不需要配置该属性
  "BoardType": "IEU"             //板卡类型：IEU
}

3.4.2 告警管理 ​

Event也叫做精细化告警，主要包括了sensor和BMC其他精细化告警，硬件sr里主要包括以下内容：

1、电源类事件/告警（过压欠压类：ADC电压、VRD电压、RTC电压；获取失败类：ADC电压、VRD电压、缓启功耗）

2、高速链路类事件/告警（HCCS）

3、器件类事件/告警（CSR访问、MCU自检、FRU标签获取情况）

4、时钟类事件/告警（100M、156.25M、32K）

5、温度类事件/告警（获取失败类：光模块温度、CPU核温、内存温度、板温；过温：VRD温度、缓启MOS温度、光模块温度、；）

6、系统类事件/告警

1. 属性说明

(不配置则使用数据类型的默认值，所以按需配置即可)

属性描述
对象名Event_xxxEvent是固定值，看做是Class，所有Event类都会分发到事件模块处理
xxx是名称，无功能意义，单个文件不重复即可，完整名称自发现会根据SR文件拼接，比如拼接成Event_xxx_0101
EventKeyId(必配)事件标识，用于匹配事件静态配置，例如告警描述等信息， 要在BMC内部定义，才能产生告警，见第三小节的列表
Reading(必配)告警读数，普通的事件比如温度可以直接拿来当做读数，其他类型的比如证书过期，可以是0和1来代替
最终是结合运算符、门限判断是否符合告警条件，所以根据业务场景配置即可
Condition(必配)告警门限值
OperatorId判断符号 1：小于 2：小于等于 3：大于 4：大于等于 5：等于 6：不等于 7：上升沿0->1产生，1->0恢复 8：下降沿1->0产生，0->1恢复
注：上升沿下降沿时，值只有0/1/255，其中255表示无效值不会处理，且不要出现小数
Hysteresis迟滞量 在恢复告警时使用,产生告警时不会使用，迟滞量支持负数，所以根据正负数表征正向/负向迟滞量
Enabled事件使能状态，或者称为屏蔽状态，被屏蔽后不再会进行读值检测
DescArgx/SuggArgx(选配) 事件的描述/建议参数，用于格式化参数，即替换描述模板中的%1、%2等占位符，如DescArg1替换描述中的%1
仅支持字符串格式，最多10个
注：如果对于浮点数期望显示为3位小数，则需要通过SR表达式format进行转换
Component关联的Component对象，正常情况下Component部件需要与事件码高位匹配，用于显示告警主体
例如：查询环境有无对应的Component Type等于事件码高位例如0x02xxxxxx则需要查找Type为2的部件
AdditionalInfo(选配)事件的附加信息，即第X个动态参数，也可以是‘1,2’指向多个,用于FD上报时区分不同事件
比如完全相同的告警仅槽位不同，一般用槽位做区分，新增的告警需要特别注意是否需要配置
LedFaultCode(选配) Led错误码，可以是固定值也可以是动态值x$ (取Component中的Instance填充$部分)
InvalidReadingIgnore(选配)是否忽略无效值,1:开启 0 : 关闭，开启后读值如果等于InvalidReading则忽略
InvalidReading(选配) 需要忽略的无效值

2. 告警产生逻辑

根据OperatorId的判断方式，将Reading的值和Condition做比较，判断为真产生告警。即:

是否产生: Reading OperatorId Condition

是否恢复: (Reading + Hysteresis) OperatorId Condition

例如OperatorId为5时，则会判断 Reading == Contion 是否成立

3. EventKeyId列表

社区版本定义迁移到vpd中，详细参考社区告警文档

4. 业务简图

5. IEU配置举例

json
MCU通信异常告警
"Event_McuCommunicationcheck": {
      "EventKeyId": "Riser.PCIeRiserMcuCommunicationAbnormal",  //EventKeyid，对应BMC不同的告警码
      "Reading": "<=/RiserCard_1.CpldStatus",   // 数据来源（包含数据计算）
      "Condition": 1,                           // 告警门限值
      "OperatorId": 5,                          // 告警产生条件，该项和告警门限值搭配使用,5表示数据来源传来的值等于Condition的值的时候触发告警
      "DescArg2": "<=/RiserCard_1.Slot",        //告警描述，可以写死，也可以同步
      "Component": "#/Component_RiserCard"      // 关联的Component对象
    },
Riser卡更换记录事件
    "Event_RiserCardReplaceMntr": {
      "EventKeyId": "Riser.RiserCardReplace",
      "Reading": "<=/Component_RiserCard.ReplaceFlag",
      "Condition": 1,
      "OperatorId": 5,
      "Enabled": true,
      "DescArg1": "#/Component_RiserCard.Instance",
      "DescArg2": "#/Component_RiserCard.PreviousSN",
      "DescArg3": "#/Component_RiserCard.SerialNumber",
      "Component" : "#/Component_RiserCard"
    }

Component类表示部件管理信息，如内存、硬盘、风扇等，一个fru里可以有多个部件，配置告警也会配一个Component对象，供event管理。Components供WEB页面查询系统事件，根据部件类型进行筛选，需要从资源树获取当前存在的所有对象的部件类型。

Riser卡只涉及Riser卡对象Component_RiserCard

1. IEU配置举例

json
"Component_RiserCard": {
      "FruId": "<=/Fru_IEU.FruId",      // 关联Fru的Fruid，如果仅用于告警则配置255
      "Instance": "${Slot}",            // 组件设备Number，即器件在整个单板中的编号
      "Type": 15,                       //部件类型，Riser卡为15
      "Location": "<=/RiserCard_1.Position",
      "Name": "<=/RiserCard_1.DeviceName",  //部件名称，同一个position中需要保证唯一
      "Presence": 1,                    //部件在位状态
      "Health": 0,                      //关联告警时，如果告警则会根据告警严重程度进行更新
      "PowerState": 1,                  // 部件电源状态
      "GroupId": 1,                     //组件逻辑组Id
      "ReplaceFlag": 0,                 //单板更换标志位
      "PreviousSN" : "",                //上一个单板的SN，SN号变更时自动更新为上一次的SN号
      "SerialNumber": "<=/FruData_IEU.BoardSerialNumber", //组件序列号
      "UniqueId": "<=/RiserCard_1.UID", //单板的UID
      "PartNumber": "02580311",         //单板的0302
      "BoardId": "<=/RiserCard_1.BoardID"  //组件单板BoardId
    }

3.4.3 电子标签管理 ​

天池架构下，单板的电子标签也存放在CSR所在的Eeprom中，配置对应的Fru对象来进行管理。

FRU即现场可替换单元（field replacement unit ），在CSR中的FRU对象用于描述产品的身份信息，如制造厂商、产品型号、版本、资产标签等。一个fru只有一个Fru对象，Riser仅需配置一个Fru对象。

1. IEU配置举例

json
"Fru_IEU": {
      "PcbId": 1,           //Pcb版本
      "PcbVersion": ".A",   //PCB版本, 根据PcbId的值进行计算得出, PcbId为1时, 显示.A , 为2时显示.B, 依次类推
      "FruId": 1,           //单板的FruId，配置为1-63会根据自发现顺序自动分配fruid，默认可以配为1，fruid为0保留给挂耳，配置64-255不会进行fruid分配
      "FruName": "PCIe Riser${Slot}",   //Fru的名称
      "PowerState": 1,      //Fru关联的热插拔状态，如果不支持可以直接配成1，支持热插拔则需要关联对应的ChassisPayload的PowerState
      "Health": 0,          //未使用
      "EepStatus": 1,       //EEPROM状态, 当此属性关联到Accessor时, Frudata模块会启动任务进行EEPROM的监控，不管理可配置为1
      "Type": 195,          //FRU类型 BCU：36 EXU：50 IEU：195 MotherBoard：0 BMCcard：26
      "FruDataId": "#/FruData_IEU"   //关联FruData对象
    }

Frudata类描述的是Fru里面的eeprom存储的信息，一个fru最多有一个Frudata对象，当前扩展板仅需配置一个FruData对象。

1. IEU配置举例

json
"FruData_IEU": {
      "FruId": 1,       //单板的FruIdfruid配置为1-63会根据自发现顺序自动分配fruid，默认可以配为1fruid为0保留给挂耳，配置64-255不会进行fruid分配
      "FruDev": "#/Eeprom_IEU",             //引用Elabel存放的对象, 如果Fru没有电子标签信息可以为空.
      "EepromWp": "#/Accessor_IEUWP.Value", //关联控制Eeprom写保护的Accessor
      "StorageType": "TianChi"              //标准电子标签StorageType需要配为TianChi或者EepromV2、File非标电子标签StorageType可以配为MCU等，不做限制
    }

注意：电子标签的相关配置需要FruData、Fru、Accessor、Eeprom共同实现

以xx机型 IEU为例：

json
    "Fru_IEU": {
      "PcbId": 1,
      "PcbVersion": ".A",
      "FruId": 1,
      "FruName": "PCIe Riser${Slot}",
      "PowerState": 1,
      "Health": 0,
      "EepStatus": 1,
      "Type": 195,
      "FruDataId": "#/FruData_IEU"
    },
    "FruData_IEU": {
      "FruId": 1,
      "FruDev": "#/Eeprom_IEU",
      "EepromWp": "#/Accessor_IEUWP.Value",
      "StorageType": "TianChi"
    },
    "Accessor_IEUWP": {
      "Chip": "#/Pca9555_IO",
      "Size": 1,
      "Offset": 1,
      "Mask": 8,
      "Type": 0,
      "Value": 0
    },
    "Eeprom_IEU": {
      "OffsetWidth": 2,
      "AddrWidth": 1,
      "Address": 174,
      "WriteTmout": 100,
      "ReadTmout": 100,
      "RwBlockSize": 32,
      "WriteInterval": 20,
      "HealthStatus": 0
    }

3.4.4 设备管理 ​

IEU对接Pcie设备，需要描述上行和下行连接器信息，高速信号的带宽、速率等信息。

  • PcieAddrInfo ​

PcieAddrInfo是用来告知BIOS Pcie槽位和BDF信息的对应关系的对象。

Interface/Private属性/方法描述是否由CSR配置
bmc.kepler.Systems.PcieAddrInfoComponentType部件类型与Component类的中的部件类型属性对应，根据Riser卡对接的下级单板来决定（标准定义，如：8:PCIe标卡、13:NCI卡、71:SAS、83:OCP卡）是
PrivateLocationPCIe槽位所在的位置，单板类型+槽位号是
PrivateContainerUID【容器UID】是
PrivateContainerUnitType【容器单板类型】是
PrivateContainerSlot槽位信息，引用Slot属性是
PrivateGroupPosition对象主键，同一个CSR里配置命名不能重复是

1. IEU配置举例

json
"PcieAddrInfo_1": {
      "Location": "RiserCard${Slot}",      //PCIe槽位所在的位置，单板类型+槽位号
      "ComponentType": 8,                  //部件类型与Component类的中的部件类型属性对应，根据Riser卡对接的下级单板来决定（标准定义，如：8:PCIe标卡、13:NCI卡、71:SAS、83:OCP卡）
      "ContainerSlot": "${Slot}",          // 槽位信息，引用Slot属性
      "ContainerUID": "00000001040302052854",   //Riser的单板UID
      "ContainerUnitType": "IEU",               //单板类型
      "GroupPosition": "PcieAddrInfo_1_${GroupPosition}" //对象主键，同一个CSR里配置命名不能重复
    }

  • BusinessConnector ​

下行业务连接器，差异跟随基础板，描述了从CPU不同Serdes出的高速资源是如何分配到端口的

Interface/Private属性/方法描述是否由CSR配置
PrivateName连接器名称是
PrivateDirection表示上行连接器。Upstream表示上行连接器，上行连接器与前级单板的UBC/UBCDD口对应是
PrivateSlot上行连接器的Slot表示在当前组件里的槽位索引，业务拓扑建立后，下行连接器的Slot，用来确定全局槽位号是
PrivateLinkWidth链路带宽是
PrivateMaxLinkRate支持的最大速率是
PrivateConnectorType连接器类型是
PrivatePorts上行才需要端口配置Ports是
PrivateUpstreamResources下行端口才需要配置是
PrivateRefMgmtConnector下行连接器关联对应的管理连接器对象，后续加载对应卡的CSR是
PrivateRefPCIeAddrInfo下行连接器关联对应的槽位PCIeAddrInfo对象是

1.IEU配置举例

json
"BusinessConnector_1": {
    "Name": "Up_1",             //连接器名称
    "Direction": "Upstream",    //表示上行连接器。Upstream表示上行连接器，上行连接器与前级单板的UBC/UBCDD口对应。
    "Slot": 1,                  //上行连接器的Slot表示在当前组件里的槽位索引，业务拓扑建立后，下行连接器的Slot，用来确定全局槽位号
    "LinkWidth": "X16",         //链路带宽
    "MaxLinkRate": "PCIe 4.0",  //支持的最大速率
    "ConnectorType": "UBCDD",   //连接器类型
    "Ports": [                  //上行才需要端口配置Ports
        {
            "Name": "Down_1",   //上行连接器对应的下行连接器的名称
            "ID": 49,           //port id，和PSR中的UnitConfiguration对象匹配
            "Offset": 0,        //不同port配置不同的偏移
            "Width": 8         //端口的带宽
        },
        {
            "Name": "Down_2",
            "ID": 50,
            "Offset": 8,
            "Width": 8
        }
    ]
},
"BusinessConnector_2": {
    "Name": "Down_1",           //连接器名称
    "Direction": "Downstream",  //表示下行连接器。Upstream表示上行连接器，上行连接器与前级单板的UBC/UBCDD口对应。
    "Slot": 1,                  //下行连接器的Slot表示在当前组件里的槽位索引，业务拓扑建立后，下行连接器的Slot，用来确定全局槽位号
    "LinkWidth": "X8",          //链路带宽
    "MaxLinkRate": "PCIe 4.0",  //支持的最大速率
    "ConnectorType": "PCIe CEM",//连接器类型
    "UpstreamResources": [      //下行端口才需要配置
        {
            "Name": "Up_1",     //下行连接器对应的上行连接器的名称
            "ID": 255,          //不需要做匹配，默认配置为255
            "Offset": 0,        //下行连接器对应的上行连接器的资源的偏移，根据Offset字段匹配上行连接器的Port
            "Width": 8          //下行连接器对应的上行连接器的资源，pcie链路宽度
        }
    ],
    "RefMgmtConnector": "#/Connector_PCIe_1",   //下行连接器关联对应的管理连接器对象，后续加载对应卡的CSR
    "RefPCIeAddrInfo": "#/PcieAddrInfo_1"       //下行连接器关联对应的槽位PCIeAddrInfo对象
},
"BusinessConnector_3": {
    "Name": "Down_2",
    "Direction": "Downstream",
    "Slot": 2,
    "LinkWidth": "X8",
    "MaxLinkRate": "PCIe 4.0",
    "ConnectorType": "PCIe CEM",
    "UpstreamResources": [
        {
            "Name": "Up_1",
            "ID": 255,
            "Offset": 8,
            "Width": 8
        }
    ],
    "RefMgmtConnector": "#/Connector_PCIe_2",
    "RefPCIeAddrInfo": "#/PcieAddrInfo_2"
}

3.5 装备测试策略 ​

IEU的装备测试项一般用于整机ST环节使用。

Dft对象的type和id属性代表测试的类型和项目，需要按照下面的表格去配置对应的测试项，其余属性见第2节详细说明。

Interface/Private属性/方法描述是否由CSR配置
bmc.kepler.ManufactureType测试类型是
bmc.kepler.ManufactureId装备测试项是
bmc.kepler.ManufactureDeviceNum用来匹配唯一装备项是
bmc.kepler.ManufactureSlot用来匹配唯一装备项是
bmc.kepler.ManufactureItemName装备项名称是
bmc.kepler.ManufacturePrompteReady当前未使用是
bmc.kepler.ManufacturePrompteFinish当前未使用是
bmc.kepler.ManufactureProcessPeriod当前未使用是
PrivateInputChip检查bypass关联chip是
PrivateChannel检查InputChip关联chip的bypass，对应channel号是

1. dft type说明

测试类型 type测试类型
1直接自检，由APP提供检验结果
2需要人工干预的前提条件，比如需要接环回头、需要设置屏幕等，由各APP提供测试结果
3拷机测试项
4需要人工检查结果，比如LED灯需要人工查看是否正常，需要由装备人员确定检测结果
5需要人工操作，如button 、LCD
6需要与装备进行交互，需要装备侧软件比对数据来确定测试结果
255无效的测试项，不进行注册

2.dft id说明

TypeDftid测试项说明
11Lm75温度传感器
13PCA95559555
14PCA95459545
17Button_cell纽扣电池
18PowerSupply电源
19MEpmu状态
111Flashflash
112EEPROMEeprom
113DDR3ddr3
115CPLDcpld
117MEM_VOLT内存通道电压
11812V_VOLT12v电源电压
1195V_VOLT5v电源电压
1203V3_VOLT3v3电源电压
122TPMCARD安全卡在位
126HixxBmc芯片
128nand_flashbmc flash
133I2cc
134Lpclpc
135IpmbIpmb
147EEPROMWPEeprom写保护
265KEYBOARD键盘
266CD光驱测试
267Fp软驱测试
268Vce图像检测
269JTAGJtag
270SPISpi
273NCSINsci线缆检测
274Ethernet Port网口链路
284HwChannel低速信号测试
289IOio测试
294Usbusb测试
398VDDQ内存电压拉偏
399VDDNio 电压拉偏
3100AVScpu核心电压拉偏
4129LEDLed灯测试
4130LedTube数码管测试
4132LedIntelligenceLed防呆测试
4133LedTubelligence数码管防呆测试
5162UidButtonUid按钮
5163PowerButton电源按钮
5195ChassisCover机箱开箱检测

3. IEU相关配置

Riser涉及到的Dft测试项如下：

json
1.CSR版本测试
"DftVersion_RiserCardCsrVersion": {
      "FruId": "<=/Fru_IEU.FruId",
      "VersionType": 25,           //CSR版本校验类型25
      "Version": "<=/RiserCard_1.SRVersion"
},
2.Pcb版本测试
"DftVersion_RiserCardPcbVersion": {
      "FruId": "<=/Fru_IEU.FruId",
      "VersionType": 0,           //PCB版本校验类型0
      "Version": "<=/RiserCard_1.PcbVersion"
},
3.Mcu版本测试
"DftVersion_RiserCardMcuVersion": {
      "FruId": "<=/Fru_IEU.FruId",
      "VersionType": 27,          //MCU版本校验类型27
      "Version": "<=/RiserCard_1.MCUVersion"
},
4.Eeprom读写测试
"DftEeprom_1": {
      "Id": 12,
      "Type": 1,
      "Slot": "${GroupId}",             //测试项槽位信息
      "DeviceNum": 0,                   //测试项序列号
      "ItemName": "Eeprom Self Test",   //测试项名字
      "PrompteReady": "",               // 测试前提示，字符串类型
      "PrompteFinish": "",              // 测试完成提示，字符串类型
      "ProcessPeriod": 65535,           // 测试时长
      "FruData": "#/FruData_IEU"        //关联测试的FruData对象
},
5.Eeprom写保护信号测试1
"DftEepromWp_1": {
      "Id": 47,
      "Type": 1,
      "Slot": "${GroupId}",
      "DeviceNum": 0,
      "ItemName": "Eeprom Write Protect Self Test",
      "PrompteReady": "",
      "PrompteFinish": "",
      "ProcessPeriod": 65535,
      "FruData": "#/FruData_IEU"
},
6.I2c信号测试
"DftI2c_1": {
      "Type": 1,
      "Id": 33,
      "Slot": "${GroupId}",
      "DeviceNum": 0,
      "ItemName": "PCA9545",
      "PrompteReady": "",
      "PrompteFinish": "",
      "ProcessPeriod": 65535,
      "RefChip": "#/Pca9545_PCA9545"   //只支持关联9555与9545器件
},
7.9545器件测试
"DftPca9545_1": {
      "Type": 1,
      "Id": 4,
      "Slot": "${GroupId}",
      "DeviceNum": 0,
      "ItemName": "PCA9545",
      "PrompteReady": "",
      "PrompteFinish": "",
      "ProcessPeriod": 65535,
      "RefChip": "#/Pca9545_PCA9545"
},
8.9555器件测试
"DftPca9555_1": {
      "Type": 1,
      "Id": 3,
      "DeviceNum": 0,
      "ItemName": "PCA9555 For IEU",
      "PrompteReady": "",
      "PrompteFinish": "",
      "ProcessPeriod": 65535,
      "RefChip": "#/Pca9555_IO"
}

3.6 线缆检测 ​

背景

Riser的线缆检测码流由MCU发送，所有Riser的MCU软件版本归一，线缆检测码流数据存储在CSR中，MCU读取解析后发送。

文件命名与路径

线缆检测文件同sr文件在同一个目录下，命名格式为单板板名_IUA.ini

存储格式

Riser拓扑检测数据存储于Fru EEPROM的Inter Use Area 域，长度固定未128字节，与CSR一起合并打包。

相关字段定义

字段描述
Version数据结构版本，当前默认值填03
FreqDet码流频率校准字段，固定为0xff
index组件索引，CSR配置为0，仅起占位作用，实际由基础板逻辑改写
UID组件UID，共24字节，不够24字节的末尾补0x00
PortNumMCU发送的端口数量；实际上不使用，填0x08; 8个端口均发数据
PortData每端口发送数据个数，固定为0x08，将所有的portdata 都发送
CpType组件类型
0x00 传统3bit CP_Type方案
0x01 SAS背板
0x02 NVMe背板
0x03 OCP卡
0x04 NIC卡
0x05 HCCS设备
0x06 Riser 卡
RSV预留数据
px_dx线缆数据
CRC8CRC8校验结果

配置举例

json
Version=0x03                //数据结构版本，当前默认值填03
FreqDet=0xff                //码流频率校准字段，固定为0xff
uid=00000001040302052854    //单板UID
PortNum=8                   //MCU发送的端口数量；实际上不使用，填0x08; 8个端口均发数据
PortData=8                  //每端口发送数据个数，固定为0x08，将所有的portdata 都发送
Cp_Type=0x06                //组件类型
Resv=0xff,0xff,0xff,0xff,0xff    //预留数据，默认填0xff
Port0=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00   //线缆数据
Port1=0x11,0x01,0x01,0x05,0x00,0x00,0x00,0x00
Port2=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
Port3=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
Port4=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
Port5=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
Port6=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
Port7=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

其中线缆端口数据 Port0 对应从MCU PA0 管脚输出的数据， Port1 对应从MCU的PA1管脚输出的数据，以此类推。

3.7 热插拔管理 ​

背景

OCP卡通知式热插拔能力依赖扩展板或者Riser卡能力

各字段定义

属性名称签名默认值操作权限说明持久化发送变化通知备注
SlotIdy不涉及只读。R: ReadOnly。槽位号，在csr中配置否否
SupportedComponentTypesay不涉及只读。R: ReadOnly槽位支持的组件类型，在csr中配置，元素取值范围与资源协作接口bmc.kepler.Systems.Component的Type属性一致否否
PowerStatestring空字符串只读。R: ReadOnly槽位供电状态，Off：不供电 On：供电否是
ReadyToRemoveU80只读。R: ReadOnly关联PCIe卡下电寄存器，写1后对PCIe卡进行下电否否

配置举例

json
"PCIeSlot_OCP_1": {
  "SlotId": "<=/PcieAddrInfo_OCP_1.SlotID",
  "SupportedComponentTypes": [83],
  "PowerState": "<=/Scanner_aux_power_state.Value |> expr($1 == 0 ? 'Off' : 'On')",
  "ReadyToRemove" : "#/Accessor_ready_to_remove.Value"
}
上一篇EXU配置指导
下一篇PSR配置指导