平台整包集成指导 | 文档中心

背景介绍

平台整包将平台组件预先打包，提供统一的依赖版本和配置。相比传统的逐个引用组件方式，具有以下优势：

简化产品配置，无需单独管理多个平台组件
避免组件版本冲突，提升构建稳定性, 削减多个conan中心仓
缩短依赖下载时间，加快构建速度

适用范围

ibmc_sdk>=5.14

整包结构介绍

整包存在形式：单独文件，tar压缩包

整包解压后目录结构：

full_package/
├── conan_cache/                                        conan缓存合集
├── community_webvnc_1711_manifest.yml                  整包配置文件1
├── community_webvnc_manufacture_1711_manifest.yml      整包配置文件2
└── ...

配置说明

manifest.yml 文件说明

manifest.yml 文件定义了整包的基本信息，包括版本、描述和组件依赖关系：

yaml

base:
  version: 5.14.00.01.B001
description: 社区1711支持webvnc整包，组件开启options：firmware_mgmt:community_enable=True remote_console:webvnc_supported=True nsm:webvnc_supported=True, 可用于社区webvnc整包构建
dependencies:
- conan: firmware_mgmt/1.0.0@openubmc/stable
  options:
    community_enable: true

字段说明：

base.version: 整包版本号
description: 整包描述信息，包含支持的特性和组件配置说明
build_type: 整包构建类型，必须和构建匹配，否则会直接失败
dependencies: 组件依赖列表
- conan: 组件名称及版本
- options: 组件配置选项

如何合并Debug/Release整包

在下载过程中，往往伴随着Debug和Release整包文件是单独存在的，在实际过程中需要进行合并。支持两种不同的方式合并，分别对应整包不同的使用方案。

1. 整包方案

合并流程：

分别下载debug/release压缩包文件
将文件迁移到linux系统进行解压
参考bingo脚本 https://gitcode.com/openUBMC/bingo/blob/main/bmcgo/utils/merge_conan2.py

执行脚本

python

python3 merge_conan2.py --base_dir=debug_path/conan_cache --merge_dir=release_path/conan_cache

将合并后的debug文件夹单独压缩为一个整体的tar包，支持.tar.gz和.tar.xz格式，参考命令:
shell
```
cd debug_path
tar -czf bmc_sdk.tar.gz *
sha256sum bmc_sdk.tar.gz
```
将sha256文件和bmc_sdk.tar.gz整体上传到文件服务器，供后续整包方案下载使用

2. 传统方案

将debug和release缓存分别上传conan中心仓

shell

rm -rf ~/.conan2/p
mv conan_cache ~/.conan2/p
conan upload * -r conan远程仓 -c

产品引用整包

产品通过在manifest仓库的manifest.yml文件中配置bmc_sdk_download和platform字段来引用整包。

bmc_sdk_download配置

bmc_sdk_download用于配置整包文件的下载信息：

yaml

bmc_sdk_download:
  url: https://example.com/full_package.tar.gz
  sha256: xxxxxx

具体整包的sha256值在下载链接文件夹有文本承载，复制即可。

配置说明：

url: 整包文件的下载地址
sha256: 整包文件的SHA256校验值，用于验证文件完整性

下载流程：

构建时会自动下载整包文件到~/bmc_sdk_download目录
使用sha256校验文件完整性
解压整包文件（tar.gz格式）
需要同意《BMC软件许可协议》才能下载

platform配置

在产品的manifest.yml文件中添加以下配置：

yaml

platform:
  conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
  options:
    rtos_version: rtos_v2
    enable_haf: false
  package: "community_webvnc_1711" #无需配置文件名最后一段_manifest.yml

默认情况下，整包内的平台组件以整包配置为准，产品 manifest 中无需再重复描述这些组件；若确需替换或定制某个平台组件的版本/options，可按"覆盖平台组件"一节的写法直接在 dependencies 中写出，无需额外声明。

配置说明

platform.conan: 指定要使用的ibmc_sdk版本
platform.options: 整包配置选项
- rtos_version: RTOS版本，可选 rtos_v2 等
platform.package: 指定要使用的整包配置，对应整包目录下的manifest.yml

完整示例

以下是一个完整的产品manifest.yml配置示例。整包内部组件（如 firmware_mgmt）的版本/options 默认以整包为准，产品端不必再写一遍；如确需覆盖整包内部组件，参见下文"覆盖平台组件"一节：

yaml

bmc_sdk_download:
  url: https://example.com/full_package.tar.gz
  sha256: xxxxxx
platform:
  conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
  options:
    rtos_version: rtos_v2
    enable_haf: false
  package: "community_webvnc_1711"
openubmc_sdk:
  conan: "openubmc_sdk/latest@openubmc/stable"
base:
  version: "26.06.00.01"
  customization: "customization/prototype.py"
  dependency_buildtools: dependency/dependency_buildtools.xml
  signature:
    files:
      - file: ${product}/ca/rootca.crl
        dst: cms.crl
      - file: ${product}/ca/rootca.der
        dst: rootca.der
dependencies:
#   - conan: firmware_mgmt
#     options:
#       community_enable: true
  - conan: vpd
    options:
      board_name: openUBMC
  # ... 其他依赖组件

覆盖平台组件（产品同名组件即覆盖）

自 openUBMC 26.09 起新增（对应 bingo ≥ 0.7.67 版本）。早期版本在使用整包配置（platform.package）时，会拦截产品对平台同名组件的版本/options 定制（报错"不允许对平台组件进行定制"），现已放开为"同名即覆盖"。

整包将平台组件预先打包，提供统一的版本与配置。但在紧急采纳上游修复版本、适配产品专有分支、或仅调整某个组件编译选项等场景下，产品可能需要替换或定制整包中的某个平台组件。bingo 现支持同名即覆盖：产品只需在 manifest.yml 的 dependencies 中对同名组件写出版本/options，即覆盖整包（以及 openubmc_sdk）中的定义，无需任何额外声明。

上文"完整示例"中被注释掉的 firmware_mgmt 即属于整包内部组件：默认不写、继承整包配置即可；确需覆盖时，按下文写法在产品 dependencies 中写明。

层间优先级

构建时，产品 manifest 与下层 manifest 按以下优先级合并（高 → 低）：

产品 > openubmc_sdk > platform

产品优先级始终最高，对同名组件写出版本/options 即生效。
产品未写时，openubmc_sdk 的同名组件优先级高于 platform（整包），即上游基线可盖过整包中的旧版本定制。

"同名"按组件名判断，例如 firmware_mgmt/1.0 与 firmware_mgmt/1.1 视为同名，生效方以高优先级层的版本为准。

替换整包组件版本

直接在产品 dependencies 中对整包同名组件写出新版本，整包钦定的版本即被产品版本覆盖：

yaml

dependencies:
  - conan: firmware_mgmt/1.1.0      # 整包中的版本被产品版本覆盖;整包中该组件的 options 被清空为 None

注意：覆盖按"整条目替换"生效，整包中该组件原有的 options 不会自动继承。只写版本、不带 options 时，产品侧未写的 options 会被清空（置为 None，即恢复默认）。因此若整包原本带了 options，仅按上例替换版本会一并丢掉这些 options；需要保留时，请在产品条目中把 options 显式写回（见下文「同时覆盖版本与 options」）。

定制 options（版本沿用整包）

若只想调整某个组件的编译选项、版本仍沿用整包默认，省略版本号即可，版本由整包补齐：

yaml

dependencies:
  - conan: firmware_mgmt            # 无版本号 → 版本由整包补齐
    options:
      community_enable: true

同时覆盖版本与 options

版本与 options 也可在同一组件上同时写明，二者都按产品侧覆盖整包（最常用的覆盖方式）：

yaml

dependencies:
  - conan: firmware_mgmt/1.1.0      # 版本覆盖整包
    options:
      community_enable: true        # options 同时覆盖整包

清空整包组件 options

若整包中某组件带了 options，而产品侧希望清空这些 options（恢复默认），对该组件仅写名字、不带 options 即可，整包中的 options 会被清空（置为 None）：

yaml

dependencies:
  - conan: firmware_mgmt            # 版本由整包补齐；整包中该组件的 options 被清空为 None

覆盖告警

为便于平台/SDK 维护者审计，bingo build（出包阶段）在同名组件的版本/options 发生覆盖时，会在构建日志中打印告警。分别对应"替换版本""定制 options""清空 options"三种场景各自输出的告警；当同一组件的版本与 options 同时变化时，二者会合并为一条告警（以 ; 连接）输出：

WARN: 组件 firmware_mgmt 被覆盖: 版本 firmware_mgmt/1.0.0 → firmware_mgmt/1.1.0; options {'community_enable': True} → None
WARN: 组件 firmware_mgmt 被覆盖: options {'community_enable': False} → {'community_enable': True}
WARN: 组件 firmware_mgmt 被覆盖: options {'community_enable': True} → None
WARN: 组件 firmware_mgmt 被覆盖: 版本 firmware_mgmt/1.0.0 → firmware_mgmt/1.1.0; options {'community_enable': False} → {'community_enable': True}

覆盖行为一览：

产品对整包同名组件的写法	生效版本	生效 options	是否告警
仅写名字，整包无 options	整包版本补齐	无	否
仅写名字，整包带 options	整包版本补齐	清空（None）	是
写出新版本（与整包不同，可同时写 options）	产品版本	产品 options	是
版本相同，options 不同	整包版本	产品 options	是
版本与 options 与整包完全一致	不变	不变	否

当版本与 options 与整包完全一致（或仅写名字且整包本身也无 options）时，不触发告警。

发布包配置

在构建发布包时，需要在tosupporte/manufacture配置中添加对应的platform配置：

yaml

tosupporte:
  default:
    platform:
      conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
      options:
        rtos_version: rtos_v2
        enable_haf: false
      package: "community_webvnc_1711"
    package_name: "openUBMC/openUBMC-CMT_${version}.zip"
    build_type: release

三种引用方式的区别

产品引用整包有三种方式：

1. 使用整包文件（推荐）

通过bmc_sdk_download下载bmc_sdk整包文件，然后通过platform.package引用：

yaml

bmc_sdk_download:
  url: https://example.com/full_package.tar.gz
  sha256: xxxxxx
platform:
  conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
  options:
    rtos_version: rtos_v2
    enable_haf: false
  package: "community_webvnc_1711"

特点：

需要将整包上传到文件服务器，校验sha256值
整包文件自动下载并解压到~/bmc_sdk_download目录
适合社区统一发布的整包
需要同意许可协议才能下载

2. 使用本地整包目录

手动指定参数--debug_platform_path，适用于手动指定整包路径联调直接通过platform.package引用本地整包目录配置：

yaml

platform:
  conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
  options:
    rtos_version: rtos_v2
    enable_haf: false
  package: "community_webvnc_1711"

特点：

需要手动将整包解压到指定目录
适合本地开发或自定义整包

3. 使用Conan包（传统方式）

通过platform.conan引用Conan包：

yaml

platform:
  conan: "ibmc_sdk/5.13.00.01.b002@openubmc/stable"
  options:
    rtos_version: rtos_v2_1712
    enable_haf: false

特点：

不需要整包文件
通过Conan仓库管理SDK版本
适合传统SDK管理方式

使用流程

使用bmc_sdk_download自动下载

配置引用：在产品manifest.yml中配置bmc_sdk_download和platform字段
构建产品：使用bingo工具构建产品包，构建时会自动下载并解压整包
bash
```
bingo build -b openUBMC
```
同意协议：下载时需要同意《BMC软件许可协议》
- 可设置环境变量自动同意：export OPENUBMC_LICENSE=true
- 或在构建时手动输入Y同意
验证下载：整包文件会下载到~/bmc_sdk_download目录，并使用sha256校验

手动使用整包目录

获取整包：从发布渠道获取整包文件（tar.gz格式）
解压整包：使用tar -xzf <整包文件名>.tar.gz解压到指定目录
配置引用：在产品manifest.yml中配置platform字段，指向解压后的整包目录

构建产品：使用bingo工具构建产品包

bash

bingo build -b openUBMC --debug_platform_path=/test/full_packages

注意事项

整包配置名称需与产品需求匹配
platform.package配置将直接引入产品manifest.yml
更新整包版本时，需同步修改platform.package配置为新的整包名称
使用bmc_sdk_download下载整包时：
- 确保网络可访问下载地址
- sha256校验值必须正确，否则下载会失败
- 下载需要同意许可协议
- 整包会下载到~/bmc_sdk_download目录并自动解压
本地已有整包目录时，可直接使用platform.package引用，使用参数--debug_platform_path指定整包路径
使用platform.conan方式时，需要确保Conan仓库中有对应的SDK包版本
产品对整包同名组件写出版本/options 即覆盖整包默认配置（同名即覆盖，无需额外声明，详见"覆盖平台组件"一节）。覆盖发生时构建日志会打印告警以便审计；仅在确需替换时才写，避免无意覆盖整包默认配置。

背景介绍 ​

适用范围 ​

整包结构介绍 ​

配置说明 ​

manifest.yml 文件说明 ​

如何合并Debug/Release整包 ​

1. 整包方案 ​

2. 传统方案 ​

产品引用整包 ​

bmc_sdk_download配置 ​

platform配置 ​

配置说明 ​

完整示例 ​

覆盖平台组件（产品同名组件即覆盖） ​

层间优先级 ​

替换整包组件版本 ​

定制 options（版本沿用整包） ​

同时覆盖版本与 options ​

清空整包组件 options ​

覆盖告警 ​

发布包配置 ​

三种引用方式的区别 ​

1. 使用整包文件（推荐） ​

2. 使用本地整包目录 ​

3. 使用Conan包（传统方式） ​

使用流程 ​

使用bmc_sdk_download自动下载 ​

手动使用整包目录 ​

注意事项 ​

背景介绍

适用范围

整包结构介绍

配置说明

manifest.yml 文件说明

如何合并Debug/Release整包

1. 整包方案

2. 传统方案

产品引用整包

bmc_sdk_download配置

platform配置

配置说明

完整示例

覆盖平台组件（产品同名组件即覆盖）

层间优先级

替换整包组件版本

定制 options（版本沿用整包）

同时覆盖版本与 options

清空整包组件 options

覆盖告警

发布包配置

三种引用方式的区别

1. 使用整包文件（推荐）

2. 使用本地整包目录

3. 使用Conan包（传统方式）

使用流程

使用bmc_sdk_download自动下载

手动使用整包目录

注意事项