CSR对象加载疑问

WH11003 · 2026 年4 月 8 日 03:58

问题描述

CSR配置

        "I2c_2": {
            "Chips": [
                "Smc_ExpBoardSMC",
                "Eeprom_EXU"
            ],
            "Connectors": [
                "Connector_LOM_1",
                "Connector_LOM_2"
            ]
        },

CSR对象加载日志

14271:1970-01-01 08:00:31.509847 hwproxy NOTICE: dispatch.lua(254): position: 0101, start to process objs in pre_type: Bus, topo_data[I2c_2], objs nums: 5
14272:1970-01-01 08:00:31.513031 hwproxy NOTICE: dispatch.lua(138): position: 0101, chip: Smc_ExpBoardSMC_0101, start creat predevice bus handle, pre_device: I2c_2,is main app: true, not scans: true, not buses: false
14273:1970-01-01 08:00:31.516588 hwproxy NOTICE: dispatch.lua(138): position: 0101, chip: Eeprom_EXU_0101, start creat predevice bus handle, pre_device: I2c_2,is main app: true, not scans: false, not buses: false
14274:1970-01-01 08:00:31.519873 hwproxy NOTICE: dispatch.lua(138): position: 0101, chip: Eeprom_3_6_0101, start creat predevice bus handle, pre_device: I2c_2,is main app: true, not scans: false, not buses: false

1 I2c_2总线下定义了4个obj，日志中objs nums为5，是否正常？
2 日志中I2c_2总线下多了一个Eeprom_3_6_0101的obj，是否正常？

环境信息

软件版本：OpenUBMC2512

ubmc_assistant · 2026 年4 月 8 日 04:01

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

结论

问题	是否正常	说明
`objs nums: 5` 而配置仅4个	正常	系统支持动态发现和加载设备，总数可超过CSR显式定义
出现未配置的 `Eeprom_3_6_0101`	正常	可能由Connector关联或I2C扫描动态生成，符合openUBMC自发现机制

建议：如需确认该行为是否符合预期，可通过以下方式验证：

使用 i2cdetect -y <bus_id> 手动扫描I2C总线设备地址

查看 /dump_info/AppDump/hwproxy/topology.txt 中的完整拓扑结构

检查Connector_LOM_1/LOM_2是否配置了指向Eeprom_3_6的引用关系

该行为体现了openUBMC系统的灵活性与自动化能力，无需将所有设备硬编码于CSR中，支持热插拔和动态配置场景。

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

CSR对象加载疑问分析

1. I2c_2总线下定义了4个obj，日志中"objs nums: 5"是否正常？

答案：正常。

根据系统的设计机制，在处理I2C总线下的对象时，实际处理的对象数量可能多于CSR配置中显式定义的数量。原因如下：

在CSR Configuration的描述中指出：CSR配置框架会自动发现和解析链接及设备信息以构建资源树。
文档《硬件自发现解析流程}提到，系统在初始化过程中会基于连接器（Connector）自动加载关联的EEPROM等设备。
系统中的hwdiscovery模块负责硬件发现、检测和初始化，它会在运行时动态添加对象到已定义的总线下。

因此，虽然CSR配置只显式声明了4个对象（2个Chip + 2个Connector），但系统在实际加载时可能额外添加了一个动态发现的设备（如Eeprom_3_6_0101），导致总数为5是符合预期的行为。

2. 日志中I2c_2总线下多了一个Eeprom_3_6_0101的obj是否正常？

答案：正常。

原因分析：

（1）动态对象生成机制

根据搜索结果《硬件自发现解析流程}中的说明：

“根据Connector配置于哪路总线下，对应的EEPROM也会生成在哪路总线下”
这表明：连接器（Connector）的存在会触发系统自动生成关联的EEPROM设备对象。
因此即使Eeprom_3_6_0101未在CSR中直接列出，只要系统检测到该物理设备存在且与I2c_2相连，则可由hwproxy或hwdiscovery在运行时动态创建。

（2）EEPROM合并机制

搜索结果《硬件代理总线读写接口使用方法}提到：

“硬件代理会将同一总线下同一地址的器件进行合并，避免无意义的内存消耗”
说明系统具备EEPROM对象的动态管理能力，可能通过扫描I2C总线自动识别挂载设备。

（3）日志行为符合系统设计逻辑

从日志可见：

chip: Eeprom_3_6_0101, start creat predevice bus handle, pre_device: I2c_2

此行为表明系统正在为一个位于I2c_2上的EEPROM创建前置设备句柄，属于标准流程。

（4）CSR配置与实际硬件可能存在差异

《硬件自发现解析流程}指出：

“CSR内多余的总线记录于extra_buses中…相关对象会被丢弃”
反向推断：系统允许运行时发现并加载超出CSR声明范围的合法设备，只要其符合拓扑规则。

结论

问题	是否正常	说明
`objs nums: 5` 而配置仅4个	正常	系统支持动态发现和加载设备，总数可超过CSR显式定义
出现未配置的 `Eeprom_3_6_0101`	正常	可能由Connector关联或I2C扫描动态生成，符合openUBMC自发现机制