新增芯片驱动在 hwdiscovery 中未被识别的问题分析与解决方案

根据您提供的问题描述、环境信息以及上下文中的知识图谱和文档内容，以下是针对 “新增芯片驱动在 hwdiscovery 中未被识别” 的全面分析与解决方案。

问题核心总结

• 现象：

  • 在 component_drivers 中新增了 I2C 芯片驱动并生成 .so 文件。
  • 在 CSR（Component Self-Description Record）文件中配置了新芯片对象（例如 Sgm58031_1）。
  • hwdiscovery 加载 SR/CSR 文件时，日志提示 get class information failed，导致该对象被忽略。
  • 最终 devmon 也未能创建该驱动的 D-Bus 对象路径，无法使用。

• 关键错误日志：

  hwdiscovery WARNING: analyse.lua(54): ignore object: Sgm58031_1_01, class: Sgm58031, error: get class information failed
  

• 根本原因：

  hwdiscovery 在加载 .sr 文件时，必须能识别 CSR 配置中对象的 类名（class），否则会因找不到类信息而跳过该对象。

  这通常是因为：尽管已在 component_drivers 添加了驱动代码，但 hwdiscovery 并不知道该类的存在，缺乏对新类的注册或定义支持。

组件职责说明（关键背景）

组件	功能	是否处理 component_drivers 驱动
component_drivers	提供底层芯片和设备驱动实现（C++/Lua），编译为 .so 文件供上层使用	是驱动来源
hwdiscovery	硬件自发现服务，负责扫描 .sr 文件、解析 CSR 数据、创建初始 D-Bus 对象树	不直接加载 component_drivers 中的驱动 但需理解 CSR 中的对象“类”
devmon	真正加载 component_drivers 驱动的组件 仅处理 FormatVersion 为 5.00 的 CSR 文件	会根据 CSR 中的类名查找驱动并启动

重要区别：

• hwdiscovery 负责 对象发现与注册 → 需要认识“类”
• devmon 负责 驱动加载与运行 → 需要 .so 驱动存在且 CSR 格式正确

正确解决方案

解决方案一：确保 hwdiscovery 认识新类（解决 get class information failed）

这是当前失败的根本原因。

即使你在 component_drivers 编写了驱动，若 hwdiscovery 未知该类，它会在解析 .sr 文件时 丢弃该对象，后续 devmon 也就无从加载。

步骤如下：

1. 确认新类已在 hwdiscovery 的类定义系统中注册

   在 OpenUBMC 架构中，hwdiscovery 使用一个 类信息数据库 或 类型定义机制（如 JSON Schema、IDL 定义等）来验证 CSR 中的对象类别。

   • 检查项目中是否存在类似以下路径的类定义文件：

     /path/to/hwdiscovery/classes/Sgm58031.json
     

     或

     {
       "class": "Sgm58031",
       "properties": [
         { "name": "Address", "type": "int" },
         { "name": "Bus", "type": "string" }
       ]
     }
     

2. 将新类添加到 hwdiscovery 可识别类列表中

   如果没有上述定义，请联系架构维护者或参考其他已有芯片类（如 Pca9555、Tps546c0）进行仿写并提交至 hwdiscovery 项目。

3. 更新 manifest.yml 确保依赖正确

   dependencies:
     - conan: component_drivers/1.2.94@openubmc/stable
   

   确保构建系统能将 component_drivers 的头文件或类型定义也提供给 hwdiscovery。

解决方案二：必须使用 FormatVersion: 5.00 的 CSR 文件

devmon 只会加载 FormatVersion 为 5.00 的 CSR 配置。

虽然 hwdiscovery 支持 3.00 及以上版本，但 devmon 仅处理 5.00。

步骤如下：

1. 修改你的 .sr 文件头部：

   {
     "FormatVersion": "5.00",
     "DataVersion": "5.00",
     "Components": {
       "Sgm58031_1": {
         "Class": "Sgm58031",
         "Address": 146,
         "Bus": "I2C_01"
       },
       "Scanner_P3V3": {
         "Chip": "#/Sgm58031_1",
         "Offset": 0,
         "Type": 0
       }
     }
   }
   

2. 把 .sr 文件放入：

   /opt/bmc/sr/
   

   并确认在设备启动时正确加载。

解决方案三：确保 .so 驱动正确构建并可被 devmon 找到

检查事项：

1. 驱动库名是否与 CSR 中类名一致？

   • 若类名为 Sgm58031，则期望生成的库为：

     libSgm58031.so
     

   • 检查 Meson 构建脚本是否正确定义：

     shared_library(
       'Sgm58031',
       sources: ['sgm58031.cpp'],
       include_directories: include_dir,
       dependencies: [driver_base_dep]
     )
     

2. 部署后是否存放在目标系统路径？

   /usr/lib/component_drivers/libSgm58031.so
   

3. 是否有权限问题？

   ls -l /usr/lib/component_drivers/libSgm58031.so
   # 应为 -rwxr-xr-x
   

当前误解纠正

问题：“是否要在 component_drivers 的 CSR 中配置传感器信息？”

正确认知：

• component_drivers 是驱动代码存放地，不是 CSR 存放地。
• CSR 文件应存放在：

  /opt/bmc/sr/
  

• component_drivers 仅提供 .so 驱动文件，不负责加载或解析 CSR。
• devmon 才是加载 CSR + 驱动的组件。

验证方法

1. 检查 hwdiscovery 是否识别类

重启后查看日志：

journalctl -u hwdiscovery | grep -i "Sgm58031"

预期输出：

NOTICE: hwcomponent.lua: load sr data successfully...
NOTICE: sdr.lua: position: xxx, get objects, count: xx

不再出现：

WARNING: analyse.lua: ignore object: Sgm58031... get class information failed

2. 检查 devmon 是否加载驱动

journalctl -u devmon | grep -i "Sgm58031"

预期输出：

INFO: devmon: loading driver for class Sgm58031
INFO: devmon: created D-Bus object at /bmc/kepler/ObjectGroup/...

3. 检查 D-Bus 是否存在对象

busctl tree bmc.kepler.devmon
# 或
dbus-send --print-reply --dest=bmc.kepler.devmon /bmc/kepler/ObjectGroup/... ...

总结建议

推荐流程整理

1. 在 component_drivers 中实现驱动代码（C++/Lua），输出 libSgm58031.so
2. 向 hwdiscovery 项目提交类定义（JSON/Schema），使其识别 Sgm58031 类
3. 编写 FormatVersion=5.00 的 .sr 文件，引用该类
4. 构建并部署到目标系统
5. 检查 hwdiscovery 和 devmon 日志是否成功加载

参考文档链接（来自知识库）

• GPU驱动规范（类结构与驱动对接方式）
• 硬盘背板开发指南（SR 文件配置示例）
• openUBMC 25.12 LTS 版本发布说明（devmon 测试覆盖增强说明）

如仍存在问题，建议：

1. 提供完整 .sr 文件片段
2. 提供 component_drivers 侧的构建 meson.build 配置
3. 提供 hwdiscovery 启动日志全段

以便进一步定位类注册或路径问题。