求助，component_drivers仓新增网卡适配

[mahuihui]

问题描述

本人想适配一张新网卡，但对bmc相关技术栈了解不多，目前仅完成了环境搭建以及qemu添加网卡的操作，因此有一些开发问题需要请教大家。

查阅论坛推荐使用component_drivers仓添加新网卡适配，阅读该组件的doc大致了解如何新增网卡，希望帮忙确认开发步骤是否有误和遗漏：

1. 添加新网卡的sr和dds文件；
2. libraries/ncsi_over_mctp 和 libraries/ncsi 添加厂商 oem 命令实现；
3. drivers/pcie_nic_card 目录下添加新网卡的驱动实现。

另外对于后续的编译以及网卡测试运行有些疑惑，希望帮忙解答：

1. component_drivers的doc文档的环境搭建是必须使用docker方式吗？与ubuntu 24.04环境搭建有区别吗？
2. 环境搭建中提到需要拉取devmon、component_drivers、libmcpp，这三个都需要执行meson的编译安装步骤吗？
3. meson执行后是否也像其他组件那样使用bingo build构建新版本在manifest.yml中引用？然后构建hpm固件真机或仿真测试？

环境信息

• 操作系统：Ubuntu 24.04

• 软件版本：git拉取的最新版本

[ubmc_assistant (openUBMC_Assistant)]

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

总结：您的开发流程建议

步骤	操作	工具/命令
1	搭建开发环境	推荐 Docker + bmc_sdk
2	添加 .sr 和 .dds 文件	放入 drivers/pcie_nic_card/<vendor>
3	实现驱动逻辑（如需）	在 drivers/pcie_nic_card 下新增
4	本地编译验证	meson setup build && ninja -C build install
5	更新 manifest 引用	修改 revision 为本地分支
6	构建固件	bingo build -sc qemu
7	QEMU 仿真测试	vemake_1711.py 启动 → AddDevice 测试
8	真机验证	烧录 HPM 包测试

关键提示：优先在 QEMU 仿真环境完成验证，再部署到真机，可大幅缩短开发周期。

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

关于 component_drivers 仓新增网卡适配的完整指导

根据您提供的问题和上下文信息，以下是针对在 component_drivers 组件仓库中完成新网卡适配的详细开发流程说明、步骤确认与常见疑问解答，结合了 openUBMC 项目的架构设计、QEMU仿真环境支持以及实际开发实践。

---

一、您的开发步骤是否正确？—— 基本正确，但需补充细节

您提出的三个核心步骤是正确的，但需要进一步细化以确保完整适配：

1. 添加 SR 和 DDS 文件（正确）

• 作用：
  • .sr 文件：静态资源（Static Resource）文件，描述 PCIe 设备的 CSR（Control and Status Register）映射关系。
  • .dds 文件：Device Driver Specification 文件，用于协议解析与驱动加载判断。
• 存放路径：

  component_drivers/drivers/pcie_nic_card/<vendor>/<product>/csr/<device_id>.sr
  component_drivers/drivers/pcie_nic_card/<vendor>/<product>/csr/<device_id>.dds
  

• 注意事项：
  • 确保文件命名符合规范：VendorID_DeviceID_SubVendorID_SubDeviceID.sr 或具体命名规则由 devmon 解析逻辑决定。
  • 需将该文件添加到构建系统中（如 meson.build 中注册或通过自动扫描机制纳入）。

建议参考已有的同类网卡实现（如 Mellanox、Intel E810 系列）进行模板化复制。

---

2. 实现 NCSI over MCTP 协议相关 OEM 命令（部分正确）

• libraries/ncsi_over_mctp 是 NCSI 协议在 MCTP 传输层上的封装库。
• libraries/ncsi 是底层 NCSI 协议处理模块。

是否需要添加 OEM 命令？

• 仅当您的网卡支持厂商自定义命令时才需要扩展。
• 若为标准 NCSI 功能（Link Status、MAC、VLAN、Stats 等），一般无需修改协议栈。
• 若有特殊功能（如固件升级、光模块诊断、节能模式等），则需：
  • 在 libraries/ncsi 中定义新的 OEM_CMD 编号。
  • 在 libraries/ncsi_over_mctp 中实现 MCTP 封装与分发。
  • 提供响应解析逻辑，并暴露接口给上层服务调用。

大部分标准网卡适配不需要修改协议库，优先验证基础通信即可。

---

3. 在 drivers/pcie_nic_card 下添加驱动实现（正确方向）

• 该目录是南向设备驱动实现的核心位置。
• 新增驱动结构应包括：

  drivers/pcie_nic_card/<vendor>/<model>/
  ├── CMakeLists.txt 或 meson.build（注册编译）
  ├── <model>_driver.cpp       # 主驱动逻辑
  ├── <model>_handler.cpp      # 协议交互逻辑（NCSI/MCTP）
  └── include/<model>_driver.h
  

• 驱动需继承通用基类（如 PcieCardBase 或 NicCardBase），并重写关键方法：
  • init()：初始化设备状态
  • probe()：探测设备是否存在
  • start() / stop()：启停控制
  • update_status()：周期性上报链路/健康状态

推荐使用 bingo create driver nic --vendor=xxx --model=yyy 模板命令（如有）快速生成骨架代码。

---

二、编译与构建流程详解

1. 环境搭建是否必须使用 Docker？与 Ubuntu 24.04 有何区别？

项目	Docker 方式	Ubuntu 24.04 原生方式
推荐程度	强烈推荐	可行但易出错
优点	环境一致性高、依赖自动管理、版本可控	启动快、调试方便
缺点	资源占用略高、需熟悉容器操作	依赖需手动安装，易版本冲突
支持情况	官方 CI/CD 和仿真推荐方式	社区支持有限，可能出现编译差异

结论：虽然可以在 Ubuntu 24.04 上直接搭建，但推荐使用 Docker 环境以避免依赖不一致问题。
openUBMC 官方通常提供标准化 Docker 镜像（如 swr.cn-north-4.myhuaweicloud.com/openbmc/qemu:latest），可确保一致性。

---

2. devmon、component_drivers、libmcpp 是否都要执行 meson 编译？

组件	是否需要单独编译？	说明
devmon	是	devmon 是核心设备发现服务，驱动依赖其加载机制
component_drivers	是	当前正在开发的目标组件，必须本地编译测试
libmcpp	是（仅首次）	提供 MCTP/PLDM 协议基础库，若有本地修改或调试需求需编译安装

建议操作流程：

# 进入各组件目录，依次执行：
meson setup build
ninja -C build
sudo ninja -C build install

注意：若使用 Conan 包管理器（常见于 QEMU 构建环境），部分库可通过 Conan 自动拉取，但本地开发建议手动安装以确保最新代码生效。

---

3. 编译完成后如何构建 HPM 固件？是否使用 bingo build？

是的，流程如下：

正确流程：

1. 修改 component_drivers 代码并本地编译验证。
2. 提交代码或打本地标签（便于 manifest 引用）。
3. 在 manifest 仓库中更新 component_drivers 的版本或 commit ID：

   components:
     component_drivers:
       repo: https://gitcode.com/openUBMC/component_drivers.git
       revision: your-local-branch-or-commit-hash
   

4. 执行整包构建命令：

   bingo build -sc qemu   # 构建用于 QEMU 仿真的固件包
   # 或
   bingo build -sc release # 构建用于真机烧录的 HPM 包
   

5. 生成的固件位于：

   out/qemu/QemuFirmwarePackage.hpm
   

支持两种测试方式：

• QEMU 仿真测试：快速验证功能，无需硬件。
• HPM 烧录真机测试：最终验证兼容性。

---

三、QEMU 仿真环境下的网卡测试建议

1. 使用 QEMU 模拟 PCIe 网卡热插拔（推荐）

您可以在运行中的 QEMU 实例中动态加载网卡仿真数据。

步骤如下：

1. 启动 QEMU：

   python3 build/works/packet/qemu_shells/vemake_1711.py
   

2. 将 .sr 文件放入 /tmp：

   cp 14140130_19e50222_19e500a1.sr /tmp/
   

3. 调用 devmon 的 D-Bus 接口添加设备：

   busctl --user call bmc.kepler.devmon /bmc/dev bmc.dev AddDevice sa{sv} "/tmp/14140130_19e50222_19e500a1.sr" 3 Position i 3 SystemId i 1 Slot i 2
   

若提示 Connector Position is not initialized，请等待 BMC 初始化完成（约 30 秒），或检查 pcie_card.json 是否正确配置了插槽映射。

---

2. 添加仿真数据（.json 和 .bin）

对于 NCSI over MCTP 的设备，还需提供仿真响应数据：

• 文件命名格式：messagetype_BDF_mctp.json
  • 示例：0x02_0x9600_mctp.json
• QEMU 会在运行时自动将其编译为 .bin 文件供仿真使用。

提示：编辑 .json 文件可实时生效（无需重启 QEMU），极大提升调试效率。

---

四、常见问题与避坑指南

问题	原因	解决方案
devmon 服务未启动	新增 .sr 文件导致解析失败	检查 .sr 文件格式是否合法；确保使用 main 分支（LTS 可能缺少南向组件）
网卡无法识别	未正确添加 .dds 或 .sr 文件	确认路径和文件名匹配 PCI ID，且被构建系统收录
Redfish 接口无数据	devmon 未上报或 NetworkAdapter 服务异常	检查 busctl tree bmc.kepler.network_adapter 是否有对象生成
QEMU 启动报错	缺少依赖或权限问题	使用 --enable-kvm 检查 CPU 支持；确认用户在 kvm 组
编译失败	Conan 包缺失或版本不匹配	查看 bmc_sdk 版本是否匹配；尝试 conan install 强制同步

---

五、推荐资源参考

资源	说明
openUBMC/qemu_mockup	QEMU 仿真数据与驱动集中管理仓库
openUBMC 25.12 LTS 发布说明	包含 QEMU 仿真优化、驱动框架增强等关键信息
QEMU 仿真与 BMC 开发指南	完整介绍如何利用 QEMU 辅助开发
Topic on Discuss.openubmc.cn（ID: 3996）	讨论了 devmon 加载 .sr 文件失败的问题及解决方法

---

总结：您的开发流程建议

步骤	操作	工具/命令
1	搭建开发环境	推荐 Docker + bmc_sdk
2	添加 .sr 和 .dds 文件	放入 drivers/pcie_nic_card/<vendor>
3	实现驱动逻辑（如需）	在 drivers/pcie_nic_card 下新增
4	本地编译验证	meson setup build && ninja -C build install
5	更新 manifest 引用	修改 revision 为本地分支
6	构建固件	bingo build -sc qemu
7	QEMU 仿真测试	vemake_1711.py 启动 → AddDevice 测试
8	真机验证	烧录 HPM 包测试

关键提示：优先在 QEMU 仿真环境完成验证，再部署到真机，可大幅缩短开发周期。

如有更多具体错误日志或现象，欢迎进一步贴出日志（如 devmon.log、journald 输出等），我可以协助深入分析。

[huangzhiyu]

怎么添加应该在component_drivers的docs目录下有相关的文档。
不用docker理论也行，docker只是隔离出一个容器。
devmon、component_drivers、libmcpp支持使用meson和bingo构建，bingo主要是编译选项不同。
manifest应该配置了，修改对应的版本号就能引用。

[mahuihui]

多谢指导，我之前在搭建的ubuntu 24.04环境上meson build失败了，再尝试用docker试试