openUBM支持多BMC芯片（海思3095和Aspeed 2600）

[yangzhun]

---

一套代码，四颗芯片：openUBMC 多 BMC 芯片支持落地实录（海思 3095 × AST2600）

从 Hi1711/1712 到 ASPEED AST2600、海思 Hi3095，openUBMC 用一套组件仓 + 一套构建工具，完成了 BMC 芯片选型的"解绑"。本文带你看看这件事是怎么落地的，以及你如何从组件适配、产品构建到上板运行逐步复现。

适合人群：BMC 固件工程师 · 服务器运维 · 开源基础设施爱好者 ｜ 阅读约 10 分钟 ｜ 全部命令可复现

---

01 场景：当产品线想换一颗 BMC 芯片时，发生了什么

凌晨两点，某服务器厂商的固件工程师小林接到任务：新平台 BMC 芯片从 A 换成 B，三个月内出样机固件。

他盘点了一下手头的工作量：

• 业务代码（Redfish、Web、传感器、风扇调度……）理论上"应该"能复用，但编译选项、链接库、内存布局全变了，每个组件都要人工趟一遍；
• 构建脚本按旧芯片的分区表、启动流程写死，换芯片意味着重写烧片镜像逻辑，手动计算分区偏移，错一个扇区整板变砖；
• 想参考社区方案，发现多数开源项目的芯片适配由各家厂商各自维护，版本节奏不一、补丁难以回流；
• 新芯片的交叉工具链、裁剪策略、签名方式，全要自己从零搭。

这不是小林一个人的困境。BMC 软件长期"绑死"在特定芯片上，是整个行业的通病——换一颗芯片，等于重做一遍固件。

02 问题与挑战：BMC 软件为什么难以跨芯片

客观来看，造成上述局面的原因有四类：

挑战	客观描述
封闭生态	传统商用 BMC 固件以黑盒交付，定制需求依赖原厂排期，用户既看不到源码，也难以自主适配新芯片
生态碎片化	开源社区中芯片适配多由不同厂商独立维护，同一项目在不同芯片上的分支差异大，补丁难以合流
构建体系门槛	主流方案基于 Yocto/BitBake，体系成熟但偏底层厚重，中小厂商上手成本高，对新芯片缺乏原生亲和
国产芯片适配缺位	国产 BMC 芯片放量在即，但既有开源项目对国产自研芯片的适配大多停留在"厂商各自为战"的阶段

AI 算力时代把这个问题进一步放大：单柜功率冲上 350kW、液冷要求毫秒级调控、供应链要求全链路自主——BMC 从"带外小模块"变成算力底座的可信根，芯片多样化是必然，软件栈绝不能每换一颗芯片就重写一次。

03 openUBMC 的答案：微组件架构 + 一套构建系统通吃多芯片

针对多芯片支持，openUBMC 社区没有另起炉灶，而是围绕主项目补齐了一条工程化链路。

3.1 方案全景：架构层次与主项目关系

各模块的职责与开源状态（承载仓库均在 openUBMC - 开源代码托管,代码协作 - AtomGit 组织下）：

模块	承载仓库	职责	开源状态
业务组件	openUBMC 主项目（100+ 组件仓）	Redfish、Web、传感器、日志等全部业务功能，换芯片零改动	开源
产品定义	manifest	每颗芯片一份 manifest.yml：组件清单、SDK 来源、裁剪与烧片策略	开源
构建工具	bingo	按芯片类型分发工具链、注入编译选项、执行裁剪与打包	开源
OS 底座	yocto_soc	openEuler Embedded BSP 基座，构建 OEE 镜像与 SDK	开源
芯片适配	hi-mpu	Hi309x SDK 源码、硬件参考设计（基于 yocto_soc 适配）	开源
平台服务	packages_download 二进制包	iBMC500 平台底座服务	闭源二进制

与主项目的关系一句话说清：主项目（微组件架构的组件群）负责"业务写一次"，manifest 负责"产品声明一次"，bingo 负责"每颗芯片正确地构建一次"，yocto_soc/hi-mpu 负责"把芯片底座长出来"，平台服务以闭源包即插即用——组件开发者只面向主项目编程，完全无感知芯片差异。多芯片支持不是新项目，而是主项目的工程化外延。

3.2 支持平台总览（manifest 产品目录实拍）

产品名（-b 参数）	芯片	系统架构	说明
openUBMC	海思 Hi1711	RTOS	社区首个开源基线
openUBMC_1712	海思 Hi1712	RTOS	第二代芯片平台
openUBMC_ast2600	ASPEED AST2600	OEE（openEuler Embedded）Linux	参考硬件 PR2715B 开发板，U-Boot + fitImage 启动
openUBMC_3095	海思 Hi3095	OEE（openEuler Embedded）Linux	鲲鹏平台 BMC 芯片
openUBMC_x86	x86_64	OEE（QEMU 虚拟机）	无硬件也能完整体验

为什么是这两颗新芯片？一颗面向全球存量最大的 BMC 硬件生态，一颗承载国产算力底座：

	ASPEED AST2600	海思 Hi3095
芯片定位	全球主流 BMC SoC，OpenBMC 生态主力芯片	鲲鹏平台自研 BMC 芯片，国产化关键环节
处理器核	双核 ARM Cortex-A7 @ 1.2GHz	海思自研架构（规格以 hi-mpu 仓公开资料为准）
启动链	U-Boot SPL → U-Boot → fitImage	l0fw → l1fw → hiboot 三段式 boot
参考硬件	PR2715B（市售 AST2600 评估板）	hi-mpu 仓公开硬件参考设计
openUBMC 产品	openUBMC_ast2600	openUBMC_3095

同一份业务组件源码（Redfish、rackmount、WebUI、sensor、snmp、nginx、skynet……100+ 个组件），跨全部芯片平台复用，通过 Conan 的 chip 选项实现按芯片差异化编译。

3.3 固件供应链：开源与平台组件的清晰分工

打开 openUBMC_ast2600/manifest.yml，两条下载配置揭示了这套方案的供应链分工：

# ① OEE 工具链/SDK —— 源自 yocto_soc 定制仓的构建产出
bmc_sdk_download:
  url: "https://dailybuild.openubmc.cn/oee_sdk/oee_sdk_0930.zip"
  sha256: "6f6de260dcb10af1b05d5f40ff58deda5dc635ee16daec3e931f8028362688ec"

# ② 闭源平台组件包 —— 提供平台基础服务
#    （对应 platform.conan: ibmc_sdk/5.15.00.01.b002 / package: community_ast2600）
packages_download:
  url: "https://repo.openubmc.cn/26.09_test/sdk/iBMC500_5.15.0.1_oee.tar.gz"
  sha256: "3bedd0c702ea7e6f5bf0e5747af1c46d6b2456c46030520de700891d8a08ce48"

Hi3095 产品同构：bmc_sdk_download 指向 oee_sdk_3095_20260929.zip（OEE 工具链/SDK，由 hi-mpu 适配仓基于 yocto_soc 构建产出），packages_download 指向 bmc_sdk_3095.tar.gz（平台组件包）。

flowchart LR
    Y["yocto_soc 定制仓<br/>openEuler Embedded BSP 基座"] -->|"OEE 镜像/SDK（AST2600）<br/>fitImage · U-Boot · rootfs"| B["bingo 构建"]
    Y --> H["hi-mpu 适配仓<br/>Hi309x SDK 源码 · 硬件参考设计"]
    H -->|"OEE 镜像/SDK（Hi3095）"| B
    P["平台组件包（闭源）<br/>iBMC500 5.15.0.1<br/>提供平台服务"] --> B
    C["开源组件仓（100+）<br/>Redfish · WebUI · sensor…"] -->|"Conan chip 选项"| B
    B --> F["整机固件<br/>HPM + eMMC 烧片镜像"]

对开发者而言，这个分工意味着：芯片底座（OEE 镜像/SDK）在社区定制仓透明可查、可参与共建（新芯片在 yocto_soc 基座上叠加适配层，如 hi-mpu 之于 Hi3095）；平台服务以二进制包即插即用；业务组件完全开源——三层供给各司其职，bingo 负责组装成整机固件。

3.4 核心理念：分层复用，按 chip 分发

bingo 没有为每颗芯片写一套构建流程，而是把构建过程拆成四个层次，每层选择已验证的最优实现复用，只在必要处定制（设计文档在 bingo 仓库 docs/ 目录公开可查）：

flowchart LR
    subgraph BUILD["bingo build 分层复用（以 oee_3095 为例）"]
        direction LR
        L1["🔧 工具链层<br/>复用 ast2600<br/>CustomBuildToolsInstaller"]
        L2["📦 组件编译层<br/>复用 1712 chip 配置<br/>chip=oee_3095 · 100+ 组件并行"]
        L3["✂️ 系统裁剪层<br/>OCT 片上裁剪<br/>OpenEuler 路径"]
        L4["💾 镜像层<br/>继承 1711/1712 基类<br/>rootfs · GPP · HPM"]
        L1 --> L2 --> L3 --> L4
    end

四颗芯片在每一层的复用关系一目了然：

构建模块	1711	1712	oee_ast2600	oee_3095	复用策略
工具链安装	默认下载	默认下载	CustomBuildToolsInstaller	CustomBuildToolsInstaller	3095 复用 ast2600
Conan 选项	symver	chipv2	chip=oee_ast2600	chip=oee_3095	3095 复用 1712
Rootfs/GPP 构建	Base 基类	Base 基类	Oee 类	Base 基类	3095 复用 1711/1712
OCT 裁剪	RTOS 裁剪	RTOS 裁剪	跳过	OpenEuler 裁剪	按操作系统定制

从 AST2600（bingo 26.06 落地）到 Hi3095（26.09 落地），两颗新芯片的完整构建支持只隔了一个版本周期——这正是分层复用架构带来的适配加速度。

3.5 一条命令背后的构建流水线

开发者侧的体验被收敛为一条命令：bingo build -t personal -b <产品名>。芯片差异全部在工具内部分发处理：

flowchart LR
    A["bingo build"] --> B["解析 manifest.yml"]
    B --> C{"chip 类型分发"}
    C -->|"1711 / 1712"| D["默认工具链<br/>DownloadDefaultBuildtools"]
    C -->|"oee_ast2600 / oee_3095"| E["OpenEuler 工具链<br/>CustomBuildToolsInstaller"]
    D --> F["Conan 组件并行构建<br/>按 chip 自动注入 options"]
    E --> F
    F --> G["OCT 片上裁剪<br/>RTOS / OpenEuler 双路径"]
    G --> H["rootfs 镜像构建<br/>strip 工具按芯片定制"]
    H --> I{"烧片打包分发"}
    I -->|"oee_3095"| J["eMMC boot + GPP 布局<br/>BaseBuildGppBin"]
    I -->|"oee_ast2600"| K["GPT 分区镜像<br/>GPTImageBuilder"]
    I -->|"1711 / 1712"| L["标准 HPM"]
    J --> M["HPM 升级包 + 烧片镜像"]
    K --> M

关键分发逻辑在 bingo 源码中只是一个芯片白名单加一层判断——新增一颗 OEE 芯片的代码改动量以"行"计（佐证见第 06 节）。

3.6 横向参照：同一颗 AST2600，两种开源路径

AST2600（双核 Cortex-A7 @ 1.2GHz）是两家开源社区共同的明星芯片，先客观看看 OpenBMC 的支持方式：它通过 meta-aspeed SoC 层叠加各家 meta-<厂商> 板级层 构建，十年积累覆盖全球 100+ 服务器平台，OpenBMC 2.18（2025 年 5 月）仍在批量纳新——生态广度和成熟度毋庸置疑。openUBMC 选择的不是替代，而是另一条工程路径，核心差异三条：

维度	OpenBMC（AST2600）	openUBMC（openUBMC_ast2600）
构建体系	Yocto/BitBake 从源码构建整个发行版，首次构建约 1 小时起步（社区实测约 20 机型全量约 3 小时）	bingo + Conan 优先复用预编译二进制，首次构建以下载为主
日常迭代	增量构建约 10~15 分钟/机型	二进制缓存 + 依赖就绪即调度，分钟级
芯片适配	为每块板卡维护独立 meta-<厂商> 机器层	产品目录 + chip 白名单分发，三步新增一颗 OEE 芯片

一句话总结：OpenBMC 用"一个发行版 + N 个机器层"换取极致的平台覆盖；openUBMC 用"组件二进制化 + 声明式产品配置"换取跨芯片的一致性与迭代速度。两条路径各有侧重，读者可按自身团队规模与芯片选型对号入座（更多维度对比见文末《OpenBMC vs openUBMC》一文）。

对比数据来源：facebook/openbmc issue #127、Arm OpenBMC 官方学习路径、openbmc 邮件列表（2022.04）、Phoronix OpenBMC 2.18 报道、openUBMC manifest 仓实测（2026.10）。

04 看得见的价值：构建侧与业务侧的双重收益

以下实测数据来自 manifest 产品仓 2026 年 10 月 23 日的实际构建产物（output/ 目录）。

4.1 构建侧：一套组件，四份固件

构建产物	芯片	实测大小
rootfs_openUBMC_1712.hpm	Hi1712（RTOS）	77 MB
rootfs_openUBMC.hpm	Hi1711（RTOS）	89 MB
rootfs_openUBMC_ast2600.hpm	AST2600（OEE Linux）	101 MB
rootfs_openUBMC_3095.hpm	Hi3095（OEE Linux）	109 MB

实测对比四份产品的构建锁文件：snmp/1.120.11 在四款产品中完全一致，sensor/1.70.127 同时服务 1712/3095/AST2600 三端——版本号里没有"芯片后缀"，也不存在某颗芯片的私有 fork，所有组件都从同一个 @openubmc/stable 发布通道拉取（个别组件版本号不同，只是不同日期构建的时间快照差异，与芯片无关）。

这意味着：业务组件开发者完全无感知芯片差异，写一份 Redfish 映射配置，四颗芯片的固件都具备该能力。

4.2 构建侧：烧片镜像从"手算扇区"到"声明式配置"

AST2600 的 eMMC 分区不再手工计算偏移，而是一份 YAML 声明（openUBMC_ast2600/emmc_layout.yml），bingo 自动完成 GPT 分区表创建、扇区对齐与数据写入：

分区	大小	类型	用途
Kernel-A / Kernel-B	32M × 2	ext4	内核 A/B 双备份
rofs-a / rofs-b	384M × 2	ext4	只读根文件系统 A/B 双备份
rwfs	1024M	ext4	/data 数据分区
mmcblk0p9	353M	ext4	/var/log 日志分区

A/B 双分区设计让固件升级天然具备回滚能力；分区中的 fitImage 内核与 U-Boot 正是取自社区定制仓产出的 OEE SDK。实测自动生成的整盘烧片镜像 openUBMC_ast2600_real.img 为 2.55 GB，含全部分区数据，量产烧片开箱即用。

Hi3095 侧则是另一套声明式布局（flash_image_3095.yml）：2 MB boot 区按 l0fw/l1fw/hiboot 三段划区、rootfs 采用 764 MB 偏移的 GPP 子头封装、CMS 签名区段化描述——同样零手算。此外，落入 bingo 26.06 的 FirmwarePackager 还提供固件解析与完整解包验证能力（分区偏移强制 512 字节对齐），产物可反向解包核对，量产前多一道保险。

4.3 构建侧：全程留痕，构建不是黑盒

以一次 Hi3095 release 构建的工作目录实录（temp/build_openUBMC_3095_release_dev/）——构建的每个阶段都有独立工作目录与档案：

temp/build_openUBMC_3095_release_dev/
├── graph.order                  # 依赖构建顺序：104 个组件分 8 层调度（30/10/5/4/1/34/16/4）
├── openubmc.lock                # 组件版本锁定，可重复构建的依据
├── conan_install/               # 106 个组件各自独立的安装目录
├── tmp_root/                    # rootfs 组装树（bin/ etc/ usr/ ...）
├── hpm_build_dir/               # HPM 打包工作区
├── custom_build_tool_new.sha256 # 工具链完整性校验档案
└── output/
    ├── rootfs_openUBMC_3095.hpm          # 固件包
    ├── rootfs_openUBMC_3095.hpm.signed   # 签名后固件
    └── rootfs_openUBMC_3095.filelist.cms # 文件清单 + CMS 签名

构建出错时也不用猜——任务日志直接定位到"哪个组件、哪条命令、哪组 chip 选项"（temp/log/task.log 实录，某次 AST2600 迭代的失败现场）：

ERROR: mdb_interface/1.110.56@openubmc/stable: Error in package() method, line 62
[2026-10-23 17:45:28 ERROR] task_build_conan.py:957 执行命令
  conan create . -pr=profile_oee.ini -pr:b profile.dt.ini
  -o *:chip=oee_ast2600 -o help/*:board_name=PR2715B ...
  错误, 日志: temp/log/task.log

依赖分层、组件目录、工具链校验、任务日志四类档案随手可查，多芯片并行开发的排障成本大幅降低；配合 Conan 二进制缓存与 --ccache，日常出包以分钟级增量为主。

4.4 业务侧：一次开发，四端同步的能力红利

• 功能一次开发、四端可用：锁文件实测 snmp/1.120.11 四端同版，同一组件源码服务全部芯片——上线一个新 Redfish 资源无需为任何芯片重写，四款固件随各自出包节奏同步获得，不存在"某芯片永远落后"的体验割裂；
• 升级更可靠：AST2600 的 Kernel/rofs A/B 双分区让固件升级失败可自动回滚，运维不必再为"升级变砖"彻夜值守；
• 运维能力按声明注入：以 Hi3095 产品为例，manifest 里声明 observability、opentelemetry、fluent-bit、webvnc_enabled: true 几行配置，固件即内置全链路可观测与 WebVNC 远程 KVM——企业级运维能力是一行配置的事，而不是一个立项。

4.5 业务侧：生态伙伴的落地实践

据社区公开信息：神州鲲泰基于 openUBMC 实现 PCIe Switch 多 GPU 自发现；长江计算联合沐创基于南向部件规范共建硬件兼容生态；海思作为开源发展委员会首批成员深度参与 3095 适配——多芯片支持不是实验室特性，而是产业链协同的产物。

05 八步上手：组件适配 → 产品构建 → 上板运行

版本落地信息：AST2600 HPM 构建能力落入 bingo 26.06；Hi3095 兼容构建与双芯片烧片镜像落入 26.09；调度优化落入 26.12；产品基线版本 openUBMC_ast2600 = 26.12.00.01、openUBMC_3095 = 26.12.01.01。环境要求 Ubuntu 24.04 LTS（或 openEuler 24.03 LTS）、16 GB 内存、64 GB 磁盘。

阶段① 组件适配：写你的第一个业务组件

# ① 注册社区账号（Conan 认证凭据）：https://usercenter.openubmc.cn/register

# ② 准备环境：克隆产品仓并一键初始化（自动安装 bingo/Conan 工具链）
git clone https://gitcode.com/openUBMC/manifest.git && cd manifest
export OPENUBMC_LICENSE=true
python3 init.py -user <用户名> -psw '<密码>'

# ③ 创建组件骨架，MDS 建模后自动生成 Lua/C 代码
cd /home/workspace
bingo new                      # 按提示创建组件骨架
cd <组件目录> && bingo gen -w   # 配置 mds/model.json 后带模板生成

# ④ 组件级构建 + 开发者测试（产物进本地 Conan 缓存，无需真机）
bingo build --stage=dev
bingo test -ut                 # 单元测试；-it 为集成测试

阶段② 产品构建：把组件集成进多芯片固件

# ⑤ 在产品 manifest.yml 中声明组件（四款芯片产品任选其一）
#    编辑 build/product/BMC/openUBMC_ast2600/manifest.yml：
dependencies:
  - conan: "<组件名>/<版本>@openubmc/stable"

# ⑥ 整包构建：换芯片 = 换一个 -b 参数
cd /home/workspace/manifest
bingo build -t personal -b openUBMC_ast2600    # 或 openUBMC_3095 / openUBMC_1712
ls -lh output/rootfs_openUBMC_ast2600.hpm      # 产物就绪

阶段③ 上板运行：真机验证或 QEMU 体验

# ⑦ 真机：将 HPM 通过 BMC Web/Redfish 标准升级接口刷入开发板
#    （AST2600 可用市售 PR2715B 评估板；量产线可改用 bingo 产出的 eMMC 整盘烧片镜像）
ssh Administrator@<BMC-IP>          # 刷机完成后 SSH 登录
ipmcget -d v                       # 查看固件版本，确认刷入成功

# ⑧ 无开发板？AST2600 QEMU 完整体验
bingo build -b openUBMC_ast2600
cd output
qemu-system-arm -M ast2600-evb,boot-emmc=true -drive file=openUBMC_ast2600_real.img,format=raw,if=sd,index=2 -nographic -net nic -net user,hostfwd=:127.0.0.1:2222-:22,hostfwd=:127.0.0.1:2443-:443,hostfwd=udp:127.0.0.1:2623-:623,hostfwd=:127.0.0.1:223-:23,hostname=qemu
# telnet:  telnet 127.0.0.1 223

06 共建邀请：下一颗芯片，由你定义

openUBMC 的多芯片架构是为扩展而设计的。按设计文档的扩展指南，适配一颗新 OEE 芯片只需三步：

1. 在 SUPPORT_CHIPV2_CHIPS 等芯片白名单中追加新芯片名；
2. 在 set_chip_option() 中添加该芯片的 Conan 选项分支；
3. 按需定制差异点（strip 工具路径、裁剪流程等）。

"三步"不是修辞，芯片分发在 bingo 源码里真的只是一个白名单加一层判断：

# OEE 芯片白名单，新增 OEE 芯片只需在此追加
OEE_CHIPS = ('oee_ast2600', 'oee_3095')

if self.config.chip in OEE_CHIPS:
    self.custom_installer.run()      # 复用 OpenEuler 工具链安装
else:
    self.download_buildtools.run()   # 1711/1712 走默认链路

三种参与姿势，总有一款适合你：

• 试用：x86 QEMU 路径无需任何 BMC 硬件，一台普通电脑即可跑起完整 openUBMC，欢迎到社区论坛聊聊你的第一印象；
• 适配：手头有 Nuvoton、AST2700、RISC-V BMC 芯片？欢迎认领适配任务，社区提供 SIG-CICD 全流程支持；
• 反馈：构建遇到问题？在 bingo 仓库 提 Issue，或到社区论坛发帖，维护者会在下个版本响应。

第一次贡献代码的四步路径（代码遵循木兰宽松许可证 MulanPSL2）：

1. GitCode 上 Fork 目标仓库（bingo / manifest / 组件仓均可）；
2. 按仓库 CONTRIBUTING.md 配置 pre-commit 后提交修改；
3. 发起 PR 并按提示签署 CLA；
4. 社区 CI 机器人自动检查，通过后等待 Maintainer 合入。

互动话题：你最希望 openUBMC 下一颗适配哪款 BMC 芯片？欢迎到社区论坛回帖留言——呼声最高的将进入社区需求池，由开源发展委员会评估排期。

---

你可能还想知道

• openUBMC/manifest 产品仓 —— 五款芯片产品定义与构建指导书
• openUBMC/bingo 构建工具仓 —— docs/26.06《基于OEE和ast2600芯片配置构建hpm包》、docs/26.09《支持OEE+Hi3095兼容构建方案》《ast2600/3095烧片包构建》等原始设计文档按版本归档
• openUBMC/yocto_soc 定制仓 —— 基于 openEuler Embedded 的 Yocto BSP 基座，OEE 镜像/SDK 的构建源头
• openUBMC/hi-mpu 适配仓 —— Hi309x 系列 SDK 源码、硬件参考设计与 Sample Code
• openUBMC 官网文档 —— 环境搭建、组件开发、接口映射系列指南

本文数据均来自 openUBMC 社区公开仓库实测（2026 年 10 月）。

---

附：名词速查

名词	含义
OEE	openEuler Embedded，openEuler 嵌入式发行版，AST2600/Hi3095 的 Linux 底座
HPM	openUBMC 固件升级包格式，可通过 BMC Web/Redfish 在线升级
GPP	通用固件包，整机烧片镜像的分区封装格式
chip 选项	Conan 组件构建选项，同一组件源码按芯片差异化编译的开关