Altas 300V pro适配时发现的若干问题

交流互助区
1

1、Altas 300V pro适配时发现NPUCard的PartNumber、Model、Core0TemperatureCelsius、PowerState显示不符合预期

（1）PartNumber的值跟CardPartNumber的初始值一致，当CardPartNumber的值变化时，PartNumber的值不变，当把CardPartNumber的取值配置为表达式：根据BoardID来取值时，PartNumber的值永远是后面的那个值

（2）Model 固定Atlas_300I_Pro可以获取BoardID 其他写法获取不到(表达式或者写死Atlas_300V_Pro都不行)

（3）Core0TemperatureCelsius的值 Altas 300V pro下电后的值不会变成默认值255，Altas 300I pro可以

（4）PowerState的值 BMC重启后 无论OS是上电状态还是下电状态 都是0 重启OS也不变，只有下电再上电后才会变成1

2、Altas 300V pro和Altas 300I pro四元组一致，只能通过BoardID区分，但是NPUCard.BoardID的options属性配置为"emitsChangedSignal": “false”，这样就导致表达式中使用BoardID时不能多参数使用，这个地方能不能修改为true？

image
image428×195 4.15 KB

2

答案内容由AI生成，仅供参考：

:white_check_mark: 总结与建议

问题 根本原因 推荐解决方案
PartNumber 不随 CardPartNumber 更新 静态绑定，未支持动态刷新 使用表达式直接赋值 PartNumber，避免依赖中间变量
Model 必须为 Atlas_300I_Pro 才能识别 固件硬编码判断 暂用兼容名，推动社区支持多型号注册
Core0TemperatureCelsius 不重置为 255 MCU 未清除状态缓存 BMC 主动监听电源状态并设置默认值
PowerState 重启 BMC 后为 0 缺少状态同步机制 BMC 启动时强制轮询一次 NPU 状态
BoardID 不触发变更信号 emitsChangedSignal: false 修改 Schema 设为 true 或使用独立标识对象
点击此处查看详细分析解答

Atlas 300V Pro NPU卡适配问题分析与解决方案

根据您在适配 Atlas 300V Pro NPU卡过程中发现的问题，结合知识库中的信息，以下是对各项异常现象的分析、原因说明以及可能的解决建议。

:wrench: 一、NPUCard属性显示异常问题

1. PartNumber 与 CardPartNumber 不同步

:white_check_mark: 问题描述：

  • PartNumber 的值始终等于 CardPartNumber 的初始值。
  • 当 CardPartNumber 被配置为动态表达式（如根据 BoardID 判断）时，PartNumber 始终取表达式的“后面”值，无法实时更新。

:pushpin: 根本原因：

  • 在 OpenUBMC 的实现中，PartNumber 是从 PCIe 卡的 FRU 数据中提取的硬件属性，通常来自 EEPROM 或 VPD 配置。
  • 而 CardPartNumber 是 CSR（Component Schema Repository）配置中用于逻辑定义的字段。
  • 两者绑定关系可能是 静态映射 或依赖于对象初始化顺序。一旦初始化完成，PartNumber 不会随 CardPartNumber 动态变化而刷新。

:white_check_mark: 解决建议：

  • 避免依赖 CardPartNumber 的动态表达式来驱动 PartNumber。
  • 若需动态显示部件号，应确保：
    • 将 PartNumber 直接配置为表达式，例如：
      "PartNumber": "#/NPUCard_1.BoardID |> expr($1 == 175 ? '03028DFH' : '02314RAL')"
    • 或通过 Lua 脚本在运行时更新对应 D-Bus 属性。
  • 检查 fru-tool 是否支持动态读取并注入 FRU 数据。

2. Model 字段必须写死为 Atlas_300I_Pro 才能获取 BoardID

:white_check_mark: 问题描述：

  • 只有当 Model 设置为 Atlas_300I_Pro 时，才能正确读取 BoardID。
  • 使用表达式或直接写 Atlas_300V_Pro 均无法获取 BoardID。

:pushpin: 根本原因：

  • OpenUBMC 的 NPU 卡识别机制对 Model 值存在 硬编码匹配逻辑，尤其是在带外管理或驱动加载阶段。
  • 系统可能将 Model == "Atlas_300I_Pro" 作为加载特定 MCU 通信协议或初始化路径的判断条件。
  • Atlas_300V_Pro 的管理固件可能是闭源组件，未适配非标准 Model 名称。

:white_check_mark: 解决建议：

  • 临时方案：保持 Model 为 Atlas_300I_Pro，在更高层（如 Redfish 接口、Web UI）通过 BoardID 映射显示真实型号。
  • 长期方案：
    • 提交 issue 至 OpenUBMC 社区，请求支持动态 Model 配置。
    • 添加新的 Model 白名单到 devmon 或 compute_service 的配置文件中。
    • 参考文档 Atlas 中心推理卡 带外管理接口说明 检查是否需注册新设备类型。

3. Core0TemperatureCelsius 下电后不恢复为默认值 255

:white_check_mark: 问题描述：

  • Atlas 300V Pro 在 OS 下电后，Core0TemperatureCelsius 不变为默认值 255（表示无效读数）。
  • Atlas 300I Pro 可正常重置。

:pushpin: 根本原因：

  • 温度传感器数据由带外管理 MCU 上报，其行为受 MCU 固件控制。
  • MCU 固件未在断电后清空缓存温度值或未触发状态重置。
  • 可能是 Atlas 300V Pro 的 MCU 固件版本（如 24.5.9）存在状态保持缺陷。

:white_check_mark: 解决建议：

  • 确认 MCU 是否支持断电状态通知机制，并在 BMC 侧监听电源事件（PowerState 变化），主动将温度设为 255。
  • 在 Lua 脚本中增加事件监听逻辑，例如：
    if power_state == 0 then
    core0_temp = 255
end
  • 升级 MCU 固件至最新版本。
  • 提交 bug 报告至 hardware-sig 成员，请求统一行为规范。

4. PowerState 重启 BMC 后始终为 0，需重新上下电才恢复为 1

:white_check_mark: 问题描述：

  • BMC 重启后，无论 OS 是否运行，PowerState 均为 0。
  • 仅当物理下电再上电后，才会变为 1。

:pushpin: 根本原因：

  • PowerState 属性来源于 带外管理 MCU 的实时状态上报，而非平台全局电源状态。
  • BMC 重启后，若未触发对 NPU 卡的主动探测流程，MCU 状态未被重新拉取。
  • 缺乏“冷启动状态同步”机制，导致缓存状态丢失或未初始化。

:white_check_mark: 解决建议：

  • 在 BMC 启动流程中，强制触发一次 NPU 卡状态同步请求（如调用 GetPowerSupplyInfo 或专用带外命令）。
  • 确保 bmc.dev.NPUCard 接口的 PowerState 支持 emitsChangedSignal 并监听 PowerOn 系统事件。
  • 可通过定时器机制，在 BMC 启动 10 秒后轮询一次所有 NPUCard 的状态。
  • 参考 compute_service 是否实现了电源事件订阅机制。

:repeat_button: 二、BoardID 属性信号未启用 emitsChangedSignal 的问题

:white_check_mark: 问题描述：

  • NPUCard.BoardID 的配置为：
    "BoardID": {
  "baseType": "U16",
  "readOnly": true,
  "options": {
    "emitsChangedSignal": "false"
  },
  "description": "NPU卡的board id",
  "default": 0
}
  • 导致在表达式中无法利用 BoardID 做动态判断（特别是多参数联动场景）。

:pushpin: 根本原因：

  • emitsChangedSignal: false 意味着该属性变更时 不会触发 D-Bus 属性变更信号。
  • 因此，依赖该属性的其他表达式或监听器 不会重新计算或响应更新，造成“死值”问题。

:white_check_mark: 解决建议：

:white_check_mark: 方案一：修改 Schema 配置（推荐）

  • 将 emitsChangedSignal 改为 true：
    "options": {
  "emitsChangedSignal": true
}
  • 影响范围：
    • 所有监听 BoardID 的对象将收到变更通知。
    • 表达式引擎会重新评估依赖项。
  • :warning: 注意：
    • 需确认 MCU 上报 BoardID 是 只读且仅在初始化时设置一次，否则频繁变更可能导致性能问题。
    • 修改后需重新生成代码（bmcgo gen）并验证 D-Bus 信号行为。

:white_check_mark: 方案二：外挂事件处理脚本

  • 使用 Lua 脚本定时读取 BoardID，并主动触发相关属性刷新：
    local board_id = dbus.get_property("/bmc/kepler/Systems/1/NPUCards/NPUCard_1", "BoardID")
if board_id == 175 then
    dbus.set_property("/bmc/kepler/Systems/1/NPUCards/NPUCard_1", "ModelDisplayName", "Atlas 300V Pro")
end

:white_check_mark: 方案三：使用独立标识对象

  • 如 搜索结果 #2 所述，可新建一个专用对象专门用于区分三款卡（300I Pro / 300V / 300V Pro）：
    "AtlasCardIdentifier": {
  "BoardID": 175,
  "CardType": "Atlas_300V_Pro"
}
  • 该对象可通过 VPD 中 BoardID 初始化，并对外暴露 CardType 供表达式使用，规避原属性限制。

:white_check_mark: 总结与建议

问题 根本原因 推荐解决方案
PartNumber 不随 CardPartNumber 更新 静态绑定，未支持动态刷新 使用表达式直接赋值 PartNumber，避免依赖中间变量
Model 必须为 Atlas_300I_Pro 才能识别 固件硬编码判断 暂用兼容名，推动社区支持多型号注册
Core0TemperatureCelsius 不重置为 255 MCU 未清除状态缓存 BMC 主动监听电源状态并设置默认值
PowerState 重启 BMC 后为 0 缺少状态同步机制 BMC 启动时强制轮询一次 NPU 状态
BoardID 不触发变更信号 emitsChangedSignal: false 修改 Schema 设为 true 或使用独立标识对象

:envelope: 后续行动建议

  1. 提交 Issue 到 OpenUBMC 社区：

    • 标题示例：[Bug] NPUCard PowerState not sync after BMC reboot
    • 包含日志、CSR 配置片段、复现步骤。

  2. 联系 hardware-sig 成员：

    • 请求支持 Atlas_300V_Pro 的正式型号注册和 MCU 通信协议开放。

  3. 升级 firmware 和 MCU 版本：

    • 当前系统固件版本为 7.5.0.5.220，可尝试升级至 7.7.x 或更高版本以修复显示问题。

  4. 参考文档：

如有进一步日志或 CSR 配置文件，可继续提供以深入分析。

3

这个问题通过升级MCU固件已经解决

4

1、
（1）PartNumber当前未同步CSR，只会在启动阶段代码主动同步一次CardPartNumber的值
（2）当前只适配了Atlas_300I_Pro，新卡都需要代码适配
（4）确定一下compute版本是什么，当前最新sdk版本，会启动监听后主动读一次当前状态，预期会与实际的后电状态保持一致
2、该改动建议上hardware-sig进行评审

综上，相关闭源代码，建议上hardware-sig进行评审后，通过issue的方式提诉求支持

6

compute版本为1.92.8，实测问题仍然存在

7

麻烦提供一下具体测试的时候的操作和日志，我们看一下具体什么时候没有更新上。