一个完整的SR文件，包含硬件的版本描述信息、硬件的管理拓扑信息、硬件的传感器和状态信息、告警和时间信息、装备测试信息。
SR数据为json格式，完整的SR数据结构包含4部分数据：FormatVersion、DataVersion、ManagementTopology和Objects。
{
"FormatVersion": "3.00", // CSR协议版本号
"DataVersion": "3.17", // CSR数据版本号
"Unit": {
"Type": "EXU",
"Name": "ExpBoard_1"
},
"ManagementTopology": { // 用于描述本组件内的管理拓扑，主要包含Anchor、Bus、Chip、Connector的层级关系
"Anchor": {
"Buses": [
"I2c_1"
]
},
"I2c_1": {
},
},
"Objects": { // 用于配置本组件内部需要描述的业务对象，例如Accessor、Event、Scanner等，各Objects的定义可见CSR字典
}
}1 CSR的版本描述信息
FormatVersion和DataVersion为CSR代次版本号和固件版本号组成:
· FormatVersion：定义了SR数据格式及整体结构，版本号范围1~99，不足两位补0
· DataVersion：跟随SR数据内容变化而变化，为两段式结构，次版本号范围0~99，不足两位补0。修改SR内实际数据时需要进行版本号更迭。版本号规则为高位大版本号，低位小版本号；
Unit：3.00格式的需要定义，定义当前SR描述的组件类型“Type”和单板名称“Name”，组件类型包括基础板BCU、扩展板EXU、硬盘背板SEU、风扇板SLU等，按照天池架构规范定义；单板名称需要与后续单板描述信息的对象对应起来；
以xx机型扩展板为例进行说明:
"FormatVersion": "3.00", // 3.00为CSR协议版本号，定义了SR数据格式及整体结构，格式为x.xx，范围1~99
"DataVersion": "3.17", // 3.17为CSR数据版本号，跟随SR数据内容变化而变化，格式为x.xx，高位为大版本号，低位为小版本号版本号，版本号范围0~99
"Unit": {
"Type": "EXU",
"Name": "ExpBoard_1"
}1.1 单板信息
2 硬件的管理拓扑信息
ManagementTopology：本组件/部件内的管理拓扑，主要包含Anchor、Buses、Chips、 Connectors的层级关系。 需要描述的EXU CSR器件、链路获取及管理层如下：
- EXU CSR器件： SMC、CPLD、Eeprom、Chip_UsbCc、Component、Connetor、FRU、FruData、Pca9545、I2cMux、UID灯、Lm75、UsbLocalIOMService、Entity实体；
- 链路获取： Accessor、Scanner、SmcDfxInfo；
- 管理层： 传感器管理、升级管理、告警管理、电源管理、能效管理、开箱检测管理、数码管点灯管理、NCSI能力管理、装备测试策略。
以xx机型扩展板为例进行说明，需要注意的是，扩展板由于直接对接BMC，故Anchor中的Buses需要和BMC的vpd仓root.sr中定义的Connector-Bus保持顺序及ID一致：
"ManagementTopology": {
"Anchor": {
"Buses": [
"I2c_1",
"I2c_2",
"I2c_3",
"I2c_4",
"I2c_5",
"I2c_6",
"I2c_7",
"I2c_8",
"I2c_11",
"Jtag_1",
"JtagOverLocalBus_1",
"Hisport_0",
"Hisport_1",
"Hisport_2",
"Hisport_3",
"Hisport_4",
"Hisport_5",
"Hisport_6",
"Hisport_7",
"Hisport_8",
"Hisport_9",
"Hisport_10",
"Hisport_11",
"Hisport_12",
"Hisport_13",
"Hisport_14",
"Hisport_15",
"Hisport_16",
"Hisport_17",
"Hisport_18",
"Hisport_19",
"Hisport_20",
"Hisport_21"
]
},
"I2c_8": {
"Chips": [
"Lm75_InletTemp",
"Chip_UsbCc_On",
"Chip_UsbCc_Sgm"
],
"Connectors": [
"Connector_PSR_EEP"
]
},
"I2c_1": {
"Chips": [
"Smc_CpuBrdSMC"
],
"Connectors": [
"Connector_BCU_1"
]
},
"I2c_5": {
"Connectors": [
"Connector_SEU_1"
]
},
"I2c_4": {
"Chips": [
"Smc_FanBoardSMC"
],
"Connectors": [
"Connector_CLU_1"
]
},
"I2c_7": {
"Chips": [
"Pca9545_i2c7_chip"
]
},
"I2c_2": {
"Chips": [
"Smc_ExpBoardSMC",
"Eeprom_EXU"
],
"Connectors": [
"Connector_PowerSupply_1",
"Connector_PowerSupply_2"
]
},
"I2c_3": {
"Chips": [
"Eeprom_PsuChip1",
"Eeprom_PsuChip2"
]
},
"Jtag_1": {
"Chips": [
"Cpld_1"
]
},
"I2c_11": {
"Chips": [
"Lm75_OutletTemp"
]
},
"I2c_6": {
"Chips": [
"Pca9545_i2c6_chip"
]
},
"Pca9545_i2c6_chip": {
"Buses": [
"I2cMux_Pca9545_i2c6_chip_3"
]
},
"I2cMux_Pca9545_i2c6_chip_3": {
"Connectors": [
"Connector_SEU_2"
]
},
"Pca9545_i2c7_chip": {
"Buses": [
"I2cMux_Pca9545_i2c7_chip_1",
"I2cMux_Pca9545_i2c7_chip_2"
]
},
"I2cMux_Pca9545_i2c7_chip_1": {
"Connectors": [
"Connector_LOM_1",
"Connector_OCP_1"
]
},
"I2cMux_Pca9545_i2c7_chip_2": {
"Connectors": [
"Connector_LOM_2",
"Connector_OCP_2"
]
}
}3 组件信息获取和管理
3.1 单板信息
3.1.1 扩展板信息
CSR是单板自描述信息，首先应当描述该单板的基础信息。以扩展板（ExpanderBoard）举例，需要明确以下对象及对应属性：
扩展板的基础单板信息：例如槽位号，唯一标识符（uid），板名，厂商信息，器件位号，板卡丝印信息，位置等；
扩展板的版本信息：例如CSR版本号，SMC版本号，逻辑版本号，这些信息均通过数值引用或者Accessor事件获取；
扩展板的状态信息：例如运行状态，CPLD自检状态等，由BMC动态刷新。
CSR常用语法：
1、对象引用：有两种在Object的字段中引用其他Object数据的方式，
#/称为引用，<=/称为同步，#/指的是当需要引用到这个属性的时候，转去访问这个符号指定的属性，一般与Accessor绑定使用，用于读写指定寄存器的值；<=/指的是监听原字段的值，当被同步的数值发生改变时，触发信号变更该属性的值。通常与Scanner绑定使用，用于周期性读取指定寄存器的值。2、数据引用：
${}称为数据引用，表示引用其他已定义的字段数值
"ExpBoard_1": {
"Slot": 1, // 槽位号，为上一层级Connector传下来的值，后续可以考虑使用${slot}替换，当前为BMC代码自动更新
"UID": "00000001010302044491", // 单板UID，vendor(00000001)+组件类型（01）+0302编码（0302057042）
"Name": "XXX", // 单板名称
"Manufacturer": "<=/FruData_Expander.BoardManufacturer", // 厂家信息，从EEPROM中的FRU中获取
"Type": "EXU", // 单板类型，EXU
"Description": "Expander Board", // 描述信息
"PartNumber": "0302044491", // 单板0302编码
"LogicVersion": "", // 逻辑版本号，通过Accessor_LogicVersionID换算得出
"LogicUnit": 5, // 逻辑位号(U位号)
"PcbID": "#/Accessor_PcbID.Value", // Pcb版本
"PcbVersion": "", // 单板的PCB版本,BMC从CPLD中获取单板的PCB版本
"LogicVersionID": "#/Accessor_LogicVersionID.Value",
"SRVersion": "${DataVersion}", // 数据引用，引用DateVersion字段
"CPLD2VersionID": "#/Accessor_LogicVersionID2.Value",// CPLD2的版本号
"MCUVersion": "", // 保留接口，供装备测试DFT使用
"BoardID": 65535,
"BoardType": "ExpBoard",
"Number": 1, // 根据整机配置更新逻辑编号，目前仅背板使用，使用SlotConfigs配置属性
"DeviceName": "ExpBoard${Slot}", // 板卡丝印信息，原则上采用大驼峰命名风格，不带下划线，提供给Redfish接口使用
"Position": "EXU${Slot}", // 位置信息，提供给Redfish接口使用
"NodeId": "EXU${Slot}ExpBoard${Slot}", // 资源id,这里由位置Position和设备丝印名称DeviceName拼接而成类似：@odata.id": "/redfish/v1/Chassis/1/Boards/EXU1ExpBoard1
"RunningStatus": 0,
"RefSMCChip": "#/Smc_ExpBoardSMC", // 关联的SMC对象
"FruID": "<=/Fru_Expander.FruId", // 类似主键,具有唯一性，用于装备通过ipmi读写电子标签信息
"CpldTestReg": "#/Accessor_CpldTest.Value", //CPLD自检标志位，通过Accessor事件传递
"CpldStatus": 0
}3.1.2 单板上的器件
单板上有很多关键器件和资源，需要先定义，再调用。
SMC
天池架构通过SMC标准命令字来承载通用的软硬件接口。**SMC（Satellite Management Controller）**作为卫星管理控制器，是单板与BMC管理中心通讯的唯一通用接口命令字，在每个组件上会设计一个控制器（在BMC抽象为一种Chip对象，实际可用CPLD或者MCU实现），通用地址设计为0x60，用于管理单板上的器件及功能，屏蔽单板差异，并且采用专有的SMC协议/命令字以和BMC进行交互。
需在EEPROM里配置SMC的所有硬件属性，以实现扩展板组件的自发现，以扩展板SMC-CPLD举例，需明确以下属性：
"Smc_ExpBoardSMC": {
"Address": 96, // 描述器件在总线的地址信息，U32类型
"AddrWidth": 1, // 地址宽度，单位Byte
"OffsetWidth": 1, // 地址偏移宽度，单位Byte
"WriteTmout": 0, // 写入寄存器的超时时间，单位ms
"ReadTmout": 0 // 读取寄存器的超时时间，单位ms
}同时，为了支持部分事件能力（如开箱检测等），需要配置CpuBoard的SMC属性（Smc_CpuBrdSMC），以便BMC能获取基础板的部分smc结果；为了能获取风扇板温度等信息，需要配置FanBoard的SMC属性（Smc_FanBoardSMC），配置方法参考上例。
CPLD
CPLD是complex programmable logic device，即复杂可编程逻辑器件。当前的扩展板设计使用了1颗或者多颗CPLD。在扩展板CSR中，只需定义Cpld_1对象供升级使用，无需定义具体属性值，该对象实际的调用方法由BMC内部定义和使用，CSR中仅需配置该对象存在与否，参考如下：
"Cpld_1": {}EEPROM
天池架构规范规定每个组件上必须存在一个在I2C总线上地址为0xAE的存储器件，当前均为Eeprom器件，用于保存硬件自描述信息，包含头部、电子标签、组件自描述信息（CSR）以及扩展信息等。天池规范定义了SR的存储载体的I2C地址固定为0xAE。我们需要在CSR中定义扩展板的CSR器件信息：
"Eeprom_EXU": {
"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，由软件更新
}同时，为支持BMC访问I2C3上的PSU Eeprom，也需要配置2个Psu E2p的地址，配置方法参考上例。
Chip_UsbCc
Chip_UsbCc_On表示挂耳上的TypeC的cc芯片器件，BMC可通过访问该器件地址定期扫描获取TypeC状态。当前需配置On和Sgm两个厂家。
需注意，ON和Sgm为多厂家，各自有对应的I2C地址，故在CSR中配置两个Chip，保证上件后的访问正常。
"Chip_UsbCc_On": {
"Address": 66, // 描述器件在总线的地址信息，U32类型
"OffsetWidth": 1, // 偏移宽度
"AddrWidth": 1, // 位宽
"WriteTmout": 0, // 写入寄存器的超时时间，单位ms
"ReadTmout": 0, // 读取寄存器的超时时间，单位ms
"HealthStatus": 0 // 器件健康状态，U8类型
}"Chip_UsbCc_Sgm": {
"Address": 142, // 描述器件在总线的地址信息，U32类型
"OffsetWidth": 1, // 偏移宽度
"AddrWidth": 1, // 位宽
"WriteTmout": 0, // 写入寄存器的超时时间，单位ms
"ReadTmout": 0, // 读取寄存器的超时时间，单位ms
"HealthStatus": 0 // 器件健康状态，U8类型
}Component
Component类表示部件管理信息，如内存、硬盘、风扇等，一个fru里可以有多个部件，配置告警也会配一个Component对象，供event管理。Components供WEB页面查询系统事件，根据部件类型进行筛选，需要从资源树获取当前存在的所有对象的部件类型。(按照CSR-DEG决策结论，这部分放到mgmt_model.sr里)
配置对象
以扩展板为例，当前需要配置的Component对象主要包括以下几种：
- 扩展板对象Component_ComEXU
- 扩展板对象Component_ComExpander：历史遗留原因，EXU和Expander对象均需配置。继承的告警不能随意改动关联了的Component，新增的告警优先关联Expander对象
- 按钮对象Component_Button
- 开箱系统对象Component_Chassis
- 线缆对象Component_Cable
- 电源对象Component_PowerSupply1和Component_PowerSupply2
配置举例
以扩展板对象为例，需要配置以下字段：
"Component_ComEXU": {
"FruId": 255, // 关联Fru的Fruid，如果仅用于告警则配置255
"Instance": 255, // 组件设备Number，即器件在整个单板中的编号
"Type": 193, // 部件类型，请参考IDP文档中的IPMI接口说明的设备类型附录
"Location": "chassis",
"Name": "EXU${Slot}", //部件名称，同一个position中需要保证唯一
"Presence": 1, //部件在位状态
"Health": 0, //关联告警时，如果告警则会根据告警严重程度进行更新
"PowerState": 1, // 部件电源状态
"GroupId": 1, // 组件逻辑组Id
"Manufacturer": "", // 组件厂商信息
"UniqueId": "N/A", // 组件唯一标识,Vendor + ComponentID
"BoardId": "<=/ExpBoard_1.BoardID" // 组件单板BoardId
}Connector
Connector为CSR文件中的一个属性字段，该属性字段记录了当前硬件所连接的下一级硬件的部分信息。板卡不同硬件之间通过Connector连接器两两相连，iBMC读取Connector所保存的属性信息，逐级发现不同硬件，最终构成整个硬件信息拓扑图。
配置对象
连接器可分为虚拟连接器和实体连接器两种，以扩展板为例，需要配置以下两种：
1.实体Connector对象：当前主要为单板连接器，包括基础板、前/后置背板、风扇板、挂耳板、灵活插卡、电源连接器。为解决单板耦合问题，此处的Bus建议把所有I2C按既定顺序包含。
2.虚拟Connertor对象：当前主要为OCP插卡的虚拟连接器
配置举例
- 实体连接器：当前以挂耳的E2P为例，需要明确以下属性：
json"Connector_PSR_EEP": { "Bom": "14100513", //表示下级组件的BOM ID，仅作为标识，定义在profile.yaml里 "Slot": 1, //槽位号，硬件传递 "Position": 10, //为保证SR定义对象名称全局唯一，需要对每个（SR）硬件组件中自描述对象进行重命名，重命名后的对象名称由SR定义的对象名+_${Position}后缀组成 "Presence": "<=/Scanner_RightEar.Value", //在位信息，只有为1时，才会加载下一级sr "Id": "", //表示下级组件Board id，天池标准组件的BoardId通过Chip属性关联的器件对象，调用对应的读写接口获取Eeprom数据中的Board Id信息。 "AuxId": "", //AuxId是副ID，和ID配合在一起加载SR用的，sr文件命名是bom_id_auxid，如果id不够用，就配置auxid "Buses": [ //本级连接器的总线 "I2c_8", "I2c_2" ], "SystemId": 1, //host的id，多host场景下会有多个配置，默认1； "ManagerId": "1", //BMC的id，多BMC场景下会有多个配置，默认1；目前只有单BMC场景 "ChassisId": "1", //机框id，多个机框有多个不同的id，默认1 "SilkText": "PSR", //丝印信息 "IdentifyMode": 3 //表示下级组件识别方式，3对应下级组件识别方式为天池标准类型组件，2对应下级组件识别方式为BoardId不可读（上报）类型组件，1对应下级组件识别方式为BoardId可读类型组件。 }- 虚拟连接器：以灵活插卡为例，需要明确以下属性：
json"Connector_OCP2_Vir": { "Bom": "14220247", //表示下级组件的BOM ID，仅作为标识，定义在profile.yaml里 "Slot": 1, //槽位号，硬件传递 "Position": 8, //为保证SR定义对象名称全局唯一，需要对每个（SR）硬件组件中自描述对象进行重命名，重命名后的对象名称由SR定义的对象名+_${Position}后缀组成 "Presence": "<=/Scanner_SerdesLom2Pres.Value;<=/Scanner_SerdesLom2CardType.Value |> expr(($1 == 1 && $2 == 1) ? 1 : 0)", "Id": "OCP", //表示下级组件Board id，天池标准组件的BoardId通过Chip属性关联的器件对象，调用对应的读写接口获取Eeprom数据中的 Board Id信息。 "AuxId": "2", //AuxId是副ID，和ID配合在一起加载SR用的，sr文件命名是bom_id_auxid，如果id不够用，就配置auxid "Buses": [ //本级连接器的总线 "I2c_2", "I2cMux_Pca9545_i2c7_chip_2" ], "SystemId": "${SystemId}", //host的id，多host场景下会有多个配置，默认1； "ManagerId": "${ManagerId}", //BMC的id，多BMC场景下会有多个配置，默认1；目前只有单BMC场景 "ChassisId": "${ChassisId}", //机框id，多个机框有多个不同的id，默认1 "SilkText": "xx", //丝印信息 "IdentifyMode": 2 //表示下级组件识别方式，3对应下级组件识别方式为天池标准类型组件，2对应下级组件识别方式为BoardId不可读（上报）类型组件，1对应下级组件识别方式为BoardId可读类型组件。 }FRU
Fru类描述的是现场可替换单元（fru）的相关信息，例如主板, Raid卡, Riser卡, 硬盘背板等，一个fru只有一个Fru对象，当前扩展板仅需配置一个Fru对象。
json"Fru_Expander": { "PcbId": "#/Accessor_PcbID.Value", //关联获取PcbID的Accessor "PcbVersion": ".A", //PCB版本，可以通过Accessor关联获取，会自动根据PcbId进行转换 "FruId": 1, //配置为1-63会自动分配fruid，默认可以配为1;为0保留给挂耳，配置64-255不会进行fruid分配 "FruName": "ExpBoard${Slot}", //Fru的名称，如CpuBoard "PowerState": 1, //Fru关联的热插拔状态，如果不支持可以直接配成1，支持热插拔则需要关联对应的ChassisPayload的PowerState "Health": 0, //未使用 "EepStatus": 1, //未使用 "ConnectorGroupId": "${GroupId}", //关联Connector传过来的GroupId "Type": 50, //Fru类型，请参考IDP文档中的IPMI接口说明的设备类型附录 "FruDataId": "#/FruData_Expander" //需要关联对应的Frudata对象 }FruData
Frudata类描述的是Fru里面的eeprom存储的信息，一个fru最多有一个Frudata对象，当前扩展板仅需配置一个FruData对象。
json"FruData_Expander": { "FruId": 1, //配置为1-63会自动分配fruid，默认可以配为1;为0保留给挂耳，配置64-255不会进行fruid分配 "FruDev": "#/Eeprom_EXU", "EepromWp": "#/Accessor_EXUWP.Value", "BoardSerialNumber": "", "StorageType": "TianChi" //存储格式，按照天池规范eeprom格式存储的标准电子标签，此时配为TianChi或者EepromV2、File }Pca9545
Pca954x是I2c多路复用器，用于扩展总线的通道。其中Pca9545/Pca9544是4路，Pca9548是8路（当前未实现）。将一个总线分成n个独立的通道，每个通道可以连接不同的从设备。通过写入内部寄存器的特定位，可以启用其中一个通道，同时只能启用一个通道。硬件设计中，在需要多个设备但总线数量有限的情况下，常用于增加从设备的数量。 Pca9545的Channel配置建议是0-3，不允许配置1-4。
配置对象
以当前扩展板为例，需要配置i2c6和i2c7上使用到的2个9545器件。
配置举例
json"Pca9545_i2c7_chip": { "OffsetWidth": 0, //偏移宽度 "AddrWidth": 1, //位宽 "Address": 224, //描述器件在总线的地址信息，U32类型 "WriteTmout": 0, //写入寄存器的超时时间，单位ms "ReadTmout": 0, //读取寄存器的超时时间，单位ms "HealthStatus": 0 //器件健康状态，U8类型 }I2cMux
I2cMux对象必须挂在Pca9544、Pca9545、Pca9548或Smc下，必须下挂在对应的Chip的总线Bus下，表示对应的通道。对于在Bus总线中定义的Pca9545对象，需要明确其对应的I2cMux通道对象，以供BMC识别。故定义时除了定义对应的Pca9545器件对象，还需要在bus总线中定义其对应的通道对象。
配置对象
以当前扩展板为例，需要明确i2c6和i2c7上两个9545器件，分别对应的通道对象和下挂器件。
配置举例
以i2c6为例：
json"Pca9545_i2c6_chip": { //对应的9545定义 "Buses": [ "I2cMux_Pca9545_i2c6_chip_3", "I2cMux_Pca9545_i2c6_chip_2" ] }, "I2cMux_Pca9545_i2c6_chip_2": { "Connectors": [ "Connector_PowerSupply_3" //对应通道的下挂器件或者连接器 ] }, "I2cMux_Pca9545_i2c6_chip_3": { "Connectors": [ "Connector_SEU_2" //对应通道的下挂器件或者连接器 ] }BMC会通过I2C_x的Chip对象加载对应的9545对象，再通过9545的Bus定义加载不同的通道I2CMux对象，再通过I2cMux_Pca9545_i2c6_chip_2对象加载下一层级的Connectors连接器，从而实现上下游的拓扑自发现。
UID灯
BMC通过Led类，把Led灯的信号抽象为一个对象。已扩展板为例，需要明确Uid灯（Led_UIDLed）和系统健康灯（Led_SysHealth）两个对象。
配置举例
以UID灯为例，需要明确其对应的以下属性：
json"Led_UIDLed": { "Id": 4, //HEALTH = 2, -- 健康灯 ID = 4 -- UID灯 "SystemId": 1, //预留属性，系统id "Name": "UIDLed", //led灯名称 "CtrlValue": "#/Accessor_UIDLedAccessor.Value", //设置uid灯光状态:ID_BLINK = 85,UID_ON = 144,UID_OFF = 0 "Capability": 1, //led灯颜色:[0] = "reserved",[1] = "BLUE",[2] = "RED",[3] = "GREEN",[4] = "AMBER",[5] = "ORANGE",[6] = "WHITE", "Mode": 0, //led模式，默认使用0:[0] = 'Local Control',[1] = 'Override',[2] = 'Lamp Test' "ColorCapabilities": 2, //Led灯支持的颜色能力 "DefaultOSColor": 1, //超驰控制颜色，输出实例按实际支持颜色配置 "DefaultLCSColor": 1, //默认本地控制颜色，输出实例按实际支持颜色配置 "LCSColor": 1, //获取当前颜色为本地控制颜色，输出实例按实际支持颜色配置 "LCSState": 0, //获取当前状态为本地控制状态，输出实例按实际支持颜色配置 "OSColor": 1, //获取当前颜色为超驰控制颜色，输出实例按实际支持颜色配置 "OSState": 0, //获取当前状态为超驰控制状态，输出实例按实际支持颜色配置 "LampTestColor": 1, //lamptest颜色，输出实例按实际支持颜色配置 "LampTestDuration": 0 //lamptest颜色持续时长，输出实例按实际支持颜色配置 }LED的功能，参考各机型对应的用户指南。
Lm75
LM75是一款集成了温度传感器、数模转换器和过温检测功能的芯片，支持I2C通信。一般仅需要配置Address属性。
配置对象
以扩展板为例，需要明确入风口温感（Lm75_InletTemp）和出风口温感（Lm75_OutletTemp）。
配置举例
json"Lm75_InletTemp": { "OffsetWidth": 1, // 偏移宽度 "AddrWidth": 1, // 位宽 "Address": 144, // 描述器件在总线的地址信息，U32类型 "WriteTmout": 0, // 写入寄存器的超时时间，单位ms "ReadTmout": 0, // 读取寄存器的超时时间，单位ms "HealthStatus": 0 // 器件健康状态，U8类型 }UsbLocalOMService
在扩展板上，BMC需要维护1个USB近端运维对象，以确认USB设备状态。当前需要明确以下属性：
配置举例
json"UsbLocalOMService_1": { "Supported": true, // 是否支持USB type-c功能 "Presence": "<=/Scanner_RightEar.Value", // 面板USB口是否在位 "Enabled": true, // USB typc-c功能使能状态 "RefCcChipOn": "#/Chip_UsbCc_On", // 引用的On厂商的CC chip "RefCcChipSgm": "#/Chip_UsbCc_Sgm", // 引用的Sgm厂商的CC chip "CcChipOnAttachStatus": "#/Scanner_CcChipOnAttachStatus.Value", // USB设备接入状态 "CcChipSgmAttachStatus": "#/Scanner_CcChipSgmAttachStatus.Value", // USB设备接入状态 "GLedStatus": "#/Accessor_USBGreenLed.Value", // 绿灯状态 "RLedStatus": "#/Accessor_USBRedLed.Value", // 红灯状态 "RndisHostIpAddr": "x.y.v.w", // usb0 口配置的ip(x、y、v、w均为非负整数)，软件内无默认值 "PortNum": 3 // 复合设备USB口，软件内无默认值 }Entity实体资源
传感器实体资源，表征当前的传感器依赖或者所属的硬件的实体描述，该实体的 在位状态 或者 上下电状态 会影响当前传感器的值以及状态，还有对应传感器事件 IPMI SEL 的生成状态。
配置对象
当前扩展板上需要定义以下几个实体对象：
入风口传感器实体（Entity_AirInlet）
当前单板实体（Entity_MainBoard）
配置举例
以当前单板对象为例，需要明确以下属性：
json"Entity_MainBoard": { "Id": 7, // 传感器对应的实体标识,具体参照IPMI规范 Table 43-, Entity ID Codes(P550) "Name": "MainBoard", // 实体名称 "PowerState": 1, // 实体上下电状态，若与上下电状态无关则配死为1，否则应 关联上下电信号 "Presence": 1, // 实体的在位状态，需要关联对应的在位信号来源 "Instance": 96 // 传感器对应的实体实例标识，保证同一Entity Id下唯一 }
3.2 硬件资源获取
3.2.1 Scanner
硬件SR文件中包含硬件对象的描述，其中scanner可以理解为硬件只读传感器，用于BMC软件扫描对应的传感器，获取硬件状态信息。
属性说明
| 属性名 | 类型 | 描述 |
|---|---|---|
| Chip | ro | 关联的Chip |
| ScanEnabled | U8 | Scanner扫描使能状态 0：未使能 1：使能，不配置默认为1 |
| Status | U8 | Scanner状态 0: 正常获取值 1: 获取值失败 2: 获取值预失败,正在进行防抖 3: 处于无效状态，未使能 4: 初始状态, 暂未开始扫描，无需配置 |
| Value | U64 | 读值 |
| NominalValue | U64 | 扫描无效（初次扫描，扫描失败，禁用扫描）之后的默认值， 注意此值不能产生告警 |
| Size | U8 | 读数据长度 |
| Offset | U32 | 偏移 |
| Period | U32 | 扫描周期 单位ms，最小配置值100， 小于100按100处理 |
| Type | U8 | 读类型 0：位读 1：块读 |
| Mask | U32 | 位读时有效，从硬件读取数据后与掩码进行按位与操作 |
| Debounce | ro | 防抖对象 |
| FailureDebounceCount | U8 | Scanner扫描获取失败时Status的防抖次数，失败超过防抖次数时将Status置为1 |
| SuccessDebounceCount | U8 | Scanner扫描获取失败时Status的防抖次数，失败状态下成功次数超过防抖次数时将Status置为0 |
| AggregateStatus | Boolean | Scanner是否从汇聚数据中读取到, 由hwproxy动态设置结果 |
| AggregateOffset | U32 | Scanner在汇聚数据中的相对偏移 |
配置对象
以扩展板为例，传感器主要包括：
系统信息的获取：灵活插卡的类型、单板在位状态（灵活插卡、风扇板、前置背板、后置背板、挂耳、PSU在位）、TypeC的CC芯片状态、主板在位告警、风扇线缆告警、风扇功率传感器状态、ADC传感器状态、Lm75健康状态
板级所有的电源传感器：PSU1/2输入状态、PSU1/2输出状态、PSU1/2的PG信号、风扇功率、整机电源故障标志位、电源按键事件、板级电源电压获取、EXU电源故障标志位等
UID按键的状态：UID短按事件、UID长按事件
板上所有的时钟传感器：100M时钟丢失、50M时钟丢失
板上所有温度传感器：进风口、出风口、灵活插卡温度、MOS过温状态获取、风扇板温度（风扇板Smc）
开箱事件扫描：上电开箱、下电开箱、开箱状态
配置举例
下面详细介绍对应的scanner下面的具体属性配置，一个标准的Scanner包含如下信息：
1、 传感器的获取方式（对应传感器的SMC命令字）
2、 软件读取传感器的扫描周期
3、 软件读取传感器的防抖策略（防抖策略为固定配置，不同的传感器防抖策略固定）
4、 软件对传感器进行扫描的条件（例如：电源传感器需要上电以后才开始扫描）
以100M时钟丢失状态scanner举例：
"Scanner_100M1ClockFailMntr": {
// 1、传感器的获取方式
"Chip": "#/Smc_ExpBoardSMC", // Smc对象
"Offset": 469770496, // Smc命令字的Opcode+Param
"Size": 1, // 数据的字节长度
"Type": 0, // 数据获取的方式，其中0是位操作，1是块操作
"Mask": 1, // 数据的掩码
// 2、 软件读取传感器的扫描周期
"Period": 400, // 扫描周期为400ms
// 3、 软件读取传感器的防抖策略
"Debounce": "#/ContBin_ExpBoardClockSignalLost", // 滤抖策略为ContBin，需要关联ContBin_ExpBoardClockSignalLost对象，具体滤抖参数需单独配置ContBin_ExpBoardClockSignalLost对象
// 4、 软件对传感器进行扫描的条件
"ScanEnabled": "<=/Scanner_PowerGd.Value", // 触发传感器扫描的条件，此处为powerGood信号
"NominalValue": 0,
"Value": 0,
"@Default": { // 为指定属性配置默认值
"ScanEnabled": 0
}
}3.2.2 Accessor
硬件SR文件中包含硬件对象的描述，其中Accessor适用于不需要循环周期性获取值或需要写入硬件值的场景，属性可读写，可以简单理解为BMC通过SMC写入的硬件信息。
属性说明
| 属性名 | 类型 | 描述 |
|---|---|---|
| Chip | ro | 关联的Chip |
| Status | U8 | Accessor状态 0: 正常获取值 1: 获取值失败 2: 获取值预失败，正在进行防抖 3: 处于无效状态 4: 初始状态，暂未开始扫描，无需配置 |
| Value | U64 | 读值 |
| Size | U8 | 读数据长度 |
| Offset | U32 | 偏移 |
| Type | U8 | 读类型 0：位读/位写 1：块读/块写和SMC命令字相关 |
| Mask | U32 | 位读时有效，从硬件读取数据后与掩码进行按位与操作 |
| FailureDebounceCount | U8 | Accessor扫描获取失败时Status的防抖次数，失败超过防抖次数时将Status置为1 |
| SuccessDebounceCount | U8 | Accessor扫描获取失败时Status的防抖次数，失败状态下成功次数超过防抖次数时将Status置为0 |
Accessor在BMC中的用法如下：
1、获取值时，hwproxy监听property_read信号，实时读取硬件的值并更新到资源树；
2、当写入值时，hwproxy监听property_before_change信号，实时写入到硬件中。
配置对象
以扩展板为例，Accessor主要包括以下几类：
1、面板、点灯类事件设置
2、传感器类事件获取
3、单板基本信息获取和使能设置
4、电源类事件的配置（面板按钮清除、面板电源按钮屏蔽、面板电源按钮防误触设置、清除系统电源事件）
5、从基础板获取的开箱类事件
6、灵活插卡信息的获取
7、系统状态类事件配置（如E2P的写保护控制、Jtag链路切换控制）
配置举例
"Accessor_PcbID": {
"Chip": "#/Smc_ExpBoardSMC", //关联的Chip
"Offset": 1792, //偏移
"Size": 2, //读数据长度
"Mask": 15, //位读时有效，从硬件读取数据后与掩码进行按位与操作
"Type": 0, //读类型 0：位读/位写 1：块读/块写和SMC命令字相关
"Value": 0 //读值
}3.2.3 DFX
一块单板的CSR有大量Scanner需要轮询访问，但很多Scanner仅存在偏移差异，**BMC在获取每个scanner信息的时候，都需要消耗一条SMC命令字，导致总线效率很低。针对此情况需要做批量读取。**dfx是Scanner的扩展，为了减少硬件访问次数产生的一个机制，本质是通过dfx汇聚任务一次将chip的数据读取出来，再根据不同的掩码分配给不同的Scanner。当同时配置了Scanner和DFX对象时， BMC会优先从DFX中获取扫描数据。 假如Scanner在Dfx中有承载，则单条Scanner的扫描周期表示从Dfx同步数据的周期。比如Dfx的扫描周期为400ms，单条Scanner的扫描周期为2000ms，则表示Dfx刷新5次之后Scanner刷新1次数据。Dfx的Period并非Dfx的扫描周期，而是Dfx扫描完成之后的等待时间，实际Dfx扫描间隔时间会受到总线上其他进程数量影响（风扇板DFX Period设置100，但是在满配场景下测试由于IIC链路上进程过多导致两次Dfx间隔最大可达到7s）。
配置对象
以扩展板当前支持的dfx命令字为例，所有DFC命令字应遵循高资源利用率导向开发，尽量节约资源，合并dfx内容：
1、传感器的获取方式（对应传感器的SMC命令字）
2、软件读取传感器的扫描周期
3、此单板支持SmcDfx的CPLD版本
4、SmcDfxInfo中每个字节与对应硬件寄存器的掩码对应关系
5、Scanner的名称与对应的配置表达式（json格式中的key为Scanner名称，Scanner必须位于同一CSR文件中，json格式中的"Value"表示为Scanner的值，通过配置表达式从硬件信号获取值）
配置举例
以扩展板DFX为例：
"SmcDfxInfo_EXU": {
"Chip": "#/Smc_ExpBoardSMC", // 引用的Smc Chip对象
"Offset": 7424, // 偏移，一般为7424，Function=0x00 Cammand=0x07 RW=1
"Size": 55, // SmcDfxInfo的长度
"Period": 200, // 扫描周期，单位ms，默认值1000
"SmcVersion": 101, // 支持的Smc最低版本，用于版本检测
"Config": { // SmcDfxInfo中每个字节与对应硬件信号的对应关系，可通过mask按照单字节或者bit位进行对应
"1": {"cpld_ver": 255},
"2": {"temp_lm75_front_low": 255},
"3": {"temp_lm75_front_high": 255},
"4": {"temp_lm75_right_low": 255},
"5": {"temp_lm75_right_high": 255},
"6": {"temp_lm75_left_low": 255},
"7": {"temp_lm75_left_high": 255},
"8": {"adc_fan_1_low": 255},
"9": {"adc_fan_2_high": 255},
"10": {"bmc_adc_vcc_12v0_1_low": 255},
"11": {"bmc_adc_vcc_12v0_1_high": 255},
"12": {"bmc_adc_vcc_12v0_2_low": 255},
"13": {"bmc_adc_vcc_12v0_2_high": 255},
"14": {"bmc_adc_vcc_12v0_3_low": 255},
"15": {"bmc_adc_vcc_12v0_3_high": 255},
"16": {"bmc_adc_stby_3v3_low": 255},
"17": {"bmc_adc_stby_3v3_high": 255},
"18": {"bmc_adc_vcc_5v0_low": 255},
"19": {"bmc_adc_vcc_5v0_high": 255},
"20": {"bmc_adc_stby_5v0_low": 255},
"21": {"bmc_adc_stby_5v0_high": 255},
"22": {"bmc_adc_vcc_12v0_4_low": 255},
"23": {"bmc_adc_vcc_12v0_4_high": 255},
"24": {"bmc_adc_vcc_12v0_5_low": 255},
"25": {"bmc_adc_vcc_12v0_5_high": 255},
"32": {"status_power_sensor": 8,"status_lm75": 4,"status_adc": 2},
"34": {"prsnt_lci_n": 2,"prsnt_rci_n": 1},
"35": {"bmc_rst_event": 4,"uid_button_event": 2,"fp_power_button_event": 1},
"36": {"nic1_prsnt": 1},
"37": {"nic2_prsnt": 1},
"38": {"m2_power_cable_prsnt": 64,"prsnt_baseboard": 32,"prsnt_tpcm": 16,"prsnt_fan_board": 8,"prsnt_inner_hdd": 4,"prsnt_psu_hdd": 2,"prsnt_front_hdd": 1},
"39": {"bbu_prsnt": 1},
"40": {"sys_all_pwrgd_reg": 1},
"41": {"sys_power_on_flash": 1},
"42": {"vcc_time_out": 8,"vcc_power_fail": 4},
"43": {"code_power_time_out": 255},
"44": {"code_power_fail": 255},
"45": {"clk_50m_loss_status": 1},
"46": {"clk_100m_loss_status": 1},
"47": {"link_nic1_port": 15},
"48": {"link_nic2_port": 15},
"49": {"over_temp_12v_5": 16,"over_temp_12v_4": 8,"over_temp_12v_3": 4,"over_temp_12v_2": 2,"over_temp_12v_1": 1},
"50": {"pmbus_cpld_alert1": 16,"pg_ip_ps_1": 8,"pg_ps_1": 4,"bmc_efusev_ps_1": 2,"psu1_cpld_prsnt": 1},
"51": {"pmbus_cpld_alert2": 16,"pg_ip_ps_2": 8,"pg_ps_2": 4,"bmc_efusev_ps_2": 2,"psu2_cpld_prsnt": 1},
"52": {"lom1_card_type": 1},
"53": {"lom2_card_type": 1}
},
"Mapping": { // Scanner与硬件信号的对应关系，通过配置表达式获取值，硬件信号名称为Config中的名称
"Scanner_SerdesLom1Pres": {"Value": "expr($nic1_prsnt)"},
"Scanner_SerdesLom2Pres": {"Value": "expr($nic2_prsnt)"},
"Scanner_Psu1OPOKStatus": {"Value": "expr($pg_ps_1)"},
"Scanner_Psu2OPOKStatus": {"Value": "expr($pg_ps_2)"},
"Scanner_PS1Pres": {"Value": "expr($psu1_cpld_prsnt)"},
"Scanner_PS2Pres": {"Value": "expr($psu2_cpld_prsnt)"},
"Scanner_UIDButtonEvent": {"Value": "expr($uid_button_event)"},
"Scanner_UIDButtonLongEvent": {"Value": "expr($bmc_rst_event)"},
"Scanner_PowerGd": {"Value": "expr($sys_all_pwrgd_reg)"},
"Scanner_PowerGdFlash": {"Value": "expr($sys_power_on_flash)"},
"Scanner_CLU_1": {"Value": "expr($prsnt_fan_board)"},
"Scanner_FanPwrSensorStatus": {"Value": "expr($status_power_sensor)"},
"Scanner_ADCExuSensorStatus": {"Value": "expr($status_adc)"},
"Scanner_Fan_Pwr": {"Value": "expr($adc_fan_1_low + ( $adc_fan_2_high << 8))"},
"Scanner_SEU_1": {"Value": "expr($prsnt_front_hdd)"},
"Scanner_SEU_2": {"Value": "expr($prsnt_psu_hdd)"},
"Scanner_PowerBtnEvt": {"Value": "expr($fp_power_button_event)"},
"Scanner_100M1ClockFailMntr": {"Value": "expr($clk_100m_loss_status)"},
"Scanner_50M1ClockFailMntr": {"Value": "expr($clk_50m_loss_status)"},
"Scanner_PowerOnTimeout": {"Value": "expr($vcc_time_out)"},
"Scanner_PwrOkSigDrop": {"Value": "expr($vcc_power_fail)"},
"Scanner_Nic1Lm75": {"Value": "expr($temp_lm75_right_low + ($temp_lm75_right_high << 8))"},
"Scanner_Nic2Lm75": {"Value": "expr($temp_lm75_left_low + ($temp_lm75_left_high << 8))"},
"Scanner_PSULm75": {"Value": "expr($temp_lm75_front_low + ($temp_lm75_front_high << 8))"},
"Scanner_ExpMos1TempHigh": {"Value": "expr($over_temp_12v_1)"},
"Scanner_ExpMos2TempHigh": {"Value": "expr($over_temp_12v_2)"},
"Scanner_ExpMos3TempHigh": {"Value": "expr($over_temp_12v_3)"},
"Scanner_ExpMos4TempHigh": {"Value": "expr($over_temp_12v_4)"},
"Scanner_ExpMos5TempHigh": {"Value": "expr($over_temp_12v_5)"},
"Scanner_RightEar": {"Value": "expr($prsnt_rci_n)"},
"Scanner_LeftEar": {"Value": "expr($prsnt_lci_n)"},
"Scanner_ECUSys12V1": {"Value": "expr($bmc_adc_vcc_12v0_1_low + ($bmc_adc_vcc_12v0_1_high << 8))"},
"Scanner_ECUSys12V2": {"Value": "expr($bmc_adc_vcc_12v0_2_low + ($bmc_adc_vcc_12v0_2_high << 8))"},
"Scanner_ECUSys12V3": {"Value": "expr($bmc_adc_vcc_12v0_3_low + ($bmc_adc_vcc_12v0_3_high << 8))"},
"Scanner_ECUSys3V1": {"Value": "expr($bmc_adc_stby_3v3_low + ($bmc_adc_stby_3v3_high << 8))"},
"Scanner_ECUSys5V1": {"Value": "expr($bmc_adc_vcc_5v0_low + ($bmc_adc_vcc_5v0_high << 8))"},
"Scanner_ECUSys5V2": {"Value": "expr($bmc_adc_stby_5v0_low + ($bmc_adc_stby_5v0_high << 8))"},
"Scanner_ECUSys12V4": {"Value": "expr($bmc_adc_vcc_12v0_4_low + ($bmc_adc_vcc_12v0_4_high << 8))"},
"Scanner_ECUSys12V5": {"Value": "expr($bmc_adc_vcc_12v0_5_low + ($bmc_adc_vcc_12v0_5_high << 8))"},
"Scanner_CpuBrdPresenceMntr": {"Value": "expr($prsnt_baseboard)"},
"Scanner_FanCableMntr": {"Value": "expr($prsnt_fan_board)"},
"Scanner_EXUPwrOnTimeOut": {"Value": "expr($code_power_time_out)"},
"Scanner_EXUPwrSigDrop": {"Value": "expr($code_power_fail)"},
"Scanner_SerdesLom1CardType": {"Value": "expr($lom1_card_type)"},
"Scanner_SerdesLom2CardType": {"Value": "expr($lom2_card_type)"}
}
}Mapping为Scanner与硬件信号的对应关系，key为Scanner名称，Scanner必须位于同一CSR中，"Value"表示为Scanner的值，通过配置表达式从硬件信号获取值
3.2.4 SmcCmdList
该对象用于BMC获取全量SMC寄存器，在一键收集日志时根据配置发送SMC命令并收集返回数据存在日志中。
"SmcCmdList_BCU": {
"Chip": "#/Smc_ExpBoardSMC",//发送SMC命令的目标对象
"Type": "EXU", //对象类型，配置错误影响日志名称显示，不影响数据收集功能
"Slot": 1, //支持多个槽位号，影响日志名称显示，不影响数据收集功能
"Config": { //配置需要发送的SMC命令字，Function、Command、MS、RW、Parameter为SMC命令字格式内容，Length为收集的数据长度，Collected为是否需要收集这条SMC命令字数据，1表示启用收集，0表示禁用收集
"1": {
"Function": 0, "Command": 1, "MS": 0, "RW": 1, "Parameter": 0, "Length": 1, "Collected": 1
},
"2": {
"Function": 1, "Command": 1, "MS": 0, "RW": 1, "Parameter": 0, "Length": 1, "Collected": 0
}
}
}3.3 数值防抖策略
读取物理寄存器数据时，不可避免会遇到因器件抖动而产生误报等现象，需要采取一些防抖措施来过滤误报场景。
在通过硬件代理Scanner对象读取硬件数据的时候，可以通过Debounce属性配置防抖对象，目前支持的防抖类型有中值滤波，均值防抖，持续一致，二值持续一致，无防抖等类型。
防抖策略在SR配置中非常重要，大量的误告警、FIT告警等问题，都与SR中配置的告警防抖策略息息相关。
要注意的是，CSR文件中定义的Debounce对象必须至少被一个Scanner对象引用
BMC推荐的CSR硬件监控防抖机制详见：官方链接
配置对象
对扩展板而言，主要有以下SMC需要配置防抖：
1、中值滤波：3V/5V/12V电压值
2、持续一致滤波：Psu供电状态
3、二值持续一致滤波：风扇功率传感器状态，时钟丢失状态、扩展板Mos温度、基础板线缆在位状态、风扇板线缆在位状态
4、均值滤波：进/出风口温度、风扇功耗、风扇板温度（风扇板Smc）
配置举例
中值滤波
json"Median_ExpBoardLowerVoltage": { // 中值滤波防抖策略 "WindowSize": 36, // 窗口大小,参考BMC v2 DbdCfgMedianl类的HistoryValNum字段，表示历史数据个数 "DefaultValue": 1780 // 默认值，U32，会参与防抖计算 }均值防抖
均值防抖，去除最大、最小值后的平均值
json"MidAvg_FanPwr": { // 均值平均策略 "WindowSize": 3, // 窗口大小,参考BMC v2 DbdCfgMidAvg类的HistoryValNum字段，表示历史数据个数 "DefaultValue": 0, // 默认值 "IsSigned": false // 是否为有符号数，对获取温度进行滤波时需填true }持续一致防抖
持续一致防抖，当持续多次读到同一值时认为信号稳定，则属性取值更新为当前读值。
json"Cont_PsuSupply": { // 持续一致策略，参考BMC v2 DbdCfgCont类 "Num": 3, // 防抖次数,参考v2 ContNum字段，表示持续次数 "DefaultValue": 0 // 默认值 }二值持续一致防抖
json"ContBin_FanPwrSensorStatus": { // 二值持续一致防抖策略，参考BMC v2 DbdCfgContBin类 "NumH": 3, // 高电平持续次数 "NumL": 1, // 低电平持续次数 "DefaultValue": 0 // 默认值 }无防抖
json"Debounce": "None"
3.4 组件管理
3.4.1 升级管理
CPLD升级
在遵守天池规范的板卡设计下，CPLD的升级是通过BMC实现的。板卡若需要支持固件的带外升级功能，需要在CSR中增加自描述信息LogicFirmware_EXU_xx），通过CSR将配置下发到固件，再进行持久化和生效。当前举例的扩展板上设计了两颗CPLD，故需要增加两个LogicFirmware对象。
"LogicFirmware_EXU_1": {
"ComponentID": 5, // 固件component id
"ComponentIDEx": 4294967295, // 固件component id ex
"UId": "00000001010302044491", // 固件UId
"Name": "EXU_CPLD1", // 固件名
"Manufacturer": "XXX",
"Version": "#/Accessor_LogicVerId.Value", // 固件版本号
"Location": 5, // 器件位号（不带U）
"UpgradeChip": "#/Cpld_1", // 升级关联的Chip
"ChipInfo": "#/Cpld_1", // Chip信息
"Routes": "#/Accessor_JtagSwitch.Value", // 升级路由
"DefaultRoute": 0,
"FirmwareRoute": 0, // 固件路由
"ValidMode": 1, // 未使用
"SoftwareId": "CPLD-YYYY", // CPLD编码信息
"ValidAction": "#/Accessor_AC.Value" // 生效方式
},"LogicFirmware_EXU_2": {
"ComponentID": 5, // 固件component id
"ComponentIDEx": 4294967295, // 固件component id ex
"Name": "EXU_CPLD2", //固件UId
"Manufacturer": "XXX", //厂商
"Version": "#/Accessor_LogicVersionID2.Value", //固件版本号
"Location": 18, // 器件位号（不带U）
"UpgradeChip": "#/Cpld_1", //升级关联的Chip
"ChipInfo": "#/Cpld_1", //Chip信息
"Routes": "#/Accessor_JtagSwitch.Value", //升级路由
"DefaultRoute": 0,
"FirmwareRoute": 0, //固件路由
"SoftwareId": "CPLD-YYYY" // CPLD编码信息
}CSR升级
SRUpgrade_1为BMC v3定义专用的EEPROM升级对象，主要用于升级单板上的CSR组件，主要包括：
- 单板UID
- 板卡类型
- CSR data版本
- 关联的对象
- 软件ID
- 关联的EEPROM写保护事件
"SRUpgrade_1": {
"UID": "00000001010302044491", // 固件UID
"Type": "EXU", // 单板类型
"Version": "${DataVersion}", // CSR版本
"StorageChip": "#/Eeprom_EXU", // CSR升级对应EEPROM芯片
"SoftwareId": "XXX-YYYYY", // 编码信息，配置格式按‘固件类型-单板名称’
"WriteProtect": "#/Accessor_EXUWP.Value" // EEPROM写保护
}3.4.2 传感器管理（Sensor）
门限模拟传感器
门限传感器，即连续性传感器，表征传感器的值是连续变化的，如：温度，电压，功耗，转速等。本文档描述的为硬件CSR中需要配置的门限传感器属性值，剩余属性均配置在软件sr文件中，供BMC调用。
配置对象
以扩展板为例，门限类传感器主要包含以下内容：
1、ADC类电压传感器（12V、5V、3V、STBY）
2、温度类传感器（进出风口、PSU温度、NIC温度）
3、功耗传感器（风扇功率）
注意：配置门限传感器时需要考虑传感器使能状态是否受到实体在位和上下电的影响，Capabilities属性（该属性一般配置在soft.sr中）需要按照规范配置
①若传感器使能状态不受实体在位及上下电影响（一般对应关联的实体的Presence和PowerState配死为1），则配置为104
②若传感器使能状态受实体在位及上下电影响，则配置为232
配置举例
以入风口温度传感器为例，需要明确以下属性：
"ThresholdSensor_InletTemp": {
"AssertMask": 29312, //传感器事件产生掩码，决定是否能产生事件，根据传感器实际配置的"UpperNoncritical"等上下限按需配置
"DeassertMask": 29312, //传感器事件恢复掩码，决定是否能恢复事件，根据传感器实际配置的门限按需配置
"ReadingMask": 6168, //传感器读值掩码，决定是否能对外显示门限
"Linearization": 0, //传感器线性计算方程
"M": 100, //传感器M计算表达式低8bit，决定传感器原始值转换到读值的转换公式参数
"RBExp": 224, //传感器R/B计算表达式，各4bit
"UpperCritical": 43, //传感器严重事件上限
"UpperNoncritical": 41, //传感器一般事件上限
"PositiveHysteresis": 2, //传感器上升事件恢复迟滞量
"NegativeHysteresis": 2 //传感器下降事件恢复迟滞量
}门限传感器SEL检测流程:
离散传感器（DiscreteSensor）
离散传感器，表征传感器的值是离散的，如：运行状态，隔离值等。AssertMask、DeassertMask、DiscreteMask：三个掩码的配置规则相同，离散传感器中一般三个会配置为相同，其中bit15默认为0，bit0~bit14分别对应不同的离散事件，具体每个bit的含义详见IPMI规范42.2章节
配置对象
以扩展板为例，离散类传感器主要包含以下内容：
1、Acpi状态
2、电源按钮状态
3、功耗健康状态
4、上电超时状态
注意：配置离散传感器时需要考虑传感器使能状态是否受到实体在位和上下电的影响，Capabilities属性（该属性一般配置在soft.sr中）需要按照规范配置
①若传感器使能状态不受实体在位及上下电影响（一般对应关联的实体的Presence和PowerState配死为1），则配置为64
②若传感器使能状态受实体在位及上下电影响，则配置为192
配置举例
以ACPI状态为例，需要明确以下属性：
json"DiscreteSensor_AcpiState": { "OwnerId": 32, // 关联对应实体的Id属性 "OwnerLun": 0, "EntityId": "<=/Entity_MainBoard.Id", "EntityInstance": "<=/Entity_MainBoard.Instance", // 关联对应实体的Instance属性 "Initialization": 99, // 传感器初始化选项，门限传感器 - 0x63 "Capabilities": 64, // 传感器能力，具体含义见IPMI标准协议规范43.1章节； "SensorType": 34, // 传感器类型 "ReadingType": 111, // 传感器读值类型，ThresholdSensor则配置为0x01 "SensorName": "ACPI State", // 传感器名称 "AssertMask": 65, // 传感器事件产生掩码 "DeassertMask": 0, // 传感器事件恢复掩码 "DiscreteMask": 65, // 传感器离散值掩码 "Unit": 192, // 传感器单位配置，离散传感器-0xc0 "BaseUnit": 0, // 离散传感器无单位，配置为0 "ModifierUnit": 0, "DiscreteType": 1, // 传感器离散类型，普通离散为0，数字互斥离散为1 "RecordSharing": 1, "Reading": 0, "SensorNumber": 255 // 无传感器编号定制需求，则不配置或配死为255，由sensor模块分配 }
3.4.3 告警管理（Event）
告警事件
配置对象
event也叫做精细化告警，主要包括了sensor和BMC其他精细化告警，硬件sr里主要包括以下内容：
1、器件事件/告警（组件E2P访问失败、入/出风口温感访问失败、电子标签获取失败、挂耳在位事件、CPU板在位、风扇板在位、扩展板更换事件、ADC器件状态告警、Lm75器件告警）
2、温度类事件/告警（入风口温度告警、Mos过温、出风口过温）
3、电源类事件/告警（PSU输出异常、服务器上下电状态事件、电源过压告警、电源过低告警、电源电压获取失败告警、PSU安装/移除事件、电源故障告警）
4、系统类事件/告警（开箱检测、风扇功耗异常、高速时钟异常、CPLD自检事件）
5、按钮类事件/告警（UID按键事件）
1. 属性说明
(不配置则使用数据类型的默认值，所以按需配置即可)
| 属性 | 描述 |
|---|---|
| 对象名Event_xxx | Event是固定值，看做是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. 业务简图
配置举例
以高速时钟丢失告警为例，当前硬件sr中需要配置以下内容：
"Event_100M1ClockFailMntr": {
"EventKeyId": "ExpandBoard.EXPBoardClockSignalLost", // 事件码，对应BMC不同的告警码
"Reading": "<=/Scanner_100M1ClockFailMntr.Value", // 数据来源（包含数据计算）
"Condition": 1, // 告警门限值
"OperatorId": 5, // 告警产生条件，该项和告警门限值搭配使用,5表示数据来源传来的值等于Condition的值的时候触发告警
"Enabled": true,
"DescArg1": "100M", // redfish配置参数，用于web界面告警显示
"DescArg2": "buffer 1", // redfish配置参数，用于web界面告警显示
"Component": "#/Component_ComExpander" // 关联的Component对象
}离散告警事件
离散告警事件，针对上述的离散门限传感器，需要配置对应的离散告警事件。
配置对象
以扩展板为例，离散类告警事件主要包含以下内容：
1、Acpi状态
2、电源按钮状态
3、功耗健康状态
4、上电超时状态
配置举例
以上电超时I状态为例，需要明确以下属性：
json"DiscreteEvent_PwrOnTimeOut": { "Property": "<=/Scanner_PowerOnTimeout.Value", // 离散事件监听的属性，如果监听类型是组合侦听则代表 IPMI SEL产生使用的数据和方向 "ListenType": 1, // 离散事件监听方式：0-组合侦听，表征SEL的数据和方向均来自于Property属性 ;1-独立侦听，表征SEL的数据和方向来自于本对象属性 "EventData1": 1, // 当监听类型是独立侦听时使用,离散事件产生的数据1，同时用来表征同一类型的离散传感器不同的离散状态方向 "EventData2": 255, // 当监听类型是独立侦听时使用,离散事件产生的数据2 "EventData3": 255, "EventDir": "<=/Scanner_PowerOnTimeout.Value", // 当监听类型是独立侦听时使用,离散事件产生的方向：0：恢复;非0：产生 "Conversion": 0, // 离散事件翻转标识，高4bit用来组合侦听时EventData1的掩码，低4bit用来表征是否翻转：1：翻转；非1：不翻转 "SensorObject": "#/DiscreteSensor_PwrOnTimeOut" // 离散事件关联的离散传感器，当IPMI SEL产生或者恢复时体现在当前传感器的健康状态以及SEL上 }
离散传感器SEL检测流程:
3.4.4 电源管理
AC上下电
扩展板上需要定义AC上下电状态，关联Accessor传递的ac上下电状态值供BMC使用。
json"ACCycle_1": { "AC": "#/Accessor_AC.Value" //关联的AC上下电状态 }PowerGood信号
扩展板上需要定义Pg信号，关联Scanner传递的pg信号供BMC使用。
json"PGSignal_1": { "PowerGDState": "<=/Scanner_PowerGd.Value", //关联的PG信号 "@Default": { //默认值 "PowerGDState":255 } }PSU槽位
扩展板上需要定义psu的槽位信息，通过配置地址用于读取电源信息，当前扩展板需要定义两个Psu的槽位信息。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| Private | SlotNumber | 槽位号 | 是 |
| Private | SlotI2cAddr | 电源槽位I2c地址（10进制） | 是 |
| Private | FruI2cAddr | FruI2c地址（10进制） | 是 |
| Private | Presence | 电源在位信息，关联电源在位寄存器 | 是 |
| Private | PsuChip | 关联PsuChip Eeprom对象 | 是 |
| Private | FruChip | 关联FruChip Eeprom对象 | 是 |
以PSU1为例：
"PsuSlot_1": {
"SlotNumber": 1, //槽位号
"Presence": "<=/Scanner_PS1Pres.Value", //电源在位寄存器
"SlotI2cAddr": 184, //电源槽位i2c地址（10进制）
"PsuChip": "#/Eeprom_PsuChip1" //关联电源i2c器件
}电源类对象
扩展板上需要定义电源类的单个对象和属性，供BMC调用
json"PowerAction_1": { "PowerOnTimeoutFlag": "#/Accessor_PowerOnLock.Value" //硬件上电锁;1表示上锁,0表示解锁 },json"PowerButton_1": { "ShortPushButton": "#/Accessor_ShortPushButton.Value", //电源短按 "LongPushButton": "#/Accessor_LongPushButton.Value" //电源长按 },json"PowerSupplies_1": { "UpgradeStatus": 0 //PSU升级状态，0表示不在升级状态，1表示在升级前准备，2表示升级准备完成，开始升级 }电源按钮
扩展板上需要定义电源按钮的状态，供BMC调用
json"ButtonEvt_1": { "PowerBtnLock": "#/Accessor_PowerBtnLock.Value", //面板屏蔽按钮，1代表长短按钮不可用,0代表长短按钮可 "GetPowerBtnEvt": "<=/Scanner_PowerBtnEvt.Value", //上报按钮按下 "SetPowerBtnEvt": "#/Accessor_PowerBtnEvt.Value", //清除按钮按下 "PowerBtnShield": "#/Accessor_PowerBtnShield.Value" //防误触短按，1代表短按按钮不可用,0代表短按按钮可用 }
3.4.5 能效管理（CoolingRequirement&温度海洋）
- 温度海洋
TemperatureInfo主要用于web界面整机温度海洋的显示，提供服务器机箱温度传感器前面板与后面板的三维热力图，以及对应传感器状态与告警信息，其中温度点横坐标、温度点纵坐标、告警状态、告警阈值下限、温度点名称、温度值、传感器状态、告警阈值上限皆由CSR配置定义。当正确配置相关属性后，web整机温度海洋界面将生成一个温度点信息
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| Private | Name | 温度点名称，用于温度海洋界面对应温度点的传感器名称显示 | 是 |
| Private | ReadingValue | 温度值 | 是 |
| Private | UpperThreshold | 告警阈值上限，高于该阈值会触发告警 | 是 |
| Private | LowerThreshold | 告警阈值下限，低于该阈值会触发告警 | 是 |
| Private | Status | 传感器状态 | 是 |
| Private | Health | 告警状态,与传感器Health属性一致 | 是 |
| Private | CoordinateX | 温度点横坐标 | 是 |
| Private | CoordinateY | 温度点纵坐标 | 是 |
配置对象
以扩展板为例，当前需要明确以下关键温度点（需要注意此处温度海洋的告警门限配置需要与对应的门限传感器门限保持一致）：
- 入风口温度TemperatureInfo_1_10
- PSU温度TemperatureInfo_1_11
- NIC1温度TemperatureInfo_1_12
- NIC2温度TemperatureInfo_1_13
- 出风口温度TemperatureInfo_1_14
配置举例
"TemperatureInfo_1_10": {
"Name": "Inlet Temp", //温度点传感器名字
"ReadingValue": "<=/Scanner_Lm75_Inlet.Value", //温度值
"Status": "<=/Scanner_Lm75_Inlet.Status", //温度传感器链路状态
"Health": "<=/ThresholdSensor_InletTemp.Health", //传感器健康状态：OK-健康；Minor-有一般告警；Major-有严重告警；Critical-有紧急告警
"UpperThreshold": [ //告警阈值上限
46, //与对应温度点的传感器的一般事件上限UpperNoncritical，轻微级别告警的门限Condition保持一致
48, //与对应温度点的传感器的严重事件上限UpperCritical，严重级别告警的门限Condition保持一致
255 //与对应温度点的传感器的紧急事件上限UpperNonrecoverable，紧急级别告警的门限Condition保持一致
],
"LowerThreshold": [ //告警阈值下限
255, //与对应温度点的传感器的一般事件下限LowerNonCritical，轻微级别告警的门限Condition保持一致
255, //与对应温度点的传感器的严重事件下限LowerCritical，严重级别告警的门限Condition保持一致
255 //与对应温度点的传感器的紧急事件下限LowerNonrecoverable，紧急级别告警的门限Condition保持一致
],
"CoordinateX": 15, //温度点横坐标
"CoordinateY": 1 //温度点纵坐标
}温度录波 - 软件属性
Temperature主要用于历史温度采集曲线，只需要定义温度点类型。当前仅入风口涉及
json"Temperature_1_11": { "TemperatureType": 11 //温度点类型 }调速策略
CoolingRequirement主要用于整机调速。BMC v3架构中对调速策略进行了解耦，通过CoolingRequirement、CoolingArea、CoolingPolicy、CoolingFan、CoolingConfig多个对象实现能效管理。其中：
CoolingConfig：用于承载cooing模块的全局配置。
CoolingRequirement：一个温度点对应一个CoolingRequirement对象，用于关联硬件温度和配置目标。当前扩展板只需要配置温度点。
建议配置方法：CoolingRequirement和CoolingArea建议成对新增，但CoolingArea必须配置在PSR中。即使不参与调速，则Area中的PolicyIdxGroup和LiquidCoolingDeviceGroup默认配置为空即可。优势在于：
1、显式的占据了一个器件位置；
2、下发目标调速的时候会检测是否存在CoolingArea，若不存在会报错，防止漏配
CoolingPolicy：一个CoolingPolicy对象代表一条环温曲线；每个温度点可能关联0个或多个CoolingPolicy对象，取计算出来的转速最大值下发；删除CoolingPolicy需要在对应CoolingAea的PolicyIdxGroup里面删除对应的PolicyIdx。
CoolingArea：用于将CooingRequirement、CoolingPolicy、CoolingFan对象关联起来，该对象配置了一个温度点调速需要哪几个风扇参与，也描述了温度点关联了哪些环温调速曲线。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.CoolingRequirement | ActiveInStandby | Standby下调速是否生效，true：生效；false：不生效 | 是 |
| bmc.kepler.Systems.CoolingRequirement | CustomSupported | 是否支持自定义目标温度值，true：支持，false：不支持 | 是 |
| bmc.kepler.Systems.CoolingRequirement | CustomTargetTemperatureCelsius | 用户自定义温度值，255为默认无效值, 当CustomSupported为True时，自定义调速模式下使用改属性作为调速点的目标调速值 | 是 |
| bmc.kepler.Systems.CoolingRequirement | FailedValue | 温度状态异常后的调速转速，不配代表该目标调速策略无异常调速；如果配置了值，温度点读取失败的时候，该策略输出PWM为该属性配置值 | 是 |
| bmc.kepler.Systems.CoolingRequirement | MaxAllowedTemperatureCelsius | 满转转速的温度值，当该策略管理温度值达到该属性配置值时，该策略输出PWM为100 | 是 |
| bmc.kepler.Systems.CoolingRequirement | MonitoringStatus | 温度点传感器状态，温度点状态 0：正常 1：异常，该属性非0时，调速策略使用FailedValue输出PWM | 是 |
| bmc.kepler.Systems.CoolingRequirement | MonitoringValue | 调速策略对应的温度点温度值 | 是 |
| bmc.kepler.Systems.CoolingRequirement | RequirementId | 目标调速策略Id，Id必须全局唯一，当前Id支持有效16位，前8位baseid,后8位Slot | 是 |
| bmc.kepler.Systems.CoolingRequirement | SensorName | 调速策略对应的温度点传感器名 | 是 |
| bmc.kepler.Systems.CoolingRequirement | SmartCoolingTargetTemperatureCelsius | 智能调速模式策略，即EnergySaving/HighPerformance/LowNoise 三种模式下的目标温度值 | 是 |
| bmc.kepler.Systems.CoolingRequirement | TargetTemperatureCelsius | 目标温度值，用于PID目标调速计算 | 是 |
| bmc.kepler.Systems.CoolingRequirement | TargetTemperatureRangeCelsius | 自定义模式温度允许范围，用于自定义目标值时的合法性判断，仅支持自定义模式策略配置生效 | 是 |
| bmc.kepler.Systems.CoolingRequirement | TemperatureType | 目标调速温度点类型 | 是 |
| Private | BackupRequirementIdx | 备用目标调速策略ID，当温度点异常时使用该属性对应目标调速策略温度值计算PWM | 是 |
| Private | BaseId | 调速策略基础ID，RequirementId前8位 | 否 |
| Private | CoolingMedium | 调速策略对应散热介质 | 是 |
| Private | Enabled | 调速策略生效条件，true有效,false无效，可通过配置该属性自定义该调速策略的生效条件 | 是 |
| Private | IsBackupRequirement | 是否作为备份温度点 | 是 |
| Private | IsValid | 调速策略是否生效，软件结合CSR配置刷新 | 否 |
| Private | LiquidFailedValue | 温度点失效液冷调速值 | 是 |
| Private | ObtainTempFaildToValid | 硬盘调速策略温度值获取失败时该调速策略生效 | 是 |
| Private | OriginFailedValue | 失效调速策略CSR原始值 | 否 |
| Private | OriginMaxAllowedTemperatureCelsius | 满转调速策略CSR原始值 | 否 |
| Private | OriginSmartCoolingTargetTemperature | 智能调速模式调速策略CSR原始值 | 否 |
| Private | Slot | 槽位号，RequirementId后8位 | 否 |
| Private | SmartCoolingTargetTemperature | 智能调速模式策略，即EnergySaving/HighPerformance/LowNoise 三种模式下的目标温度值 | 是 |
配置对象
以支持液冷的某机型为例，当前扩展板上需要定义以下几个CoolingRequirement：
- 入风口对象
- 泵对象（液冷特有）
- 出风口对象
配置举例
以出风口对象为例：
"CoolingRequirement_1_7": {
"RequirementId": 7, // Id全局唯一，对应CoolingArea中的RequirementIdx属性
"TemperatureType": 2, // 目标调速温度类型（具体查看目标调速类型定义，仅用于支持自定义目标调速的温度点）
"MonitoringStatus": "<=/Scanner_Lm75_Outlet.Status", // 温度状态，用于异常调速，0正常,其他为异常
"MonitoringValue": "<=/Scanner_Lm75_Inlet.Value;<=/Scanner_Lm75_Outlet.Value |> expr((($1 + 5) > ($2 - 10)) ? ($1 + 5) : ($2 - 10))", // 温度值，关联硬件，不允许关联传感器Reading值，MonitoringStatus为0且温度小于255时候会下发温度进行目标和环温调速, MonitoringStatus为非0使用FailedValue值触发异常调速
"FailedValue": 80, // 温度状态异常后的异常调速转速，不配代表温度点异常不触发异常调速,默认值为0。
"TargetTemperatureCelsius": 50, // 当前调速目标值，默认配置EnergySaving模式目标值
"MaxAllowedTemperatureCelsius": 60, // 目标调速满转温度
"TargetTemperatureRangeCelsius": [ // 自定义模式目标温度值允许设置范围
40,
60
],
"SmartCoolingTargetTemperature": [ // EnergySaving/HighPerformance/LowNoise 三种模式下的目标温度值，不需要区分的话不配即可
50,
47,
53
],
"CustomSupported": true, // 是否支持自定义目标值
"CustomTargetTemperatureCelsius": 50, // 自定义模式目标温度，自定义模式使用该值作为目标温度值进行调速
"SensorName": "#/ThresholdSensor_OutletTemp.SensorName" //对应MonitoringValue所配置的传感器名称
}3.4.6 开箱检测管理
在扩展板上，需要定义一个开箱检测事件类，集合所有基础板和扩展板传递的开箱检测类事件，以供BMC调用。
"Chassis_1": {
"Name": "1", // 机框名
"IntrusionACOn": "<=/Scanner_ChassisIntrusionACOn.Value", // AC上电开箱事件关联Smc
"IntrusionACOff": "<=/Scanner_ChassisIntrusionACOff.Value", // AC下电开箱事件关联Smc
"CoverStatus": "<=/Scanner_ChassisCoverStatus.Value", // 机盖状态关联Smc
"IntrusionACOnClear": "#/Accessor_ChassisIntrusionACOnClear.Value", // AC上电开箱事件写清关联Smc
"IntrusionACOffClear": "#/Accessor_ChassisIntrusionACOffClear.Value", // AC下电开箱事件写清关联Smc
"IntrusionFlag": 0, // 软件属性
"UidButtonAccessor": "#/Accessor_UIDButtonEvent.Value", // uid短按信号写清关联Smc
"UidButtonScanner": "<=/Scanner_UIDButtonEvent.Value", // uid短按信号关联Smc
"UidButtonPressed": 0, // 软件属性，短按uid按钮事件
"UidButtonLongAccessor": "#/Accessor_UIDButtonLongEvent.Value", // uid长按信号写清关联Smc
"UidButtonLongScanner": "<=/Scanner_UIDButtonLongEvent.Value", // uid长按信号关联Smc
"UidButtonLongPressed": 0 // 软件属性，短按uid按钮事件
}3.4.7 数码管点灯管理
在扩展板上，需要定义一个数码管点灯控制类，以供BMC调用
"LedDispControl_0": {
"LedTubeSupport": true, // 能力支持
"LeftLedTube": "#/Accessor_LeftLedTube.Value", // 左灯
"MidLedTube": "#/Accessor_MidLedTube.Value", // 中灯
"RightLedTube": "#/Accessor_RightLedTube.Value" // 右灯
}3.4.8 NCSI能力管理
Pcie的NCSI能力配置。当前可通过扩展板的SMC命令字查询NCSI功能状态和设置NCSI功能通路，故需在单板CSR中配置该NCSI能力的对象，如下：
"NCSICapabilities_1": {
"PCIeNCSIEnabled": "#/Accessor_NCSI.Value", // NCSI能力配置，通过Accessor事件获取
"PCIeNCSISupported": false
}3.4.9 OCP卡热插拔
BMC根据天池连接器的在位信号判断OCP卡是否在位，然后设置非天池连接器完成卡加载或卸载。在OCP卡下行连接器添加配置天池连接器关联实际在位信号，如下：
"BusinessConnector_1": {
"Name": "OCP_BizConnector_3",
"Direction": "Downstream",
"Slot": 3,
"LinkWidth": "X8",
"MaxLinkRate": "PCIe 4.0",
"ConnectorType": "PCIe CEM",
"UpstreamResources": [],
"Ports": [],
"RefMgmtConnector": "#/Connector_OCP_1",
"RefMgmtConnectorTianChi": "#/Connector_OCP_1TianChi",
"RefPCIeAddrInfo": "#/PcieAddrInfo_OCP_1"
},
"Connector_OCP_1TianChi": {
"Bom": "xxx",
"Slot": 1,
"Position": 7,
"Presence": "<=/Scanner_SerdesLom1Pres.Value;<=/Scanner_SerdesLom1CardType.Value |> expr(($1 == 1 && $2 == 1) ? 1 : 0)",
"Buses": [
"I2c_2",
"I2cMux_Pca9545_i2c7_chip_1"
],
"SystemId": "${SystemId}",
"ManagerId": "${ManagerId}",
"ChassisId": "${ChassisId}",
"SilkText": "xxx",
"IdentifyMode": 3,
"Type": "OCP"
}3.4.10 BMC卡rootBDF自发现
不同机型的CPU带宽有差异，BMC对应的PortId不同，而BMC作为PCIeDevice的信息在platform.sr中配死。为了归一platform.sr需要通过拓扑建立，从PCIeAddrInfo中获取rootBDF，EXU相关配置举例如下：
CSR中需要配置BMC相关的PCIeAddrInfo槽位，上下行端口：
"BusinessConnector_1": {
"Name": "Up_1",
"Direction": "Upstream",
"Slot": 1,
"LinkWidth": "X8",
"MaxLinkRate": "PCIe 5.0",
"ConnectorType": "UBC",
"Ports": [
{
"Name": "Port1",
"ID": 1,
"Offset": 0,
"Width": 8
}
],
"Port1LinkInfo": "MB UBC"
},
"BusinessConnector_2": {
"Name": "Down_1",
"Direction": "Downstream",
"Slot": 1,
"LinkWidth": "X2",
"MaxLinkRate": "PCIe 5.0",
"ConnectorType": "PCIe CEM",
"UpstreamResources": [
{
"Name": "Up_1",
"ID": 255,
"Offset": 0,
"Width": 2
}
],
"RefPCIeAddrInfo": "#/PcieAddrInfo_BMC_1"
},
"PcieAddrInfo_BMC_1": {
"Location": "ExpBoard${Slot}",
"ComponentType": 26,
"ContainerSlot": "${Slot}",
"ContainerUID": "xx",
"ContainerUnitType": "EXU",
"GroupPosition": "PcieAddrInfo_BMC_1_${GroupPosition}"
}PSR中需要配置BMC的槽位:
"UnitConfiguration_EXU": {
"SlotType": "EXU",
"SlotNumber": 1,
"SlotSilkText": "EXU",
"Configurations": [
{
"UID": "xx",
"Index": 1,
"SrcPortName": [
"A6a"
],
"TargetPortID": [
1
],
"Slot": [1],
"Device": []
}
],
"Port1LinkInfo": "",
"Port1Status": 0
}3.5 装备测试策略
DFT类为装备测试专用，其中分为公共属性和不同类的专用属性。
配置对象
当前扩展板需要配置以下几种DFT装备测试项：
- E2PROM及对应的WIP测试项
- Lm75测试项
- ADC采样的电压值（5V0Vlot_1/5V0Vlot_1/3V3Vlot_1）测试项
- PSU测试项
- PMU测试项
- Bmc插卡测试项
- 基础板Cpld测试项
- Flash测试项
- DDR3测试项(新开发单板一般没有该测试项，需要检查确认)
- LPC测试项(新开发单板一般没有该测试项，需要检查确认)
- IPMB测试项
- NCSI测试项
- MGMT测试项
- 电源按钮测试项
- 开箱检测测试项
- NAND Flash测试项
- JTAG测试项
- SPI测试项
- Type C USB测试项
- IO类测试项：扩展板Lm75 SMC通信、NIC1 Lm75 SMC通信、NIC2 Lm75 SMC通信、PSU Lm75 SMC通信
- Led测试项及Led Tube测试项(部分机型的LED灯控制由多个单板的CPLD完成，例如taishan2.16中前后UID灯的点灯测试由EXU的逻辑控制，而健康灯的点灯由CLU的逻辑控制，故对应的UID灯点灯测试项应该配置到EX的CSR中,健康灯点灯测试项应该配置到CLU的CSR中)
- Eth测试项
配置举例
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Manufacture | Type | 测试类型 | 是 |
| bmc.kepler.Manufacture | Id | 装备测试项 | 是 |
| bmc.kepler.Manufacture | DeviceNum | 用来匹配唯一装备项 | 是 |
| bmc.kepler.Manufacture | Slot | 用来匹配唯一装备项 | 是 |
| bmc.kepler.Manufacture | ItemName | 装备项名称 | 是 |
| bmc.kepler.Manufacture | PrompteReady | 当前未使用 | 是 |
| bmc.kepler.Manufacture | PrompteFinish | 当前未使用 | 是 |
| bmc.kepler.Manufacture | ProcessPeriod | 当前未使用 | 是 |
| Private | InputChip | 检查bypass关联chip | 是 |
| Private | Channel | 检查InputChip关联chip的bypass，对应channel号 | 是 |
以Lm75为例，最后的“RefChip”为专用属性，表示关联的Lm75对象。
"DftLm75_1": {
"Id": 1, // 测试项类型：1人工自检，2需要人工准备前置条件，3拷机测试，4人工检查结果，5人工操作测试，6与装备交互测试
"Type": 1, // 测试项id
"DeviceNum": 0,
"ItemName": "LM75 For Inlet Temp",
"PrompteReady": "", // 测试前提示，字符串类型
"PrompteFinish": "", // 测试完成提示，字符串类型
"ProcessPeriod": 65535, // 测试时长
"RefChip": "#/Lm75_InletTemp" // 关联的Chip对象
}| Type(测试类型) | 含义 |
|---|---|
| 1 | 直接自检，由APP提供检验结果 |
| 2 | 需要人工干预的前提条件，比如需要接环回头、需要设置屏幕等，由各APP提供测试结果 |
| 3 | 拷机测试项 |
| 4 | 需要人工检查结果，比如LED灯需要人工查看是否正常，需要由装备人员确定检测结果 |
| 5 | 需要人工操作，如button 、LCD |
| 6 | 需要与装备进行交互，需要装备侧软件比对数据来确定测试结果 |
| 255 | 无效的测试项，不进行注册 |