如何在新加的组件中调用general_hardware中mcu_collection

wangdong · 2026 年2 月 6 日 07:43

// 此模板仅供参考，如果不适用可以修改

问题描述

如何在新加的模块中调用general_hardware中的mcu_collection，并根据同级sr对象找到mcu_collection中对应的MCUFirmware对象

环境信息

操作系统：[如 Ubuntu 24.04]
软件版本：[如 OpenUBMC2509]
硬件配置：[如 CPU、内存等]

重现步骤

[第一步]
[第二步]
[第三步]

期望结果

知道如何跨组件调用mcu_collection

实际结果

[实际发生了什么，包含错误信息]

尝试过的解决方案

[列出您已经尝试过的解决方案及结果]

ubmc_assistant · 2026 年2 月 6 日 07:45

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

总结

要在新组件中调用 general_hardware 的 mcu_collection 并找到对应的 MCUFirmware：

添加 general_hardware 为构建依赖；
使用 mds.class.collection("MCUFirmware") 获取集合；
从同级 SR 对象提取 UID 等唯一标识；
使用 collection:find({ UID = ... }) 进行精准匹配；
确保 CSR 正确配置且系统已完成硬件发现。

核心原则：以 UID 为桥梁，跨组件共享硬件固件状态。

通过上述方法，即可实现安全、可靠地跨组件访问 MCU 固件对象，支持后续的版本查询、升级控制等操作。

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

如何在新组件中调用 `general_hardware` 中的 `mcu_collection`

在 OpenUBMC 系统中，general_hardware 是负责管理通用硬件（尤其是天池组件）的核心模块之一。其中，mcu_collection 是一个关键的对象集合，用于统一管理和访问系统中所有已发现的 MCU 及其相关固件对象（如 MCUFirmware）。以下是如何在新加的组件中正确调用 general_hardware 的 mcu_collection，并根据同级 SR 对象查找对应的 MCUFirmware 对象的完整指南。

背景说明

general_hardware：是 OpenUBMC 中用于管理各类板卡（如 Riser、DPU、PSU 等）硬件信息和固件升级的核心组件。
mcu_collection：是一个 ORM（对象关系映射）集合，集中注册了系统中所有通过硬件自发现机制识别出的 MCU 固件对象，便于统一查询与操作。
MCUFirmware：表示 MCU 的固件实体，通常在 CSR 文件中配置，并由 general_hardware 根据 SR 定义动态实例化并加入 mcu_collection。
SR（System Resource）对象：描述硬件资源的静态配置结构，通常包含 UID、BoardType 等属性，用于唯一标识一个硬件单元。

目标

在新开发的组件中：

成功引用 general_hardware 提供的 mcu_collection。
根据当前 SR 对象（如同级的 RiserCard 或 ExpBoard）信息，在 mcu_collection 中查找到对应的 MCUFirmware 实例。

实现方法

步骤 1：确保依赖已正确引入

在新建组件的 Conan 依赖或构建配置中，必须声明对 general_hardware 的依赖：

-- conanfile.txt 或 build.ini 中添加
requires = general_hardware/[version]@openubmc/stable

推荐版本：1.80.55 或更高版本，确保支持 ORM collection 查询。

步骤 2：获取 `mcu_collection` 引用

在 Lua 代码中通过 ORM 框架全局访问 MCUFirmware 的 collection：

-- 引入 MDS ORM 框架支持
local mds = require("mds")

-- 获取 MCUFirmware 的全局 collection
local mcu_collection = mds.class.collection("MCUFirmware")

mds.class.collection("MCUFirmware") 是标准方式获取 general_hardware 创建的 MCUFirmware 集合。

步骤 3：从同级 SR 对象提取匹配字段

假设你的新组件处理的是 RiserCard 类型板卡，它有一个 SR 对象名为 ExpBoard_RiserCard1，你需要从中提取可用于匹配 MCUFirmware 的字段，最常见的是：

字段	说明
`UID`	唯一标识符，用于精确匹配
`BoardType`	板卡类型
`FruId`	硬件物理标识

示例：从当前对象获取 UID：

-- 假设 self.parent 或 self.context 是当前 RiserCard 的 MDS 对象
local board_uid = self.fru_data.UID  -- 或 self.UID，根据实际字段名调整

步骤 4：在 `mcu_collection` 中查找匹配的 `MCUFirmware` 对象

使用 find 方法进行精确查找：

-- 根据 UID 查找 MCUFirmware
local target_mcu_firmware = mcu_collection:find({ UID = board_uid })

if target_mcu_firmware then
    print("✅ 找到匹配的 MCUFirmware: ", target_mcu_firmware:name())
else
    print("❌ 未找到对应 MCUFirmware，可能未注册或 UID 不匹配")
end

collection:find({ key = value }) 支持按任意字段查询，推荐使用 UID 保证唯一性。

示例：完整调用逻辑

local function get_mcu_firmware_by_board(self)
    local mds = require("mds")
    local mcu_collection = mds.class.collection("MCUFirmware")

    -- 从当前板卡对象获取 UID（示例，实际字段依对象而定）
    local board_uid = self:get_attr("UID")
    if not board_uid then
        error("Board UID is missing")
        return nil
    end

    -- 在 mcu_collection 中查找
    local target = mcu_collection:find({ UID = board_uid })
    if target then
        return target
    else
        log.warn("No MCUFirmware found for UID: " .. board_uid)
        return nil
    end
end

注意事项

生命周期同步
mcu_collection 中的对象是在系统启动时由 general_hardware 自动发现并注册的。确保查询发生在硬件发现完成之后（例如，在 initialized 回调或延迟任务中执行）。
命名空间与重命名规则
根据 SR 自描述对象重命名规则，对象名可能添加了 _${Position} 后缀（如 MCUFirmware_RiserCard1），但 UID 仍是唯一匹配依据，应优先使用 UID 而非对象名匹配。
跨组件依赖权限
需确保新组件有权访问 general_hardware 提供的 ORM 类型定义。若报错 class not found: MCUFirmware，请检查：
- 是否缺少 general_hardware 依赖
- 是否未启动 general_hardware 服务
- 是否 CSR 中正确定义了 MCUFirmware_xxx 对象

CSR 配置要求
必须在 SR 文件中正确配置 MCUFirmware 对象，例如：

{
  "MCUFirmware_IEU": {
    "UID": "00000001040302052854",
    "RefChip": "#/Chip_MCU1",
    "Address": 200,
    "BoardType": "IEU",
    "Protocol": "SMC"
  }
}

否则 general_hardware 不会创建该对象，mcu_collection 中也不会存在。

总结