SMCDfxInfo能否配置多个对象

背景:新机型有1P与2P,继承天池SMC,但是不继承主板SR加载,1P和2P共包。希望配置一个CPUBoard/MainBoard,然后关联两个虚拟连接器,用于区分1P和2P的CPU相关传感器以及告警。

目前发现CPU很多信息依赖smcdfx进行获取,但是引用不能跨SR。想确认下DFXInfo配置同一个Offset的多个类,会不会有问题?
比如都是读CPUBoard的DFXInfo,MainBoard上读取一些公共的内容,在2P上读取所有CPU相关的信息,在1P上读取CPU1的相关信息,这样是否可行?

答案内容由AI生成,仅供参考:

总结

虽然技术上可能实现相同Offset的多SmcDfxInfo配置,但不推荐这样做。更好的做法是:

  • 使用不同的Offset对应不同类型的读取需求
  • 通过合理的Config和Mapping设计实现数据分发
  • 利用虚拟连接器的属性差异实现1P/2P识别

这种架构更稳定、可维护性更好,也符合openUBMC的最佳实践。

点击此处查看详细分析解答

SmcDfxInfo 配置多个对象的可行性分析

根据您的需求,您希望在新机型的1P与2P配置中共用一个CPUBoard/MainBoard,并通过虚拟连接器区分不同CPU的传感器和告警信息。同时,您关心是否可以在同一Offset上配置多个SmcDfxInfo对象来分别获取公共信息和特定CPU信息。

SmcDfxInfo 多对象配置能力

结论:支持配置多个SmcDfxInfo对象,但需要遵循特定规则。

系统完全支持配置多个SmcDfxInfo对象,这在实际应用中很常见。例如,在扩展板上有:

  • SmcDfxInfo_ExuSensor:用于读取载板传感器信息
  • SmcDfxInfo_EXU:用于读取RTC信息

这两者可以同时存在并正常工作。

同一Offset的多对象配置问题

对于"配置同一个Offset的多个类"这一具体问题,需要谨慎处理:

:white_check_mark: 支持的场景

  • 不同Offset,不同功能:多个SmcDfxInfo对象使用不同的Offset(即不同的SMC命令字)是标准做法。
  • 相同Chip,不同Offset:多个SmcDfxInfo对象指向同一个Chip但不同Offset是完全允许的。

:warning: 潜在风险

配置相同Offset的多个SmcDfxInfo对象可能存在以下问题:

  1. 资源竞争:多个对象同时尝试访问同一硬件地址可能导致冲突
  2. 数据一致性:难以保证各对象获取的数据同步性
  3. 版本校验冲突:如果各对象配置了不同的版本要求,可能导致预期外的行为

推荐解决方案

针对您的1P/2P架构需求,建议采用以下方案:

方案一:分层式SmcDfxInfo配置

"SmcDfxInfo_MainBoard": {
  "Chip": "#/Smc_CpuBrdSMC",
  "Offset": 4000,           // 公共信息偏移量
  "Size": 16,
  "Period": 1000,
  "SmcVersion": 1,
  "Config": { /* 公共配置 */ }
},
"SmcDfxInfo_CPU1": {
  "Chip": "#/Smc_CpuBrdSMC",
  "Offset": 4100,           // CPU1专用偏移量
  "Size": 8,
  "Period": 500,
  "SmcVersion": 1,
  "Config": { /* CPU1配置 */ }
},
"SmcDfxInfo_CPU2": {
  "Chip": "#/Smc_CpuBrdSMC",
  "Offset": 4108,           // CPU2专用偏移量
  "Size": 8,
  "Period": 500,
  "SmcVersion": 1,
  "Config": { /* CPU2配置 */ }
}

方案二:统一SmcDfxInfo + 虚拟连接器区分

使用单个SmcDfxInfo读取所有CPU信息,然后通过虚拟连接器的Mapping表达式进行逻辑分割:

"SmcDfxInfo_AllCPUs": {
  "Chip": "#/Smc_CpuBrdSMC",
  "Offset": 4100,
  "Size": 16,
  "Period": 500,
  "SmcVersion": 1,
  "Config": {
    "1": {"cpu1_temp": 255},
    "2": {"cpu1_volt": 255},
    "3": {"cpu2_temp": 255},
    "4": {"cpu2_volt": 255}
  },
  "Mapping": {
    "Scanner_CPU1_Temp_1P": {
      "Value": "expr($cpu1_temp)"
    },
    "Scanner_CPU2_Temp_2P": {
      "Value": "expr($cpu2_temp)"
    }
  }
}

实施建议

  1. 避免重复Offset:尽量为不同功能的SmcDfxInfo分配不同的Offset
  2. 版本兼容性:确保所有SmcDfxInfo的SmcVersion要求一致或兼容
  3. 周期设置:合理配置Period参数,不应小于200ms
  4. Config映射:确保Config中的字段定义与Mapping中的引用一一对应
  5. 虚拟连接器:利用虚拟连接器的SystemId、Slot等属性实现1P/2P区分

总结

虽然技术上可能实现相同Offset的多SmcDfxInfo配置,但不推荐这样做。更好的做法是:

  • 使用不同的Offset对应不同类型的读取需求
  • 通过合理的Config和Mapping设计实现数据分发
  • 利用虚拟连接器的属性差异实现1P/2P识别

这种架构更稳定、可维护性更好,也符合openUBMC的最佳实践。

配置相同的smcdfx对象会合并的,比如先加载smcdfx_1_0101,后面又有smcdfx_1_010101,这俩配置相同就会合并,合并是将Config和Mapping合并起来,Period取最小值。

配置不相同,我意思是底板smcdfx不配置CPU相关信息,然后CPU的虚拟连接器配置smcdfx,两者偏移和SMC addr一致,但是信息获取不一样。

这两个会在不同的SR里配置,意思最终在代码里会合并成一个并且不影响使用吗?

同一个器件,同一偏移的smcdfx对象就会合并。你可以看下一键收集里AppDump/hwproxy/smcdfx_info就明白了