一个完整的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等，按照天池架构规范定义；单板名称需要与后续单板描述信息的对象对应起来；

以xx机型主板为例进行说明：

json

"FormatVersion": "3.00", // 3.00为CSR代次版本
"DataVersion": "3.22",   // 3.22为固件对外的版本，即BMC显示的CSR版本号，3为大版本号，22为小版本号
"Unit": {
  "Type": "BCU",
  "Name": "CpuBoard_1"
}

2 硬件的管理拓扑信息

ManagementTopology为本组件的管理拓扑，主要包含Anchor、Buses、Chips、 Connectors的层级关系。管理拓扑是SR中描述组件上的管理树模型，包括单板上的管理根链路I2C，hisport_over_I2C通道，以及单板上存在和内存、TPM、UBC连接器和软件虚拟的状态连接器。

以xx主板为例进行说明：

json

"ManagementTopology": {
  "Anchor": {
    "Buses": [
      "I2c_1",
      "I2c_2",
      "I2c_8",
      "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_1": {
    "Chips": [
      "Smc_CpuBrdSMC",
      "Eeprom_BCU"
    ],
    "Connectors": [
      "Connector_Memory",
      "Connector_TrustedModule",
      "Connector_PsEvent",
      "Connector_BCUExtend",
      "Connector_UbcConfig"
    ]
  },
  "Hisport_16": {
    "Connectors": [
      "Connector_A1a"
    ]
  },
  "Hisport_17": {
    "Connectors": [
      "Connector_A1c"
    ]
  },
  "Hisport_18": {
    "Connectors": [
      "Connector_A2a"
    ]
  },
  "Hisport_19": {
    "Connectors": [
      "Connector_A2c"
    ]
  },
  "Hisport_20": {
    "Connectors": [
      "Connector_A3a"
    ]
  },
  "Hisport_21": {
    "Connectors": [
      "Connector_A4a"
    ]
  },
  "Hisport_15": {
    "Connectors": [
      "Connector_B1a"
    ]
  },
  "Hisport_14": {
    "Connectors": [
      "Connector_B2a"
    ]
  },
  "Hisport_12": {
    "Connectors": [
      "Connector_B3a"
    ]
  },
  "Hisport_13": {
    "Connectors": [
      "Connector_B3c"
    ]
  },
  "Hisport_10": {
    "Connectors": [
      "Connector_B4a"
    ]
  },
  "Hisport_11": {
    "Connectors": [
      "Connector_B4c"
    ]
  },
  "Hisport_6": {
    "Connectors": [
      "Connector_C4a"
    ]
  },
  "Hisport_7": {
    "Connectors": [
      "Connector_C5a"
    ]
  },
  "Hisport_8": {
    "Connectors": [
      "Connector_C6a"
    ]
  },
  "Hisport_9": {
    "Connectors": [
      "Connector_C7b"
    ]
  },
  "Hisport_3": {
    "Connectors": [
      "Connector_D4b"
    ]
  },
  "Hisport_2": {
    "Connectors": [
      "Connector_D5a"
    ]
  },
  "Hisport_1": {
    "Connectors": [
      "Connector_D6a"
    ]
  },
  "Hisport_0": {
    "Connectors": [
      "Connector_D7a"
    ]
  },
  "I2c_2": {
    "Chips": [
      "Smc_ExpBoardSMC"
    ]
  },
  "JtagOverLocalBus_1": {
    "Chips": [
      "Cpld_1"
    ]
  }
}

3 组件信息获取和管理

3.1 单板信息

3.1.1 主板信息

CSR是单板自描述信息，首先应当描述本板的基本信息。对于主板来讲，主要包括以下信息： 1、单板身份信息：单板UID、单板板名、厂商信息、单板类型、类型描述、单板部件编码、PCB版本、BoardID； 2、单板管理信息：板上CPLD的位号和版本号，CSR的版本号、MCU版本号；

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

json

"CpuBoard_1": { 
    "Slot": 1,                      // slot就是用来区分不同槽位的同类型单板的，通常在上级Connector定义不同的slot值，然后在下级sr中引用，由软件进行更新
    "UID": "XXX",  // 主板UID：vendor+组件类型+0302编码
    "Name": "<=/FruData_CpuBoard.BoardProductName|> expr($1 == '' ? 'BC83AMDH' : $1)",   // 主板板名
    "Manufacturer": "<=/FruData_CpuBoard.BoardManufacturer",    // 厂家信息，从EEPROM中的FRU中获取
    "Description": "CpuBoard",      //  单板类型描述
    "PartNumber": "<=/FruData_CpuBoard.BoardPartNumber",        // 单板部件编码，即0302编码，此处直接从FRU中获取
    "LogicVersion": "",             // 逻辑CPLD版本号，无需配置，由软件设置
    "LogicUnit": 6288,              // 逻辑CPLD的位号
    "PcbID": "#/Accessor_PcbID.Value",          // 单板的PCB版本
    "BmcStartFlag": "#/Accessor_BmcStartFlag.Value",            // 用于获取bmc启动状态进行基础板点灯
    "PcbVersion": "",               // 单板的PCB版本,BMC从CPLD中获取单板的PCB版本
    "LogicVersionID": "#/Accessor_LogicVersionID.Value",        // CPLD1逻辑版本号，通过Accessor获取（针对基础板上有两个CPLD的场景）
    "CPLD2VersionID": "#/Accessor_Cpld2VersionID.Value",        // CPLD2逻辑版本号，通过Accessor获取（针对基础板上有两个CPLD的场景）
    "MultiLogicUnit": {             // CPLD1和CPLD2在主板上的位号(不用加U)
      "CPLD1": 6288,
      "CPLD2": 6293
    },
    "MultiLogicVersion": {          // CPLD1和CPLD2默认版本号（未识别到CPLD版本号或CPLD升挂的时候使用此默认值）
      "CPLD1": "0.00",
      "CPLD2": "0.00"
    },
    "SRVersion": "${DataVersion}",  // 引用CSR文件中定义的CSR固件版本号
    "MCUVersion": "",               // MCU版本号，无需配置，由软件设置
    "BoardID": 65535,               // 单板BoardID,天池单板未使用BoardID,此值固定写成65535（CSR为json格式，数据均为10进制）
    "BoardType": "CpuBoard",        // 单板类型：CpuBoard
    "Number": 1,                    // 逻辑编号
    "DeviceName": "CpuBoard${Slot}",// 板卡丝印信息，原则上采用大驼峰命名风格，不带下划线，redfish接口
    "Position": "BCU${Slot}",       // 位置信息，redfish接口
    "NodeId": "BCU${Slot}CpuBoard${Slot}",      // 资源ID，Position和DeviceName拼接而成，redfish接口
    "RefSMCChip": "#/Smc_CpuBrdSMC",            // 主板挂载的SMC对象
    "FruID": "<=/Fru_CpuBoard.FruId",           // 单板的FRUID
    "CpldTestReg": "#/Accessor_CpldTest.Value", // CPLD自检寄存器，BMC通过命令交替向CPLD的自检寄存器写入55h和Aah，再读取Test寄存器，用来判断CPLD是否处于正常工作状态
    "CpldStatus": 0                 // CPLD的自检状态
}

3.1.2 单板上的器件

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

天池架构下，通过SMC标准命令字承载通用软硬件接口，BMC、BIOS等均通过标准SMC命令字与硬件交互，一块单板只有一个SMC中心（非智能组件没有SMC，比如Riser），通常由CPLD或者MCU实现。 天池架构的管理根链路为I2C，BMC通过I2C与SMC通讯，因此SMC需要配置对应的I2C地址，访问带宽等参数，在天池规范中，SMC的地址固定为0x60。

json

"Smc_CpuBrdSMC": {
    "Address": 96,      // 天池架构中，所有单板的SMC地址固定为0x60即96
    "AddrWidth": 1,     // 地址宽度，单位Byte
    "OffsetWidth": 1,   // 地址偏移宽度，单位Byte
    "WriteTmout": 0,    // 写超时，单位ms，SMC的读写超时均设置为0
    "ReadTmout": 0      // 读超时，单位ms，SMC的读写超时均设置为0
}

EEPROM

天池规范要求每个组件在管理根链路上下挂一个存储器件，用于存储自身的描述信息，即SR的存储载体。当前组件均采用Eeprom作为SR的存储载体。天池规范定义了SR的存储载体的I2C地址固定为0xAE。在这个EEPROM中不仅存储了硬件自描述信息，还包含电子标签和用于自定义数据等。

器件类对象EEPROM包含以下信息：

1、I2C器件公共属性（地址、地址宽度、偏移宽度、写超时、读超时）

2、EEPROM特有属性（分页写数据大小、分页写时间间隔、器件健康状态）

json

"Eeprom_BCU": {
    "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，最大允许取值1024，程序默认值为32
    "WriteInterval": 20,  // 分页写延时间隔，单位ms，最大允许取值500
    "HealthStatus": 0     // 器件健康状态，默认配置为0，由软件更新
}

CPLD

基础板（BCU）上的信号控制通常通过CPLD实现，如果板上有CPLD，则需要定义器件类对象CPLD。

json

"Cpld_1": {}  // 此对象在CSR中未定义属性

定义说明：BMC会调用CPLD对象的方法，因此即使CSR中未定义CPLD对象的属性，也要声明CPLD对象。

基础板（BCU）上包含CPU器件，<>2P基础板需要分别定义器件类对象CPU_1和CPU_2，1P基础板只需要定义器件类对象CPU_1。以CPU1举例：

json

"CPU_1": {
    "Id": "${Slot} |> expr($1 * 2 - 1)",    // CPU编码，多Host场景下可用于区分
    "SystemId": "${SystemId}",              // CPU所在的Host
    "PhysicalId": "${Slot} |> expr($1 * 2 - 1)", // 在单个Host里面标识CPU，应设置为(LogicalId - 1)
    "LogicalId": "${Slot} |> expr($1 * 2 - 2)", // 在单个Host里面标识CPU
    "Presence": 1,                              // 在位状态
    "Architecture": "ARM",                      // CPU架构
    "DiagnosticFault": 0,                       // 预故障标志位，默认值0
    "PredictiveFault": 0,                       // FDM诊断发现故障的标志位，默认值0，异常状况下由软件置1
    "CATERR": "<=/Scanner_Cpu1CATERRAccessor.Value", // 宕机信号
    "Position": "CpuBoard${Slot}",              // CPU所在的基础板
    "DeviceLocator": "${Slot} |> expr($1 * 2 - 1) |> string.format('CPU%s', $1)", // CPU位置，多Host场景下标识CPU
    "ProcessorHot": "<=/Scanner_Cpu1ProcessorHotAccessor.Value", // CPU内核过温告警配置
    "ThermalTrip": "<=/Scanner_Cpu1ThermalTripAccessor.Value", // CPU过温告警配置
    "ClearThermalTrip": "#/Accessor_Cpu1ClearThermalTripAccessor.Value",  //CPU清除过热保护状态
    "Health": "<=/Component_ComCpu1.Health",    // CPU健康状态
    "PowerGood": "<=/Scanner_PowerGood.Value",  // CPU上电状态
    "TemperatureCelsius": 0,                    // CPU温度，由软件赋值
    "MaxMemoryTemperatureCelsius": 0,           // 关联的内存的最大温度，由软件赋值
    "MaxMemoryTemperatureName": "N/A",          // 最高温度的内存标识，由软件赋值
    "Name": "${Slot} |> expr($1 * 2 - 1) |> string.format('CPU%s', $1)",
    "SilkText": "CPU1",                         // CPU名字
    "IsMemoryPresence": 0,                      // 是否有关联的内存
    "Manufacturer": ""                    // 制造商
}

Connector

天池架构支持组件自发现，组件与基础板、组件与组件均通过连接器连接，如果组件的自描述信息（csr文件）里配置了拓扑信息和connector，就可以根据connector的数据找到下一级连接的组件。

Connector对象包含下级硬件组件的参数信息，决定了下级硬件组件执行自发现的方式，也定义了与下级硬件组件关联的Buses信息。

对于基础板而言，Connector主要分为以下几类：

1、实体连接器（UBCDD/UBC（以X8为单位定义一个Connertor）、TPM模块）

2、虚拟连接器（电源配置及告警、基础板拓扑检测配置及告警、UBC配置、内存配置及告警）

以实体连接器为例：

json

"Connector_A1a": {
  "Bom": "14100513",             // 下级组件的Bom Id
  "Slot": 1,                     // 给下级组件分配的槽位信息，对应连接器所接riser对应的IO槽位
  "Position": 1,                 // 用于在命名中区分不同对象，无实际含义
  "Presence": "<=/Scanner_A1a.Value", // 在位状态，可以直接配置，也可以间接获取
  "Id": "",                      // 下级组件的Board Id
  "AuxId": "",                   // 下级组件的额外Id信息
  "Buses": [                     // 下级csr中会用到的总线
    "Hisport_I2C_16"
    ],
  "SystemId": 1,                 // 给下级组件分配的SystemId
  "SilkText": "CpuBoard${Slot}", // 丝印信息
  "IdentifyMode": 3,             // 下级组件识别方式，3为天池标准类型组件，2为BoardId不可读（上报）类型组件，1为BoardId可读类型组件
  "Type": "PCIeRiserCard"        //以下场景必须显示配置：FRU ID动态生成场景、PCIe设备加载场景、硬件类型区分场景
}

以虚拟连接器为例：

json

"Connector_PsEvent": {
  "Bom": "PsEvent",
  "Slot": "${Slot}",
  "Position": 24,
  "Presence": 1,
  "Id": "BC83AMDA",
  "AuxId": "0",
  "Buses": [
  "I2c_1"
  ],
  "SystemId": 1,
  "IdentifyMode": 2
}

BIOS

BIOS作为运行在硬件上的系统软件，与SMC、BMC均有大量交互，CSR中需要配置BIOS类。

json

"Bios_1": {
  "SystemId": 1,          // 所在的Host Id
  "ResetCmos": "#/Accessor_CMOS.Value", // 0-未下发清除bios配置，1-已下发清除bios配置
  "SecureBootEnableCompletionCode": "#/Accessor_SecureBootEnableCompletionCode.Value",
  "SecureBootEnableState": "#/Accessor_SecureBootEnableState.Value",
  "SecureBootVerifyCompletionCode": "#/Accessor_SecureBootVerifyCompletionCode.Value",
  "SecureBootVerifyState": "#/Accessor_SecureBootVerifyState.Value",
  "UpgradeFailed": 0,     // 判断升级是否失败
  "RecoverFailed": 0,     // 0-自愈成功，1-自愈失败且上报secure boot failed告警
  "FlashNum": 2,          // 基础板Flash数量
  "FlashSize": 64,        // Flash大小
  "FlashChannel": "#/Accessor_FlashChannel.Value", //Flash通道切换
  "FlashChannelIds": [0, 1]       //Flash通道匹配，用于升级，校验，自愈等功能的片选通道匹配，有几片Flash配对应配几个通道
}

json

"Pmu_1": {
    "SystemId": 1,      // 与Host个数保持一致
    "PmuType": 0,       // 当前都配置为0
    "ResetPmu": "#/Accessor_ResetPmu.Value", // 复位寄存器
    "SFPMaxTemperature": 0 // 光模块最大温度
}

json

"Fru_CpuBoard": {
    "PcbId": "#/Accessor_PcbID.Value", // 关联获取PcbID的Accessor
    "FruId": 1,                        // 除挂耳外配成1即可
    "FruName": "CpuBoard${Slot}" ,     // Fru的名称，如CpuBoard
    "PcbVersion": ".A",
    "PowerState": 1,
    "Health": 0,
    "EepStatus": 1,
    "Type": 36,                        //与装备有关，需要配置
    "FruDataId": "#/FruData_CpuBoard", //与装备有关，需要配置
    "UniqueId": "00000001020302083825",//与装备有关，需要配置
    "ConnectorGroupId": "${GroupId}"   //与装备有关，需要配置
},

3.2 硬件资源获取

CSR中承载了所描述硬件对象(单板)的关键硬件资源，包括软件可获取的电压、温度、告警等传感器信息，和软件可以操作的比如复位、清除告警等能力。在天池架构下，组件上通过卫星管理中心SMC来管理单板上的硬件器件，BMC软件通过标准的SMC命令字来获取和控制对应的硬件，因此本章节所描述的Scanner、Accessor、DFX都与对应组件的SMC命令字一一对应，并且与硬件逻辑代码和MCU代码一一对应。

3.2.1 Scanner

硬件SR文件中包含硬件对象的描述，其中scanner可以理解为硬件传感器，用于BMC软件扫描对应的传感器，获取硬件状态信息。在天池组件设计规范中，为了更好的做到软硬件解耦，组件上的传感器都是由硬件获取，并且通过SMC标准命令字上报给BMC，所以scanner对象可以简单理解为BMC通过SMC读取的硬件信息。

对于基础板来说，传感器主要包括：

1、板上所有高速连接器上的hisport_I2C使能状态

2、板级所有的电压传感器（板上所有进入ADC检测的电源）

3、板上所有的温度传感器（单板温感、缓启mos过温传感器等）

4、板上所有的时钟传感器（CPLD/MCU进行的时钟有无和频偏检测）

5、板上的CPU传感器（caterr、processhot、thermtrip、CPU致命错误、CPU状态）

6、系统信息的获取（包括组件工作模式、VR类型、系统上电状态、RTC时间、TPM在位、单板功率、系统复位时间、CPU类型、系统状态）

下面详细介绍对应的scanner下面的具体属性配置，一个标准的Scanner包含如下信息：

1、传感器的获取方式（对应传感器的SMC命令字）

2、软件读取传感器的扫描周期

3、软件读取传感器的防抖策略（防抖策略为固定配置，不同的传感器防抖策略固定）

4、软件对传感器进行扫描的条件（例如：电源传感器需要上电以后才开始扫描）

5、禁用时的备用默认值。

以12V电压检测scanner举例：

json

"Scanner_12v1": {
    "Chip": "#/Smc_CpuBrdSMC",  // 获取数据的SMC对象
    "Offset": 4865,             // 硬件地址偏移(Offset项)：需要逻辑/MCU提供opcode
    "Size": 2,                  //　数据的字节长度
    "Mask": 65535,              //　数据掩码
    "Type": 0,                  //　数据获取的方式，0-位操作，1-块操作
    "Period": 3000,             //　扫描周期，单位毫秒
    "Debounce": "#/Median_6win",//　滤抖策略为Median_6win
    "ScanEnabled": "<=/Scanner_PowerGood.Value", //　0-Scanner未使能，1-Scanner使能，注意STBY的电源不需要该EN，否则STBY状态下传感器没有数值
    "NominalValue": 2467,       //　当芯片处于不可用状态时，可通过ScanEnabled属性与NominalValue属性配置Scanner的禁用状态与禁用状态下的取值；
    "Status": 0,                //　Scanner状态
    "Value": 0,                 //　Scanner的值
    "@Default": {               // 为指定属性配置默认值
      "ScanEnabled": 0
    }
}

3.2.2 Accessor

Accessor也可以理解为硬件传感器，与Scanner不同，Accessor适用于需要随时读写硬件寄存器的场景。与scanner对比，Accessor也是硬件代理的传感器，但是与Scanner不同，Accessor对象是BMC可以写入的传感器，所以Accessor对象可以简单理解为BMC通过SMC写入的硬件信息。

其在BMC中的用法如下：

1、获取值时，hwproxy监听property_read信号，实时读取硬件的值并更新到资源树；

2、当写入值时，hwproxy监听property_before_change信号，实时写入到硬件中。

对于基础板而言，Accessor类传感器主要包括以下几类：

1、系统状态类的获取（单板PCB版本、单板逻辑版本、BT物理通道）

2、系统状态类的配置（设置BMC启动状态灯、设置扩展板JTAG选通链路、设置整机Power Cycle）、设置组件EEPROM写保护状态、CPLD自检设置、复位业务系统、清楚业务系统复位事件、清除电源超时记录tag、清楚电源fail记录tag、设置组件进入装备测试模式、设置VGA切换模式）

3、CPU状态的清除与配置（ThermalTrip的清除、复位IMU、清除CMOS、清除业务系统复位事件、清除IMU使能复位系统事件）

4、CPU状态的获取（查询安全启动使能状态完成码、查询安全启动使能状态、查询安全校验状态完成码、查询安全校验启动状态）

下面详细介绍对应的Accessor下面的具体属性配置，一个标准的Accesor包含如下信息：

1、传感器的获取方式（对应传感器的SMC命令字）

2、默认值

以获取单板PCB版本举例：

json

"Accessor_PcbID": {
  "Chip": "#/Smc_CpuBrdSMC", // Smc对象
  "Offset": 1792,            // Smc命令字的偏移
  "Size": 2,                 // 数据的字节长度
  "Mask": 15,                // 数据的掩码
  "Type": 0,                 // 数据获取的方式，其中0是位操作，1是块操作
  "Value": 0                 // 默认值
}

3.2.3 DFX

一块单板的CSR有大量Scanner需要轮询访问，但很多Scanner仅存在偏移差异，**BMC在获取每个scanner信息的时候，都需要消耗一条SMC命令字，导致总线效率很低。针对此情况需要做批量读取。**dfx是Scanner的扩展，为了减少硬件访问次数产生的一个机制，本质是通过dfx汇聚任务一次将chip的数据读取出来，再根据不同的掩码分配给不同的Scanner。在配置了DFX统一获取命令后，单条Scanner命令可以不在SR中配置。 假如Scanner在Dfx中有承载，则单条Scanner的扫描周期表示从Dfx同步数据的周期。比如Dfx的扫描周期为400ms，单条Scanner的扫描周期为2000ms，则表示Dfx刷新5次之后Scanner刷新1次数据。Dfx的Period并非Dfx的扫描周期，而是Dfx扫描完成之后的等待时间，实际Dfx扫描间隔时间会受到总线上其他进程数量影响（风扇板DFX Period设置100，但是在满配场景下测试由于IIC链路上进程过多导致两次Dfx间隔最大可达到7s）。

DFX对象中每个字节的具体信息，需要与硬件的SMC命令字实现保持一致

下面详细介绍对应的SmcDfxInfo下面的具体属性配置，一个标准的SmcDfxInfo包含如下信息：

1、传感器的获取方式（对应传感器的SMC命令字）

2、软件读取传感器的扫描周期

3、此单板支持SmcDfx的CPLD版本

4、SmcDfxInfo中每个字节与对应硬件寄存器的掩码对应关系

5、Scanner的名称与对应的配置表达式（json格式中的key为Scanner名称，Scanner必须位于同一CSR文件中，json格式中的"Value"表示为Scanner的值，通过配置表达式从硬件信号获取值）

json

"SmcDfxInfo_BCU": {
  "Chip": "#/Smc_CpuBrdSMC",        // 获取数据的smc对象
  "Offset": 7424,                   // smc命令字的偏移
  "Size": 72,                       // 数据的字节长度
  "Period": 400,                    // 扫描周期，单位ms
  "SmcVersion": 211,                // 支持的SMC最低版本
  "Config": {                       // 此处配置每个字节与硬件信号对应关系树
    "1": {"cpld_ver": 255},         // 第一个(CSR中从1开始)字节对应的信号及掩码
    "2": {"test_for_dxf": 1},
    "3": {"12v1_low": 255},
    "4": {"12v1_high": 255},
    "5": {"12v2_low": 255},
    "6": {"12v2_high": 255},
    "7": {"12v3_low": 255},
    "8": {"12v3_high": 255},
    "9": {"3v1_low": 255},
    "10": {"3v1_high": 255},
    "11": {"3v2_low": 255},
    "12": {"3v2_high": 255},
    "13": {"5v_low": 255},
    "14": {"5v_high": 255},
    "15": {"rtc_battery_low": 255},
    "16": {"rtc_battery_high": 255},
    "17": {"cpu_board_temp_low": 255},
    "18": {"cpu_board_temp_high": 255},
    "19": {"pwr_2_low": 255},
    "20": {"pwr_2_high": 255},
    "21": {"pwr_3_low": 255},
    "22": {"pwr_3_high": 255},
    "23": {"pwr_4_low": 255},
    "24": {"pwr_4_high": 255},
    "33": {"sensorStatus_1": 255}, 
    "35": {"rtc_byte_1": 255},
    "36": {"rtc_byte_2": 255},
    "37": {"rtc_byte_3": 255},
    "38": {"rtc_byte_4": 255},
    "39": {"rtc_byte_5": 255},
    "40": {"rtc_byte_6": 255},
    "41": {"rtc_byte_7": 255},
    "42": {"rtc_byte_8": 255},
    "43": {"flag_cpu_over_temp": 32,"vcc_time_out": 16,"vcc_power_fail": 8,"os_reboot_event_bmc": 4,"bmc_reboot_event_bmc": 2,"pltrst_event": 1},
    "44": {"pwr_time_out_error_code": 255},
    "45": {"pwr_fail_error_code": 255},
    "46": {"system_status": 255},
    "48": {"32k_clock_fail": 1}, 
    "47": {"32k_clock_fail": 1},  // 此处为MCU 32k时钟
    "50": {"clk_buffer_loss_status_6": 64,"clk_buffer_loss_status_5": 32,"clk_buffer_loss_status_4": 16,"clk_buffer_loss_status_3": 8,"clk_buffer_loss_status_2": 4,"clk_buffer_loss_status_1": 2,"clk_buffer_loss_status_0": 1},
    "51": {"sys_rst_all_event_0": 32,"cpu0_caterr_effect": 16,"cpu0_prochot_event": 8,"cpu0_thermtrip_event": 4,"cpu0_prochot_effect": 2,"cpu0_pkg_crack_ball_out": 1,"cpu0_status": 255},
    "52": {"sys_rst_all_event_1": 32,"cpu1_caterr_effect": 16,"cpu1_prochot_event": 8,"cpu1_thermtrip_event": 4,"cpu1_prochot_effect": 2,"cpu1_pkg_crack_ball_out": 1,"cpu1_status": 255},
    "53": {"tpm_cpld_prsnt_r": 1},
    "54": {"chassis_cover_status": 2},
    "55": {"mos_over_temp_12v_4_event": 8,"mos_over_temp_12v_2_3_event_2": 4,"mos_over_temp_12v_2_3_event_1": 2,"mos_over_temp_12v_1_event": 1},
    "56": {"hisport_i2c_enable_21": 64,"hisport_i2c_enable_20": 16,"hisport_i2c_enable_19": 8,"hisport_i2c_enable_18": 4,"hisport_i2c_enable_17": 2,"hisport_i2c_enable_16": 1},
    "58": {"hisport_i2c_enable_11": 128,"hisport_i2c_enable_10": 64,"hisport_i2c_enable_13": 32,"hisport_i2c_enable_12": 16,"hisport_i2c_enable_14": 4,"hisport_i2c_enable_15": 1},
    "60": {"hisport_i2c_enable_6": 64,"hisport_i2c_enable_5": 16},
    "61": {"hisport_i2c_enable_9": 16,"hisport_i2c_enable_8": 4,"hisport_i2c_enable_7": 1},
    "62": {"hisport_i2c_enable_3": 64,"hisport_i2c_enable_4": 16},
    "63": {"hisport_i2c_enable_0": 16,"hisport_i2c_enable_1": 4,"hisport_i2c_enable_2": 1},
    "70": {"vrd_type": 7},
    "72": {"system_cpu_error_restart": 1}
  },
  "Mapping": {              // config中配置的信号与scanner的对应关系
    "Scanner_Dftenabled": {"Value": "expr($test_for_dxf)"},
    "Scanner_A1a": {"Value": "expr($hisport_i2c_enable_16)"},
    "Scanner_A1c": {"Value": "expr($hisport_i2c_enable_17)"},
    "Scanner_A2a": {"Value": "expr($hisport_i2c_enable_18)"},
    "Scanner_A2c": {"Value": "expr($hisport_i2c_enable_19)"},
    "Scanner_A3a": {"Value": "expr($hisport_i2c_enable_20)"},
    "Scanner_A4a": {"Value": "expr($hisport_i2c_enable_21)"},
    "Scanner_B1a": {"Value": "expr($hisport_i2c_enable_15)"},
    "Scanner_B2a": {"Value": "expr($hisport_i2c_enable_14)"},
    "Scanner_B3a": {"Value": "expr($hisport_i2c_enable_12)"},
    "Scanner_B3c": {"Value": "expr($hisport_i2c_enable_13)"},
    "Scanner_B4a": {"Value": "expr($hisport_i2c_enable_10)"},
    "Scanner_B4c": {"Value": "expr($hisport_i2c_enable_11)"},
    "Scanner_C3a": {"Value": "expr($hisport_i2c_enable_5)"},
    "Scanner_C4a": {"Value": "expr($hisport_i2c_enable_6)"},
    "Scanner_C5a": {"Value": "expr($hisport_i2c_enable_7)"},
    "Scanner_C6a": {"Value": "expr($hisport_i2c_enable_8)"},
    "Scanner_C7b": {"Value": "expr($hisport_i2c_enable_9)"},
    "Scanner_D4b": {"Value": "expr($hisport_i2c_enable_3)"},
    "Scanner_D5a": {"Value": "expr($hisport_i2c_enable_2)"},
    "Scanner_D6a": {"Value": "expr($hisport_i2c_enable_1)"},
    "Scanner_D7a": {"Value": "expr($hisport_i2c_enable_0)"},
    "Scanner_12v1": {"Value": "expr((($12v1_low >> 4) << 4) + ($12v1_high << 8))"},
    "Scanner_12v2": {"Value": "expr((($12v2_low >> 4) << 4) + ($12v2_high << 8))"},
    "Scanner_12v3": {"Value": "expr((($12v3_low >> 4) << 4) + ($12v3_high << 8))"},
    "Scanner_3v1": {"Value": "expr((($3v1_low >> 4) << 4) + ($3v1_high << 8))"},
    "Scanner_3v2": {"Value": "expr((($3v2_low >> 4) << 4) + ($3v2_high << 8))"},
    "Scanner_5v": {"Value": "expr((($5v_low >> 4) << 4) + ($5v_high << 8))"},
    "Scanner_vid": {"Value": "expr($vrd_type)"},
    "Scanner_RTCBatteryMntr": {"Value": "expr($rtc_battery_low + ($rtc_battery_high << 8))"},
    "Scanner_CpuMosTempHigh_1": {"Value": "expr($mos_over_temp_12v_1_event)"},
    "Scanner_CpuMosTempHigh_2": {"Value": "expr($mos_over_temp_12v_2_3_event_1)"},
    "Scanner_CpuMosTempHigh_3": {"Value": "expr($mos_over_temp_12v_2_3_event_2)"},
    "Scanner_CpuMosTempHigh_4": {"Value": "expr($mos_over_temp_12v_4_event)"},
    "Scanner_Cpu1CATERRAccessor": {"Value": "expr($cpu0_caterr_effect)"},
    "Scanner_Cpu1ProcessorHotAccessor": {"Value": "expr($cpu0_prochot_event)"},
    "Scanner_Cpu1ThermalTripAccessor": {"Value": "expr($cpu0_thermtrip_event)"},
    "Scanner_Cpu2CATERRAccessor": {"Value": "expr($cpu1_caterr_effect)"},
    "Scanner_Cpu2ProcessorHotAccessor": {"Value": "expr($cpu1_prochot_event)"},
    "Scanner_Cpu2ThermalTripAccessor": {"Value": "expr($cpu1_thermtrip_event)"},
    "Scanner_CPUStatus": {"Value": "expr($cpu0_status + ($cpu1_status << 8))"},
    "Scanner_SystemStatus": {"Value": "expr($system_status)"},
    "Scanner_Rtc": {"Value": "expr($rtc_byte_1 + ($rtc_byte_2 << 8) + ($rtc_byte_3 << 16) + ($rtc_byte_4 << 24) + ($rtc_byte_5 << 32) + ($rtc_byte_6 << 40) + ($rtc_byte_7 << 48) + ($rtc_byte_8 << 56))"},
    "Scanner_TPMPresence": {"Value": "expr($tpm_cpld_prsnt_r)"},
    "Scanner_CpuBoard_Temp": {"Value": "expr($cpu_board_temp_high)"},
    "Scanner_pwr2": {"Value": "expr((($pwr_2_low >> 6) << 6) + ($pwr_2_high << 8))"},
    "Scanner_pwr3": {"Value": "expr((($pwr_3_low >> 6) << 6) + ($pwr_3_high << 8))"},
    "Scanner_pwr4": {"Value": "expr((($pwr_4_low >> 6) << 6) + ($pwr_4_high << 8))"},
    "Scanner_100M0ClockFailMntr": {"Value": "expr($clk_buffer_loss_status_0)"},
    "Scanner_100M1ClockFailMntr": {"Value": "expr($clk_buffer_loss_status_1)"},
    "Scanner_100M3ClockFailMntr": {"Value": "expr($clk_buffer_loss_status_2)"},
    "Scanner_100M4ClockFailMntr": {"Value": "expr($clk_buffer_loss_status_3)"},
    "Scanner_100M5ClockFailMntr": {"Value": "expr($clk_buffer_loss_status_4)"},
    "Scanner_100M6ClockFailMntr": {"Value": "expr($clk_buffer_loss_status_5)"},
    "Scanner_32kClockFailMntr": {"Value": "expr($32k_clock_fail)"}, // 此处为MCU 32k时钟
    "Scanner_156M25ClockFailMntr": {"Value": "expr($clk_buffer_loss_status_6)"},
    "Scanner_SysRstDetected": {"Value": "expr($pltrst_event)"},
    "Scanner_SystemCPUErrorRestart": {"Value": "expr($system_cpu_error_restart)"},
    "Scanner_SensorStatus_1": {"Value": "expr($sensorStatus_1)"}
  }
}

3.2.4 SmcCmdList

该对象用于BMC获取全量SMC寄存器，在一键收集日志时根据配置发送SMC命令并收集返回数据存在日志中。

json

"SmcCmdList_BCU": {
  "Chip": "#/Smc_CpuBrdSMC",//发送SMC命令的目标对象
  "Type": "BCU",            //对象类型，配置错误影响日志名称显示，不影响数据收集功能
  "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、中值滤波：ADC电压（12V缓启、3V3、5V）

2、持续一致滤波：组件工作模式、VRD固件类型区分、Thremtrip信号使能状态

3、二值持续一致滤波：MOS过温、板上时钟检测

4、均值滤波：RTC电源、主板板温

中值滤波

json

"Median": {
    "WindowSize": 6,    // 窗口大小
    "DefaultValue": 11  // 默认值
}

持续一致滤波

json

"Cont": {
    "Num": 6,           // 防抖次数
    "DefaultValue": 11  // 默认值
}

二值持续一致

json

"ContBin": {
    "NumH": 6,          // 高电平防抖次数
    "NumL": 6,          // 低电平防抖次数
    "DefaultValue": 11  // 默认值
}

均值防抖

json

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

无防抖

json


"None": {
    "DefaultValue": 11
}

3.4 组件管理

3.4.1 升级管理

基础板上有CPLD、MCU、CSR、BIOS、VRD等固件，需要配置这些固件的升级对象，便于BMC加载。

CPLD升级

基础板上有几个CPLD，就需要配置几个CPLD的升级对象

json

"LogicFirmware_BCU_1": {
  "ComponentID": 24,                // 固件component id
  "ComponentIDEx": 1,               // 固件component id ex
  "UId": "00000001020302031825",    // 固件UID
  "Name": "BCU_CPLD1",              // 视不同单板有不同的配置
  "Manufacturer": "XXX",         // 厂商
  "Version": "#/Accessor_LogicVerId.Value", // 固件版本
  "Location": 6288,                 // 器件位号（不带U）
  "UpgradeChip": "#/Cpld_1",        // 使用Jtag链路升级对应的芯片
  "ChipInfo": "#/Cpld_1",           // 获取cpld厂商和bypass使能对应的chip
  "Routes": "#/Accessor_JtagSwitch.Value", // 升级对应链路
  "DefaultRoute": 0,
  "FirmwareRoute": 1,               // 与Routes关联的Smc对应，升级时后会设置对应值切到对应链路。0代表不需要切
  "ValidMode": 1,                   // 未使用
  "SoftwareId": "CPLD-BC83AMDA",    // CPLD编码信息
  "ValidAction": "#/Accessor_AC.Value" // 未使用
}

CSR升级

json

"SRUpgrade_1": {
    "UID": "00000001020302031825",    // 固件UID
    "Type": "BCU",                    // 单板类型
    "Version": "${DataVersion}",      // CSR版本
    "StorageChip": "#/Eeprom_BCU",    // CSR升级对应EEPROM芯片
    "SoftwareId": "XXX-YYYY",    // 编码信息
    "WriteProtect": "#/Accessor_BCUWP.Value"  // EEPROM写保护
}

MCU升级

json

"MCUFirmware_1": {
  "UID": "00000001020302031825", // 固件UID
  "RefChip": "#/Smc_CpuBrdSMC",  // 升级使用的Chip
  "LockChip": "#/Smc_CpuBrdSMC", // 并行升级时调用的总线锁
  "Address": 96,                 // MCU地址
  "Protocol": "SMC",             // 升级使用的协议
  "SoftwareId": "MCU-YYYY",  // 编码信息
  "BoardType": "BCU"             // 单板类型
}

BIOS升级

json

"Bios_1": {
  "SystemId": 1,          // 所在的Host Id
  "ResetCmos": "#/Accessor_CMOS.Value", // 0-未下发清除bios配置，1-已下发清除bios配置
  "SecureBootEnableCompletionCode": "#/Accessor_SecureBootEnableCompletionCode.Value",
  "SecureBootEnableState": "#/Accessor_SecureBootEnableState.Value",
  "SecureBootVerifyCompletionCode": "#/Accessor_SecureBootVerifyCompletionCode.Value",
  "SecureBootVerifyState": "#/Accessor_SecureBootVerifyState.Value",
  "UpgradeFailed": 0,     // 判断升级是否失败
  "RecoverFailed": 0      // 0-自愈成功，1-自愈失败且上报secure boot failed告警
}

3.4.2 VRD管理

CSR中以一个CPU为单位去获取VRD的电压和温度。新的VRD管理方式配置示例：

json

"VrdPower_0V75_CPU0_DDRVDD_FIX": {
  "@Parent": "VrdChip_U108",  // 配置所属的VRDmgmt
  "SystemId": 1,              // 和上层VRDmgmt的该项保持一致
  "CpuId": 1,                 // 1-归属于cpu1，2-归属于cpu2
  "Type": 2,                  // 继承bios配置，2表示uncore
  "DieId": 255                // 继承bios配置，255表示NOT_EXIST
}

VrdMgmt配置

VrdMgmt是VRD系统的顶层管理对象，负责管理特定CPU的整体VRD信息。

字段	说明	数据类型	单位	备注
SystemId	系统ID号	U8	-	标识系统
CpuId	所关联的CPU ID	U8	-	标识CPU
Cpu0v9TACore	VRD供电信息，供电区域类型为CORE，DieId为1	Double	V	电压值
Cpu0v75DDRVDD	VRD供电信息，供电区域类型为DDR，无DieId	Double	V	电压值
Cpu0v9TBCore	VRD供电信息，供电区域类型为CORE，DieId为3	Double	V	电压值
Cpu0v9Uncore	VRD供电信息，供电区域类型为UNCORE，无DieId	Double	V	电压值
Cpu0v8NADVDD	VRD供电信息，供电区域类型为Nimbus，DieId为0	Double	V	电压值
Cpu0v8NBDVDD	VRD供电信息，供电区域类型为Nimbus，DieId为2	Double	V	电压值
Cpu1v1DDRVddq	VRD供电信息，供电区域类型为VDDQ，无DieId	Double	V	电压值
CpuTACoreTemp	临时VRD供电信息，供电区域类型为CORE，DieId为1	Double	°C	温度值
CpuDDRVDDTemp	临时VRD供电信息，供电区域类型为DDR，无DieId	Double	°C	温度值
CpuTBCoreTemp	临时VRD供电信息，供电区域类型为CORE，DieId为3	Double	°C	温度值
CpuUncoreTemp	临时VRD供电信息，供电区域类型为UNCORE，无DieId	Double	°C	温度值
CpuNADVDDTemp	临时VRD供电信息，供电区域类型为Nimbus，DieId为0	Double	°C	温度值
CpuNBDVDDTemp	临时VRD供电信息，供电区域类型为Nimbus，DieId为2	Double	°C	温度值
CpuDDRVddqTemp	临时VRD供电信息，供电区域类型为VDDQ，无DieId	Double	°C	温度值
VrdTemperatureCelsius	最高温度温度	Double	°C	整体温度
Status	VRD状态	U8	-	0=无效值，1=有效值

VrdChip配置

字段	说明	数据类型	单位	备注
Name	芯片名称	String	-	Type+No格式
Vendor	厂商信息	String	-
Type	芯片类型	String	-	SKU信息
FirmwareVersion	固件版本	String	-	版本号

VrdPower配置

字段	说明	数据类型	单位	备注
SystemId	系统ID号	U8	-	标识系统
CpuId	CPU ID	U8	-	标识CPU
Type	电源类型	U8	-	供电区域类型
DieId	芯片Die ID	U8	-	芯片内部标识
Voltage	电压值	Double	V	电压
CurrentAmps	电流值	Double	A	电流
TemperatureCelsius	温度值	Double	°C	温度

3.4.3 传感器管理

传感器包括门限传感器（也叫连续性传感器，表征传感器的值是连续变化的）和离散传感器（表征传感器的值是离散的，如：运行状态，隔离值等）。

门限传感器

对于基础板而言，门限类传感器主要包含以下内容：

1、电压（ADC电压、VRD电压）

2、功耗（缓启功耗）

3、温度（VCPU核温、CPU内存温度、VRD温度、光模块温度、主板板温）

接口定义如下:

Interface/Private	属性/方法	描述	是否由CSR配置
Private	Reading	事件读值，变更时会检测是否满足告警门限	是

门限传感器，主要是配置对应的告警门限。

json

"ThresholdSensor_Cpu1TaCoreTemp": {
  "AssertMask": 128,      // 传感器事件产生掩码，决定是否能产生事件，根据传感器实际配置的"UpperNoncritical"等上下限按需配置
  "DeassertMask": 28800,  // 传感器事件恢复掩码，决定是否能恢复事件，根据传感器实际配置的门限按需配置
  "ReadingMask": 2058,    //传感器读值掩码，决定是否能对外显示门限
  "M": 100,               // 决定传感器原始值转换到读值的转换公式参数
  "RBExp": 224,           // 决定传感器原始值转换到读值的转换公式参数
  "UpperNoncritical": 120,// 传感器一般事件上限
  "PositiveHysteresis": 2,// 传感器上升事件恢复迟滞量
  "NegativeHysteresis": 2 // 传感器下降事件恢复迟滞量
}

注意：配置门限传感器时需要考虑传感器使能状态是否受到实体在位和上下电的影响，Capabilities属性（该属性一般配置在soft.sr中）需要按照规范配置

①若传感器使能状态不受实体在位及上下电影响（一般对应关联的实体的Prsence和PowerState配死为1），则配置为104

②若传感器使能状态受实体在位及上下电影响，则配置为232

门限传感器SEL检测流程:

离散传感器

对于基础板而言，离散传感器包含以下三个：

1、RTC电压

json

"DiscreteSensor_RTCBattery": {
    "AssertMask": 1,    // 传感器事件产生掩码，决定是否能产生事件
    "DeassertMask": 1,  // 传感器事件恢复掩码，决定是否能恢复事件
    "DiscreteMask": 1   // 传感器离散值掩码，决定离散状态能否通过传感器返回
}

此处的Battery掩码bit0代表电池低电量，bit1代表电池故障，bite2代表电池在位检测

2、系统相关

json

"DiscreteSensor_SystemNotice": {
    "AssertMask": 256,
    "DeassertMask": 256,
    "DiscreteMask": 256
}

此处的掩码各bit含义如下

bit	severity event states
0	transition is Ok
1	transition to Non-Critical from Ok
2	transition Critical from less severe
3	transition to Non-recoverable from less severe
4	transition to Non-Critical from more severe
5	transition to Critical from non-recoverable
6	transition to Non-recoveralbe
7	Monitor
8	Informational

json

"DiscreteSensor_SystemError": {
    "AssertMask": 4,
    "DeassertMask": 4,
    "DiscreteMask": 4
}

此处的掩码各bit含义如下

bit	event
0	System Reconfigured
1	OEM System Boot Event
2	Undetermined system hardware failure
3	Entry added to Auxiliary log
4	PEF Action
5	Timestamp Clock Synch

AssertMask、DeassertMask、DiscreteMask：三个掩码的配置规则相同，离散传感器中一般三个会配置为相同，其中bit15默认为0，bit0~bit14分别对应不同的离散事件，具体每个bit的含义详见IPMI规范42.2章节

注意：配置离散传感器时需要考虑传感器使能状态是否受到实体在位和上下电的影响，Capabilities属性（该属性一般配置在soft.sr中）需要按照规范配置

①若传感器使能状态不受实体在位及上下电影响（一般对应关联的实体的Prsence和PowerState配死为1），则配置为64

②若传感器使能状态受实体在位及上下电影响，则配置为192

离散传感器SEL检测流程:

3.4.4 告警管理

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_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	(选配) 需要忽略的无效值

当电源的异常掉电和上电超时告警不通过Connector加载vpd内置的CSR时，需要配置电源告警PowerEvent对象

属性	描述
对象名PowerEvent_xxx	PowerEvent是固定值，看做是Class，所有PowerEvent类都会分发到事件模块处理 xxx是名称，无功能意义，单个文件不重复即可，完整名称自发现会根据SR文件拼接，比如拼接成PowerEvent_xxx_0101
EventKeyId	(必配)事件标识，用于匹配事件静态配置，例如告警描述等信息，要在BMC内部定义，才能产生告警，见第三小节的列表
Reading	(必配)告警读数，普通的事件比如温度可以直接拿来当做读数，其他类型的比如证书过期，可以是0和1来代替最终是结合运算符、门限判断是否符合告警条件，所以根据业务场景配置即可
Component	关联的Component对象，正常情况下Component部件需要与事件码高位匹配，用于显示告警主体例如：查询环境有无对应的Component Type等于事件码高位例如0x02xxxxxx则需要查找Type为2的部件
AdditionalInfo	(选配)事件的附加信息，即第X个动态参数，也可以是‘1,2’指向多个,用于FD上报时区分不同事件比如完全相同的告警仅槽位不同，一般用槽位做区分，新增的告警需要特别注意是否需要配置
Mappings	(必配) 告警产生条件的集合列表
Mappings/Reading	(必配)配置的两个Reading值相等时产生告警
Mappings/LedFaultCode	(选配) Led错误码，可以是固定值也可以是动态值`x$` (取Component中的Instance填充`$`部分)
Mappings/DescArgs	事件的描述/建议参数数组，用于格式化参数，即替换描述模板中的%1、%2等占位符，如索引为0的参数替换描述中的%1 仅支持字符串格式，最多10个注：如果对于浮点数期望显示为3位小数，则需要通过SR表达式format进行转换

2. 告警产生逻辑

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

是否产生: Reading OperatorId Condition

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

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

3. EventKeyId列表

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

4. 业务简图

配置实例：

json

"Event_CpuBoard12V1_LowerVoltage": {
    "EventKeyId": "CpuBoard.LowerVoltage",  // 事件码，对应BMC不同的告警码
    "Condition": 10.8,                      // 告警门限值
    "Hysteresis": 0.48,                     // 告警恢复迟滞量
    "LedFaultCode": "b01",                  // LED告警码，产生故障时，服务器的挂耳数码管上可以显示故障码
    "Reading": "<=/Scanner_12v1.Value |> expr($1  == 32767 ? 12 : (($1 / 10) * 3.3 * 6 * 10 / 4096))",                                // 数据来源（包含数据计算）
    "@Default": {                           // 数据默认值，防止误告警
    "Reading": 12
    },
    "OperatorId": 2,                        //告警产生条件，该项和告警门限值搭配使用,2表示数据来源传来的值小于等于Condition的值的时候触发告警
    "DescArg1": "<=/Scanner_12v1.Value |> expr($1  == 32767 ? 12 : (($1 / 10) * 3.3 * 6 * 10 / 4096)) |> string.format('%0.3f', $1)",  // redfish配置参数，用于web界面告警显示
    "DescArg2": "12V",                      // redfish配置参数，用于web界面告警显示
    "DescArg3": "BCU${Slot}_V_VCC_12V0_1",  // redfish配置参数，用于web界面告警显示
    "DescArg4": "10.8",                     // redfish配置参数，用于web界面告警显示
    "Component": "#/Component_CpuBoard",    // 关联的Component对象
    "AdditionalInfo": "3"                   // 填写可以用来区分不同告警的DescArg
}

3.4.5 能效管理

CoolingRequirement

CoolingRequirement用于描述整机调速中的目标调速策略，策略信息由CSR配置，如温度点读值、目标温度、温度点状态、温度点失效调速、目标调速生效条件等。软件通过加载CoolingRequirement CSR，对目标调速策略进行管理，输出PWM至散热器件，实现整机散热管理。

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 三种模式下的目标温度值	是

基础板主要包括以下几个调速点： 1、CPU温度 2、内存温度 3、VRD温度

配置样例：

json

"CoolingRequirement_1_20": {
    "RequirementId": 20,        // ID,需要确保全局唯一
    "TemperatureType": 1,       // 目标调速温度类型，详见下表
    "MonitoringStatus": "<=/CPU_1.TemperatureCelsius |> expr(($1 == 16384) ? 0 : ($1 >= 255 ? 1 : 0))",        // 温度状态，用于异常调速，1-异常，0-正常
    "MonitoringValue": "<=/CPU_1.TemperatureCelsius",// 温度值
    "FailedValue": 80,          // 温度状态异常后的异常调速转速，不配代表不触发异常调速
    "TargetTemperatureCelsius": 85, // 当前调速目标值，默认配置节能模式目标值
    "MaxAllowedTemperatureCelsius": 103,    // 目标调速满转温度
    "TargetTemperatureRangeCelsius": [      // 目标温度允许范围
      50,
      95
    ],
    "ThresholdValue": [],       // 告警阈值，用于告警调速，不需要告警调速不配即可
    "AlarmSpeed": [],           // 告警调速对应的转速，不需要告警调速不配即可
    "SmartCoolingTargetTemperature": [  // 节能/性能/安静 三种模式下的目标温度值，不需要区分的话不配即可
      90,
      85,
      95
    ],
    "CustomSupported": true,    // 是否支持自定义目标温度
    "CustomTargetTemperatureCelsius": 85,   // 用户自定义的目标温度
    "SensorName": "#/ThresholdSensor_CPU1CoreRem.SensorName"    // 传感器名称
}

TemperatureType	含义
1	Cpu
2	Outlet
3	Disk
4	Memory
5	PCH
6	VRD
7	VDDQ
8	NPUHbm
9	NPUAiCore
10	NPUBoard

TemperatureInfo

TemperatureInfo主要用于web界面整机温度海洋的显示，提供服务器机箱温度传感器前面板与后面板的三维热力图，以及对应传感器状态与告警信息，其中温度点横坐标、温度点纵坐标、告警状态、告警阈值下限、温度点名称、温度值、传感器状态、告警阈值上限皆由CSR配置定义。当正确配置相关属性后，web整机温度海洋界面将生成一个温度点信息。基础板主要包含以下五个温度点：

1、CPU核温（CPU1、CPU2）

2、内存温度（CPU1对应的内存温度、CPU1对应的内存温度）

3、主板板温

Interface/Private	属性/方法	描述	是否由CSR配置
Private	Name	温度点名称，用于温度海洋界面对应温度点的传感器名称显示	是
Private	ReadingValue	温度值	是
Private	UpperThreshold	告警阈值上限，高于该阈值会触发告警	是
Private	LowerThreshold	告警阈值下限，低于该阈值会触发告警	是
Private	Status	传感器状态	是
Private	Health	告警状态,与传感器Health属性一致	是
Private	CoordinateX	温度点横坐标	是
Private	CoordinateY	温度点纵坐标	是

配置样例：

json

"TemperatureInfo_1_1": {
  "Name": "#/ThresholdSensor_CPU1CoreRem.SensorName", // 温度传感器名称,应引用对应传感器的SensorName
  "ReadingValue": "<=/CPU_1.TemperatureCelsius",      // 温度值
  "Status": "<=/CPU_1.TemperatureCelsius;<=/Scanner_PowerGood.Value |> expr(($2 == 0) ? 2 : ($1 > 255 ? 2 : 0))", // 链路状态
  "Health": "<=/ThresholdSensor_CPU1CoreRem.Health",  // 传感器健康状态，Ok-健康，Minjor-有一般告警，Major-有严重告警,Critical-有紧急告警
  "UpperThreshold": [ // 告警值上限
    105, //与对应温度点的传感器的一般事件上限UpperNoncritical，轻微级别告警的门限Condition保持一致
    110, //与对应温度点的传感器的严重事件上限UpperCritical，严重级别告警的门限Condition保持一致
    255 //与对应温度点的传感器的紧急事件上限UpperNonrecoverable，紧急级别告警的门限Condition保持一致
  ],
  "LowerThreshold": [ // 告警值下限
    255, //与对应温度点的传感器的一般事件下限LowerNonCritical，轻微级别告警的门限Condition保持一致
    255, //与对应温度点的传感器的严重事件下限LowerCritical，严重级别告警的门限Condition保持一致
    255 //与对应温度点的传感器的紧急事件下限LowerNonrecoverable，紧急级别告警的门限Condition保持一致
  ],
  "CoordinateX": 12,  // 温度点横坐标
  "CoordinateY": 15   // 温度点纵坐标
}

3.4.6 CPU管理

PCIe设备管理

Interface/Private	属性/方法	描述	是否由CSR配置
bmc.kepler.Systems.PcieAddrInfo	Segment	多PCI Bridge场景的编号，每一个Segment对应一个PCI Bus空间	是
bmc.kepler.Systems.PcieAddrInfo	GroupID	逻辑组ID	是
bmc.kepler.Systems.PcieAddrInfo	SlotID	【PCIe设备的槽位号】	是
bmc.kepler.Systems.PcieAddrInfo	SocketID	【CPU ID】 1、0：CPU1； 2、1：CPU 2	是
bmc.kepler.Systems.PcieAddrInfo	Bus	root port Bus号	是
bmc.kepler.Systems.PcieAddrInfo	Device	root port Device号	是
bmc.kepler.Systems.PcieAddrInfo	Function	root port Function号	是
bmc.kepler.Systems.PcieAddrInfo	ComponentType	部件类型与Component类的中的部件类型属性对应，根据Riser卡对接的下级单板来决定（标准定义，如：8:PCIe标卡、13:NCI卡、71:SAS、83:OCP卡）	是
bmc.kepler.Systems.PcieAddrInfo	ControllerIndex	PCIe控制器索引，CPU内部同类型控制器的索引，从0开始编号	是
bmc.kepler.Systems.PcieAddrInfo	ControllerType	【PCIe控制器类型】 0：PCIeCore； 1：NIC； 2：SAS； 3：SATA， 4：ZIP； 5：SEC	是
Private	Location	PCIe槽位所在的位置，单板类型+槽位号	是
Private	ContainerUID	【容器UID】	是
Private	ContainerUnitType	【容器单板类型】	是
Private	GroupPosition	对象主键，同一个CSR里配置命名不能重复	是

json

"PcieAddrInfo_NIC_1": {
  "Segment": 0,       // 多PCI Bridge场景的编号，每一个Segment对应一个PCI Bus空间
  "GroupID": 1,       // 逻辑组ID
  "SlotID": 1,        // PCIe设备的槽位号
  "SocketID": 0,      // 0-CPU1，1-CPU2
  "Bus": 52,          // root port Bus号
  "Device": 0,        // root port Device号
  "Function": 0,      // root port Function号
  "Location": "CpuBoard${Slot}", // PCIe槽位所在的位置
  "ComponentType": 13,// 部件类型，与Component类的中的部件类型属性对应。（标准定义，如：8-PCIe标卡、13-NCI卡、83-OCP卡）
  "ControllerIndex": 0,// PCIe控制器索引，CPU内部同类型控制器的索引，从0开始编号
  "ControllerType": 1, // PCIe控制器类型（0-PCIeCore，1-NIC，2-SAS，3-SATA，4-ZIP，5-SEC）
  "ContainerUID": "00000001020302031825", // 容器UID
  "ContainerUnitType": "BCU", // 容器单板类型
  "GroupPosition": "PcieAddrInfo_NIC_1_${GroupPosition}" // 对象主键，同一个CSR里配置命名不能重复
}

CPU占用率管理

Interface/Private	属性/方法	描述	是否由CSR配置
bmc.kepler.Systems.Processor.ProcessorMetrics	BandwidthPercent	CPU占用率	是
bmc.kepler.Systems.Processor.ProcessorMetrics	BandwidthThresholdPercent	CPU占用率门限	是

json

"CPUMetrics_1": {
  "BandwidthPercent": 255,    // CPU占用率
  "BandwidthThresholdPercent": 100    // CPU占用率门限
}

内存占用率管理

Interface/Private	属性/方法	描述	是否由CSR配置
bmc.kepler.Systems.Memory.MemoryMetrics	BandwidthPercent	CPU占用率	是
bmc.kepler.Systems.Memory.MemoryMetrics	BandwidthThresholdPercent	CPU占用率门限	是

json

"MemoryMetrics_1": {
  "BandwidthPercent": 255,    // 内存占用率
  "BandwidthThresholdPercent": 100    // 内存暂用率门限
}

BTC管理

Interface/Private	属性/方法	描述	是否由CSR配置
	BTCMode	BTC通道类型	是

json

"BTCChannelMode_BT": {
  "BTCMode": "#/Accessor_BTCChannelMode.Value"    // BTC通道类型
}

VGA管理—

属性/方法	描述	是否由CSR配置
Slot	槽位号	是
DeviceType	Device类型	是
Chip	切换前后VGA接口	是

json

"DeviceChip_VGADftSwitch": {
  "Slot": 0,          // 槽位号
  "DeviceType": 1,    // Device类型
  "Chip": "#/Accessor_VGADftSwitch.Value" // 切换前后VGA接口
}

拓扑检测管理

属性/方法	描述	是否由CSR配置
Type	线缆检测类型	是
Slot	基础板BCU槽位号	是
RefSmcChip	使用的的smc	是

json

"BusinessTopoNode_1": {
  "Type": "Compute",  // 线缆检测类型
  "Slot": "${Slot}",  // 基础板BCU槽位号
  "RefSmcChip": "#/Smc_CpuBrdSMC" // 使用的的smc
}

下行连接器

属性1	属性2	取值举例	默认值	是否必选	属性描述
Name	/	"Down_1"	""	是	连接器名称
Direction	/	"Downstream"	""	是	表示下行连接器
BCUIndex	/	1	1	是	考虑多基础板场景,1表示主板，2表示从板
Slot	/	1	0	是	对于基础板中的UBC下行连接器无意义
LinkWidth	/	"X8"	""	是	连接器pcie链路宽度
MaxLinkRate	/	"PCIe5.0"	""	是	连接器支持的最大pcie规范
ConnectorType	/	"UBC"	""	是	连接器类型
UpstreamResources	Name	"Serdes_0_1_A"	[]	是	下行连接器对应Serdes的名称，下行连接器根据该属性匹配对应的Serdes资源
	ID	255	0	否	不用做匹配
	Offset	0	0	否	不用做匹配
	Width	4	0	否	下行连接器对应的Serdes，pcie链路宽度。
Ports	Name	"A1a"	""	是	UBC端口名称
	ID	1	0	是	用于线缆检测，ID与硬件命令字定义一致
	Offset	0	0	是	不用做匹配
	Width	8	0	是	UBC端口pcie链路宽度

json

"BusinessConnector_CPU0UBC1": {
  "Name": "Down_1",            //下行连接器名称
  "Direction": "Downstream",   //表示下行连接器
  "BCUIndex": "${Slot}",       //Slot为1表示主板，Slot为2表示从板
  "Slot": 1,                   //对于基础板中的UBC下行连接器无意义
  "LinkWidth": "X8",           //连接器的pcie链路宽度
  "MaxLinkRate": "PCIe 5.0",   //连接器支持的最大pcie规范
  "ConnectorType": "UBC",      //连接器类型，UBC连接器
  "SilkText": "CPU0 UBC1",     //连接器丝印
  "UpstreamResources": [       //关联的Serdes资源
    {
        "Name": "SerDes_0_0_U",   //Serdes资源名称
        "ID": 0,                  //无需关注
        "Offset": 0,              //无需关注
        "Width": 4                //Serdes的pcie链路宽度
    },
    {
        "Name": "SerDes_0_1_U",
        "ID": 1,
        "Offset": 0,
        "Width": 4
    }
  ],
  "Ports": [                        //关联的UBC端口信息
    {
      "Name": "A1a",            //UBC端口名称
      "ID": 1,                  //用于线缆检测，ID与硬件命令字定义一致
      "Offset": 0,              //无需关注
      "Width": 8                //UBC端口pcie链路宽度
    }
  ]
}

Serdes

属性1	属性2	取值举例	默认值	是否必选	属性描述
Name	/	"SerDes_0_1_A"	""	是	Serdes资源名称
ID	/	1	0	是	Serdes的Id
SocketID	/	0	0	是	Serdes对应的ChipId
LinkWidth	/	4	0	是	Serdes对应的pcie链路宽度
WorkMode	/	1	0	是	Serdes模式，NONE = 0,PCIE = 1,HCCS_DMI = 2,SATA = 3,SAS = 4,CXL = 5,GBE_ETH = 6,USB = 7,GPIO = 8
ModeConfigs	Mode	1	0	是	Serdes模式，NONE = 0,PCIE = 1,HCCS_DMI = 2,SATA = 3,SAS = 4,CXL = 5,GBE_ETH = 6,USB = 7,GPIO = 8
	Device	[14,14,15,15]	[]	是	Serdes对应的ubcconfig的device
	ControllerIndex	[0,0,0,0]	[]	是	Serdes对应的PCIe控制器序号

json

"SerDes_0_1_A": {
    "Name": "SerDes_0_1_A",
    "ID": 1,
    "SocketID": 0,
    "LinkWidth": 8,
    "WorkMode": 1,
    "ModeConfigs": [
        {
            "Mode": 1,
            "Device": [
                8,
                8,
                9,
                9,
                10,
                10,
                11,
                11
            ],
            "ControllerIndex": [
                1,
                1,
                1,
                1,
                1,
                1,
                1,
                1
            ]
        }
    ]
}

3.4.7 串口管理

系统串口参数动态配置管理

对于部分机型，支持从bios菜单设置→bios自动复位→下发给cpld→bmc监听smc传递的参数值并在读到配置发生变更后进行串口参数改配

Interface/Private	属性/方法	描述	是否由CSR配置
Private	SysComId	用于支持动态配置的输入端口Id；Uart:0~15, Port:16~31(Port口换算为+16，如Port1的SysComId为17)	是
Private	RawConfigData	从硬件读到的串口参数原始数据；默认值0，表示串口参数恢复为默认配置	是

有几个系统节点需要支持串口参数动态配置，就需要配置几个UartDynamicConfig对象

json

"UartDynamicConfig_0": {
  "SysComId": 0,                                 // 用于支持动态配置的输入端口Id
  "RawConfigData": "<=/Scanner_Chan0Conf.Value"  // 从硬件读到的串口参数原始数据
}

3.4.8 日志导出

BCU FLASH日志导出

支持

Interface/Private	属性/方法	描述	是否由CSR配置
Private	Name	基础板日志名称, 一般为CpuBoardN, 其中N表示BCU板所在槽位号	是
Private	ManageChip	访问板载flash对象的器件或总线类型描述,可选:Cpld/Mcu/Hisport	是
Private	BoardLogChip	访问板载flash对象的器件或总线对象	是
Private	GetLenthCmd	获取硬件读取flash总长度命令	是
Private	SetStartPosCmd	设置硬件读取flash偏移命令	是
Private	FlashPath	Flash对象的设备树路径	是

有几个BCU组成系统节点需要支持Flash日志导出，就需要配置几个BoardRAS对象

json

"BoardRAS_1": {
  "ManageChip": "Hisport",
  "Name": "CpuBoard${Slot}",
  "GetLenthCmd": "#/Accessor_GetFlashSize.Value",
  "SetStartPosCmd": "#/Accessor_SetFlashReadPos.Value",
  "BoardLogChip": "#/SPIFlash_2"
}

3.5 装备测试策略

装备测试中涉及装备向BMC传递数据，需要依靠CSR来实现，因此需在CSR中添加装备测试项相关内容。

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号	是

json

"DftJTAG_1": {
    "Type": 2,                  // 测试类型，详见下表
    "Id": 69,                   // 装备测试项
    "DeviceNum": 1,             // 用来匹配唯一装备项
    "Slot": "${GroupId}",       // 用来匹配唯一装备项
    "ItemName": "SEU JTAG Test",// 装备项名称
    "PrompteReady": "",         // 未使用
    "PrompteFinish": "",        // 未使用
    "ProcessPeriod": 65535,     // 未使用
    "InputChip": "#/Cpld_1",
    "Channel": 2                // 检查InputChip关联chip的bypass，对应channel号
}

json

"DftVersion_CpuBoardCpldVersion": {
    "Id": 129,              // 装备测试项
    "Type": 4,              // 测试类型
    "Slot": "${GroupId}",   // 用来匹配唯一装备项
    "DeviceNum": 0,         // 用来匹配唯一装备项
    "ItemName": "Physical Led Test", // 装备项名称
    "PrompteReady": "",     // 未使用
    "PrompteFinish": "Please check the leds", 
    "ProcessPeriod": 65535, // 未使用
    "DftEnable": "#/Accessor_DftEnable.Value" // 装备模式寄存器置位，开始设置1，停止设置0
}

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

1 CSR的版本描述信息 ​

2 硬件的管理拓扑信息 ​

3 组件信息获取和管理 ​

3.1 单板信息 ​

3.1.1 主板信息 ​

3.1.2 单板上的器件 ​

SMC ​

EEPROM ​

CPLD ​

CPU ​

Connector ​

BIOS ​

Pmu ​

FRU ​

3.2 硬件资源获取 ​

3.2.1 Scanner ​

3.2.2 Accessor ​

3.2.3 DFX ​

3.2.4 SmcCmdList ​

3.3 信号处理策略 ​

中值滤波 ​

持续一致滤波 ​

二值持续一致 ​

均值防抖 ​

无防抖 ​

3.4 组件管理 ​

3.4.1 升级管理 ​

CPLD升级 ​

CSR升级 ​

MCU升级 ​

BIOS升级 ​

3.4.2 VRD管理 ​

VrdMgmt配置 ​

VrdChip配置 ​

VrdPower配置 ​

3.4.3 传感器管理 ​

门限传感器 ​

离散传感器 ​

3.4.4 告警管理 ​

3.4.5 能效管理 ​

CoolingRequirement ​

TemperatureInfo ​

3.4.6 CPU管理 ​

PCIe设备管理 ​

CPU占用率管理 ​

内存占用率管理 ​

BTC管理 ​

VGA管理— ​

拓扑检测管理 ​

下行连接器 ​

Serdes ​

3.4.7 串口管理 ​

系统串口参数动态配置管理 ​

3.4.8 日志导出 ​

BCU FLASH日志导出 ​

3.5 装备测试策略 ​

1 CSR的版本描述信息

2 硬件的管理拓扑信息

3 组件信息获取和管理

3.1 单板信息

3.1.1 主板信息

3.1.2 单板上的器件

SMC

EEPROM

CPLD

CPU

Connector

BIOS

Pmu

FRU

3.2 硬件资源获取

3.2.1 Scanner

3.2.2 Accessor

3.2.3 DFX

3.2.4 SmcCmdList

3.3 信号处理策略

中值滤波

持续一致滤波

二值持续一致

均值防抖

无防抖

3.4 组件管理

3.4.1 升级管理

CPLD升级

CSR升级

MCU升级

BIOS升级

3.4.2 VRD管理

VrdMgmt配置

VrdChip配置

VrdPower配置

3.4.3 传感器管理

门限传感器

离散传感器

3.4.4 告警管理

3.4.5 能效管理

CoolingRequirement

TemperatureInfo

3.4.6 CPU管理

PCIe设备管理

CPU占用率管理

内存占用率管理

BTC管理

VGA管理—

拓扑检测管理

下行连接器

Serdes

3.4.7 串口管理

系统串口参数动态配置管理

3.4.8 日志导出

BCU FLASH日志导出

3.5 装备测试策略