添加的FruData对象和自带的FruData对象id都是1

交流互助区
1

问题描述

自己添加了一个新的FruData对象如下图：

image
image541×287 34.9 KB

一开始按照教程id填的是1，后来改成了3，但是不管设为几，最后在bmc中看到的都是1，且跟另一个FruData_Expander_0101冲突，id都为1，这是怎么回事？

image
image1062×159 4.32 KB

image
image454×110 1.89 KB

image
image304×609 8.82 KB

image
image296×603 8.62 KB

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：[如 OpenUBMC2509]

2

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

总结

问题 原因 解决方法
FruId始终显示为1 系统对1–63范围内的FruId执行自动分配，忽略配置值 将FruId设为≥64
多个FruData对象FruId冲突 多个对象落入自动分配区间，系统统一分配为1 确保FruId唯一且超出自动分配范围
配置值未生效 Overview接口中的FruId由系统注入，未读取CSR原始值 审查frudata服务初始化逻辑

建议操作：立即将FruData_Fru1的FruId改为64或更高值，并重新加载配置，然后使用lsprop验证FruId是否正确体现。

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

关于FruData对象FruId均为1的问题分析

问题描述

您在系统中添加了一个新的FruData_Fru1对象，配置的FruId为3（或1），但最终在BMC中通过lsprop查看时，其FruId显示为1。同时，该对象与已有的FruData_Expander_0101对象在FruId上发生冲突，两者均显示为1。

从提供的lsprop输出可见：

  • FruData_Fru1_0101的bmc.kepler.Systems.FruData.Overview.FruId=1
  • FruData_Expander_0101的bmc.kepler.Systems.FruData.Overview.FruId=1

尽管您在配置中指定FruId为3，但系统最终未能保留该值，而是将其统一设为1。

原因分析

1. FruId自动分配机制导致配置值被覆盖

根据知识库和文档信息，FruId的分配遵循以下规则：

FruId值范围说明：

  • 0：保留给“挂耳”（Bracket）等特殊用途；
  • 1–63：系统会自动分配FruId；
  • 64–255：使用用户配置值，不进行自动分配；
  • 默认配置为1是常见做法。

相关证据：

  • 搜索结果文档 #1 和 #9 明确指出：FruId配置为1–63时会自动分配，默认可以配为1。
  • 但一旦自动分配机制启动，实际运行时的FruId可能被系统重写为1，尤其是当系统依据加载顺序或其他逻辑统一分配时。

因此，尽管您在CSR配置中将FruId设为3，只要其值落在1–63范围内，系统仍可能将其重新映射为1，从而导致多个FruData对象冲突。

2. FruId在D-Bus接口Overview中被覆盖

从lsprop输出可以看出，两个对象的FruId均来自bmc.kepler.Systems.FruData.Overview接口：

bmc.kepler.Systems.FruData.Overview
    FruId = 1

说明：FruId的实际值可能并非直接取自CSR配置中的FruData.FruId字段，而是由系统在初始化过程中动态注入到Overview接口中的。

而该注入逻辑可能：

  • 忽略用户配置的数值；
  • 统一设置为默认值1；
  • 或根据组件类型、顺序等规则分配，但当前实现中未区分不同对象。

3. 对象命名冲突或资源协作机制影响

虽然您的对象命名为FruData_Fru1，但系统中已存在FruData_Expander_0101，如果两者都通过相同的资源协作路径（如MdbService）注册，并且未正确绑定到唯一的物理设备或EEPROM地址，则系统可能将它们视为同类设备并赋予相同的FruId。

此外，ObjectIdentifiers=["1","1","0101"] 的结构表明系统使用多级标识符，其中第二个“1”可能对应FruId字段，若此字段由系统自动生成，则无法保证与CSR中配置的一致性。

解决方案建议

:white_check_mark: 方案一：将FruId设为64及以上（推荐）

为避免系统自动分配机制干预，请将自定义FruData对象的FruId配置为64–255之间的值。

例如：

FruData_Fru1: {
    "FruId": 64,
    ...
}

:warning: 根据知识库：1–63范围内的FruId会被自动分配；64及以上才使用配置值。

这样可确保您设置的FruId不会被系统覆盖。

:white_check_mark: 方案二：验证并修复FruDataId关联关系

确保Fru对象正确引用FruData实例：

Fru_Expander_0101 {
    "FruDataId": "#/FruData_Expander_0101"
}

若多个Fru对象引用了相同或错误的FruDataId，可能导致元数据混淆，进而使FruId重复。

:white_check_mark: 方案三：检查ObjectIdentifier唯一性

确认ObjectIdentifiers字段在整个系统中唯一，避免不同对象拥有相同路径标识。可通过修改辅助字段（如GroupID、AuxId）确保唯一性。

:white_check_mark: 方案四：排查系统是否强制统一FruId

检查系统是否存在如下情况：

  • 初始化脚本或FRU服务对特定类型的板卡（如BMC、Expander）硬编码FruId=1；
  • 使用了默认模板（如FruData_Template）导致所有对象继承相同属性。

可通过查看frudata组件的日志或源码中Update、GenerateFruId等方法确认逻辑。

参考依据

来源 内容
搜索结果#1, #9 “fruid配置为1-63会自动分配fruid，默认可以配为1”
“fruid为0保留给挂耳，配置64-255不会进行fruid分配”
知识图谱FruId实体 “有效FruId范围：1–63为自动分配；64–255为非标准/保留用途”
关系 FruId → bmc.kepler.Systems.FruData.Overview FruId作为Overview接口属性，是运行时暴露的最终值，可能与配置值不同

总结

问题 原因 解决方法
FruId始终显示为1 系统对1–63范围内的FruId执行自动分配，忽略配置值 将FruId设为≥64
多个FruData对象FruId冲突 多个对象落入自动分配区间，系统统一分配为1 确保FruId唯一且超出自动分配范围
配置值未生效 Overview接口中的FruId由系统注入，未读取CSR原始值 审查frudata服务初始化逻辑

建议操作：立即将FruData_Fru1的FruId改为64或更高值，并重新加载配置，然后使用lsprop验证FruId是否正确体现。

3

fruid是工具position进行分配的，position不一样就会分配不一样的fruid，想深入了解的话看一下frudata初始化流程代码