[{"data":1,"prerenderedAt":403},["ShallowReactive",2],{"lang-check-\u002Fzh\u002Fblogs":3,"blog-all-zh":4},null,[5,27,42,56,71,85,99,114,129,144,157,172,186,199,217,233,248,262,277,291,306,319,335,348,364,378,391],{"_path":6,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":10,"description":11,"date":12,"category":13,"author":14,"_type":18,"_id":19,"_source":20,"_file":21,"_stem":22,"_extension":23,"coverImage":24,"plainText":25,"authorNames":26},"\u002Fzh\u002Fblogs\u002F20260605UBMC","blogs",false,"","打破业务边界：openUBMC 北向自接入，重构BMC创新落地模式","openUBMC 创新性提出北向自接入概念，重新定义BMC开发与交付模式","2026\u002F06\u002F05","essentials",[15],{"name":16,"description":17},"于飞","openUBMC社区委员会委员&openUBMC开源软件专家，十五年管理软件产品化经验，先后负责鲲鹏\u002F昇腾多个代次产品的管理软件设计。","markdown","content:zh:blogs:20260605UBMC.md","content","zh\u002Fblogs\u002F20260605UBMC.md","zh\u002Fblogs\u002F20260605UBMC","md","\u002Fcategory\u002Fblog\u002F20260605UBMC-boke\u002F%E5%9B%BE%E7%89%871.png","01 BMC 创新的“最后一公里”困在哪里？ 作为算力基础设施核心统一管理底座，BMC 向来以门槛高著称。开发者除了软件技能，还得懂服务器硬件、数据中心运维、部件适配等。这套知识体系横跨算法、软件和硬件，天然就把很多人挡在门外。伴随算力产业升级， BMC 的集成模式、交付形态与核心职责迎来全新变革：  芯片级调优、部件故障智能诊断、硬件预加载、特性校准等系统调优职责不断下沉； AI安全防护（入侵检测、合规审计、供应链可信、业务性能调优）成为刚需； AIOps推动北向接口重构，端云深度联动与协作诊断成为常态； Agentic BMC统一互操作规范（标准MCP、嵌入式LLM能力）也在加速落地。 然而，传统BMC的开发模式相对封闭、周期漫长，每一项新需求的接入都高度依赖固件团队。硬件调优、算法、安全、运维等领域的专家，即便有成熟的创新想法，也因为不掌握BMC底层开发技能，难以快速落地。 于是出现了一个尴尬的局面：领域专家有想法，BMC 有部署优势，但两者之间横亘着技术鸿沟。这正是BMC创新应用最难跨越的“最后一公里”。  02 破局之道：北向自接入，让BMC从封闭架构升级为开放应用平台 为破解上述行业痛点，openUBMC 创新性提出北向自接入概念，重新定义BMC开发与交付模式。 简单来说，北向自接入是一套面向上层开发者、领域专家的开放式组件接入体系，核心宗旨为让专业的人做专业的事，剥离 BMC 底层硬件适配、编译部署等复杂工作，允许非专职开发人员独立开发、接入运维、安全、调优类功能组件，彻底打破行业技术壁垒。  具体而言，openUBMC Service & AI agent runtime架构提供了四项关键能力： 硬件统一访问 ：屏蔽底层差异，提供标准化温度、功耗、故障日志等监测接口，开发者无需关心IPMI\u002FRedfish协议。 组件安全托管 ：组件运行于独立沙箱，资源配额隔离，单组件崩溃不影响系统，支持热升级与原子回滚；支持AI推理引擎与特征工程库，算法专家直接调用。 北向标准集成 ：组件声明能力后，框架快速适配Redfish、SNMP、WEB等北向接口，无缝对接上层网管与云平台。 集群协同调度 ：支持组件批量部署至大规模节点，实现状态聚合、告警关联与统一配置下发。 北向自接入使非 BMC 开发者能够快速开发、部署创新组件，从根本上重构了 BMC 开发交付模式—从“整机厂商交付完整固件”演进为“第三方发布独立组件，按需组装”。  03 底层支撑：三大架构创新，筑牢自接入能力底座 上述能力的实现，离不开底层架构的系统性重构。平台彻底摒弃传统单体架构，重构为微组件化开放架构，从上层组件迭代、底层硬件适配、开发工具链到生态市场完成全链路升级，为北向自接入能力提供坚实技术底座： 创新一：微组件架构：让第三方应用“塞得进去、跑得稳” 传统 BMC 固件是单体架构，所有功能揉在一起。openUBMC 将其拆分为微组件，每个组件可以独立开发、编译、发布、升级。  组件之间通过契约式接口通信，运行环境相互隔离—一个组件崩溃，不会拖垮整个 BMC。组件声明的管理能力映射到北向接口（Redfish\u002FWEB\u002FSNMP 等），开发者无需关心协议细节。 创新二：南向驱动标准化：让北向组件“叫得动”任何硬件 针对服务器零部件适配乱象，openUBMC 统一南向硬件接入标准，打破行业“七国八制”的适配困局。部件厂商可独立开发、发布驱动，真正实现一次开发、全域复用，交付主体从整机厂商下沉至部件厂商。  算法专家聚焦数据应用，运维专家深耕高阶功能，硬件架构师专注差异化设计—各司其职，最大化释放研发价值。 创新三：开放应用市场：让组件“灵活组合，按需安装” 开发者将组件发布至 Conan 仓库，整机厂商或用户可根据业务需求，从应用市场中灵活挑选组件，组装出自定义的 BMC 固件。系统自动处理组件间的依赖关系，一键完成固件构建与打包，全流程自动化。  目前社区已上架 30+ 开源组件，形成“开发-发布-组合-交付”和“开发-发布-安装”的完整闭环，让组件真正实现一次开发、灵活复用。  04 展望：北向自接入规范进行时 openUBMC 技术委员会主席宋铜铃在 KADC openUBMC 分论坛上表示，北向自接入统一规范已正式启动编制，预计 2026 年底发布。依托完整的南北向标准体系建设，openUBMC 将打通全链路开发壁垒，助力每一个创新想法快速落地，推动 BMC 从传统管理平台，进化为全领域的创新舞台，为算力基础设施智能化升级筑牢坚实底座。  欢迎关注openUBMC 社区官网： https:\u002F\u002Fwww.openubmc.cn 代码仓地址： https:\u002F\u002Fgitcode.com\u002FopenUBMC",[16],{"_path":28,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":29,"description":30,"date":31,"category":13,"author":32,"_type":18,"_id":36,"_source":20,"_file":37,"_stem":38,"_extension":23,"coverImage":39,"plainText":40,"authorNames":41},"\u002Fzh\u002Fblogs\u002F2026UBMC-Changsha","开源BMC筑基AI算力——openUBMC 走进长沙高校","在AI大模型浪潮席卷全球的今天，算力已成为驱动创新的核心引擎。然而，支撑这庞大算力的，不仅是高性能的 GPU 和芯片，更是那些默默无闻、却至关重要的底层基础设施。其中，BMC 作为服务器的“第二大脑”，负责硬件监控、远程管理、故障诊断等关键任务，是保障大规模AI集群稳定、高效、智能运行的基石。","2026\u002F05\u002F06",[33],{"name":34,"description":35},"openUBMC小助手","openUBMC小助手是openUBMC社区的活跃推手，专注于为开发者提供前沿技术动态、深度文章解析以及丰富的社区互动内容，致力于打造一个开放、互助、充满活力的技术社区，助力每一位成员在技术探索中不断进步。","content:zh:blogs:2026UBMC-Changsha.md","zh\u002Fblogs\u002F2026UBMC-Changsha.md","zh\u002Fblogs\u002F2026UBMC-Changsha","\u002Fcategory\u002Fblog\u002F26UBMC-Changsha\u002F%E5%9B%BE%E4%BA%8C.jpg","openUBMC 走进长沙高校 在AI大模型浪潮席卷全球的今天，算力已成为驱动创新的核心引擎。然而，支撑这庞大算力的，不仅是高性能的 GPU 和芯片，更是那些默默无闻、却至关重要的底层基础设施。其中，BMC 作为服务器的“第二大脑”，负责硬件监控、远程管理、故障诊断等关键任务，是保障大规模AI集群稳定、高效、智能运行的基石。 近期，由CCF开源发展技术委员会主办的“开源高校行”系列活动走进长沙，在国防科技大学、湖南大学、湖南师范大学、长沙理工大学四所顶尖学府掀起了一场关于开源与AI算力的热潮。openUBMC 社区技术委员会委员张雨博作为核心分享嘉宾，全程参与了这四场活动，为数千名师生带来了一场关于开源 BMC 如何构筑现代化AI算力底座的深度解读。 走进 BMC 的世界，点燃开源创新的火种 如何让高校师生对一个偏底层的“幕后”技术产生兴趣？在长沙四校的分享中，答案从一组真实案例开始。 当 Atlas 384 超节点的庞大规模呈现在屏幕上时，在场师生第一次直观感受到现代算力基础设施的复杂程度——数百颗算力芯片、数千条互联链路、数万个传感器节点，任何一个环节的异常都可能影响整体训练的稳定性。 而更让人印象深刻的，是 xAI Colossus 集群的故事：一个10万张H100 GPU 规模的超级计算机集群，从首个机架进场到正式开始AI模型训练，仅仅用了19天。这种“极限速度”的背后，依靠的正是一套能够实现全集群自动化部署、批量固件升级、实时状态监控的智能管理底座——其核心，正是 BMC。 这些案例让师生们意识到，BMC 远不止是课本上的概念，而是支撑AI算力底座的关键节点。而传统 BMC 长期运行在封闭、固化的生态中——这个领域正在经历一场深刻变革：BMC 能否从封闭的“黑盒子”，变成一个开放、可编程、可创新的平台？ 这正是 openUBMC 社区的使命。\n    大赛赛题详情 社区秉持“开放共建、协作创新”的理念，汇聚企业、高校和个人的力量，共同打破技术壁垒。在这里，没有标准答案——开发者可以大胆探索AI推理下沉、大语言模型对话等全新可能。 社区珍视每一个大胆的猜想和 POC，因为突破往往始于“疯狂”。正是这种开源精神，让 openUBMC 联合第八届CCF开源创新大赛，为高校师生量身打造了两道赛题，期待敢于打破常规的创新火花。 赛题一：重塑BMC——AI时代智能运维创新平台 传统 BMC 功能以基础监控、电源控制和远程访问为主，而随着AI算力场景爆发，BMC 平台已具备承载更多“非传统”能力的巨大潜力。 本赛题邀请参赛者跳出传统 IPMI\u002FRedfish 思维框架，探索将智能运维能力下沉到BMC的全新可能——无论是智能网络策略执行、遥测聚合与自治、轻量资源调度、故障自愈逻辑，还是带内\u002F带外协同实现AI驱动预测维护、根因自动分析、算力动态优化，甚至是插件化扩展框架、零信任安全模型等跨领域融合。 评审将聚焦功能完整性、创新性与资源优化性，期待参赛者在 openUBMC 平台上快速验证大胆构想，用 POC 重新定义下一代智能 BMC。 赛题二：嵌入式芯片的LLM挑战 现代 BMC 芯片（如Hi3095的4核@1.5GHz、4GB内存）已具备一定的边缘推理能力。 本赛题要求参赛者在 openUBMC 环境中部署一个轻量化大语言模型（如Gamma4、Hunyuan-0.5B、Qwen-0.5B等），并通过命令行接口实现完全本地化的自然语言交互——让管理员能直接用自然语言查询系统状态、分析日志、诊断故障，全程无需云端。 评审重点关注苛刻硬件条件下的功能完整性与极致优化：内存占用越低越好（鼓励INT4\u002FGPTQ等极限量化），推理速度越快越好，同等资源消耗下模型的理解与回答能力越强越好。这是一场在嵌入式世界里挑战 LLM 部署极限的技术擂台。 加入openUBMC，让创意落地 加入我们：将奇思妙想变为现实 两大赛题，为每一位怀揣技术热情的开发者提供了施展才华的广阔舞台： 丰厚激励 ：赛事提供高额奖金，认可你的每一次创新突破。 实战平台 ：在真实项目中锻炼工程能力，积累宝贵的开源项目经验。 社区赋能 ：与 openUBMC 社区的技术专家直接交流，获得专业指导。 无论你是对底层系统充满好奇的学生，还是希望深耕基础软件领域的开发者，这里都有你施展才华的舞台。 行动起来 了解项目： https:\u002F\u002Fwww.openubmc.cn 报名参赛： 10万奖金池已就位！第八届CCF开源创新大赛openUBMC赛道邀你来战 从岳麓山下到湘江之滨，开源的薪火已被点燃。我们期待更多有志青年加入openUBMC社区，共同筑牢中国AI算力的基础设施底座，为构建自主可控、安全高效的数字未来贡献青春力量。",[34],{"_path":43,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":44,"description":45,"date":31,"category":13,"author":46,"_type":18,"_id":50,"_source":20,"_file":51,"_stem":52,"_extension":23,"coverImage":53,"plainText":54,"authorNames":55},"\u002Fzh\u002Fblogs\u002Fopen-A-IInfra-summit-review","Open AI Infra Summit 2026｜openUBMC以架构创新和开源标准破解智算集群运维痛点","2026年4月9-10日，2026 Open AI Infra Summit 在北京举办。\nopenUBMC 社区技术委员会委员 & iBMC 集群管理软件专家黄晗，在超节点生态分论坛发表《基于 openUBMC 打造超节点硬件智能管理平台》主题演讲，分享开源体系下硬件智能管理最新实践，以标准化方案破解智算集群运维痛点，引发行业广泛关注。\n",[47],{"name":48,"description":49},"黄晗","openUBMC 社区技术委员会委员& iBMC 集群管理软件专家","content:zh:blogs:open A IInfra summit-review.md","zh\u002Fblogs\u002Fopen A IInfra summit-review.md","zh\u002Fblogs\u002Fopen A IInfra summit-review","\u002Fcategory\u002Fblog\u002Fopen%20A%20IInfra%20summit-review\u002F640.webp","分论坛回顾 2026年4月9-10日，2026 Open AI Infra Summit 在北京举办。\nopenUBMC 社区技术委员会委员 & iBMC 集群管理软件专家黄晗，在超节点生态分论坛发表《基于 openUBMC 打造超节点硬件智能管理平台》主题演讲，分享开源体系下硬件智能管理最新实践，以标准化方案破解智算集群运维痛点，引发行业广泛关注。\n  智算规模化发展，运维标准供需失衡凸显 随着智算集群快速扩张， 硬件模块化、供应多元化 趋势明显，也对 BMC 带外管理提出新要求： 以灵衢为代表的高速互联技术普及，推动超节点Scale-up架构快速落地，统一内存语义技术进一步实现硬件资源池化，BMC随之面临可组合解耦基础设施（CDI）的管理挑战，以Redfish、Sunfish等BMC北向模型，正在突破传统单机管理的物理边界，为超节点多设备协同管理提供了技术基础。\n  与此同时，用户对统一设备北向运维接入能力的需求日益迫切，但现有标准难以适配新一代智算硬件的复杂场景：整机与部件厂商虽希望通过差异化构建竞争力，却因缺乏统一规范导致北向接口参差不齐，形成用户统一运维诉求与厂商差异化规划之间的行业鸿沟。 以互联网为代表的客户趋向硬件与BMC固件规范白盒化，却未形成全行业统一标准，一方面导致各厂商需基于同一代码基线适配多套客户规范，代码复用率极低，研发与适配成本居高不下；另一方面，用户运维系统仍需针对设备能力差异做定制化适配（如屏蔽不支持的功能），进一步推高设备接入与运维开发成本。  以服务器硬件指标采集为例，不同客户在采集范围上各有定义，采集方式也呈现碎片化： ➣  采集范围：无统一界定  ➣  采集方式： IPMI传感器 自定义rest接口下载csv文件 自定义redfish查询接口 其他定制化方式 构建超节点多BMC协同底座，CDI资源透明管理 针对超节点管理的核心痛点，openUBMC 从 软件架构层面 给出针对性解决方案： 统一超节点计算域与交换域的设备管理对象模型，并基于统一模型实现高性能数据同步，进而实现超节点系统在资产、故障、能效等维度的多节点协同管理，让 CDI 资源可被上层运维系统透明感知、统一调度。\n图三 以标准筑基，以社区赋能 AI 智能运维 面对行业痛点，openUBMC 以开源生态为底座，从标准协同与技术实现 双重维度 给出系统性解决方案： 接轨国际标准 \nopenUBMC社区提前布局技术预研，平台满足国际主流标准，为北向运维接入提供稳定、通用的基础能力。 共建行业统一标准 \n联合行业标准组织、用户、整机及部件厂商共建统一北向标准，当前正在围绕灵衢部件、DPU等关键部件制定管理接口规范，同步搭建测评认证体系，相关标准在社区优先落地并实现 100% 复用，以“社区 + 标准”推动产业协同创新。\n  标准化遥测接口，赋能 AI 运维闭环 \n通过标准化流式遥测接口与统一指标定义，用户运维系统可以无缝对接不同厂商的设备，采集高精准、低时延的数据，支撑 AI 运维系统完成 “收集–分析–决策–执行”全流程闭环。\n  \n数据主动推送，重构硬件运维效能\n  相比传统轮询模式，openUBMC采用的主动推送模式优势显著： 分层架构，被采集侧主动上报，无需采集侧频繁轮询； 采集侧与被采集侧仅一次订阅交互，大幅降低交互开销； 亚秒级实时采集并推送，无采样盲区，保障数据实时性； 通过数据主动推送，用户运维系统可实现从硬件到固件的全方位可观测，经过LLM训练推理，硬件运维管理从传统的故障被动响应升级为主动预防，同时支撑系统负载与能耗的深度调优，为智算集群高效稳定运行提供坚实保障。 携手共筑硬件管理统一标准 openUBMC 社区诚邀整机、部件、云厂商及行业用户： 携手共建算力基础设施硬件管理北向统一标准，使能产业高质量发展！ 欢迎加入openUBMC社区Interface SIG，共商标准、共建生态、共启智算硬件管理新未来。 Interface SIG： https:\u002F\u002Fwww.openubmc.cn\u002Fzh\u002Fsig\u002Fsig-interface",[48],{"_path":57,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":58,"description":59,"date":60,"category":13,"author":61,"_type":18,"_id":65,"_source":20,"_file":66,"_stem":67,"_extension":23,"coverImage":68,"plainText":69,"authorNames":70},"\u002Fzh\u002Fblogs\u002Fbaiao-websol","浏览器直达服务器串口：百敖基于 openUBMC 的 Web SOL 技术实践","在服务器运维中，当系统宕机、无法启动或网络中断时，串口控制台往往是诊断和恢复的核心途径。传统方式依赖专用客户端软件，部署复杂、跨平台不便，尤其在紧急场景下效率低下。\n为此，南京百敖团队基于 openUBMC架构，实现了 Serial Over LAN（SOL）功能的 Web 化迁移： 如下图，在浏览器访问BMC串行接口及系统串行接口：","2026\u002F04\u002F14",[62],{"name":63,"description":64},"汪涛","南京百敖软件有限公司技术总监，openUBMC技术委员会委员，在BMC、BIOS等固件领域从事研发14年，多次承担国家科技支撑计划，拥有丰富的服务器固件领域研发经验。","content:zh:blogs:baiao-websol.md","zh\u002Fblogs\u002Fbaiao-websol.md","zh\u002Fblogs\u002Fbaiao-websol","\u002Fcategory\u002Fblog\u002Fbaiao-websol\u002F%E5%9B%BE%E4%B8%80.png","引言 在服务器运维中，当系统宕机、无法启动或网络中断时，串口控制台往往是诊断和恢复的核心途径。传统方式依赖专用客户端软件，部署复杂、跨平台不便，尤其在紧急场景下效率低下。\n为此，南京百敖团队基于 openUBMC架构，实现了 Serial Over LAN（SOL）功能的 Web 化迁移： 用户无需安装任何软件，直接在浏览器中访问服务器串口控制台。  如下图，在浏览器访问BMC串行接口及系统串行接口：   本文分享这一功能的完整技术实践，包括架构设计、关键挑战及解决方案，以及在百敖 openUBMC 商业版中的集成经验。 架构设计：分层构建可靠的 Web SOL 系统 在实现浏览器化串口管理的过程中，我们面临多项嵌入式 Web 系统常见的难题。这些挑战直接指导了架构选型，最终形成清晰的三层设计： 前端界面层、网关层与后端服务层 。这种分层不仅实现了功能，还确保了兼容性、安全性和性能。  1. 前端界面层：利用Vue框架集成xterm.js 初期尝试直接将串口原始数据输出到 HTML 时，遇到了严重渲染异常——字符错乱、ANSI\u002FVT 控制序列（如光标定位、清屏）无法解析，导致显示与物理终端完全不一致。这直接暴露了普通 Web 元素处理复杂终端序列的局限性。 因此，我们选用 Vue.js 构建单页应用，并集成 xterm.js 作为终端仿真核心。xterm.js 能准确解析并渲染控制序列，支持色彩、滚动等完整特性。同时，通过 WebSocket 实现实时双向通信，并添加自动重连机制，确保连接稳定性。 2. 网关层：安全与协议兼容的必然选择 Web SOL 需要在浏览器与后端间建立持久双向通道，同时必须应对嵌入式环境的资源限制和安全需求。我们早期在 WebSocket 处理上遇到兼容性问题，因此需要更好的解决方案。 openUBMC中集成了Nginx，因此它成为理想选择：它高效处理 TLS 1.2\u002F1.3 加密传输、WebSocket 协议升级与代理转发。同时，集成 JWT 身份验证、IP 访问控制及严格 CSP 策略，提供统一的安全入口和流量分发能力，避免直接暴露后端服务。 3. 后端服务层：高并发与底层操作的权衡 后端的核心难点在于高效管理多个 WebSocket 会话，同时精准操作底层 TTY 设备。 Lua WebSocket库在Skynet协程环境下会出现阻塞异常，而串口配置中还遇到回声干扰（如“阶梯式换行”）和硬件端口识别问题。 为此，我们优化了WebSocket的实现，并兼容了Skynet的协程框架，重构事件处理逻辑，最大化地复用了Skynet高并发能力来管理多个WebSocket对话。 串口通信模块则通过 C 扩展实现：使用  cfmakeraw()  将 TTY 设为 raw 模式，禁用内核级处理（如回车转换），采用读写分离架构避免数据回显干扰。同时通过对接openUBMC的SerialManagement 服务，支持了BMC与服务器OS的串口切换能力，让Web SOL的能力进一步增强。 通过层层攻克上述挑战，这套三层架构最终在 openUBMC 上完美落地了 Web SOL 系统，实现了高效、可靠且安全的浏览器化串口管理。 产品化集成：落地百敖 openUBMC 商业版 功能开发完成后，我们将其模块化封装：前端资源、Nginx 配置、后端服务通过openUBMC的Conan体系构建和管理。最终结合百敖自研的其他能力（实时监控界面、灵活的传感器告警策略等），基于openUBMC 25.06 社区发行版推出了百敖的openUBMC商业发行版。   总结与展望 本次 Web SOL 的成功实践，充分验证了 openUBMC 架构的灵活性和扩展性：其基于 Skynet、D-Bus、Lua\u002FC 混合开发以及模块化构建体系，能够高效支持各类新型运维特性的快速集成与落地，为服务器远程管理提供了广阔的创新空间。 同时，这次从底层 TTY 操作到 Web 前端的完整开发过程，也标志着百敖团队已具备深厚的 openUBMC 技术积累，能够为客户提供从功能定制、性能优化到安全加固的全栈开发服务，满足多样化的国产化服务器管理需求。 未来，我们将继续基于 openUBMC 平台迭代更多实用特性。我们相信，通过持续的技术迭代与生态建设，百敖openUBMC将为服务器远程管理提供更加强大、便捷且安全的解决方案，助力企业数据中心实现更高水平的运维自动化与智能化。",[63],{"_path":72,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":73,"description":74,"date":60,"category":13,"author":75,"_type":18,"_id":79,"_source":20,"_file":80,"_stem":81,"_extension":23,"coverImage":82,"plainText":83,"authorNames":84},"\u002Fzh\u002Fblogs\u002Fefficiency-improved150","效率提升150%！基于openUBMC的高密存储服务器产品化实践","概要：\n在 AI 与大数据时代，海量数据的存储需求催生了高密度存储服务器的蓬勃发展。然而，当一台服务器容纳的硬盘数量从传统的十几块跃升至 60甚至 70 块时，带外管理系统（BMC）便面临着前所未有的并发压力与性能挑战。\n如何让 BMC 在如此庞大的硬件规模下依然保持高效、稳定、流畅的管理体验，成为产品化落地的关键一环。本文将分享我们基于 openUBMC 与社区协作，成功实现高密存储型服务器产品化的实践经验。",[76],{"name":77,"description":78},"华从辉","长江计算 BMC 系统工程师，从事8年嵌入式软件开发，深耕鲲鹏生态，主导多款服务器BMC 及整机柜 RMC 研发。","content:zh:blogs:efficiency- improved150.md","zh\u002Fblogs\u002Fefficiency- improved150.md","zh\u002Fblogs\u002Fefficiency- improved150","\u002Fcategory\u002Fblog\u002F20250807\u002F%E6%95%88%E7%8E%87%E6%8F%90%E5%8D%87150\u002F1212%20(1).png","概要：  \n在 AI 与大数据时代，海量数据的存储需求催生了高密度存储服务器的蓬勃发展。然而，当一台服务器容纳的硬盘数量从传统的十几块跃升至 60甚至 70 块时，带外管理系统（BMC）便面临着前所未有的并发压力与性能挑战。  \n如何让 BMC 在如此庞大的硬件规模下依然保持高效、稳定、流畅的管理体验，成为产品化落地的关键一环。本文将分享我们基于 openUBMC 与社区协作，成功实现高密存储型服务器产品化的实践经验。 背景：当“盘多多”遇上 BMC 管理瓶颈 我们的目标产品是一款典型的高密存储服务器，其核心特点在于极致的存储密度： 双 RAID 卡管理高达 70 块硬盘：  \n包括 60 块 3.5 英寸机械盘和 10 块 2.5 英寸盘。 复杂的硬件拓扑：  \n4 个 15 盘位背板通过二级扩展架构连接，支持跨槽位即插即用。 独特的散热设计：  \n采用双型号风扇分区调速，前置风扇负责主板\u002FPCIe 卡散热，后置风扇专责 3U 硬盘仓散热。 在基于 openUBMC 进行开发初期，我们遇到了一个严重影响用户体验的核心痛点：首次上电或 OS 重启后，Web 界面刷新全部 60+ 块硬盘的带外信息需要长达 20分钟以上!对于运维人员而言，这意味着漫长的等待，极大地降低了服务器的可用性和管理效率。 问题与挑战：多任务并发下的性能瓶颈 深入分析发现，这一痛点背后是多重挑战的叠加： 挑战一：海量任务并发阻塞 现象：  满配 70 盘时，BMC 需要同时处理超过 200 个并发任务，包括RAID 信息刷新、硬盘点灯、SMART 信息读取等。 根因：  有限的 I²C 总线带宽无法承受瞬间爆发的高并发通信压力，导致任务大量阻塞和超时。   挑战二：多RAID 场景下的数据获取失败 现象：  在双 RAID 卡场景下，BMC 概率性地无法获取完整的 RAID 数据。 根因:  该场景独特,强依赖于闭源组件  hwproxy  和  raid sdk ,原生机制存在兼容性问题。 挑战三：硬件适配与部署效率低下 现象：  4个相同的 15 盘背板需支持跨槽位即插即用，但传统方案需为每个槽位编写不同的 CSR 配置，物料成本高且部署繁琐。 根因：  多部件 (如扩展板、Riser卡)的 CSR包需独立升级，每次升级都伴随 BMC 重启，耗时费力。 openUBMC 方案:社区协作驱动的创新优化 面对这些挑战，我们采取了“本地(场景发现 +开源优化) +社区 (闭源优化)”的协作模式，充分利用 openUBMC 的开放性和灵活性，实施了一系列针对性优化。 功能一：多任务并发访问优化 无效冗余优化：  重构硬盘点灯逻辑，将非必要的“盘在位”判断优化为精准的“盘定位”，并减少点灯状态确认次数，单次操作节省数百毫秒，累积效应显著。 任务分级运行：  对硬盘任务进行优先级划分，高优先级任务 (如盘符匹配)优先执行，次要任务(如日志收集)延长刷新周期，有效降低瞬时I²C 通信压力。 多任务隔离：  在非首次上电场景下，优先完成 RAID 任务后再更新硬盘信息，避免任务相互干扰。  功能二：自适应盘符机制 问题解决：  利用 openUBMC 强大的 CSR 模型和字符串操作能力，设计了一套基于  Connector.Slot  与  SR  公式的自适应公式。 实现效果：  无论 15 盘背板插入哪个槽位，系统都能根据物理链路自动计算并生成正确的对外盘符（如 Disk10-Disk24），真正实现了跨槽位即插即用，省去了硬件拨码开关的成本。  功能三：高效 CSR 部署 问题解决：  借助社区推出的 BMC Studio 图形化工具，将多个独立的 CSR 包打包成一个 ALL-in-One 的升级包。 实现效果：  部署方式从“多次升级、多次重启”转变为“一次升级、一次重启”，极大提升了多部件产品的部署效率。  看得见的价值：从 20 分钟级到 8 分钟的飞跃 我们的优化带来了立竿见影的效果 ，用数据证明了方案的有效性： 性能提升：  60+ 盘信息刷新时间从 20+ 分钟缩短至8分钟，效率提升150%+。 稳定性增强 ：  双 RAID 场景下 RAID 数据获取成功率从概率性失败提升至100%稳定获取 。 部署提效：  CSR 多部件部署时间大幅缩短，运维效率显著提升。 成本节约 ：  自适应盘符机制节省了硬件拨码物料成本，并简化了现场运维部署流程。 此外，整个项目过程中，我们向openUBMC社区贡献了38条经验总结与优化建议，形成了良性的社区共建循环。 5. 共建：打造更强大的 openUBMC 存储生态 高密存储服务器的挑战只是 openUBMC 应用场景的一个缩影。我们相信，openUBMC的未来在于每一位开发者的共同参与和贡献。 在此，我们诚挚邀请各位开发者、合作伙伴加入 openUBMC 社区： 如果您也在进行高密存储、AI 服务器或其他创新硬件的产品化开发，欢迎分享您的挑战与解决方案。 如果您对 BMC 的性能优化、硬件抽象、自动化部署等方向有独到见解，期待您的代码贡献。 让我们一同将“问题场景”前置为“需求场景”，推动社区基线版本更贴合产业实际，共同构建一个繁荣、高效、稳定的开源 BMC 生态！ 加入我们，让每一次“盘多多”的挑战，都成为 openUBMC 进化的新动力！",[77],{"_path":86,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":87,"description":88,"date":60,"category":13,"author":89,"_type":18,"_id":93,"_source":20,"_file":94,"_stem":95,"_extension":23,"coverImage":96,"plainText":97,"authorNames":98},"\u002Fzh\u002Fblogs\u002Fwangxun-1GE","部件适配新模式：网迅科技基于南向部件规范的1GE网卡适配实战","在服务器硬件生态飞速发展的今天，BMC（基板管理控制器）作为硬件远程管控的核心中枢，其部件适配效率直接关乎产品的上市节奏与市场竞争力。长期以来，部件厂商在传统 BMC 适配模式下，饱受部件繁杂、软件栈碎片化、协议标准不一、调试手段缺失等痛点困扰。",[90],{"name":91,"description":92},"王晨","北京网迅科技有限公司工程师，openUBMC Component Drivers SIG Maintainer。深入参与 openUBMC 南向部件驱动开发。","content:zh:blogs:wangxun-1GE.md","zh\u002Fblogs\u002Fwangxun-1GE.md","zh\u002Fblogs\u002Fwangxun-1GE","\u002Fcategory\u002Fblog\u002Fwangxun-1GE\u002F%E5%9B%BE%E4%B8%80.png","引言 在服务器硬件生态飞速发展的今天，BMC（基板管理控制器）作为硬件远程管控的核心中枢，其部件适配效率直接关乎产品的上市节奏与市场竞争力。长期以来，部件厂商在传统 BMC 适配模式下，饱受部件繁杂、软件栈碎片化、协议标准不一、调试手段缺失等痛点困扰。 北京网迅科技有限公司作为网卡厂商，依托 openUBMC 社区南向部件规范，独立完成了 1GE 网卡的适配落地。 本文将从网卡厂商实践视角出发，深度拆解传统适配模式的行业痛点，系统阐述南向部件规范的技术革新优势，完整呈现 1GE 网卡适配的全流程路径，并结合实践提出生态共建的展望，为硬件行业的开源适配提供可复用的参考方案。 关于网迅科技：专注芯片设计的网络硬件实力派 网迅科技成立于 2014年5月，专注集成电路高端芯片设计，提供网络产品解决方案，凭借多年技术沉淀，构建了覆盖 100\u002F40\u002F25\u002F10\u002F1GE 的全系列网卡芯片及配套网卡产品矩阵。此次分享的核心产品——1GE 网卡，提供 1 口\u002F2 口\u002F4 口多端口选择，支持 NCSI over MCTP over SMBus 进行带外管理，可充分满足服务器场景的多样化管理需求。 传统 BMC 适配四大痛点：制约厂商效率的关键瓶颈 网迅科技在网卡 BMC 适配过程中，深刻感受到传统模式带来的多重挑战，这也是行业内众多硬件厂商共同面临的难题： 适配工作量巨大：  网卡产品型号丰富，需确保每一款网卡适配不同整机商的 BMC 环境，每新增一款网卡，部件商都要投入大量人力进行 BMC 驱动适配与兼容性验证，研发周期被大幅拉长。 软件栈碎片化：  整机商 BMC 软件栈标准不一，部件厂商需投入大量精力学习不同架构，全量适配难度极高。 协议标准不统一：  各整机商对网卡管理协议的要求存在差异，一款机型上完成全量开发验证的周期漫长。 调试能力缺失：  缺乏自主调试手段，网卡固件潜在问题易流入下游环节，排查与整改成本高昂。 南向部件规范：创新模式下的适配革新方案 南向部件规范的出现，以开源协作模式打破传统适配的封闭壁垒，网迅科技在实践中切实体会到四大核心优势： 标准化接口降门槛：  规定了服务器部件接口要求，对服务器部件的驱动接口信息、部件模型信息和部件描述信息进行标准化，由 CSR 承载，并提供开发指导，让部件厂商可直接基于规范开发驱动，无需适配不同整机商的 BMC 软件栈，降低开发门槛，减少重复的硬件适配工作。 模块化开发提效率：  驱动代码模块独立封装，按照部件类型分为网卡部件管理接口模型、xPU 部件管理接口模型，RAID 部件管理接口模型等，部件厂商研发人员无需掌握 BMC 全量知识，通过不同部件管理接口即可对资源进行操作，能够聚焦部件本身，快速完成驱动开发。 高自由度促创新：  减少了新协议预研和功能迭代对 BMC 厂商的依赖，且驱动开发阶段即可直接通过 BMC 作为调试测试工具，简化验证流程，使部件厂商能自主优化产品的能力。 开源生态共赋能：  部件厂商通过 openUBMC 社区自主发布驱动，整机商无需重复开发，直接集成即可实现兼容，形成“部件厂商开发、全行业共享”的良性生态。  网迅 1GE 网卡适配实战：从驱动开发到测试验证的全流程 基于南向部件规范，网迅科技完成 1GE 网卡适配的全流程落地，形成可直接复用的技术路径： CSR准备及驱动配置：  在 csr 文件中指定网迅自研驱动，通过 NCSI over MCTP over SMBus 协议实现带外管理功能。\n  拓扑与层级设计：  开发平台基于米尔 Hi3093 开发板，依托南向部件框架的层级加载机制，root.sr 增加 I2c_8 拓扑，以及对应 Connector 对象，选择非天池模式加载 1GE 网卡。\n  核心功能开发：  聚焦厂商实现层目录进行针对性修改，无需关注框架底层细节；针对网卡 oem 功能补充指令，优化网卡信息获取（如 get vpd pn，get temperature 等 oem 命令）。\n  多场景测试验证：  完成 SMBus 通信指令收发、数据传输的全流程验证，并进行长期稳定运行的可靠性测试，针对性覆盖服务器 DC，AC 上电 \u002F 掉电，BMC 冷 \u002F 热复位等复杂工况，充分验证自研驱动在各类严苛运行条件下的稳定运行能力。 追踪调试优化：  利用框架自带的调试工具，快速定位驱动问题，提升开发迭代效率。\n    行业展望：共建开源适配新生态 在实践中，网迅科技也发现南向部件规范生态仍有完善空间，期待与行业伙伴共同发力： 标准持续迭代：  南向接口标准仍在持续迭代，需跟进最新标准动态，及时更新适配方案。 文档体系完善：  社区文档体系尚不完善，期待更多厂商加入，丰富技术资料与开发指南。 工具化辅助：  呼吁工具化辅助开发工具的落地，进一步提升部件驱动开发效率。 统一测试认证：  建议共建统一的测试用例集与标准认证体系，保障驱动质量与稳定性。 结语 南向部件规范以开源协作重构了硬件适配的底层逻辑，为部件厂商提供了更高效、更灵活的适配路径。网迅科技的 1GE 网卡适配实践，不仅验证了该模式的可行性与优越性，更展现了开源生态“共建、共享、共赢”的核心价值。 未来，网迅科技将持续深耕 openUBMC 社区，积极参与南向部件规范的完善与推广，与行业伙伴携手推动服务器硬件管理生态的标准化、高效化发展。",[91],{"_path":100,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":101,"description":102,"date":103,"category":13,"author":104,"_type":18,"_id":108,"_source":20,"_file":109,"_stem":110,"_extension":23,"coverImage":111,"plainText":112,"authorNames":113},"\u002Fzh\u002Fblogs\u002FAlgorithm-Explained","让AI真正“防宕机”：openUBMC 故障预测系统的指标误区澄清与无感运维应用","当前，我们在 openUBMC 中构建了故障预测的完善体系，包含内存、硬盘、光模块、链路的故障预测与诊断技术，进行智能运维决策。","2026\u002F03\u002F19",[105],{"name":106,"description":107},"张文宇","华为AI算法工程师，统计学博士，深度参与openUBMC算法设计与开发。","content:zh:blogs:Algorithm Explained.md","zh\u002Fblogs\u002FAlgorithm Explained.md","zh\u002Fblogs\u002FAlgorithm Explained","\u002Fcategory\u002Fblog\u002F%E7%AE%97%E6%B3%95%E7%A7%91%E6%99%AE\u002F%E5%9B%BE%E7%89%871.png","概要 当前，我们在 openUBMC 中构建了故障预测的完善体系，包含内存、硬盘、光模块、链路的故障预测与诊断技术，进行智能运维决策。 在 openUBMC 的智能运维探索中，一个看似平庸的“双50%”指标，背后竟藏着远超随机猜测的算法价值。本文带你穿透数据表象，理解精准率与召回率的真实含金量。 故障预测中的指标真相 在现代数据中心中， BMC（Baseboard Management Controller） 是服务器的“隐形守护者”。随着 AI 运维（AIOps）的普及，利用 BMC 采集的带外数据（如带内错误事件、电流波动、风扇转速、温度）进行故障预测已成为核心能力。 在阅读相关的技术论文时，我们常看到算法评估指标为精准率 \u002F 覆盖率 \u002F F1分数（Precision\u002FRecall\u002FF1-score）：  图片来源：Wang X, Li Y, Chen Y, et al. On workload-aware dram failure prediction in large-scale data centers C \u002F\u002F2021 IEEE 39th VLSI Test Symposium (VTS). IEEE, 2021: 1-6. 而部分模型的指标甚至都在 50% 以下。这似乎有点不符合我们的直觉： 就算随机抛一枚均匀硬币做猜测，指标是不是也能轻松达成 50%？为什么模型的指标却如此之低？ 简单直接的回答是  【精准率50% & 覆盖率50%】和【随机抛均匀硬币猜测】不一定等效，甚至通常不等效。 要回答这个问题，我们首先得弄清楚：在故障预测的二分类模型中，这些数字究竟是怎么算出来的。  故障预测的二分类模型 在 BMC 场景中，二分类模型本质上是在做“预警决策”： 正类 (Positive) ：预测设备即将在未来一段时间内发生内存宕机或电源故障。 负类 (Negative) ：预测设备运行正常。 基于预测与真实结果的重合情况，产生了四个原子指标： TP (真阳性) ：成功预警了即将发生的故障。 FP (假阳性) ：虚警，设备正常却报了警。（备注：误诊） TN (真阴性) ：正确判断设备平安无事。 FN (假阴性) ：漏报，设备坏了但模型没发现。（备注：漏诊）  实际为正类 实际为负类 总和 预测为正类 TP (True Positive) FP (False Positive) 预测为正的样本数 预测为负类 FN (False Negative) TN (True Negative) 预测为负的样本数 总和 真实正样本数 真实负样本数 样本总数  核心评估指标的计算方式 1. 精准率 (Precision) 精准率（Precision）：代表“不乱报”。 计算公式为： Precision = TP \u002F (TP + FP) 它是【正确正样本数】占【预测为正的样本数】的比例，衡量的是在所有“报警”中，有多少是真的？它决定了运维人员的信任度。 2. 覆盖率（Recall） 覆盖率（Recall）：代表“不漏掉”。 计算公式为： Recall = TP \u002F (TP + FN) 它是【正确正样本数】占【真实正样本数】的比例，衡量的是在所有“真实故障”中，有多少被提前抓住了？它决定了系统的安全性。 3. F1分数 (F1-Score) F1分数 (F1-Score)：精准率和覆盖率的“调和平均数”。 在实际操作中，精准率和覆盖率往往是一对“冤家”：你为了不漏掉故障（提高覆盖率）而扩大报警范围，就不可避免会产生更多误报（降低精准率）。为了衡量两者的整体平衡性，我们引入了 F1分数： F1 = 2 * (Precision * Recall) \u002F (Precision + Recall) 为什么要用调和平均，而不是普通的算术平均？ \n因为调和平均对“极小值”非常敏感。如果你的精准率是 90% 但覆盖率只有 1%（空有精度但几乎漏掉了所有故障），算术平均还有 45.5%，但 F1 分数会迅速跌落至约 2%。这能有效防止模型通过“极端偏科”来刷分。 注 ：F1 分数与我们开头关心的问题没有必然联系，仅顺便做普及。  问题分析：为什么 50% 不等于“抛硬币”？ 假设我们监测 1000 台设备，其中只有 10 台会发生故障（即正样本占比仅为 1%）。我们来看看“抛硬币”和“模型预测”的巨大差异： 1. 抛硬币的“盲目性” 如果通过抛一枚均匀的硬币来决定设备是否有故障（即 50% 的概率猜故障，50% 的概率猜正常）：  实际为正 实际为负 总和 预测为正 5 495 500 预测为负 5 495 500 总和 10 990 1000 覆盖率 ：10 台故障设备中，因为运气猜中 5 台，覆盖率 = 50%。 精准率 ：一共猜了 500 台设备有故障，但其中只有 5 台是真的。精准率 = 5 \u002F 500 =  1% 。 结论 ：在正样本占比低时，抛硬币虽然能拿到 50% 的覆盖率，但精准率会低得离谱。 2. “50% 精准率 + 50% 覆盖率”模型的含金量 如果一个算法能跑出 50% 精准率 + 50% 覆盖率：  实际为正 实际为负 总和 预测为正 5 5 10 预测为负 5 985 990 总和 10 990 1000 这意味着报出的 10 个故障里，有 5 个是真的；同时抓住了全场 10 个故障中的 5 个。 对比抛硬币 1% 的精准率，这个算法的预测能力是抛硬币的 50 倍；预测为正的总样本数为 10，意味着这个算法比随机猜测更加谨慎！ 这就是为什么在故障预测（通常是极端不平衡数据）的论文中，精准率和覆盖率即便都在 50% 左右，也往往意味着模型捕捉到了极其深刻的特征规律，而非随机运气。 额外思考 ：我们的举例假设是正样本占比低，这符合故障预测数据“正常样本多、故障样本少”的普遍规律。如果正负样本比例均衡，或者正样本占比高于负样本时，与随机抛硬币相比的结果会如何？欢迎补充结论！  进阶思考：在 openUBMC 中，如何根据运维成本调整预测策略？ 在正样本比例低的数据中，精准率 50% 和覆盖率 50% 虽然远优于随机猜测，但未必是“最优决策”。模型指标的取舍，本质上是一场关于“运维成本”的博弈。 在 openUBMC 的实际工程中，最典型的应用场景莫过于 DDR 内存故障预测。现代服务器内存均支持 ECC（纠错码）机制。当内存位翻转在纠错能力范围内时，系统会上报可纠正错误（Correctable Error, CE），此时业务运行不受影响；然而，一旦错误模式超过纠错上限（如同一条带内多位翻转），则会演变为不可纠正错误（Uncorrectable Error, UCE），直接触发系统致命异常（如 Linux 的 Kernel Panic），导致业务瞬间宕机。 业界研究表明，CE 是 UCE 的重要前兆，尤其是高频 CE、多列 CE 等特定模式对 UCE 具有极强的启示作用。基于这些 CE 特征构建的二分类模型，其指标取舍直接决定了运维的经济性： 1. 追求高精准率 运维动作 ：在 上篇文章（openUBMC：基于BMC的AI故障预测系统构建及应用） 中，我们提到故障预测最常见的应用方式是与业务联合，在业务调度间隙替换即将失效的服务器，从而实现业务无损。在追求高精准率时，运维仅在模型极度确信故障将发生时，才通知现场备件更换。 成本考量 ：对于超大规模集群（如 10 万节点以上），如果精准率过低，每日产生的“虚假预警”将导致运维团队陷入无穷无尽的无效排查中，甚至导致备件库存非正常耗尽。此时，我们宁愿覆盖率只有 30%（只抓最明显的故障），也要保证精准率在 80% 以上，以确保每一次下场维修都是“有的放矢”。 2. 追求高覆盖率 运维动作 ：在 上篇文章（openUBMC：基于BMC的AI故障预测系统构建及应用） 中，我们提到我们会将故障预测与芯片 RAS 结合，利用芯片的冗余修复能力，实现硬件故障无感修复。在追求高覆盖率时，一旦预测到 UCE 风险，运维会 (a) 尽早更换内存条, 或 (b) 直接由BMC侧调用芯片的RAS能力修复部件即将失效的区域。 成本考量 ： 更换内存条 ：如果承载的是核心数据库业务，宕机一分钟的损失远超一根内存条的成本。此时，即便模型精准率仅为 30%（即 10 次报警中仅 3 次是真的），但只要覆盖率达到 80%，就能避免绝大部分非计划停机，这种“过杀”策略在经济上是完全划算的。 调用芯片的 RAS 能力 ：这种方案在不中断业务的情况下对硬件故障进行细粒度的修复，不需要隔离整服务器，即使精准率较低导致误隔离，也仅仅是影响部件冗余资源的使用，对于业务运行几乎无成本损失。   在 BMC 故障预测的二分类世界里，没有绝对完美的指标，只有最契合业务场景的平衡点。真正能让 AI 赋能运维的，是我们在深入理解 CE 与 UCE 的物理特性、衡量业务宕机与人工成本后，对精准率与覆盖率进行的最后那次温情调优。",[106],{"_path":115,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":116,"description":117,"date":118,"category":13,"author":119,"_type":18,"_id":123,"_source":20,"_file":124,"_stem":125,"_extension":23,"coverImage":126,"plainText":127,"authorNames":128},"\u002Fzh\u002Fblogs\u002FUBMC-AI","openUBMC： 基于BMC的AI故障预测系统构建及应用","传统数据中心由hypervisor虚拟化层对硬件资源进行池化，单台设备故障可通过VM虚机快速倒换避免业务中断。AI\u002FHPC大规模并行计算场景，单设备故障会导致集群单次计算无法完成，进而导致整集群训练中断，硬件可靠性是影响系统可用度的重要因素。大模型训练中常用的办法是通过断点续训机制快速重拉业务，这仍是一种事后补救办法，无法避免整集群业务中断。通过AI故障预测提前识别硬件失效风险并无感容错是业界重要的技术研究方向，本文重点介绍基于BMC的AI故障预测系统构筑，以及如何与芯片RAS、业务结合提升集群系统可用度。","2026\u002F03\u002F13",[120],{"name":121,"description":122},"王校文","华为iBMC故障管理专家，十年芯片RAS、AI智能运维和系统可靠性工作经验，先后负责华为鲲鹏\u002F昇腾多个代次产品RAS和系统可靠性设计。","content:zh:blogs:UBMC-AI.md","zh\u002Fblogs\u002FUBMC-AI.md","zh\u002Fblogs\u002FUBMC-AI","\u002Fcategory\u002Fblog\u002FUBNC-AI\u002F%E5%9B%BE1.png","1.背景摘要 传统数据中心由hypervisor虚拟化层对硬件资源进行池化，单台设备故障可通过VM虚机快速倒换避免业务中断。AI\u002FHPC大规模并行计算场景，单设备故障会导致集群单次计算无法完成，进而导致整集群训练中断，硬件可靠性是影响系统可用度的重要因素。大模型训练中常用的办法是通过断点续训机制快速重拉业务，这仍是一种事后补救办法，无法避免整集群业务中断。通过AI故障预测提前识别硬件失效风险并无感容错是业界重要的技术研究方向，本文重点介绍基于BMC的AI故障预测系统构筑，以及如何与芯片RAS、业务结合提升集群系统可用度。 2.AI故障预测部件选择 一台服务器包含CPU、内存、电源、风扇等众多部件，如何选择预测的部件至关重要。首先需要分析硬件故障的可预测性，业界常用的指标是突发\u002F非突发故障的比例，突发故障即硬件失效前没有任何征兆，这种故障通常无法预测，非突发故障指硬件失效前有征兆（如CE、误码等），这种故障可以进行AI预测。基于数据统计分析DDR、HBM、硬盘故障非突发比例超过50%（如图1所示），AI预测的可能性较大。  其次，需要依据器件的失效概率和影响进行评估，优先对失效率高、故障业务影响大的部件进行故障预测。如图2所示，介质（含DDR、HDD\u002FSSD）和CPU失效占比超过80%，且都会导致业务中断，因此内存、硬盘、XPU故障预测是业界重要研究方向。  3.基于BMC的AI故障预测系统构筑 构建AI在线预测系统的核心要素是预测模型训练和在线推理平台。预测模型生成即训练的过程，通常分为在线训练和离线训练，考虑到BMC只能收集单台硬件设备的日志，训练的数据量和BMC芯片处理能力均无法满足在线训练的要求，所以选择离线训练生成预测模型，集成到BMC后进行在线推理，如下图3所示。  具体实现流程和注意事项如下: 海量运行日志数据采集，可采集BMC、带内OS等运行的日志数据，需包含正常、亚健康、故障状态的日志信息，有效训练数据数量直接影响训练结果。 对日志数据进行清洗，提取预测相关的信息，提升训练的效率。如DDR故障预测则需要提取内存型号、CE、UEO、UCE等相关信息。 预测部件的训练特征向量提取，通过大数据分析、专家经验等提取有效的预测特征向量，此步骤最为关键，直接影响训练结果的精准率和覆盖率。 选择合适的训练算法，如random forest、xgboost等算法，并对算法参数进行调优，使训练的结果最优；也可以使用大模型进行训练，但需注意生成模型大小和对BMC的CPU内存资源使用。 生成预测模型，BMC集成预测模型。 BMC集成在线推理能力，将实时日志数据输入给模型得到推理结果，可以调整F1 Score来调整模型输出的精准率和覆盖率。 4.基于BMC的AI故障预测应用 4.1 故障预测与业务结合 故障预测最常见的应用方式是与业务联合，在业务调度间隙替换即将失效的服务器，从而实现业务无损，如图4所示。  具体流程如下: BMC预测到服务器2重要部件即将失效，将预测结果告知业务调度模块 业务调度模块在调度间隙将服务器2业务迁移到备份服务器，并将服务器从业务侧下线 业务调度模块将备份模块纳入业务调度，继续进行业务训练 该方案需要重点考虑预测准确率的问题，精准率低会导致误隔离节点太多进而导致系统计算资源不足，因此可以考虑结合业务性能变化等参数联合判断提升准确性。 4.2 故障预测与芯片RAS结合 另一种方案故障预测到器件即将失效后，利用芯片的冗余修复能力，实现硬件故障无感修复，此种方案不需要隔离故障服务器，如图5所示。  具体步骤如下: MC预测到重要部件即将失效，需要精准预测到可隔离的粒度，如DDR的Row等。 BMC调用芯片的RAS能力修复部件即将失效的区域，同时保证数据一致性。 此方案可以在不中断业务的情况下对硬件故障进行细粒度的修复，不需要隔离整服务器，即使精度无法做到100%有误隔离，也仅仅是影响部件冗余资源的使用，几乎无影响。 5 总结 在硬件失效率无法量级优化的情况下，AI\u002FHPC系统可用度会随着集群规模增加而线性下降，对重点部件的故障预测和业务无感容错是提升系统可用度最有效的方法之一。基于带外BMC的AI故障预测，在推理数据获取便利性、用户计算资源占用、部件精细化预测、芯片RAS结合等方面均具有优势，是业界技术研究的重要方向。",[121],{"_path":130,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":131,"description":132,"date":133,"category":13,"author":134,"_type":18,"_id":138,"_source":20,"_file":139,"_stem":140,"_extension":23,"coverImage":141,"plainText":142,"authorNames":143},"\u002Fzh\u002Fblogs\u002FBMC-supernode","openUBMC：超节点时代的 BMC 新范式","人工智能的持续发展同时驱动了智算和通算基础设施的显著变革，超节点架构成为算力的新形态，到2026年仍在持续普及应用。在此背景下，超节点的大规模硬件资源管理成为新的挑战。openUBMC基于先进的微组件架构，天然适应超节点时代的管理需求。","2026\u002F02\u002F13",[135],{"name":136,"description":137},"宋铜铃","openUBMC技术委员会主席，二十年服务器管理软件研发积淀，华为iBMC、FusionDirector奠基人，固件产业技术创新联盟发起人之一。","content:zh:blogs:BMC-supernode.md","zh\u002Fblogs\u002FBMC-supernode.md","zh\u002Fblogs\u002FBMC-supernode","\u002Fcategory\u002Fblog\u002F%E8%B6%85%E8%8A%82%E7%82%B90213\u002F%E5%9B%BE%E7%89%871.png","概要 人工智能的持续发展同时驱动了智算和通算基础设施的显著变革，超节点架构成为算力的新形态，到2026年仍在持续普及应用。在此背景下，超节点的大规模硬件资源管理成为新的挑战。openUBMC基于先进的微组件架构，天然适应超节点时代的管理需求。 01.灵衢超节点广泛应用 Agentic AI是人工智能发展的里程碑式阶段，与传统大语言模型（LLM）不同，Agentic AI的核心特征在于能够维持复杂的跨回合工作流，并在长时间跨度内积累和反思中间推理结果。在这一背景下，大容量高性能上下文存储成为智能计算系统的重要部分。然而，海量的存储需求已远超NPU\u002FGPU等加速卡的HBM容量限制，因此需要结合DRAM和SSD构建PB级超大容量、高性能上下文存储。  而超节点是实现超大规模分级存储的理想方案。昇腾超节点通过将多协议（文件、对象、块）统一到单一的管理平面，极大地降低了元数据管理的复杂性，跨跳延迟从微秒级压缩至纳秒级，最大化提升了NPU到分级存储介质的读写性能。Nvidia Rubin也采用了类似技术，把GPU、DPU、CPU、DRAM集成在一个超节点内，结合ICMS技术实现高性能上下文存储系统。 超节点在通用计算场景同样发挥着重要价值。结合灵衢超节点技术，数据库将迎来重要的架构创新，一举改写云原生数据库游戏规则。依托灵衢超节点架构和UB内存语义总线，可以做到计算、内存解耦，实现数据库多节点多活、多写，实现了极致的RTO（秒级）与写性能的数量级提升。  以上是超节点在智算、通算领域两个典型的应用案例。预计26年超节点将在不同业务场景获得广泛的应用。基于灵衢的昇腾超节点在AI训练、AI推理、AI agent应用持续发挥重要价值。鲲鹏超节点将在数据库、虚拟化、微服务、搜推、低时延应用等场景发挥重要价值。 02. 灵衢超节点技术特点 灵衢超节点基于UB总线实现CPU、NPU、DPU、SSU等算力部件高效协同，打破以“CPU为中心”的计算架构，走向“对等计算”。让数据自主流动，在合适的地方以合适的算力计算。基于合适的资源配比，形成匹配业务负载的最佳计算系统。  灵衢超节点的六大核心特征充分体现了其技术颠覆性 ： 总线级互联  \n打破传统CPU为中心的互联架构，实现 CPU、NPU、SSU、DPU 等组件的 \"平等互联\"，让数据像在单条总线上传输一样高效。 平等协同  \n采用去中心化架构，所有设备都是 \"平等节点\"，NPU可以直接找 DPU、NPU 可以直接找内存，无需通过 CPU 中转。 全量池化  \n所有内存、算力都成为\"资源池\"，支持跨节点的算力、内存、存储资源动态分配与迁移。 协议归一 \n统一数据中心内的各种协议（PCIe、NVLink、SAS、以太网等），实现“车同轨、书同文”。 大规模组网 \n支持万卡千节点规模。 高可用 \n支持实时故障检测和自动切换，确保系统的高可靠性。 03. 超节点架构对 BMC 的新挑战 硬件管理复杂度增长 超节点架构带来的首要挑战在于硬件管理复杂度呈倍数级增长。在功率密度显著提升的背景下，超节点内部器件连接规模达到传统架构的七倍以上，导致故障传播链条更为复杂，跨域、跨层故障的定位难度也大幅增加。具体来看，这种复杂性主要体现在以下三个维度： 规模挑战： \n相比传统服务器有限的物理节点硬件对象，超节点集成了成百上千个组件单元，部件之间相互影响，故障排查范围显著扩大。 异构挑战： \n超节点融合了 CPU、NPU、DPU、SSU 等多种异构计算单元，各类组件在管理接口、监控指标和运维需求上均存在差异。BMC 必须构建统一的管理抽象能力，实现“一套接口、多样硬件”的融合管控。 多元挑战： \n超节点内部采用了灵衢（UnifiedBus）、ETH、NVMe、PCIe 等多种互连协议，要求 BMC 具备灵活、多元的管理适配与协议协调能力。 为应对上述挑战，openUBMC 在技术架构设计初期即针对超节点场景进行系统规划，引入微组件框架以增强系统扩展性与适应性。该框架通过开放消息总线实现组件互联，支持组件级、插件级与配置化三重扩展机制。同时，基于标准化接口将软件业务拆分为多个独立协同的单元，使得各模块可独立设计、演进与部署，从而为超节点环境下的智能运维奠定技术基础。 能效管理精细化与故障诊断能力升级的需求 超节点的高功率密度对BMC的功耗监控与能效管理能力提出了更高要求： 监控粒度精细化： \n动态功耗波动显著，需实现更精细的实时功耗采集与异常能耗设备的快速识别。 监测全面化： \n面对液冷复杂管路可能出现的泄漏、凝露、结晶等风险，BMC需具备对温度、压力、流量等关键参数的全面监测能力。 智能能效优化： \n超节点单柜功耗已突破 100KW，BMC 需要具备更有效的能效优化能力，降低整机柜的功耗。 同样，超节点系统的复杂性要求 BMC 具备更强的故障诊断能力： 故障传播的复杂性： \n超节点系统相比通用服务器更紧密的耦合特性，使得故障不再是简单的单点问题，而可能涉及多个组件、多个层次的复杂故障链。 实时故障检测： \n超节点的高可靠性要求 BMC 具备实时故障检测能力，能够在故障发生的第一时间发现并进行处理，最大限度减少故障对业务的影响。 openUBMC 已具备对异构硬件资源的实时监控与事件上报能力，可覆盖CPU负载、IO、内存等关键指标，并支持全系统温度趋势分析，实现硬件健康状态的动态感知。此外，平台集成了基于机器学习的故障预测算法，能够通过历史数据与实时信息分析，提前预警内存、CPU等部件的潜在故障。面向超节点场景，openUBMC 可从容应对日益增长的智能化运维需求，为系统稳定与能效优化提供可靠支撑。 04. 结语 随着超节点架构的普及，管理领域正迎来全新变革。在这一新范式下，唯有坚持开放协作，才能持续驱动算力基础设施的创新与演进。2025年，openUBMC社区已初步构建起相对丰富的南北向生态；进入2026年，我们将更聚焦于智能化管理能力的深化与拓展。未来，社区将继续紧密围绕新兴产业结构，积极推动自身演进，引领BMC技术发展，为计算生态的繁荣筑牢坚实的技术基石。",[136],{"_path":145,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":146,"description":147,"date":148,"category":13,"author":149,"_type":18,"_id":151,"_source":20,"_file":152,"_stem":153,"_extension":23,"coverImage":154,"plainText":155,"authorNames":156},"\u002Fzh\u002Fblogs\u002FLive-Review","直播回顾｜openUBMC 25.12 LTS版本解读 共建开放、高效、可靠的BMC新生态","openUBMC 25.12 LTS版本解读直播于2月3日成功举办，本次直播在华为计算视频号、华为计算B站账号、华为ICT学院公众号、黄大年茶思屋官网四大技术平台同步直播，吸引了超过600位开发者在线观看，充分体现广大开发者对 openUBMC 社区的高度关注与支持！让我们期待未来更多精彩！","2026\u002F02\u002F09",[150],{"name":34,"description":35},"content:zh:blogs:Live-Review.md","zh\u002Fblogs\u002FLive-Review.md","zh\u002Fblogs\u002FLive-Review","\u002Fcategory\u002Fblog\u002F%E7%9B%B4%E6%92%AD%E5%9B%9E%E9%A1%BE\u002F%E6%8F%92%E5%9B%BE.png","整体情况 openUBMC 25.12 LTS版本解读直播于2月3日成功举办，本次直播在华为计算视频号、华为计算B站账号、华为ICT学院公众号、黄大年茶思屋官网四大技术平台同步直播，吸引了超过600位开发者在线观看，充分体现广大开发者对 openUBMC 社区的高度关注与支持！让我们期待未来更多精彩！ 版本核心要点  1. 核心理念：开放架构，驱动高效协同 南向打破“黑盒”  \n业界首创南向驱动规范，实现部件自接入，版本“即插即用”，赋能部件商自主创新，助力整机商敏捷集成。 北向广泛兼容  \n全面兼容 Redfish、IPMI、SNMP等主流标准运维接口，并支持与 Zabbix、Ansible、Cmdlets、Nagios等运维工具无缝对接，运维生态友好。 开发提效降本  \n配套 BMC Studio 一站式开发工具链与 QEMU 仿真测试，极大简化开发流程，缩短产品上市周期。 2. 三大维度重磅升级 北向生态满足度建设：一套Basecode，对接万千生态 北向架构支持一套basecode多规范接口定制  \nRedfish、IPMI标准命令支持，主流云厂商规范基本要求全满足，定制接口可共存； Web UI 全面焕新 支持3D服务器爆炸视图，整机状态一屏总览，故障定位效率倍 新增多网口管理、温度曲线、部件健康状态可视化等实用功能； 支持多主机KVM管理（5共享+1独享），运维体验再升级； 运维软件生态打通  \n支持 Zabbix、Ansible、Nagios、Cmdlets 等主流网管系统插件。 运维能力增强：更可靠、更安全、更智能 固件升级革命性提速  \n支持多固件并行升级，某高密计算场景下总中断时间从54分钟降至20分钟，并具备异常自恢复能力。 可靠性与安全性双提升 关键部件支持“临终遗言”持久化； 新增 SPDM 认证与国密TLS支持，构建可信硬件接入； Web端支持SSO单点登录、敏感信息加密、强密码策略等； 双Host管理  \n全面支持多系统独立显示、管理及上下电，满足复杂部署需求。 南向生态建设：海量硬件，即插即用 硬件覆盖空前丰富  \n新增支持 160+款 主流硬件，包括： xPU (35款)  \nAtlas系列、华为DPU系列，VG1000\u002FDC1000，风华1号，NVIDIA L20\u002FL40\u002FT4、AMD W6800、BlueField DPU等； 硬盘 (9款)  \n华为ES系列、国产SATA、SSD、NVMe等； 网卡 (60款):  \n华为、Broadcom、Mellanox、Intel及国产网迅等全系列； 协议能力补齐  \n全面支持 MCTP、PLDM、NCSI 等标准和OEM协议，并深度适配 NVMe-MI、华为自研SSD SMART 等存储管理协议。 社区基础设施日臻完善 四层防护网已100%建成，确保LTS版本高质 社区官网、文档中心、论坛功能持续补齐，中英文内容同步建设； 社区活力高涨：贡献单位达 21家，开发者 482人，累计合入PR 5671个，Issue闭环率高达 97.32%。 欢迎加入openUBMC 下载体验：访问 openUBMC 社区官网，获取 25.12 LTS 最新版本。 参与共建：欢迎提交代码、报告Issue、参与SIG讨论，共同塑造BMC未来！ 回放连接：( https:\u002F\u002Fwww.chaspark.com\u002F#\u002Flive\u002F1235021105117437952 ) 再次感谢每一位参与者的热情与贡献！让我们携手，共建开放、繁荣的BMC新生态！",[34],{"_path":158,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":159,"description":160,"date":161,"category":13,"author":162,"_type":18,"_id":166,"_source":20,"_file":167,"_stem":168,"_extension":23,"coverImage":169,"plainText":170,"authorNames":171},"\u002Fzh\u002Fblogs\u002FopenUBMC-and-POST-Code","昆仑太科基于openUBMC的POST Code功能实现从开源社区到产业标准：openUBMC携手UBIOS引领服务器管理新纪元","POST（Power-On Self-Test，开机自检）是服务器启动过程中最关键的诊断阶段。在此阶段，系统会逐项检测 CPU、内存、硬盘、网卡、GPU 等核心硬件是否正常工作。而 POST Code 则是在此过程中由 BIOS 向 BMC 输出的一系列十六进制诊断代码，以IPMI OEM命令的方式发送POST Code到BMC，从而实现对硬件自检过程的实时监控与状态记录。以IPMI OEM命令的方式来报告硬件检测的进度和状态。\n对于运维人员和系统集成商而言，POST Code 是快速定位启动故障、提升排障效率的重要功能。","2026\u002F02\u002F03",[163],{"name":164,"description":165},"王亚洲","作者王亚洲，昆仑太科固件研发中心副总经理，openUBMC技术委员会委员，从事固件开发业务20年，做为骨干人员多次参与核高基等重点项目开发，参与多项BMC行业标准制定","content:zh:blogs:openUBMC-and-POST Code.md","zh\u002Fblogs\u002FopenUBMC-and-POST Code.md","zh\u002Fblogs\u002FopenUBMC-and-POST Code","\u002Fcategory\u002Fblog\u002Fopenubmc-and-postcode%E5%9B%BE%E7%89%87\u002F2.2%E5%9B%BE%E7%89%871.png","概要 POST（Power-On Self-Test，开机自检）是服务器启动过程中最关键的诊断阶段。在此阶段，系统会逐项检测 CPU、内存、硬盘、网卡、GPU 等核心硬件是否正常工作。而 POST Code 则是在此过程中由 BIOS 向 BMC 输出的一系列十六进制诊断代码，以IPMI OEM命令的方式发送POST Code到BMC，从而实现对硬件自检过程的实时监控与状态记录。以IPMI OEM命令的方式来报告硬件检测的进度和状态。\n对于运维人员和系统集成商而言，POST Code 是快速定位启动故障、提升排障效率的重要功能。 一、openUBMC实现POST Code支持 昆仑太科BMC团队基于 openUBMC 架构，定义了IPMI OEM命令格式和数据解析映射规则，实现了对POST Code功能的完整支持。具体包括： 实时捕获并解析POST Code  \n通过发送POST Code到BMC，精准获取 BIOS 发出的POST Code，借助定制化的解析逻辑，识别并结构化这些状态码； 可视化展示与精细化时序分析  \n在Web UI、IPMI CLI 及Redfish API中均支持POST Code的清晰展示。同时，为每一条POST Code记录关联精确的时间戳，并自动计算其相对于本次启动首个POST Code的时间偏移量，相关数据均在日志页面集中呈现，便于进行精细化的启动时序分析与故障诊断； 异常代码智能告警  \n当检测到非正常终止的POST Code，系统将自动触发告警，并推送至运维平台； 历史记录有据可查  \n每一次启动的POST Code序列都将被记录在POST Code日志，并支持一键导出，为分析偶发性启动失败或性能抖动提供了无可替代的第一手数据。 二、技术实现细节 当BIOS发送POST Code到BMC后，POST Code通过以下路径被捕获并显示。  工作原理：\nBIOS在启动时执行Power-On Self-Test，发送POST Code到BMC；\nBMC捕获并解析POST Code，识别状态码；\nPOST Code服务内关联精确时间戳，进行数据结构化存储；\n提供用户查询与导出接口，可通过Web UI、IPMI CLI及Redfish API显示；\n异常代码自动触发告警并推送至运维平台。  昆仑太科openUBMC商业发行版（昆仑BMC-U）的POST Code在设计过程中充分考虑到该功能的可靠性与易用性。采取了以下策略： 非易失存储备份  \n将POST Code历史数据存储到BMC文件系统中，即使BMC重启也不会丢失关键调试信息； 增加重试机制  \n对读取的POST Code增加重试机制，避免因临时通信错误导致数据丢失； 高速缓冲区  \n使用环形缓冲区（Ring Buffer）存储最近N 条POST Code（如 512 条），即使 BMC重启也能保留关键历史； 直观的显示  \n通过时间偏移量，运维人员能立即识别启动过程中哪个阶段耗时异常（如内存训练时间过长），POST Code页面设计易于使用，支持按照时间、数值进行检索，支持导出与删除； 灵活的访问方式  \n提供Web UI、IPMI 命令及Redfish API查询与导出POST Code数据方式； 智能告警  \n将POST Code与BMC的SEL（系统事件日志）关联，当POST Code异常结束即触发告警，便于运维人员定位故障。  三、当产品化落地 除了集成POST Code功能之外，本次昆仑太科openUBMC商业发行版（昆仑BMC-U）还在扩展外设支持、产品定制化、配套文档完善等多个方面做出改进，支持了例如IPMB定制化支持、启动速度优化等功能。 作为openUBMC开源发展委员会成员单位，昆仑太科始终是社区技术创新与生态共建的核心推动者。通过代码贡献、问题修复、技术分享与联合调试，昆仑太科与社区开发者共学共研、共促成长，持续打磨更健壮、更通用的 BMC 基础能力。 欢迎关注openUBMC 社区官网： https:\u002F\u002Fwww.openubmc.cn  \n代码仓地址： https:\u002F\u002Fgitcode.com\u002FopenUBMC",[164],{"_path":173,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":174,"description":175,"date":176,"category":13,"author":177,"_type":18,"_id":180,"_source":20,"_file":181,"_stem":182,"_extension":23,"coverImage":183,"plainText":184,"authorNames":185},"\u002Fzh\u002Fblogs\u002FopenUBMC-UBIOS","从开源社区到产业标准：openUBMC携手UBIOS引领服务器管理新纪元","在数字经济的浪潮下，基础系统软件固件作为算力基石的“操作系统”，其管理效能正面临严峻挑战。基于此，UBIOS与openUBMC实现深度耦合，旨在通过共建开放生态，从根本上破解适配、效率与安全困局，为数字化基座释放更可靠、更灵活的算力。","2026\u002F01\u002F26",[178],{"name":34,"description":179},"oUBIOS与openUBMC共建开放生态，提升算力基石效能。","content:zh:blogs:openUBMC-UBIOS.md","zh\u002Fblogs\u002FopenUBMC-UBIOS.md","zh\u002Fblogs\u002FopenUBMC-UBIOS","\u002Fcategory\u002Fblog\u002F0126%E5%8D%9A%E5%AE%A2%E5%9B%BE%E7%89%87\u002F%E5%9B%BE%E7%89%871.png","从开源社区到产业标准：openUBMC携手UBIOS引领服务器 在数字经济的浪潮下，基础系统软件固件作为算力基石的“操作系统”，其管理效能正面临严峻挑战。基于此，UBIOS与openUBMC实现深度耦合，旨在通过共建开放生态，从根本上破解适配、效率与安全困局，为数字化基座释放更可靠、更灵活的算力。 一、当前困境 随着数字经济的加速渗透，数据中心已成为支撑云计算与人工智能算力的核心基石。据IDC最新报告显示，截止2025年，全球数据中心服务器数量将突破2000万台，超大规模数据中心的数量每五年翻一番。作为服务器运行的“底层引擎”，固件的管理效率与安全性直接决定了数据中心的稳定运行和算力输出能力。然而现实却是，超过70%的企业因固件管理不到位而频繁遭遇安全事件，手动升级失误所导致的业务中断损失往往高达数十万元。在此行业痛点之下，UBIOS与openUBMC的联手，正在推动一场服务器管理领域的生态革命。 BIOS和服务器管理的困境，本质上是“多元算力适配难”与“大规模运维失控”的双重挑战。长期以来，UEFI等传统固件标准由国外主导的行业组织把控，核心代码闭源，导致国产芯片适配技术门槛高、周期长。同时，UEFI标准演进乏力，相关规范如《UEFI Specification》《UEFI Shell Specification》《UEFI Platform Initialization Specification》及《ACPI Specification》等篇幅庞大，学习成本与门槛较高。 此外，随着芯片技术不断演进——从单一处理器到多处理器、从单一模式到多模式、从单Die到多Die，仅在ARM领域就存在PSCI、SDEI、SCMI等多种固件与操作系统接口规范。随着Chiplet技术的广泛应用，芯片设计复杂度持续攀升，相关接口也日趋复杂。另一方面，不同品牌、型号的设备搭载各异的固件管理系统，版本混乱、升级流程繁琐，运维团队面对数千台设备时常陷入“补丁追不上漏洞”的被动局面。更严峻的是，固件漏洞已成为网络攻击的重灾区：2023年全球网络安全报告显示，当年约30%的网络安全攻击与固件漏洞相关，而分散的管理模式进一步导致漏洞响应滞后，合规风险显著增加。 二、破局关键 破解这一困局的关键，在于构建统一的底层标准与开放的管理生态。UBIOS的出现，率先打破了国外在固件核心标准领域的垄断。作为全球计算联盟（GCC）主导发布的《统一基本输入输出系统（UBIOS）基础架构规范》，该标准从零开始重构固件体系，创新性地提出统一虚拟总线（UVB）概念。UVB如同构建了一个“超级交通枢纽”，既能满足纵向接口的演进需求，也支持横向接口的扩展，未来还可向集群化方向延伸，使所有硬件组件通过统一接口进行交互，彻底解决了传统固件模块耦合度高、扩展性差的短板。UBIOS不仅全面兼容ARM、RISC-V等异构架构，更能适配Chiplet等前沿技术，为跨场景、跨设备的可信启动提供了统一的“语言”。    其中，《统一基本输入输出系统（UBIOS）基础架构规范》重点定义和描述架构实现原理和要求，《统一基本输入输出系统（UBIOS）接口规范》（待发布）则聚焦功能接口的定义和描述。  基于UBIOS规范的实现，让组件间的调用与组件内的调用接口一致，让调用者无感，开发者更聚焦功能实现。 三、固件协同 智管增效 如果将UBIOS视为服务器管理的“统一地基”，那么openUBMC便是构建于其上的“智能管理中枢”。作为一款开源的算力设备管理软件，openUBMC基于BMC技术，打造了独立于主操作系统的“离线管理核心”——即便在设备宕机的情况下，仍能实现远程监控、故障诊断与固件升级。其微组件架构支持灵活扩展，一套代码即可兼容多种算力平台，配合标准化SDK套件与全流程工具链，显著降低了开发与适配成本。更重要的是，开源模式充分吸纳社区力量，形成了开放协作、持续创新的生态氛围。 UBIOS与openUBMC的结合，并非简单的技术叠加，而是构建了“标准统一 + 管理智能”的全链路固件管理新生态，释放出“1+1>2”的协同效应。在技术层面，两者通过标准化接口实现无缝对接：UBIOS的统一底层架构为openUBMC提供了一致的硬件交互基础，而openUBMC的智能管理能力则使UBIOS的标准价值得以充分落地，从而形成“底层标准化、管理自动化、运维智能化”的完整闭环。   这一生态协同，正精准破解行业核心难题：针对多元算力适配困境，UBIOS的统一标准实现了不同架构设备的同源开发，而openUBMC则通过统一的南北向接口，实现对全域设备的集中版本管控。这不仅大幅简化了研发流程、缩短交付周期、节约开发成本，更助力企业聚焦于核心竞争力构建，从而推动更加繁荣、可持续的服务器管理生态形成。 生态的繁荣，离不开开放协作的土壤。UBIOS与openUBMC共同构建的新生态，始终秉持“开源开放、协同创新”的理念，正在逐步建立覆盖服务器产业链的多层次合作体系： 在标准层面  \n联合服务器厂商、芯片企业持续完善接口规范，推动南向硬件自适应与北向数据中心管理平台无缝对接，兼容Redfish等主流运维协议； 在社区层面  \n打造服务器固件开发者协作平台，提供面向x86、ARM等架构的定制化开发工具链，降低中小企业与开发者的参与门槛，激发创新活力； 在产业层面  \n树立数据中心标杆实践，覆盖通用算力、AI智算等关键场景，加速生态解决方案在超大规模数据中心中的规模化部署。 从技术跟随到标准引领，UBIOS与openUBMC的深度合作，不仅为国内企业突破国外垄断提供了可行路径，更在全球服务器管理领域树立了开源协作的新范式。当统一的管理标准与开放的管理生态深度融合，数字基础设施的底层根基将更加牢固，为云计算、人工智能、物联网等技术的纵深发展提供坚实支撑。 未来已来，服务器管理的新篇章正在展开。UBIOS与openUBMC以开源共建为契机，诚邀更多产业链伙伴加入这一生态浪潮——以开放凝聚合力，以协同驱动创新，共同塑造服务器管理的未来图景。 欢迎关注openUBMC 社区官网： https:\u002F\u002Fwww.openubmc.cn  \n代码仓地址： https:\u002F\u002Fgitcode.com\u002FopenUBMC",[34],{"_path":187,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":188,"description":189,"date":190,"category":191,"author":192,"_type":18,"_id":194,"_source":20,"_file":195,"_stem":196,"_extension":23,"plainText":197,"authorNames":198},"\u002Fzh\u002Fblogs\u002Fsig-new-app-creation","openUBMC社区新建仓库指南","本指南详细介绍了在openUBMC社区创建新代码仓库的标准流程与最佳实践，旨在帮助贡献者高效完成组件提交与集成。","2025\u002F12\u002F15","guide",[193],{"name":34,"description":35},"content:zh:blogs:sig-new-app-creation.md","zh\u002Fblogs\u002Fsig-new-app-creation.md","zh\u002Fblogs\u002Fsig-new-app-creation","openUBMC社区新建仓库指南 在开源社区中贡献代码、共享组件，是推动技术进步和生态繁荣的重要方式。在openUBMC社区中，每一个APP都需通过一个独立的代码仓库进行管理。本文旨在为希望在openUBMC社区中创建新仓库的开发者或贡献者，提供一份完整、清晰的操作指南。无论您是希望贡献一个全新的功能模块，还是计划将一个现有项目迁移到社区，遵循本指南将帮助您高效地完成从构思、评审到最终集成的全流程，让您的创意与努力顺利融入社区中。 新增组件评审 根据社区运作规则，组件创建者需要向社区TC申请，在TC例会中评审并通过后才可以创建。为了保证会上评审的质量和效率，需要在会前准备好以下信息，以便TC委员更好地评估申请。 **组件的名字和职责：**需要明确组件的名字和职责，以及组件的实现思路、长期发展是否符合社区整体方向。 **组件所属的SIG：**需要明确组件的归属， 建议提前与你认为合适的SIG组Maintainer进行讨论 。如果希望新增SIG，可以将SIG申请和组件申请合并成一个议题。 **组件的License：**如果组件涉及引入三方库，需要明确其使用的License，确保新增组件使用的License符合社区规范。 **组件的编程语言：**主要用于评估当前社区CICD是否支持，若不支持则需要与Infra、CICD持续合作确保组件可被覆盖。 !NOTE 注意：\n可以利用SIG例会、社区邮件、社区论坛等途径提前沟通，确保会前便得到一些TC委员的支持，增加会上评审的通过率。 创建仓库 当完成社区评审后，需要通过 community 仓库完成仓库的自动创建。 每个SIG的目录中，都会存在两个文件，分别是 sig-info.yaml （保存SIG组信息）和 repo-info.yaml （保存SIG组对应的Repo仓库信息）文件。所有由该SIG管理的代码仓库，其信息都记录在这两个对应的YAML文件中。 修改对应的代码文件，提交PR时附上TC评审结论即可，TC委员将在1-2个工作日内合入PR。 repo-info.yaml repo-info.yaml  文件描述了 SIG 组的 仓库信息 ，包含如下基本元素： 名称 类型 说明 name 字符串 仓库名称 description 字符串 仓库包含组件的描述 type 枚举类型，可选 public 或者 private 仓库是否可公开访问 在某些场景下，如果不想在仓库ready前正式公开，可以在创建的时候选择 private ，默认SIG的Maintainer有权限访问仓库，并通过Maintainer邀请加入仓库。 例： -  name :  mdb_interface\n   description :  \"Resource collaboration APIs definition\"\n   type :  public\n  sig-info.yaml sig-info.yaml  文件描述了 SIG 组的 人员和权限信息 ，针对新增组件，如果无需单独配置Committers，则无需改动。**默认所有Maintainer都拥有该仓库的合入权限。 如果需要配置Committers，则需要修改 repositories 配置： 名称 类型 说明 repo Array 需要独立配置的仓库名称列表 committers Array 该仓库配置的Committers列表 例： repositories :\n   -  repo :\n       -  openUBMC\u002Frepo_1\n       -  openUBMC\u002Frepo_2\n     committers :\n       -  gitcode_id :  committer_1\n         name :  Committer 1 Name\n       -  gitcode_id :  committer_2\n         name :  Committer 2 Name\n 组件CICD配置 当PR合入后，大约1小时内社区机器人便会完成仓库创建，接下来需要完成CICD配置，确保组件PR可被合入。 社区所有的CI门禁设置都在 openubmc-ci 仓库进行管理。 ci-repos openUBMC社区CI设置较为复杂，详情请参考 openubmc-ci 仓库的文档。此处仅提供最初始的配置方法。 在 ci-repos 目录下，创建一个与组件仓同名的文件夹。 在该文件夹下，创建 config.yaml 文件，配置组件的门禁开关。 name :  dcmid  # 组件名\n codecheck :  false\n it :  false\n ut :  false\n poison :  false\n sca :  false\n coverage :  false\n build :  false\n version_check :  false\n ipmi_check :  false\n dependency_check :  false\n line_limit_check :  false\n model_check :  false\n header :  false\n !NOTE 注意\n初始化阶段建议将门禁项关闭，避免在组件未准备好时被门禁拦截。 提交PR并合入后，完成组件的初始化和构建脚本开发。 构建脚本ready后，再根据实际情况打开各门禁项。 总结 在openUBMC社区创建一个新的仓库，远不止是在代码托管平台上点击“新建”按钮。它是一个严谨的社区协作过程，旨在确保每一个新增组件都能与社区的整体技术方向、质量标准和协作规范保持一致。 回顾整个流程，关键在于三个核心步骤： **充分的会前沟通与评审准备：**在正式向TC提交申请前，通过与SIG例会、邮件讨论、论坛等方式明确组件的定位、归属和合规性，不仅能提升TC评审会的效率，更能显著增加提案通过的成功率。 **通过配置化方式实现仓库管理：**配置化管理社区组件有效地避免了人为操作带来的不确定性，同时也为长期维护提供了有效的方式。 **渐进式地集成CICD：**根据实际情况进行组件的CICD配置，既保证前期能够快速地完成组件创建，又能持续保障组件的代码合入质量。 总而言之，这份指南不仅是一套操作说明，更体现了openUBMC社区对开放、透明和高质量协作的追求。我们鼓励每一位开发者在贡献代码的同时，也积极融入社区的治理流程。希望本文能成为您参与openUBMC社区建设的得力助手，期待您的精彩贡献。 如果您在流程中遇到任何问题，欢迎通过社区论坛、邮件列表或相应的SIG频道寻求帮助。社区的成功，离不开每一位成员的积极参与和共同努力。 html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[34],{"_path":200,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":201,"description":202,"date":203,"sig":204,"archives":205,"category":206,"author":207,"_type":18,"_id":211,"_source":20,"_file":212,"_stem":213,"_extension":23,"coverImage":214,"plainText":215,"authorNames":216},"\u002Fzh\u002Fblogs\u002Fsouth-component-driver-netcard-adapt-guide","南向网卡驱动适配指南","南向驱动是基于硬件组件驱动程序框架，采用分层架构设计，支持多种设备类型和通信协议。本文档面向网卡适配的设备驱动开发者，提供从设计到实现的完整开发流程，并基于现有代码实例分析，提供一篇快速适配的开发指南。","2025\u002F11\u002F06","sig-docs","2025-11","case",[208],{"name":209,"description":210},"常德兴","openUBMC component-drivers SIG Committer，致力于深耕部件驱动标准化，建设部件生态社区。","content:zh:blogs:south-component-driver-netcard-adapt-guide.md","zh\u002Fblogs\u002Fsouth-component-driver-netcard-adapt-guide.md","zh\u002Fblogs\u002Fsouth-component-driver-netcard-adapt-guide","\u002Fcategory\u002Fblog\u002Fsouth-component-driver-netcard-adapt-guide\u002Fdriver_layered_architecture.PNG","南向网卡驱动适配指南 南向驱动是基于硬件组件驱动程序框架，采用分层架构设计，支持多种设备类型和通信协议。本文档面向网卡适配的设备驱动开发者，提供从设计到实现的完整开发流程，并基于现有代码实例分析，提供一篇快速适配的开发指南。 1. 概述 1.1 什么是南向网卡驱动适配？ 南向网卡驱动适配是指在BMC系统中，为不同厂商的PCIe网卡提供统一的驱动程序接入方案，使BMC能够管理和监控网卡设备。 1.2 适配后可以实现什么功能？ 获取网卡基本信息（厂商ID、设备ID、固件版本等） 监控网卡状态（温度、链路状态、带宽等） 管理网口（链路信息、MAC地址、LLDP等） 监控光模块（温度、收发功率、序列号等） 故障诊断和日志收集 1.3 需要了解的关键概念 设备对象 对象类型 说明 示例 网卡主对象 代表整个PCIe网卡 PCIeNicCard 网口对象 代表网卡上的物理网口 NicPort 光模块对象 代表插在网口上的光模块 OpticalTransceiver 接口 gen命名空间 ：自动生成的接口基类，定义属性 dev命名空间 ：厂商具体实现类，实现功能 接口组合 ：一个设备可以实现多个接口，如 PCIeDevice 、 NetworkAdapter 等 协议库 NCSI over MCTP ：网卡控制协议，通过PCIe与网卡通信 SMBUS ：系统管理总线协议，用于I2C通信 不同厂商可能使用不同的协议扩展  1.4 驱动分层架构 分层架构 ：构建了一个从接口定义到硬件交互的完整体系，接口定义层→设备接口层→设备对象层→设备驱动层，每层职责明确，协同工作； 设计理念 ：接口与实现分离，先是“接口定义层”建立接口规范，并在“设备接口层” 自动生成C++接口代码，再由各厂商提供“设备驱动层”的具体部件驱动实现；  2. 前置准备 2.1 明确网卡信息 必需信息 信息项 说明 示例 VID Vendor ID（厂商ID） 0x19e5 DID Device ID（设备ID） 0x0222 SVID Subsystem Vendor ID 0x19e5 SSID Subsystem Device ID 0x0052 协议信息 支持的通信协议（NCSI标准协议、厂商OEM扩展等） 协议命令集（获取温度、链路状态等命令的定义） 数据格式（响应数据的字节序、字段定义等） 硬件信息 网口数量 是否支持光模块 特殊功能（如DCB、LLDP等） 2.2 驱动代码结构熟悉 Component Driver采用分层架构设计，代码组织清晰，各个目录职责明确。理解这些目录的结构和作用是快速适配驱动的基础。  2.2.1 整体目录结构 component_drivers\u002F\n├── drivers\u002F              # 设备驱动实现目录（各类硬件设备驱动）\n├── gen\u002F                  # 自动生成的代码目录（接口基类）\n├── libraries\u002F            # 协议库目录（通信协议封装）\n├── tests\u002F                # 测试代码目录\n├── docs\u002F                 # 文档目录\n├── include\u002F              # 公共头文件目录\n└── meson.build           # 构建配置文件\n  2.2.2 drivers目录 - 设备驱动实现 drivers\u002F 目录包含所有硬件设备的具体驱动实现，按设备类型组织。 目录结构 drivers\u002F\n├── pcie_nic_card\u002F        # PCIe网卡驱动（本指南重点）\n│   ├── hisi\u002F             # 华为海思网卡驱动\n│   │   ├── csr\u002F          # 设备配置文件（DDS\u002FSR）\n│   │   │   ├── 14140130_19e50222_19e50052.dds   # Hi1822设备描述\n│   │   │   ├── 14140130_19e50222_19e50052.sr    # Hi1822硬件自描述信息\n│   │   │   ├── 14140130_19e50222_19e500a1.dds   # Hi1822另一配置\n│   │   │   └── 14140130_19e50222_19e500a1.sr\n│   │   ├── hi182x\u002F       # Hi182x系列网卡实现\n│   │   │   ├── hi182x_card.h          # 网卡主对象头文件\n│   │   │   ├── hi182x_card.cpp        # 网卡主对象实现\n│   │   │   ├── hi182x_port.h          # 网口对象头文件\n│   │   │   ├── hi182x_port.cpp        # 网口对象实现\n│   │   │   ├── hi182x_om.h            # 光模块对象头文件\n│   │   │   ├── hi182x_om.cpp          # 光模块对象实现\n│   │   │   ├── hi182x_abi.cpp         # ABI导出接口\n│   │   │   └── meson.build            # 构建配置\n│   │   ├── hi183x\u002F       # Hi183x系列网卡实现\n│   │   ├── interface\u002F    # 接口实现目录（继承gen基类）\n│   │   │   ├── pcie_device.h\u002Fcpp              # PCIe设备接口实现\n│   │   │   ├── network_adapter.h\u002Fcpp          # 网络适配器接口实现\n│   │   │   ├── network_adapter\u002F               # 网络适配器子接口\n│   │   │   │   ├── cooling.h\u002Fcpp              # 温度监控接口\n│   │   │   │   ├── fault_status.h\u002Fcpp         # 故障状态接口\n│   │   │   │   └── log_collection.h\u002Fcpp       # 日志收集接口\n│   │   │   ├── network_port.h\u002Fcpp             # 网口接口实现\n│   │   │   ├── network_port\u002F                  # 网口子接口\n│   │   │   │   ├── link_info.h\u002Fcpp            # 链路信息接口\n│   │   │   │   ├── lldp_receive.h\u002Fcpp         # LLDP接收接口\n│   │   │   │   ├── data_center_bridging.h\u002Fcpp # DCB接口\n│   │   │   │   └── metrics.h\u002Fcpp              # 流量统计接口\n│   │   │   ├── optical_module\u002F                # 光模块子接口\n│   │   │   │   ├── cooling.h\u002Fcpp              # 光模块温度接口\n│   │   │   │   ├── status.h\u002Fcpp               # 光模块状态接口\n│   │   │   │   ├── power.h\u002Fcpp                # 光模块功率接口\n│   │   │   │   ├── voltage.h\u002Fcpp              # 光模块电压接口\n│   │   │   │   └── current.h\u002Fcpp              # 光模块电流接口\n│   │   │   ├── board.h\u002Fcpp                    # 板卡信息接口\n│   │   │   ├── pcie_card.h\u002Fcpp                # PCIe卡接口\n│   │   │   └── pcie_device\u002F\n│   │   │       └── bandwidth.h\u002Fcpp            # PCIe带宽接口\n│   │   └── meson.build\n│   ├── wx\u002F               # 网迅网卡驱动\n│   │   ├── csr\u002F          # 设备配置文件\n│   │   ├── interface\u002F    # 接口实现目录\n│   │   ├── wx_card.h\u002Fcpp         # 网卡主对象\n│   │   ├── wx_port.h\u002Fcpp         # 网口对象\n│   │   ├── wx_abi.cpp            # ABI导出接口\n│   │   └── meson.build\n│   └── meson.build\n│\n├── pcie_gpu_card\u002F        # PCIe GPU卡驱动\n│   └── innosilicon\u002F      # 芯动GPU驱动\n│       ├── csr\u002F          # 设备配置文件\n│       ├── awm_m11p\u002F     # AWM-M11P GPU实现\n│       ├── interface\u002F    # 接口实现目录\n│       └── meson.build\n│\n├── bus\u002F                  # 总线驱动\n│   ├── i2c\u002F              # I2C总线驱动\n│   ├── i2c_mux\u002F          # I2C多路复用器驱动\n│   ├── hisport\u002F          # Hisport总线驱动\n│   └── meson.build\n│\n├── chip\u002F                 # 芯片驱动\n│   ├── lm75\u002F             # LM75温度传感器驱动\n│   ├── ads78\u002F            # ADS78 ADC驱动\n│   ├── eeprom\u002F           # EEPROM驱动\n│   ├── pca9545\u002F          # PCA9545 I2C多路复用器驱动\n│   ├── pca9555\u002F          # PCA9555 GPIO扩展器驱动\n│   ├── complex\u002F          # 复杂芯片驱动\n│   ├── interface\u002F        # 芯片接口定义\n│   └── meson.build\n│\n├── accessor\u002F             # 访问器驱动（提供统一的属性访问接口）\n├── scanner\u002F              # 扫描器驱动（自动发现硬件设备）\n├── debounce\u002F             # 防抖驱动（信号滤波算法）\n│   ├── average\u002F          # 平均值滤波\n│   ├── median\u002F           # 中位数滤波\n│   ├── continue\u002F         # 连续性滤波\n│   └── binary_continue\u002F  # 二值连续性滤波\n│\n├── internal\u002F             # 内部实现（驱动框架基础类）\n│   ├── bus\u002F              # 总线基类实现\n│   ├── chip\u002F             # 芯片基类实现\n│   └── manager.h\u002Fcpp     # 驱动管理器\n│\n└── meson.build\n 关键目录说明 目录 说明 用途 pcie_nic_card\u002F PCIe网卡驱动根目录 按厂商组织网卡驱动 hisi\u002Fcsr\u002F 设备配置文件目录 存放DDS和SR配置文件，定义设备接口和硬件自描述信息 hisi\u002Fhi182x\u002F Hi182x网卡实现 包含网卡、网口、光模块的实现代码 hisi\u002Finterface\u002F 接口实现目录 继承gen基类，实现具体协议逻辑和数据更新 internal\u002F 内部基础框架 提供驱动框架的基础类  2.2.3 gen目录 - 自动生成的接口基类 gen\u002F 目录包含自动生成的接口基类定义，驱动代码继承这些基类实现功能。 注意：此目录的代码由工具自动生成，不要手动修改。 目录结构 gen\u002F\n├── include\u002F              # 头文件目录\n│   └── device_tree\u002F\n│       ├── base.h        # 基础类定义\n│       ├── interface\u002F    # 接口基类定义\n│       │   ├── NetworkAdapter.h              # 网络适配器接口基类\n│       │   ├── NetworkAdapter\u002F               # 网络适配器子接口\n│       │   │   ├── Cooling.h                 # 温度监控接口基类\n│       │   │   ├── FaultStatus.h             # 故障状态接口基类\n│       │   │   └── LogCollection.h           # 日志收集接口基类\n│       │   ├── NetworkPort.h                 # 网口接口基类\n│       │   ├── NetworkPort\u002F                  # 网口子接口\n│       │   │   ├── LinkInfo.h                # 链路信息接口基类\n│       │   │   ├── LLDPReceive.h             # LLDP接收接口基类\n│       │   │   ├── DataCenterBridging.h      # DCB接口基类\n│       │   │   ├── Metrics.h                 # 流量统计接口基类\n│       │   │   └── FibreChannel.h            # 光纤通道接口基类\n│       │   ├── OpticalModule.h               # 光模块接口基类\n│       │   ├── OpticalModule\u002F                # 光模块子接口\n│       │   │   ├── Status.h                  # 光模块状态接口基类\n│       │   │   ├── Cooling.h                 # 光模块温度接口基类\n│       │   │   ├── Power.h                   # 光模块功率接口基类\n│       │   │   ├── Voltage.h                 # 光模块电压接口基类\n│       │   │   ├── Current.h                 # 光模块电流接口基类\n│       │   │   ├── Channel.h                 # 光模块通道接口基类\n│       │   │   └── Diagnose.h                # 光模块诊断接口基类\n│       │   ├── PCIeDevice.h                  # PCIe设备接口基类\n│       │   ├── PCIeDevice\u002F\n│       │   │   └── Bandwidth.h               # PCIe带宽接口基类\n│       │   ├── PCIeCard.h                    # PCIe卡接口基类\n│       │   ├── Board.h                       # 板卡信息接口基类\n│       │   ├── Gpu.h                         # GPU接口基类\n│       │   ├── Gpu\u002F\n│       │   │   ├── Power.h                   # GPU功率接口基类\n│       │   │   └── Status.h                  # GPU状态接口基类\n│       │   ├── Memory.h                      # 内存接口基类\n│       │   ├── Processor.h                   # 处理器接口基类\n│       │   ├── Chip.h                        # 芯片接口基类\n│       │   ├── Chip\u002F\n│       │   │   ├── BlockIO.h                 # 块IO接口基类\n│       │   │   └── Pca9545.h                 # PCA9545接口基类\n│       │   ├── Bus\u002F                          # 总线接口基类\n│       │   │   ├── I2c.h                     # I2C总线接口基类\n│       │   │   ├── I2cMux.h                  # I2C多路复用器接口基类\n│       │   │   └── Hisport.h                 # Hisport总线接口基类\n│       │   ├── Debounce\u002F                     # 防抖接口基类\n│       │   │   ├── Average.h                 # 平均值滤波接口基类\n│       │   │   ├── Median.h                  # 中位数滤波接口基类\n│       │   │   ├── Continue.h                # 连续性滤波接口基类\n│       │   │   └── BinaryContinue.h          # 二值连续性滤波接口基类\n│       │   ├── Accessor.h                    # 访问器接口基类\n│       │   └── Scanner.h                     # 扫描器接口基类\n│       │\n│       └── object\u002F       # 对象组合定义\n│           ├── PCIeNicCard\u002F                  # 网卡对象组合\n│           │   ├── pcie_nic_card.h           # 网卡对象组合基类\n│           │   ├── network_port.h            # 网口对象组合基类\n│           │   └── optical_module.h          # 光模块对象组合基类\n│           └── PCIeGpuCard\u002F                  # GPU卡对象组合\n│               ├── pcie_gpu_card.h           # GPU卡对象组合基类\n│               ├── gpu.h                     # GPU对象组合基类\n│               └── memory.h                  # 内存对象组合基类\n│\n├── src\u002F                  # 源文件目录（与include结构对应）\n│   └── device_tree\u002F\n│       ├── interface\u002F    # 接口基类实现（.cpp文件）\n│       └── object\u002F       # 对象组合实现（.cpp文件）\n│\n└── meson.build\n 关键概念 概念 说明 示例 接口基类 定义接口的属性和方法签名 gen::NetworkAdapter 定义了 FirmwareVersion 、 ChipModel 等属性 对象组合 将多个接口组合成完整对象 网卡对象组合了 PCIeDevice 、 NetworkAdapter 、 Board 等接口 命名空间 所有生成的代码在 gen 命名空间下 驱动代码继承 gen::NetworkAdapter 实现 dev::NetworkAdapter 自动生成 基于模型文件自动生成，不手动修改 通过修改模型文件（JSON）重新生成 使用方式 驱动开发时，需要继承对应的gen基类并实现功能： \u002F\u002F 继承gen命名空间的基类\n class NetworkAdapter : public gen::NetworkAdapter {\n public:\n     \u002F\u002F 实现具体功能\n     void update_firmware_version();\n     void start_ncsi_update_task(...);\n };\n \n \u002F\u002F 注册时指定基类\n MC_REFLECT(dev::NetworkAdapter, (gen::NetworkAdapter), ())\n  2.2.4 libraries目录 - 通信协议库 libraries\u002F 目录包含各种通信协议的封装实现，为驱动提供标准化的协议接口。 目录结构 libraries\u002F\n├── mctp\u002F                 # MCTP协议库（管理组件传输协议）\n│   ├── mctp.h            # MCTP协议接口定义\n│   ├── mctp.cpp          # MCTP协议实现\n│   ├── pcie_transport.h  # PCIe传输层实现\n│   ├── pcie_transport.cpp\n│   └── meson.build\n│\n├── ncsi_over_mctp\u002F       # NCSI over MCTP协议库\n│   ├── ncsi_over_mctp.h           # NCSI over MCTP基类\n│   ├── ncsi_over_mctp.cpp\n│   ├── ncsi_over_mctp_standard.h  # 标准NCSI协议实现\n│   ├── ncsi_over_mctp_standard.cpp\n│   ├── ncsi_over_mctp_huawei.h    # 华为NCSI扩展协议\n│   ├── ncsi_over_mctp_huawei.cpp\n│   ├── ncsi_over_mctp_wx.h        # 网迅NCSI扩展协议\n│   ├── ncsi_over_mctp_wx.cpp\n│   └── meson.build\n│\n├── ncsi\u002F                 # NCSI协议定义（头文件库）\n│   ├── ncsi_protocol.h   # NCSI标准协议定义\n│   ├── ncsi_huawei.h     # 华为NCSI扩展定义\n│   ├── ncsi_wx.h         # 网迅NCSI扩展定义\n│   ├── ncsi_socket.h     # NCSI Socket接口\n│   ├── adapter.h         # NCSI适配器接口\n│   └── meson.build\n│\n├── smbus\u002F                # SMBus协议库\n│   ├── smbus.h           # SMBus协议接口定义\n│   ├── smbus.cpp         # SMBus协议实现\n│   ├── std_smbus.h       # 标准SMBus实现\n│   ├── std_smbus.cpp\n│   └── meson.build\n│\n├── ipmb\u002F                 # IPMB协议库（IPMI消息块协议）\n│   ├── ipmb.h            # IPMB协议接口定义\n│   ├── ipmb.cpp          # IPMB协议实现\n│   └── meson.build\n│\n├── imu\u002F                  # IMU协议库（智能管理单元协议）\n│   ├── imu.h             # IMU协议接口定义\n│   ├── imu.cpp           # IMU协议实现\n│   └── meson.build\n│\n├── protocol\u002F             # 通用协议基类\n│   ├── protocol.h        # 协议基类定义\n│   ├── protocol.cpp      # 协议基类实现\n│   └── meson.build\n│\n└── meson.build\n 协议库说明 协议库 说明 传输方式 应用场景 mctp 管理组件传输协议（DMTF标准） PCIe、SMBus 作为底层传输协议，封装上层协议消息 ncsi_over_mctp 基于MCTP的NCSI协议 MCTP over PCIe\u002FSMBus 网卡管理的主要协议，获取网卡状态、配置信息 ncsi NCSI协议定义 - 定义NCSI命令格式、数据结构（仅头文件） smbus 系统管理总线协议 I2C\u002FSMBus 直接读取芯片寄存器，获取温度等数据 ipmb IPMI消息块协议 I2C IPMI命令传输 imu 智能管理单元协议 I2C\u002FIMU 获取PCIe配置空间信息、BDF地址 protocol 协议基类 - 所有协议的通用基类，定义标准接口 协议分层关系 应用层：  网卡驱动代码\n          ↓\n协议层：  NCSI over MCTP (ncsi_over_mctp_huawei\u002Fwx)\n          ↓\n传输层：  MCTP (mctp + pcie_transport)\n          ↓\n物理层：  PCIe硬件 \u002F SMBus硬件\n 使用示例 \u002F\u002F 1. 创建MCTP对象\n mctp* mctp_object = new mctp(this, phy_addr, \n                              MCTP_MESSAGE_TYPE::MCTP_MESSAGE_TYPE_NCSI, \"\");\n \n \u002F\u002F 2. 创建NCSI协议对象\n auto ncsi_huawei = std::make_shared\u003Cncsi_over_mctp_huawei>(*mctp_object);\n \n \u002F\u002F 3. 发送NCSI请求\n mc::dict request = {\n     {\"CommandId\", 0x50},  \u002F\u002F OEM命令\n     {\"Data\", data_vec}\n };\n auto response = ncsi_huawei->request(request);\n \n \u002F\u002F 4. 创建SMBus对象\n auto smbus_obj = mc::make_shared\u003Csmbus>(this);\n smbus_obj->init(params);\n \n \u002F\u002F 5. 读取SMBus数据\n std::vector\u003Cuint8_t> data = smbus_obj->read(offset, length);\n  2.2.5 目录之间的关系  工作流程 代码生成 ：根据模型文件生成 gen\u002F 目录下的接口基类 接口实现 ：在 drivers\u002F*\u002Finterface\u002F 下继承gen基类，实现具体功能 驱动组装 ：在 drivers\u002F*\u002F具体型号\u002F 下组合接口，创建完整驱动对象 协议调用 ：驱动通过 libraries\u002F 中的协议库与硬件通信 框架支持 ： drivers\u002Finternal\u002F 提供基础设施支持 2.3 驱动协议分层  2.4 底层协议确定 在适配网卡驱动前，首先要确定网卡支持的底层通信协议。不同厂商的网卡可能支持不同的协议组合。 协议类型 协议 说明 适用场景 NCSI over MCTP over PCIe 通过PCIe总线进行MCTP通信 网卡直接连接到PCIe总线 NCSI over MCTP over SMBus 通过SMBus\u002FI2C进行MCTP通信 网卡通过SMBus桥接芯片管理 SMBus直接访问 通过I2C直接读取芯片数据 获取MAC、温度等信息 厂商协议支持对比 厂商 NCSI over MCTP over PCIe NCSI over MCTP over SMBus SMBus直接访问 说明 华为海思 Hi182x ✓ - ✓ 主要通过PCIe，SMBus用于带外信息获取 网迅 WX - ✓ - 通过SMBus桥接MCTP通信 协议配置方式 方式一：NCSI over MCTP over PCIe + SMBus（华为海思Hi182x） 这种方式同时使用PCIe和SMBus两种协议： PCIe通道 ：用于NCSI协议通信，获取网卡主要信息（MAC地址、链路状态等） SMBus通道 ：用于直接读取芯片温度等数据 SR文件配置示例 （参考 14140130_19e50222_19e500a1.sr ）： {\n     \"ManagementTopology\" : {\n         \"Anchor\" : {\n             \"Buses\" : [\n                 \"I2cMux_9545Chan3\"\n             ]\n         },\n         \"I2cMux_9545Chan3\" : {\n             \"Chips\" : [\n                 \"Chip_Hi1822\" ,            \u002F\u002F 网卡芯片（SMBus访问）\n             ]\n         }\n     },\n     \"Objects\" : {\n         \u002F\u002F 配置芯片对象（SMBus访问参数）\n         \"Chip_Hi1822\" : {\n             \"OffsetWidth\" :  0 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  232 ,            \u002F\u002F I2C地址：0xE8\n             \"WriteTmout\" :  100 ,\n             \"ReadTmout\" :  100 ,\n             \"HealthStatus\" :  0 ,\n             \"WriteRetryTimes\" :  2 ,\n             \"ReadRetryTimes\" :  0\n         },\n         \n         \"PCIeNicCard_1\" : {\n             \"bmc.dev.NetworkAdapter\" : {\n                 \"Manufacturer\" :  \"Huawei\" ,\n                 \"ChipModel\" :  \"Hi1822\" ,\n                 \"NetworkPortCount\" :  2 ,\n                 \"SupportedMctp\" :  true ,\n                 \u002F\u002F 关键：通过RefChip关联Chip_Hi1822，支持SMBus访问\n                 \"RefChip\" :  \"#\u002FChip_Hi1822\"\n             }\n         }\n     }\n }\n 关键配置说明： ManagementTopology定义I2C拓扑 指定网卡芯片挂在哪条I2C总线上 Chip_Hi1822 定义芯片的I2C访问参数 RefChip关联 bmc.dev.NetworkAdapter 接口通过 RefChip 字段引用 Chip_Hi1822 这样 NetworkAdapter 接口可以通过SMBus读取芯片数据（如温度） 双协议工作 PCIe协议：代码中通过MCTP over PCIe获取网卡功能信息 SMBus协议：代码中通过 RefChip 访问芯片寄存器获取温度 代码实现要点 （ hi182x_card.cpp ）： bool hi182x_card::start_protocol() {\n     \u002F\u002F 1. 启动NCSI over MCTP over PCIe协议\n     if (!start_ncsi_protocol()) {\n         \u002F\u002F BDF未就绪，注册回调等待\n     }\n     \n     \u002F\u002F 2. 启动SMBus协议\n     start_smbus_protocol();\n     \n     return true;\n }\n \n bool hi182x_card::start_smbus_protocol() {\n     \u002F\u002F 获取RefChip引用\n     register_RefChip();\n     \n     \u002F\u002F 初始化SMBus对象\n     m_smbus_obj = mc::make_shared\u003Csmbus>(this);\n     m_smbus_obj->init(params);\n     \n     \u002F\u002F 注册读写方法，通过RefChip访问\n     m_smbus_obj->register_WriteRead_method([&](const std::vector\u003Cuint8_t>& data, uint32_t len) {\n         return m_ref_chip->invoke(\"bmc.dev.Chip\", \"BlockIOWriteRead\", {data, len})\n                          .as\u003Cstd::vector\u003Cuint8_t>>();\n     });\n     \n     \u002F\u002F 启动各接口的SMBus更新任务\n     m_network_adapter.start_smbus_update_task(m_smbus_obj, m_smbus_interval);\n     m_network_adapter_cooling.start_smbus_update_task(m_smbus_obj, m_smbus_interval);\n     \n     return true;\n }\n  方式二：NCSI over MCTP over SMBus（网迅WX） 这种方式通过SMBus桥接实现MCTP通信，所有数据都通过SMBus传输。 SR文件配置示例 （参考 14140130_80881001_80880300.sr ）： {\n     \"ManagementTopology\" : {\n         \"Anchor\" : {\n             \"Buses\" : [\n                 \"I2cMux_9545Chan\"\n             ]\n         },\n         \"I2cMux_9545Chan\" : {\n             \"Chips\" : [\n                 \"Chip_SmbusChip\"         \u002F\u002F SMBus桥接芯片\n             ]\n         }\n     },\n     \"Objects\" : {\n         \u002F\u002F SMBus芯片配置\n         \"Chip_SmbusChip\" : {\n             \"Address\" :  146 ,              \u002F\u002F I2C地址：0x92\n             \"AddrWidth\" :  1 ,\n             \"OffsetWidth\" :  1 ,\n             \"WriteTmout\" :  100 ,\n             \"ReadTmout\" :  100 ,\n             \"HealthStatus\" :  0\n         },\n         \n         \u002F\u002F MCTP绑定配置\n         \"MctpBinding_1\" : {\n             \"BmcSMBusEid\" :  8 ,           \u002F\u002F BMC的MCTP端点ID\n             \"BmcSMBusPhyAddr\" :  16       \u002F\u002F BMC的物理地址\n         },\n         \n         \u002F\u002F MCTP端点配置\n         \"Endpoint_1\" : {\n             \"TargetEid\" :  \"${Slot} |> expr($1 + 8)\" ,     \u002F\u002F 目标端点ID（动态计算）\n             \"TargetPhyAddr\" :  73 ,                         \u002F\u002F 目标物理地址\n             \"MessageType\" :  2 ,                            \u002F\u002F 消息类型：NCSI\n             \"MediumType\" :  128 ,                           \u002F\u002F 介质类型：SMBus\n             \"RefChip\" :  \"#\u002FChip_SmbusChip\"               \u002F\u002F 关联SMBus芯片\n         },\n         \n         \"PCIeNicCard_1\" : {\n             \"bmc.dev.NetworkAdapter\" : {\n                 \"Manufacturer\" :  \"Beijing Wangxun Technology Co., Ltd.\" ,\n                 \"ChipModel\" :  \"SP1000A\" ,\n                 \"NetworkPortCount\" :  2 ,\n                 \"SupportedMctp\" :  true ,\n                 \"SupportedLldp\" :  true\n                 \u002F\u002F 注意：没有RefChip字段，因为不需要直接SMBus访问\n             }\n         }\n     }\n }\n 关键配置说明： Chip_SmbusChip 定义SMBus桥接芯片的I2C访问参数 这个芯片负责将MCTP消息转换为SMBus传输 MctpBinding_1 配置BMC侧的MCTP绑定信息 指定BMC的EID和物理地址 Endpoint_1 配置网卡侧的MCTP端点 MessageType: 2 表示NCSI消息类型 MediumType: 128 表示通过SMBus传输 RefChip 关联到SMBus芯片 无RefChip NetworkAdapter 接口不需要 RefChip 所有数据通过NCSI over MCTP over SMBus获取 代码实现要点 （ wx_card.cpp ）： bool wx_card::start_protocol() {\n     \u002F\u002F 只需启动NCSI over MCTP协议\n     \u002F\u002F 框架会根据SR配置自动使用SMBus传输\n     if (!start_ncsi_protocol()) {\n         \u002F\u002F BDF未就绪，注册回调等待\n     }\n     return true;\n }\n \n bool wx_card::start_ncsi_protocol() {\n     \u002F\u002F 创建MCTP对象（框架会根据SR配置使用SMBus传输）\n     mctp* mctp_object = new mctp(this, phy_addr, \n                                  MCTP_MESSAGE_TYPE::MCTP_MESSAGE_TYPE_NCSI, 0);\n     \n     auto ncsi_update_task = [this, mctp_object]() {\n         \u002F\u002F 创建网迅专用的NCSI协议实例\n         m_ncsi_over_mctp_wx = std::make_shared\u003Cncsi_over_mctp_wx>(*mctp_object);\n         \n         \u002F\u002F 启动更新任务（温度等数据也通过NCSI获取）\n         m_pcie_device.start_ncsi_update_task(m_ncsi_over_mctp_wx, m_interval);\n         m_network_adapter_cooling.start_ncsi_update_task(m_ncsi_over_mctp_wx, m_interval);\n     };\n     \n     mctp_object->create_transport_and_endpoint(\n         std::string(get_object_name()), ncsi_update_task);\n     \n     return true;\n }\n  配置检查清单 方式一（NCSI over MCTP over PCIe + SMBus）：   SR文件中定义了网卡芯片对象（如 Chip_Hi1822 ）    ManagementTopology 中配置了I2C拓扑    NetworkAdapter 接口中配置了 RefChip 字段   代码中实现了 start_smbus_protocol() 方法   代码中实现了SMBus更新任务 方式二（NCSI over MCTP over SMBus）：   SR文件中定义了SMBus芯片对象（如 Chip_SmbusChip ）   配置了 MctpBinding_1 对象   配置了 Endpoint_1 对象，并关联SMBus芯片    Endpoint_1 的 MessageType 设置为2（NCSI）    Endpoint_1 的 MediumType 设置为128（SMBus）   代码中只需实现NCSI协议，无需SMBus  2.5 网卡支持的能力 本节以Hi182x网卡为例，详细列举网卡驱动可以支持的各种能力，帮助开发者了解可以实现哪些功能接口。 网卡级能力 Hi182x网卡主对象实现了以下8个接口： 能力类别 接口名称 说明 可获取的信息 PCIe设备信息 PCIeDevice PCIe设备基础信息 VID\u002FDID、BDF地址、设备名称、设备类型 PCIe卡信息 PCIeCard 板卡物理信息 卡槽位置、序列号、插槽类型 网络适配器 NetworkAdapter 网卡功能信息 厂商、型号、固件版本、MAC地址数量、支持的协议 温度监控 NetworkAdapter_Cooling 网卡温度信息 芯片温度、最高温度、温度阈值、散热状态 故障诊断 NetworkAdapter_FaultStatus 故障状态信息 故障代码、健康状态、错误计数、告警信息 带宽监控 PCIeDevice_Bandwidth PCIe带宽信息 链路速度、链路宽度、实际吞吐量、协商状态 日志收集 NetworkAdapter_LogCollection 日志导出功能 网卡日志文件、故障诊断信息、事件记录 板卡信息 Board 板卡制造信息 板卡序列号、部件号、制造商、生产日期  网口级能力 Hi182x的每个网口对象实现了以下5个接口： 能力类别 接口名称 说明 可获取的信息 网口基础信息 NetworkPort 网口基本属性 端口ID、MAC地址、最大速率、端口类型、启用状态 链路信息 NetworkPort_LinkInfo 链路状态信息 链路Up\u002FDown、当前速度、双工模式、自协商状态 LLDP接收 NetworkPort_LLDPReceive LLDP协议信息 邻居设备信息、网络拓扑、设备能力、VLAN信息 DCB支持 NetworkPort_DataCenterBridging 数据中心桥接 QoS配置、流量控制、优先级映射、带宽分配 网口指标 NetworkPort_Metrics 流量统计信息 收发包数、字节数、错误包、丢包率  光模块能力 Hi182x支持光模块，每个光模块对象实现了以下6个接口： 能力类别 接口名称 说明 可获取的信息 光模块基础信息 OpticalModule 光模块识别信息 型号、序列号、厂商、波长、传输距离、接口类型 状态信息 OpticalModule_Status 光模块状态 在位状态、工作状态、故障状态、使能状态 温度监控 OpticalModule_Cooling 光模块温度 当前温度、最高\u002F最低温度、温度告警阈值 电压监控 OpticalModule_Voltage 工作电压 当前电压、电压范围、电压告警阈值 功率监控 OpticalModule_Power 光功率信息 发射功率、接收功率、功率告警阈值、光衰减 电流监控 OpticalModule_Current 工作电流 偏置电流、电流范围、电流告警阈值  能力获取方式 Hi182x网卡通过三种协议获取不同的信息： 协议类型 获取的信息 更新频率 数据来源 NCSI over MCTP over PCIe 固件版本、MAC地址、链路状态、LLDP信息、DCB配置、网口流量统计、光模块信息、故障状态、带宽统计 5秒～180秒 网卡固件 SMBus直接访问 芯片温度、故障寄存器状态 5秒 网卡芯片寄存器 IMU协议 PCIe配置空间信息、BDF地址、四元组信息 按需 PCIe配置空间 更新频率策略： 快速变化数据 （5秒）：温度、链路状态、故障状态、流量统计 慢速变化数据 （120秒）：固件版本、设备信息、网卡配置 极慢变化数据 （180秒）：带宽统计、历史数据  3. 适配流程详解 假设我们要适配一个新厂商\"XYZ\"的网卡\"xyz1000\" 3.1 创建目录结构 在  drivers\u002Fpcie_nic_card\u002F  下创建： pcie_nic_card\u002F\n└── xyz\u002F                           # 厂商目录\n    ├── xyz1000\u002F                   # 型号目录\n    │   ├── xyz1000_card.h         # 主卡头文件\n    │   ├── xyz1000_card.cpp       # 主卡实现\n    │   ├── xyz1000_port.h         # 网口头文件\n    │   ├── xyz1000_port.cpp       # 网口实现\n    │   ├── xyz1000_om.h           # 光模块头文件（可选）\n    │   ├── xyz1000_om.cpp         # 光模块实现（可选）\n    │   ├── xyz1000_abi.cpp        # ABI导出\n    │   └── meson.build            # 构建配置\n    ├── interface\u002F                 # 接口实现目录\n    │   ├── pcie_device.h\n    │   ├── pcie_device.cpp\n    │   ├── network_adapter.h\n    │   ├── network_adapter.cpp\n    │   └── meson.build\n    ├── csr\u002F                       # 设备配置目录\n    │   ├── [VID_DID_SVID_SSID].dds    # DDS文件（设备接口定义）\n    │   └── [VID_DID_SVID_SSID].sr     # SR文件（硬件自描述信息）\n    └── meson.build\n  3.2 配置设备描述文件（DDS） DDS文件定义设备的接口和路径，是框架识别和加载驱动的关键配置。 文件命名规则 格式：14140130_[VID][DID]_[SVID][SSID].dds\n示例：14140130_19e50222_19e50052.dds\n说明：VID=0x19e5, DID=0x0222, SVID=0x19e5, SSID=0x0052\n DDS文件内容 {\n     \"Schema\" :  \"dds-v1\" ,\n     \"Type\" :  \"Component\" ,\n     \"DeviceCategory\" :  \"PCIeNicCard\" ,\n     \"ID\" :  \"N\u002FA\" ,\n     \"Objects\" : {\n         \"PCIeNicCard\" : {\n             \"Path\" :  \"\u002Fbmc\u002Fdev\u002FSystems\u002F:SystemId\u002FPCIeNicCard\u002F:Id\" ,\n             \"Interfaces\" : [\n                 \"bmc.dev.PCIeDevice\" ,\n                 \"bmc.dev.PCIeCard\" ,\n                 \"bmc.dev.Board\" ,\n                 \"bmc.dev.NetworkAdapter\" ,\n                 \"bmc.dev.NetworkAdapter.Cooling\" ,\n                 \"bmc.dev.NetworkAdapter.FaultStatus\" ,\n                 \"bmc.dev.PCIeDevice.Bandwidth\"\n             ]\n         },\n         \"NicPort\" : {\n             \"Path\" :  \":Parent\u002FNicPort\u002F:Id\" ,\n             \"Interfaces\" : [\n                 \"bmc.dev.NetworkPort\" ,\n                 \"bmc.dev.NetworkPort.LinkInfo\" ,\n                 \"bmc.dev.NetworkPort.DataCenterBridging\" ,\n                 \"bmc.dev.NetworkPort.Metrics\"\n             ]\n         },\n         \"OpticalTransceiver\" : {\n             \"Path\" :  \":Parent\u002FOpticalTransceiver\" ,\n             \"Interfaces\" : [\n                 \"bmc.dev.OpticalModule\" ,\n                 \"bmc.dev.OpticalModule.Status\" ,\n                 \"bmc.dev.OpticalModule.Cooling\" ,\n                 \"bmc.dev.OpticalModule.Voltage\" ,\n                 \"bmc.dev.OpticalModule.Power\" ,\n                 \"bmc.dev.OpticalModule.Current\"\n             ]\n         }\n     }\n }\n 关键字段说明 字段 说明 注意事项 DeviceCategory 设备类别 必须是 \"PCIeNicCard\" Objects 对象定义 键名必须与ABI中的 device_name 一致 Path 对象路径 :SystemId 、 :Id 是动态参数， :Parent 表示父对象 Interfaces 接口列表 必须与 MC_OBJECT 宏中声明的接口一致 配置要点 接口列表要完整 ：DDS中的 Interfaces 必须包含代码中 MC_OBJECT 声明的所有接口 对象名称要匹配 ： Objects 的键名（如 PCIeNicCard 、 NicPort ）必须与ABI注册时的 device_name 一致 路径格式固定 ：主对象路径和子对象路径格式不要修改 可选对象 ：如果不支持光模块，可以删除 OpticalTransceiver 对象定义  3.3 配置硬件自描述信息（SR） SR文件定义硬件拓扑、芯片配置和对象初始值，用于复杂的硬件管理场景。 文件命名规则 格式：14140130_[VID][DID]_[SVID][SSID].sr\n示例：14140130_19e50222_19e50052.sr\n说明：文件名必须与DDS文件一致\n SR文件结构 {\n     \"FormatVersion\" :  \"5.00\" ,\n     \"DataVersion\" :  \"5.00\" ,\n     \"Unit\" : {\n         \"Type\" :  \"PCIeNicCard\" ,\n         \"Name\" :  \"PCIeNicCard_1\" ,\n         \"Compatible\" : [ \"xyz_vendor\" ,  \"xyz_model\" ]\n     },\n     \"ManagementTopology\" : {\n         \u002F\u002F 硬件拓扑配置（I2C总线、芯片连接关系）\n     },\n     \"Objects\" : {\n         \u002F\u002F 对象初始配置和属性值\n     }\n }\n ManagementTopology配置（I2C拓扑） 如果网卡需要通过SMBus访问，需要配置I2C拓扑： \"ManagementTopology\" : {\n     \"Anchor\" : {\n         \"Buses\" : [ \"I2cMux_9545Chan3\" ]\n     },\n     \"I2cMux_9545Chan3\" : {\n         \"Chips\" : [\n             \"Chip_XYZ1000\" ,       \u002F\u002F 网卡芯片\n         ]\n     }\n },\n \"Objects\" : {\n     \"Chip_XYZ1000\" : {\n         \"OffsetWidth\" :  0 ,\n         \"AddrWidth\" :  1 ,\n         \"Address\" :  232 ,           \u002F\u002F I2C地址：0xE8\n         \"WriteTmout\" :  100 ,\n         \"ReadTmout\" :  100 ,\n         \"HealthStatus\" :  0 ,\n         \"WriteRetryTimes\" :  2 ,\n         \"ReadRetryTimes\" :  0\n     }\n }\n 网卡对象配置（PCIeNicCard_1） 定义网卡的初始属性值： \"PCIeNicCard_1\" : {\n     \"bmc.dev.PCIeDevice\" : {\n         \"DeviceName\" :  \"PCIe Card ${Slot} (XYZ1000)\" ,\n         \"FunctionClass\" :  2 ,\n         \"VendorId\" :  \"0x1234\" ,\n         \"DeviceId\" :  \"0x0001\" ,\n         \"SubSystemVendorId\" :  \"0x1234\" ,\n         \"SubSystemDeviceId\" :  \"0x0002\" ,\n         \"Slot\" :  \"${Slot}\" ,\n         \"Segment\" :  0 ,\n         \"SocketId\" :  0 ,\n         \"DeviceType\" :  \"MultiFunction\" ,\n         \"SlotType\" :  \"FullLength\" ,\n         \"FunctionProtocol\" :  \"PCIe\" ,\n         \"FunctionType\" :  \"Physical\" ,\n         \"ComponentType\" :  8 ,\n         \"Container\" :  \"${Container}\"\n     },\n     \"bmc.dev.NetworkAdapter\" : {\n         \"Manufacturer\" :  \"XYZ Vendor\" ,\n         \"ChipModel\" :  \"XYZ1000\" ,\n         \"Description\" :  \"4*25GE\" ,\n         \"ChipVendor\" :  \"XYZ\" ,\n         \"NetworkPortCount\" :  4 ,\n         \"SupportedMctp\" :  true ,\n         \"SupportedLldp\" :  true ,\n         \"Type\" :  3 ,\n         \"RefChip\" :  \"#\u002FChip_XYZ1000\" ,     \u002F\u002F 关联SMBus芯片（如果需要）\n         \"OSPowerState\" :  0\n     },\n     \"bmc.dev.Board\" : {\n         \"Slot\" :  \"${Slot}\" ,\n         \"Description\" :  \"4*25GE\" ,\n         \"Id\" :  255 ,\n         \"Type\" :  \"PCIeCard\" ,\n         \"PartNumber\" :  \"PART1234\"\n     },\n     \"bmc.dev.NetworkAdapter.Cooling\" : {\n         \"TemperatureStatus\" :  3 ,\n         \"TemperatureCelsius\" :  0\n     }\n }\n 网口对象配置（NicPort_N） 为每个网口配置初始值： \"NicPort_0\" : {\n     \"@Parent\" :  \"PCIeNicCard_1\" ,\n     \"bmc.dev.NetworkPort\" : {\n         \"PortId\" :  0 ,\n         \"NetDevFuncType\" :  1 ,\n         \"MediumType\" :  \"FiberOptic\" ,\n         \"MaxSpeedSupported\" :  \"25GE\" ,\n         \"PermanentMACAddress\" :  \"00:00:00:00:00:00\" ,\n         \"MACAddress\" :  \"00:00:00:00:00:00\" ,\n         \"BDF\" :  \"\"\n     },\n     \"bmc.dev.NetworkPort.LinkInfo\" : {\n         \"AutoSpeedNegotiationEnabled\" :  false ,\n         \"SpeedMbps\" :  4294967295 ,\n         \"WorkloadType\" :  0 ,\n         \"LinkStatus\" :  255\n     }\n }\n **说明：** @Parent 指定父对象，表示这个网口属于 PCIeNicCard_1 。 光模块对象配置（OpticalTransceiver_N） 如果支持光模块，为每个端口配置光模块对象： \"OpticalTransceiver_0\" : {\n     \"@Parent\" :  \"NicPort_0\" ,\n     \"bmc.dev.OpticalModule\" : {\n         \"ChannelNum\" :  1 ,\n         \"Presence\" :  0 ,\n         \"MediumType\" :  \"\"\n     },\n     \"bmc.dev.OpticalModule.Status\" : {\n         \"PowerState\" :  0 ,\n         \"FaultState\" :  0 ,\n         \"SpeedMatch\" :  true ,\n         \"TypeMatch\" :  true\n     },\n     \"bmc.dev.OpticalModule.Cooling\" : {\n         \"TemperatureCelsius\" :  65535 ,\n         \"TemperatureLowerThresholdCritical\" :  65535 ,\n         \"TemperatureUpperThresholdCritical\" :  65535\n     }\n }\n SR文件配置要点 RefChip关联 ：如果需要通过SMBus直接访问网卡芯片，必须在 NetworkAdapter 接口中配置 RefChip 父子关系 ：使用 @Parent 字段指定对象的层次关系 动态参数 ： ${Slot} 等参数会在运行时替换 初始值 ：65535通常表示\"无效值\"或\"未初始化\" 接口完整性 ：SR中定义的接口必须与DDS文件中声明的接口一致 3.4 创建网卡主对象 代码示例： xyz1000_card.h 参考  hi182x_card.h ： #ifndef XYZ1000_CARD_H\n #define XYZ1000_CARD_H\n \n #include \u003Cmc\u002Fengine.h>\n #include \u003Cncsi_over_mctp\u002Fncsi_over_mctp.h>\n \n #include \"xyz1000_port.h\"\n #include \"interface\u002Fboard.h\"\n #include \"interface\u002Fnetwork_adapter.h\"\n #include \"interface\u002Fpcie_card.h\"\n #include \"interface\u002Fpcie_device.h\"\n \n namespace dev {\n \n using ncsi_over_mctp_xyz_ptr = std::shared_ptr\u003Cncsi_over_mctp>;\n \n class xyz1000_card : public mc::engine::object\u003Cxyz1000_card> {\n public:\n     \u002F\u002F MC_OBJECT宏定义：类名、对象类型、路径模式、接口列表\n     MC_OBJECT(\n         xyz1000_card, \n         \"PCIeNicCard\",\n         \"\u002Fbmc\u002Fdev\u002FSystems\u002F1\u002FPCIeNicCard\u002F${object_name}\",\n         (PCIeDevice)(PCIeCard)(NetworkAdapter)(Board)\n     )\n \n     xyz1000_card();     \u002F\u002F 构造函数\n     ~xyz1000_card();    \u002F\u002F 析构函数\n \n     \u002F\u002F 生命周期方法\n     bool init(mc::mutable_dict& csr_object, const mc::dict& connector);\n     bool start();\n     bool stop();\n \n     \u002F\u002F 子设备管理\n     void init_network_ports();\n \n     \u002F\u002F 接口成员变量\n     PCIeDevice     m_pcie_device;\n     PCIeCard       m_pcie_card;\n     NetworkAdapter m_network_adapter;\n     Board          m_board;\n     uint8_t        m_system_id;\n \n private:\n     std::vector\u003Cxyz1000_port*> m_network_ports;\n     \n     \u002F\u002F 协议支持\n     bool start_ncsi_protocol();\n     bool start_protocol();\n     ncsi_over_mctp_xyz_ptr m_ncsi_over_mctp;\n     mc::milliseconds m_interval = mc::milliseconds(5000);\n     mctp*            m_mctp_object;  \u002F\u002F 管理MCTP对象生命周期\n };\n \n } \u002F\u002F namespace dev\n \n \u002F\u002F MC_REFLECT宏：反射信息注册\n MC_REFLECT(dev::xyz1000_card,\n            ((m_system_id, \"SystemId\"))\n            ((m_pcie_device, \"bmc.dev.PCIeDevice\"))\n            ((m_pcie_card, \"bmc.dev.PCIeCard\"))\n            ((m_network_adapter, \"bmc.dev.NetworkAdapter\"))\n            ((m_board, \"bmc.dev.Board\")))\n \n #endif  \u002F\u002F XYZ1000_CARD_H\n 关键说明 1. MC_OBJECT宏的参数： 第1个 ：类名 第2个 ：设备类型（固定为 \"PCIeNicCard\" ） 第3个 ：对象路径模板（固定格式） 第4个 ：实现的接口列表（按需选择） 2. 接口选择原则： 接口 必需性 说明 PCIeDevice 、 PCIeCard 、 Board 必需 基础接口 NetworkAdapter 必需 网卡功能接口 NetworkAdapter_Cooling 可选 支持温度监控时添加 NetworkAdapter_FaultStatus 可选 支持故障诊断时添加 PCIeDevice_Bandwidth 可选 支持带宽监控时添加  3.5 实现网卡主对象 代码示例： xyz1000_card.cpp #include \"xyz1000_card.h\"\n #include \u003Cmc\u002Flog.h>\n \n namespace dev {\n \n \u002F\u002F 构造函数：初始化MCTP对象指针为nullptr\n xyz1000_card::xyz1000_card() : m_mctp_object(nullptr) {\n }\n \n \u002F\u002F 析构函数：释放MCTP对象，防止内存泄漏\n xyz1000_card::~xyz1000_card() {\n     \u002F\u002F 释放MCTP对象内存\n     \u002F\u002F 取消注册OS重置回调\n }\n \n \u002F\u002F 初始化方法：从配置文件加载网卡属性\n bool xyz1000_card::init(mc::mutable_dict& csr_object, const mc::dict& connector) {\n     \u002F\u002F 使用from_variant自动加载配置到成员变量\n     \u002F\u002F 异常处理\n }\n \n \u002F\u002F 启动方法：启动网卡和所有子设备\n bool xyz1000_card::start() {\n     \u002F\u002F 初始化子网口对象\n     \u002F\u002F 启动每个网口\n     \u002F\u002F 启动NCSI协议\n     \u002F\u002F 启动SMBus协议（如果支持）\n }\n \n \u002F\u002F 停止方法：停止网卡并清理资源\n bool xyz1000_card::stop() {\n     \u002F\u002F 停止所有网口\n     \u002F\u002F 清理定时器等资源\n }\n \n \u002F\u002F 初始化网口对象：从子对象列表中提取所有网口\n void xyz1000_card::init_network_ports() {\n     \u002F\u002F 获取子对象列表\n     \u002F\u002F 筛选出NicPort类型的对象\n     \u002F\u002F 加入m_network_ports向量\n }\n \n \u002F\u002F 启动NCSI协议：创建MCTP通信和NCSI协议实例\n bool xyz1000_card::start_ncsi_protocol() {\n     \u002F\u002F 检查BDF地址是否就绪\n     \u002F\u002F 创建MCTP对象（赋值给成员变量）\n     \u002F\u002F 定义NCSI更新任务（lambda表达式）\n     \u002F\u002F 为各接口启动更新任务\n     \u002F\u002F 创建传输层并启动\n }\n \n \u002F\u002F 启动协议：启动NCSI协议，如果失败则注册回调等待BDF就绪\n bool xyz1000_card::start_protocol() {\n     \u002F\u002F 尝试启动NCSI协议\n     \u002F\u002F 如果失败，注册BDF变化回调\n }\n \n } \u002F\u002F namespace dev\n 关键说明 方法 职责 init() 加载配置文件中的属性值，使用 from_variant 自动映射 start() 初始化子设备、启动协议通信、注册回调和定时器 stop() 清理资源 协议启动流程： 获取BDF（Bus\u002FDevice\u002FFunction） 创建MCTP对象 创建NCSI协议实例 为接口绑定更新任务  3.6 实现网口对象 代码示例： xyz1000_port.h #ifndef XYZ1000_PORT_H\n #define XYZ1000_PORT_H\n \n #include \u003Cmc\u002Fengine.h>\n #include \u003Cncsi_over_mctp\u002Fncsi_over_mctp.h>\n \n #include \"interface\u002Fnetwork_port.h\"\n #include \"interface\u002Fnetwork_port\u002Flink_info.h\"\n \n namespace dev {\n \n using ncsi_over_mctp_xyz_ptr = std::shared_ptr\u003Cncsi_over_mctp>;\n \n class xyz1000_port : public mc::engine::object\u003Cxyz1000_port> {\n public:\n     MC_OBJECT(\n         xyz1000_port,\n         \"NicPort\",\n         \":Parent\u002FNicPort\u002F:Id\",\n         (NetworkPort)(NetworkPort_LinkInfo)\n     )\n \n     xyz1000_port() = default;\n     ~xyz1000_port() = default;\n \n     bool init(mc::mutable_dict& csr_object, const mc::dict& connector);\n     bool start();\n     bool stop();\n \n     void start_ncsi_protocol(ncsi_over_mctp_xyz_ptr ncsi_over_mctp, \n                              mc::milliseconds interval);\n \n     NetworkPort          m_network_port;\n     NetworkPort_LinkInfo m_network_port_link_info;\n \n private:\n     ncsi_over_mctp_xyz_ptr m_ncsi_over_mctp;\n     mc::core::timer*       m_ncsi_timer = nullptr;\n };\n \n } \u002F\u002F namespace dev\n \n MC_REFLECT(dev::xyz1000_port,\n            ((m_network_port, \"bmc.dev.NetworkPort\"))\n            ((m_network_port_link_info, \"bmc.dev.NetworkPort.LinkInfo\")))\n \n #endif  \u002F\u002F XYZ1000_PORT_H\n 代码示例： xyz1000_port.cpp #include \"xyz1000_port.h\"\n #include \u003Cmc\u002Flog.h>\n \n namespace dev {\n \n \u002F\u002F 初始化网口：从配置加载网口属性\n bool xyz1000_port::init(mc::mutable_dict& csr_object, const mc::dict& connector) {\n     \u002F\u002F 使用from_variant加载配置\n     \u002F\u002F 加载PortId、MAC地址等属性\n }\n \n \u002F\u002F 启动网口：执行网口启动逻辑\n bool xyz1000_port::start() {\n     \u002F\u002F 执行网口特定的启动操作\n     \u002F\u002F 打印启动日志\n }\n \n \u002F\u002F 停止网口：停止定时器并清理资源\n bool xyz1000_port::stop() {\n     \u002F\u002F 停止NCSI定时器\n     \u002F\u002F 释放定时器内存\n }\n \n \u002F\u002F 启动NCSI协议：创建定时器周期性更新网口状态\n void xyz1000_port::start_ncsi_protocol(ncsi_over_mctp_xyz_ptr ncsi_over_mctp, \n                                         mc::milliseconds interval) {\n     \u002F\u002F 保存NCSI协议对象\n     \u002F\u002F 创建定时器\n     \u002F\u002F 设置定时器回调（获取链路状态、流量统计等）\n     \u002F\u002F 启动定时器\n }\n \n } \u002F\u002F namespace dev\n 关键说明 网口对象的路径使用 :Parent ，表示在父对象（网卡）路径下 定时器用于周期性更新网口状态 从NCSI协议获取数据并更新到接口属性  3.7 实现接口类 核心要点 接口类继承自 gen 命名空间的基类，负责具体的协议实现和数据更新。 1. 接口类定义 \u002F\u002F 继承自生成的基类\n class NetworkAdapter : public gen::NetworkAdapter {\n public:\n     \u002F\u002F 启动NCSI更新任务：创建定时器周期性更新属性\n     void start_ncsi_update_task(ncsi_over_mctp_xyz_ptr ncsi_over_mctp,\n                                 mc::milliseconds interval);\n     \n     \u002F\u002F 停止更新任务：停止并释放定时器\n     void stop_ncsi_update_task();\n     \n     \u002F\u002F 更新方法：通过NCSI协议获取数据并更新属性\n     void update_firmware_version();\n     void update_chip_info();\n     \n private:\n     mc::core::timer*         m_ncsi_timer = nullptr;\n     ncsi_over_mctp_xyz_ptr   m_ncsi_over_mctp;\n };\n \n \u002F\u002F MC_REFLECT注册：指定基类\n MC_REFLECT(dev::NetworkAdapter, (gen::NetworkAdapter), ())\n 2. 关键实现方法 \u002F\u002F 启动更新任务：创建定时器周期性更新属性\n void NetworkAdapter::start_ncsi_update_task(ncsi_over_mctp_xyz_ptr ncsi_over_mctp,\n                                             mc::milliseconds interval) {\n     \u002F\u002F 保存协议对象\n     \u002F\u002F 创建定时器\n     \u002F\u002F 设置定时器回调（调用各个update方法）\n     \u002F\u002F 启动定时器\n     \u002F\u002F 立即执行一次更新\n }\n \n \u002F\u002F 更新固件版本：通过NCSI协议获取并更新FirmwareVersion属性\n void NetworkAdapter::update_firmware_version() {\n     \u002F\u002F 构造NCSI请求数据\n     \u002F\u002F 调用m_ncsi_over_mctp->request()发送请求\n     \u002F\u002F 解析响应数据\n     \u002F\u002F 更新属性：FirmwareVersion = parsed_version\n }\n 关键要点： 接口类必须继承对应的 gen 基类 使用定时器周期性调用update方法 update方法负责：获取数据 → 解析 → 更新属性 属性更新后会自动触发信号通知上层  3.8 实现ABI导出 ABI（Application Binary Interface）是驱动程序与框架交互的标准接口。 代码示例： xyz1000_abi.cpp #include \u003Cdevmon\u002Fdriver_abi.h>\n #include \u003Cmc\u002Flog.h>\n \n #include \"xyz1000_card.h\"\n #include \"xyz1000_port.h\"\n \n using namespace dev;\n \n extern \"C\" {\n \n \u002F\u002F ============================================\n \u002F\u002F 网卡主对象ABI函数\n \u002F\u002F ============================================\n \n \u002F\u002F 创建网卡对象：分配内存并设置基本属性\n driver_handle_t create_xyz1000_card(void* service, const char* name) {\n     \u002F\u002F 参数检查\n     \u002F\u002F 创建xyz1000_card对象\n     \u002F\u002F 设置service和对象名称\n     \u002F\u002F 返回对象指针\n }\n \n \u002F\u002F 初始化网卡对象：加载配置\n status_t init_xyz1000_card(driver_handle_t device, void* csr_object, void* connector) {\n     \u002F\u002F 参数检查\n     \u002F\u002F 类型转换\n     \u002F\u002F 调用对象的init方法\n     \u002F\u002F 返回状态码\n }\n \n \u002F\u002F 启动网卡对象：启动设备和协议\n status_t start_xyz1000_card(driver_handle_t device) {\n     \u002F\u002F 参数检查\n     \u002F\u002F 调用对象的start方法\n     \u002F\u002F 返回状态码\n }\n \n \u002F\u002F 停止网卡对象：停止设备和清理资源\n status_t stop_xyz1000_card(driver_handle_t device) {\n     \u002F\u002F 参数检查\n     \u002F\u002F 调用对象的stop方法\n     \u002F\u002F 返回状态码\n }\n \n \u002F\u002F ============================================\n \u002F\u002F 网口对象ABI函数\n \u002F\u002F ============================================\n \n \u002F\u002F 创建网口对象：分配内存并设置基本属性\n driver_handle_t create_xyz1000_port(void* service, const char* name) {\n     \u002F\u002F 参数检查\n     \u002F\u002F 创建xyz1000_port对象\n     \u002F\u002F 设置service和对象名称\n     \u002F\u002F 返回对象指针\n }\n \n \u002F\u002F 初始化网口对象：加载配置\n status_t init_xyz1000_port(driver_handle_t device, void* csr_object, void* connector) {\n     \u002F\u002F 参数检查\n     \u002F\u002F 类型转换\n     \u002F\u002F 调用对象的init方法\n     \u002F\u002F 返回状态码\n }\n \n \u002F\u002F 启动网口对象：启动网口\n status_t start_xyz1000_port(driver_handle_t device) {\n     \u002F\u002F 参数检查\n     \u002F\u002F 调用对象的start方法\n     \u002F\u002F 返回状态码\n }\n \n \u002F\u002F 停止网口对象：停止网口\n status_t stop_xyz1000_port(driver_handle_t device) {\n     \u002F\u002F 参数检查\n     \u002F\u002F 调用对象的stop方法\n     \u002F\u002F 返回状态码\n }\n \n \u002F\u002F ============================================\n \u002F\u002F 驱动注册\n \u002F\u002F ============================================\n \n \u002F\u002F 网卡主对象驱动结构体：定义设备名和生命周期函数\n device_driver_t xyz1000_card_device_driver = {\n     .device_name = \"PCIeNicCard\",           \u002F\u002F 设备类型名（必须与DDS文件一致）\n     .ctor        = create_xyz1000_card,     \u002F\u002F 创建函数\n     .init        = init_xyz1000_card,       \u002F\u002F 初始化函数\n     .start       = start_xyz1000_card,      \u002F\u002F 启动函数\n     .stop        = stop_xyz1000_card        \u002F\u002F 停止函数\n };\n \n \u002F\u002F 网口对象驱动结构体：定义设备名和生命周期函数\n device_driver_t xyz1000_port_device_driver = {\n     .device_name = \"NicPort\",               \u002F\u002F 设备类型名（必须与DDS文件一致）\n     .ctor        = create_xyz1000_port,     \u002F\u002F 创建函数\n     .init        = init_xyz1000_port,       \u002F\u002F 初始化函数\n     .start       = start_xyz1000_port,      \u002F\u002F 启动函数\n     .stop        = stop_xyz1000_port        \u002F\u002F 停止函数\n };\n \n \u002F\u002F 驱动数组：包含所有设备类型的驱动\n device_driver_t xyz1000_device_driver[] = {\n     xyz1000_card_device_driver,\n     xyz1000_port_device_driver\n };\n \n \u002F\u002F 驱动注册函数：框架调用此函数获取驱动列表\n status_t register_device_driver(device_driver_t** device_driver, uint8_t* count) {\n     \u002F\u002F 返回驱动数组指针\n     *device_driver = xyz1000_device_driver;\n     \u002F\u002F 返回驱动数量\n     *count = sizeof(xyz1000_device_driver) \u002F sizeof(xyz1000_device_driver[0]);\n     \n     ilog(\"Registered xyz1000 device driver: ${count} devices\", (\"count\", *count));\n     return STATUS_OK;\n }\n \n } \u002F\u002F extern \"C\"\n 关键说明 所有ABI函数必须用 extern \"C\" 包装，确保C语言兼容 每个设备类型需要4个函数： create 、 init 、 start 、 stop device_name 必须与DDS文件中的对象类型匹配 register_device_driver 是框架调用的入口函数  3.9 配置构建编译 代码示例： meson.build # 源文件列表\n xyz1000_sources = files(\n     'xyz1000_card.cpp',\n     'xyz1000_port.cpp',\n     'xyz1000_abi.cpp',\n )\n \n # 接口实现源文件\n interface_sources = files(\n     'interface\u002Fpcie_device.cpp',\n     'interface\u002Fnetwork_adapter.cpp',\n     'interface\u002Fnetwork_port.cpp',\n     'interface\u002Fnetwork_port\u002Flink_info.cpp',\n )\n \n # 合并源文件\n all_sources = xyz1000_sources + interface_sources\n \n # 包含目录\n include_dirs = [\n     include_directories('.'),\n     include_directories('interface'),\n     gen_inc,\n     internal_inc\n ]\n \n # 静态库（用于测试）\n libxyz1000_static = static_library(\n     'xyz1000',\n     all_sources,\n     include_directories: include_dirs,\n     dependencies: [\n         dev_deps,\n         libncsi_over_mctp_dep,\n         libmctp_dep\n     ],\n     install: false\n )\n \n # 动态库（用于部署）\n libxyz1000 = shared_library(\n     'xyz1000',\n     include_directories: include_dirs,\n     name_prefix: 'lib',\n     name_suffix: 'so',\n     install: true,\n     install_dir: drivers_install_dir,\n     link_whole: [libxyz1000_static]\n )\n 关键说明 库名会成为驱动SO文件名： libxyz1000.so install_dir 使用 drivers_install_dir 变量（框架定义） 依赖关系要明确列出，避免链接错误  4. 最佳实践建议 4.1 代码规范 命名规范 类型 规范 示例 类名 厂商_型号_类型 xyz1000_card 文件名 与类名一致 xyz1000_card.h 成员变量 m_ 前缀 m_network_ports 常量 大写+下划线 DEFAULT_TIMEOUT 日志规范 启动\u002F停止 ：使用 ilog 错误 ：使用 elog 调试信息 ：使用 dlog 日志要包含上下文信息 ilog(\"Starting xyz1000_card: ${name} with ${count} ports\",\n      (\"name\", card_name)(\"count\", port_count));\n 错误处理 所有可能失败的操作都要检查返回值 使用 try-catch 捕获异常 记录详细的错误信息 try {\n     bool ret = operation();\n     if (!ret) {\n         elog(\"Operation failed: ${reason}\", (\"reason\", error_msg));\n         return false;\n     }\n } catch (const std::exception& e) {\n     elog(\"Exception caught: ${error}\", (\"error\", e.what()));\n     return false;\n }\n  4.2 性能优化 定时任务间隔 根据数据变化频率设置不同的更新间隔，避免不必要的通信开销 快速变化数据 ：5秒（5000ms） - 温度、链路状态、故障状态 慢速变化数据 ：120秒（120000ms） - 固件版本、设备信息 极慢变化数据 ：180秒（180000ms） - 带宽统计、配置信息 实际应用示例： \u002F\u002F 不同接口使用不同的更新间隔\n m_network_adapter_cooling.start_ncsi_update_task(ncsi, mc::milliseconds(5000));      \u002F\u002F 温度：5秒\n m_network_adapter.start_ncsi_update_task(ncsi, mc::milliseconds(120000));            \u002F\u002F 基础信息：120秒\n m_pcie_device_bandwidth.start_ncsi_update_task(ncsi, mc::milliseconds(180000));      \u002F\u002F 带宽：180秒\n 内存管理 优先使用智能指针（ shared_ptr ） 及时清理定时器等资源 重要 ：MCTP对象必须使用成员变量管理，防止严重内存泄漏 MCTP对象管理： \u002F\u002F 头文件声明\n class xyz1000_card : public mc::engine::object\u003Cxyz1000_card> {\n private:\n     mctp* m_mctp_object;  \u002F\u002F 使用成员变量管理\n };\n \n \u002F\u002F 实现文件\n xyz1000_card::xyz1000_card() : m_mctp_object(nullptr) {}\n \n xyz1000_card::~xyz1000_card() {\n     \u002F\u002F 在析构函数中释放，防止内存泄漏\n     if (m_mctp_object) {\n         delete m_mctp_object;\n         m_mctp_object = nullptr;\n     }\n }\n \n bool xyz1000_card::start_ncsi_protocol() {\n     \u002F\u002F 赋值给成员变量，而不是局部变量\n     m_mctp_object = new mctp(this, phy_addr, ...);\n }\n 定时器资源管理： \u002F\u002F 清理定时器\n if (m_timer != nullptr) {\n     m_timer->stop();\n     delete m_timer;\n     m_timer = nullptr;\n }\n 协议优化 批量请求减少通信次数 缓存不变的数据 失败时使用指数退避 4.3 测试建议 单元测试 测试每个接口的更新方法 测试异常情况处理 使用mock对象模拟协议 TEST(xyz1000_card, test_init) {\n     xyz1000_card card;\n     mc::mutable_dict csr_object = {...};\n     mc::dict connector = {...};\n     \n     EXPECT_TRUE(card.init(csr_object, connector));\n }\n 集成测试 测试完整的生命周期： create  →  init  →  start  →  stop 测试与实际硬件的通信 测试长时间运行的稳定性 回归测试 每次修改后重新测试基本功能 检查是否影响其他网卡驱动 验证Redfish接口数据正确 结语 南向网卡驱动适配是一项系统性工作，需要对硬件特性、通信协议、软件架构都有深入理解。本文档提供了一套完整的适配流程和代码示例，但实际适配中还会遇到各种具体问题，欢迎大家积极在社区沟通交流和贡献。 html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[209],{"_path":218,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":219,"description":220,"date":221,"category":206,"archives":222,"author":223,"_type":18,"_id":227,"_source":20,"_file":228,"_stem":229,"_extension":23,"coverImage":230,"plainText":231,"authorNames":232},"\u002Fzh\u002Fblogs\u002Fhi3093-dev-board-i2c","Hi3093开发板的传感器功能适配与调试","本文介绍了基于适配I2C传感器的常用调试和适配方法，供社区开发者适配传感器提供指导。","2025\u002F08\u002F25","2025-08",[224],{"name":225,"description":226},"郭馨","任职于昆仑太科（北京）技术股份有限公司，是openUBMC项目组组长。","content:zh:blogs:hi3093-dev-board-i2c.md","zh\u002Fblogs\u002Fhi3093-dev-board-i2c.md","zh\u002Fblogs\u002Fhi3093-dev-board-i2c","\u002Fcategory\u002Fblog\u002Fhi3093-dev-board-i2c\u002FHi3093_board.jpg","Hi3093开发板的传感器功能适配与调试 前言 本文介绍了基于 米尔电子MYC-LHi3093开发板 适配I2C传感器的常用调试和适配方法，供社区开发者适配传感器提供指导。 物料准备 Hi3093核心板 核心板电源适配器 网线 typeC-USB线 杜邦线 扩展板（拥有LM75传感器） I2C工具的应用 目前2506版本的OpenUBMC暂不支持i2ctool工具进行i2cdetect和i2ctransfer操作，本文参考论坛帖子 自制I2C调试工具分享(适用于OpenUBMC平台的i2cdetect和i2ctransfer) ，将i2cdetect和i2ctransfer工具通过scp上传到\u002Fdata目录下使用。 传感器的调试 根据米尔科技开发板硬件原理图设计，通过开发板上的排针将BMC的I2C总线等通过杜邦线连接到外部调试板上。本文以I2C9为例，电源、GND、SDA和SCL连线如下图所示：  已知连接到外部调试板上的I2C9下挂载有LM75(0x48)、LM75(0x4f)、PCA9546(0x70)，PCA9546的channel0下接有LM75(0x49)。\n通过\u002Fdata目录下执行 .\u002Fi2cdetect 9 可看出上述设备已经正确探测到。  通过执行 .\u002Fi2ctransfer 9 w2@0x70 0x01 ，使能PCA9546 channel0，再执行 .\u002Fi2cdetect 9 可看出LM75(0x49)可以被探测到。  PCA9546控制寄存器低四位分别对应四个Channel，可以通过i2ctransfer使能指定Channel，查看指定Channel下I2C设备是否连接正常。  通过以下命令可独立使能PCA9546 对应四个channel，通过向PCA9546写入0x00，则可禁用所有Channel。 Channel ID 命令 Channel 0 i2ctransfer \u003Ci2cbus> w1@0x70 0x01 Channel 1 i2ctransfer \u003Ci2cbus> w1@0x70 0x02 Channel 2 i2ctransfer \u003Ci2cbus> w1@0x70 0x04 Channel 3 i2ctransfer \u003Ci2cbus> w1@0x70 0x08 传感器的配置 CSR配置以board name为openUBMC为例， vpd\u002Fvendor\u002FHuawei\u002FServer\u002FKunpeng\u002FopenUBMC\u002Froot.sr  中配置如下： ManagementTopology ->  Anchor -> Buses 内增加  I2c_9 I2c_9 下增加LM75传感器芯片和 Connectors 配置，  Connector 下配置 Connector_DemoCard ，以表示PCA9546位于下级组件DemoCard的CSR。 Objects 下配置LM75对象、 Entity 、 ThresholdSensor ，因该传感器是定时轮询获取数值，故配置 Scanner 。 Objects 下配置 Connector_DemoCard ， IdentifyMode 配置为2表示下一级组件非天池组件，非天池组件由Bom、Id、AuxId三项配置决定下一级组件CSR名称:  Bom_Id_AuxId.csr ，本例中下一级组件CSR名称为 14100513_DemoCard_0.sr 。 Buses 中配置的 I2c_9 表示和下一级板卡连接的总线为I2C9，需注意同一个CSR文件中的任意两个连接器 Position 不能重复。 {\n     \"ManagementTopology\" : {\n         \"Anchor\" : {\n             \"Buses\" : [\n                 \"I2c_1\" ,\n                 \"I2c_2\" ,\n                 \"I2c_3\" ,\n                 \"I2c_4\" ,\n                 \"I2c_5\" ,\n                 \"I2c_6\" ,\n                 \"I2c_7\" ,\n                 \"I2c_8\" ,\n                 \"I2c_9\" ,\n                 \"I2c_11\"\n             ]\n         },\n         \"I2c_9\" : {\n             \"Chips\" : [\n                 \"Lm75_1\" ,\n                 \"Lm75_2\"\n             ],\n             \"Connectors\" : [\n                 \"Connector_DemoCard\"\n             ]\n        }\n     },\n     \"Objects\" : {\n         \"I2c_9\" : {\n             \"Id\" :  9\n         },\n         \"Lm75_1\" : {\n             \"OffsetWidth\" :  1 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  144\n         },\n         \"Lm75_2\" : {\n             \"OffsetWidth\" :  1 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  158\n         },\n         \"Scanner_InletLM75\" : {\n             \"Chip\" :  \"#\u002FLm75_1\" ,\n             \"Size\" :  1 ,\n             \"Offset\" :  0 ,\n             \"Mask\" :  255 ,\n             \"Period\" :  1000\n         },\n         \"Scanner_OutletLM75\" : {\n             \"Chip\" :  \"#\u002FLm75_2\" ,\n             \"Size\" :  1 ,\n             \"Offset\" :  0 ,\n             \"Mask\" :  255 ,\n             \"Period\" :  1000\n         },\n         \"ThresholdSensor_InletTemp\" : {\n             \"AssertMask\" :  516 ,\n             \"DeassertMask\" :  516 ,\n             \"ReadingMask\" :  4626 ,\n             \"Linearization\" :  0 ,\n             \"M\" :  100 ,\n             \"RBExp\" :  224 ,\n             \"UpperCritical\" :  60 ,\n             \"LowerCritical\" :  5 ,\n             \"PositiveHysteresis\" :  2 ,\n             \"NegativeHysteresis\" :  2 ,\n             \"OwnerId\" :  32 ,\n             \"OwnerLun\" :  0 ,\n             \"EntityId\" :  \"\u003C=\u002FEntity_InletTemp.Id\" ,\n             \"EntityInstance\" :  \"\u003C=\u002FEntity_InletTemp.Instance\" ,\n             \"Initialization\" :  127 ,\n             \"Capabilities\" :  104 ,\n             \"SensorType\" :  1 ,\n             \"ReadingType\" :  1 ,\n             \"SensorName\" :  \"Inlet_Temp\" ,\n             \"Unit\" :  128 ,\n             \"BaseUnit\" :  1 ,\n             \"ModifierUnit\" :  0 ,\n             \"Analog\" :  1 ,\n             \"MaximumReading\" :  127 ,\n             \"MinimumReading\" :  128 ,\n             \"Reading\" :  \"\u003C=\u002FScanner_InletLM75.Value\"\n         },\n         \"Entity_InletTemp\" : {\n             \"Id\" :  99 ,\n             \"Name\" :  \"Inlet_Temp\" ,\n             \"PowerState\" :  1 ,\n             \"Presence\" :  1 ,\n             \"Instance\" :  96\n         },\n         \"ThresholdSensor_OutletTemp\" : {\n             \"AssertMask\" :  29312 ,\n             \"DeassertMask\" :  29312 ,\n             \"ReadingMask\" :  6168 ,\n             \"Linearization\" :  0 ,\n             \"M\" :  100 ,\n             \"RBExp\" :  224 ,\n             \"UpperCritical\" :  65 ,\n             \"UpperNoncritical\" :  50 ,\n             \"PositiveHysteresis\" :  2 ,\n             \"NegativeHysteresis\" :  2 ,\n             \"OwnerId\" :  32 ,\n             \"OwnerLun\" :  0 ,\n             \"EntityId\" :  \"\u003C=\u002FEntity_OutletTemp.Id\" ,\n             \"EntityInstance\" :  \"\u003C=\u002FEntity_OutletTemp.Instance\" ,\n             \"Initialization\" :  127 ,\n             \"Capabilities\" :  104 ,\n             \"SensorType\" :  1 ,\n             \"ReadingType\" :  1 ,\n             \"SensorName\" :  \"Outlet_Temp\" ,\n             \"Unit\" :  128 ,\n             \"BaseUnit\" :  1 ,\n             \"ModifierUnit\" :  0 ,\n             \"Analog\" :  1 ,\n             \"MaximumReading\" :  127 ,\n             \"MinimumReading\" :  128 ,\n             \"Reading\" :  \"\u003C=\u002FScanner_OutletLM75.Value\"\n         },\n         \"Entity_OutletTemp\" : {\n             \"Id\" :  99 ,\n             \"Name\" :  \"OutletTemp\" ,\n             \"PowerState\" :  1 ,\n             \"Presence\" :  1 ,\n             \"Instance\" :  97\n         },\n         \"Connector_DemoCard\" : {\n             \"Bom\" :  \"14100513\" ,\n             \"Slot\" :  2 ,\n             \"Position\" :  4 ,\n             \"Presence\" :  1 ,\n             \"Id\" :  \"DemoCard\" ,\n             \"AuxId\" :  \"0\" ,\n             \"Buses\" : [\n                 \"I2c_9\"\n             ],\n             \"SystemId\" :  1 ,\n             \"ManagerId\" :  \"1\" ,\n             \"ChassisId\" :  \"1\" ,\n             \"IdentifyMode\" :  2\n         }\n     }\n }\n 因新增了CSR文件，需要在 vpd\u002Fvendor\u002FHuawei\u002FServer\u002FKunpeng\u002FopenUBMC\u002Fprofile.txt 中增加 14100513_DemoCard_0.sr 文件所在路径。本例中配置如下： Huawei\u002FServer\u002FKunpeng\u002FopenUBMC\u002FPSR\u002F14100513_DemoCard_0.sr\n PCA9546可使用Pca9545配置，需注意 Objects -> I2cMux_Pca9545_i2c9_chan0 配置 ChannelId ， 14100513_DemoCard_0.sr 配置如下： {\n     \"FormatVersion\" :  \"3.00\" ,\n     \"DataVersion\" :  \"3.00\" ,\n     \"ManagementTopology\" : {\n         \"Anchor\" : {\n             \"Buses\" : [\n                 \"I2c_9\"\n              ]\n         },\n         \"I2c_9\" : {\n             \"Chips\" : [\n                 \"Pca9545_i2c9_chip\"\n             ]\n         },\n         \"Pca9545_i2c9_chip\" : {\n             \"Buses\" : [\n                 \"I2cMux_Pca9545_i2c9_chan0\"\n             ]\n         },\n         \"I2cMux_Pca9545_i2c9_chan0\" : {\n             \"Chips\" : [\n                 \"Lm75_3\"\n             ]\n         }\n     },\n     \"Objects\" : {\n         \"Pca9545_i2c9_chip\" : {\n             \"OffsetWidth\" :  0 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  224 ,\n             \"WriteTmout\" :  0 ,\n             \"ReadTmout\" :  0 ,\n             \"HealthStatus\" :  0\n         },\n         \"I2cMux_Pca9545_i2c9_chan0\" : {\n             \"ChannelId\" :  0\n         },\n         \"Lm75_3\" : {\n             \"OffsetWidth\" :  1 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  146\n         },\n         \"Scanner_NicLM75\" : {\n             \"Chip\" :  \"#\u002FLm75_3\" ,\n             \"Size\" :  1 ,\n             \"Offset\" :  0 ,\n             \"Mask\" :  255 ,\n             \"Period\" :  1000\n         },\n         \"ThresholdSensor_DemoTemp\" : {\n             \"AssertMask\" :  31381 ,\n             \"DeassertMask\" :  31381 ,\n             \"ReadingMask\" :  16191 ,\n             \"Linearization\" :  0 ,\n             \"M\" :  100 ,\n             \"RBExp\" :  224 ,\n             \"UpperNonrecoverable\" :  70 ,\n             \"UpperCritical\" :  65 ,\n             \"UpperNoncritical\" :  55 ,\n             \"LowerNonrecoverable\" :  0 ,\n             \"LowerCritical\" :  5 ,\n             \"LowerNoncritical\" :  10 ,\n             \"PositiveHysteresis\" :  2 ,\n             \"NegativeHysteresis\" :  2 ,\n             \"OwnerId\" :  32 ,\n             \"OwnerLun\" :  0 ,\n             \"EntityId\" :  \"\u003C=\u002FEntity_NicTemp.Id\" ,\n             \"EntityInstance\" :  \"\u003C=\u002FEntity_NicTemp.Instance\" ,\n             \"Initialization\" :  127 ,\n             \"Capabilities\" :  104 ,\n             \"SensorType\" :  1 ,\n             \"ReadingType\" :  1 ,\n             \"SensorName\" :  \"Nic_Temp\" ,\n             \"Unit\" :  128 ,\n             \"BaseUnit\" :  1 ,\n             \"ModifierUnit\" :  0 ,\n             \"Analog\" :  1 ,\n             \"MaximumReading\" :  127 ,\n             \"MinimumReading\" :  128 ,\n             \"Reading\" :  \"\u003C=\u002FScanner_NicLM75.Value\"\n         },\n         \"Entity_NicTemp\" : {\n             \"Id\" :  9 ,\n             \"Name\" :  \"Nic_Temp\" ,\n             \"PowerState\" :  1 ,\n             \"Presence\" :  1 ,\n             \"Instance\" :  98\n         }\n     }\n }\n 传感器Web显示 经过上述配置后，可看到传感器Web已显示正常。\n  html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[225],{"_path":234,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":235,"description":236,"date":237,"category":206,"author":238,"_type":18,"_id":242,"_source":20,"_file":243,"_stem":244,"_extension":23,"coverImage":245,"plainText":246,"authorNames":247},"\u002Fzh\u002Fblogs\u002F20250815","商业实践 | 宝德计算：基于openUBMC智能串口屏的应用实践","本文分享宝德计算机系统股份有限公司基于openUBMC实现自研创新组件落地的成功商业实践——智能串口屏。文章将围绕功能应用背景与落地成果、关键设计解析及核心功能实现逻辑展开，深入阐述宝德引领性的自研组件实现路径，为openUBMC生态开发者提供极具价值的实践参考与创新指引。","2025\u002F08\u002F15",[239],{"name":240,"description":241},"邱豪","宝德计算系统工程师和BMC研发主管，深度参与openUBMC相关项目的设计与研发。","content:zh:blogs:20250815.md","zh\u002Fblogs\u002F20250815.md","zh\u002Fblogs\u002F20250815","\u002Fcategory\u002Fblog\u002F20250815\u002Fimg01.webp","商业实践 | 宝德计算：基于openUBMC智能串口屏的应用实践 本文分享宝德计算机系统股份有限公司基于openUBMC实现自研创新组件落地的成功商业实践——智能串口屏。文章将围绕功能应用背景与落地成果、关键设计解析及核心功能实现逻辑展开，深入阐述宝德引领性的自研组件实现路径，为openUBMC生态开发者提供极具价值的实践参考与创新指引。 智能串口屏： 实时性高场景，边缘计算场景 智能串口屏为服务器BMC人机交互提供了轻量化、高可靠的本地管理入口，在实时性要求严苛的边缘计算场景尤其适合。 随着服务器应用场景的拓展（如边缘计算场景），传统远程监控（如IPMI、Web界面）无法满足快速故障定位需求，尤其是网络中断或远程工具故障时，本地可视化监控成为刚需，仍可通过本地屏进行紧急操作，提升系统可靠性。  同时边缘计算节点，部署在偏远或物理隔离环境，通过本地监控屏可减少对远程管理的依赖，故障快速响应需求。如风扇停转、温度过高等硬件故障需要即时可视化的告警能力，避免远程监控延迟导致宕机风险。  智能串口屏的低功耗设计，相比传统显示终端节能较多，有效降低长期运维成本。串口屏硬件成本低且易于集成，适合大规模部署。 智能串口屏支持本地化控制能力，可直接通过触摸屏控制BMC，实现本地化的服务器运维操作（如重启服务器、调整风扇策略、切换电源模式，等等），提升现场运维灵活性。  在断网等极端环境下仍可以通过串口屏直接查看BMC或系统日志及实时备份日志，为后期维护诊断带来了有力的帮助。  宝德智能串口屏高度集成主流监控与控制功能，包括串口信息重定向、日志备份、设备受控管理、系统状态实时监测及告警监控等核心模块。其成功部署，显著提升了产线与机房运维人员对服务器管理的实时性、高效性与智能化水平。  智能串口屏实现方案 智能串口屏作为BMC管理体系的典型应用场景，其实现需深度整合BMC软件开发、硬件设计、底层协议（I2C\u002F串口），及终端桌面应用开发等跨领域技术能力。  硬件设计方案 通过重新设计BMC的低速总线接口，分出一组I2C线，连接到机箱外部，将智能串口屏与BMC相连。同时通过卡扣等方式将智能串口屏接在机箱上，支持可选配拆卸。利用在扩展板上适配I2C转串口模块，基于I2C模拟特定串口协议来实现BMC与串口屏通信。  软件设计方案 通过新增openUBMC的组件，完成智能串口屏的功能实现。通过openUBMC的资源协作接口，宝德的智能串口屏组件能够很轻易地获取到服务器的资产信息、网络信息、SEL事件并通过串口发送给智能串口屏。同时通过openUBMC的组件框架监听和轮询服务器整体状态和各部件状态、各温度点数据，准确地将服务器的健康状态传输至智能串口屏，实现可视化告警能力。 智能串口屏下发的串口命令指令也会路由至此组件，通过解析串口命令并与对应的资源协作接口方法一一关联，实现整机上下电、BMC重启、风扇模式设置等交互命令。  串口屏组件串口信息重定向功能设计介绍 宝德智能串口屏支持串口信息重定向，将BMC的串口日志传输至智能串口屏，显著提升现场运维故障定位时效性。基于此技术基础，创新性设计串口信息定期备份机制，打造类航空\"黑匣子\"级数据保护能力。在断电断网、设备受损等极端工况下，仍可确保关键运维数据完整留存。串口重定向功能逻辑流程实现方案如下，供社区开发者参考借鉴。  结语 宝德计算积极参与openUBMC社区活动，通过自研组件快速实现创新设计应用落地，彰显出openUBMC的开源生态价值。宝德将积极地向社区共享商业实践经验，与社区开发者共同进步。希望后续能与更多社区开发者在BMC领域持续创新，共同推动openUBMC社区发展。 欢迎关注openUBMC 社区官网： https:\u002F\u002Fwww.openubmc.cn 代码仓地址： https:\u002F\u002Fgitcode.com\u002FopenUBMC\u002Fnetwork_adapter",[240],{"_path":249,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":250,"description":251,"date":252,"category":206,"archives":222,"author":253,"_type":18,"_id":257,"_source":20,"_file":258,"_stem":259,"_extension":23,"plainText":260,"authorNames":261},"\u002Fzh\u002Fblogs\u002Fpki-cert-service-guide","PKI 实践指南：构建完整的证书服务系统","本文是一份基于  的证书服务实践教程，目标是在 Demo 环境中快速跑通 CA\u002FRA 全流程，包括证书模板创建、终端实体模板配置、审批流程启用，以及 RA 端的终端证书申请与下载。教程聚焦“能跑起来”，适合实验、PoC 或内部演示，不涉及生产环境的安全加固与合规细节。","2025\u002F08\u002F11",[254],{"name":255,"description":256},"沈威","openubmc 社区开发者对BMC与开源固件有长期兴趣，活跃于openubmc社区，热衷于探索和交流新特性。","content:zh:blogs:pki-cert-service-guide.md","zh\u002Fblogs\u002Fpki-cert-service-guide.md","zh\u002Fblogs\u002Fpki-cert-service-guide","PKI 实践指南：构建完整的证书服务系统 1. 引言 本文是一份基于  EJBCA  的证书服务实践教程，目标是在 Demo 环境中快速跑通 CA\u002FRA 全流程，包括证书模板创建、终端实体模板配置、审批流程启用，以及 RA 端的终端证书申请与下载。教程聚焦“能跑起来”，适合实验、PoC 或内部演示，不涉及生产环境的安全加固与合规细节。 主要收获 ：掌握 EJBCA 的核心操作路径，完成从模板配置到证书签发的全过程  2. 方案架构与术语 RA ：负责终端实体注册与身份审核。 证书模板（Certificate Profile） ：预设密钥用法、SAN、有效期等。  3. 实验环境与前置条件 操作系统：Ubuntu 20.04 Server（离线安装） 前置软件：Docker ，docker-compose (apt 包)  4. EJBCA Docker 部署与持久化 本文将详细介绍如何在 Docker 中部署  EJBCA 证书服务 ，并确保其数据持久化存储在独立数据盘上，避免因容器或虚拟机重启导致数据丢失。内容包括使用内部数据库（默认 H2）的持久化配置、 docker-compose  方式运行容器、开放远程访问所需的配置。 4.1 环境准备与代理配置 由于部分 EJBCA Docker 镜像（如  keyfactor\u002Fejbca-ce  ）需要从公网拉取，为确保环境可用，请先配置 Docker Daemon 的 HTTP\u002FHTTPS 代理。 配置 systemd 代理 Docker Daemon 运行在 systemd 管理下，需添加配置以继承系统代理。 sudo  mkdir  -p  \u002Fetc\u002Fsystemd\u002Fsystem\u002Fdocker.service.d\n sudo  nano  \u002Fetc\u002Fsystemd\u002Fsystem\u002Fdocker.service.d\u002Fhttp-proxy.conf\n 内容如下： [Service]\n Environment=\"HTTP_PROXY=http:\u002F\u002F192.168.xxx.xxx:7890\"\n Environment=\"HTTPS_PROXY=http:\u002F\u002F192.168.xxx.xxx:7890\"\n Environment=\"NO_PROXY=127.0.0.1,localhost,192.168.13.119\"\u002F\u002Fip需要改成自己虚拟机主机ip\n 重新加载并重启 Docker sudo  systemctl  daemon-reload\n sudo  systemctl  restart  docker\n sudo  systemctl  status  docker  --no-pager  -l\n 若输出中含有  Active: active (running)  即表示代理配置生效。 验证代理是否生效 docker  info  |  grep  -i  proxy\n 出现如下输出说明代理生效： HTTP  Proxy:  http:\u002F\u002F192.168.xxx.xxx:7890\n HTTPS  Proxy:  http:\u002F\u002F192.168.xxx.xxx:7890\n 4.2 数据持久化配置 使用文件方式保存 H2 数据库：将数据库配置为  jdbc:h2:\u002Fmnt\u002Fpersistent\u002Fejbcadb;DB_CLOSE_DELAY=-1 宿主机挂载路径： \u002Fopt\u002Fejbca-data:\u002Fmnt\u002Fpersistent 避免使用  --rm  启动容器 设置宿主机权限： chown -R 10001:10001 \u002Fopt\u002Fejbca-data 📌 提示：正式环境建议切换到 PostgreSQL \u002F MySQL 等外部数据库，提升可靠性与容灾能力。 4.3 使用 Docker Compose 部署 创建目录结构： mkdir  -p  \u002Fopt\u002Fejbca-compose\n cd  \u002Fopt\u002Fejbca-compose\n mkdir  -p  \u002Fopt\u002Fejbca-data\n chown  -R  10001:10001  \u002Fopt\u002Fejbca-data\n 当前目录下创建 docker-compose.yml ，编写  docker-compose.yml ： version :  \"3.3\"  # 使用 Docker Compose 文件格式版本 3.3\n \n services :\n   ejbca :  # 定义名为 ejbca 的服务\n     image :  keyfactor\u002Fejbca-ce:latest  # 使用 Keyfactor 提供的 EJBCA 社区版镜像，使用最新版本\n     container_name :  ejbca  # 容器名称为 ejbca\n     hostname :  myejbca.test.local  # 容器内部主机名，影响证书中的 CN 等字段\n \n     environment :  # 设置环境变量配置 EJBCA 的启动行为\n       -  DATABASE_JDBC_URL=jdbc:h2:\u002Fmnt\u002Fpersistent\u002Fejbcadb;DB_CLOSE_DELAY=-1  # 使用嵌入式 H2 数据库，数据保存在挂载目录下\n       -  TLS_SETUP_ENABLED=true  # 启用自动 TLS 设置（用于 HTTPS 接入）\n       -  SMTP_DESTINATION=192.168.xx.xx  # 设置 SMTP 邮件服务器地址（用于发送通知邮件）\n       -  SMTP_DESTINATION_PORT=25  # SMTP 服务端口，默认 25（未启用加密）\n       -  SMTP_FROM=ejbca@example.local  # 设置邮件发送的发件人地址\n       -  SMTP_TLS_ENABLED=false  # 不启用 SMTP 的 STARTTLS\n       -  SMTP_SSL_ENABLED=false  # 不启用 SMTP 的 SSL\u002FTLS 加密\n \n     ports :  # 映射容器端口到宿主机\n       -  \"80:8080\"  # 宿主机 80 端口映射到容器的 8080（HTTP）\n       -  \"443:8443\"  # 宿主机 443 端口映射到容器的 8443（HTTPS）\n \n     volumes :  # 数据卷挂载，将容器中的目录映射到宿主机，以持久化数据\n       -  \u002Fopt\u002Fejbca-data:\u002Fmnt\u002Fpersistent  # 将宿主机的 \u002Fopt\u002Fejbca-data 目录挂载到容器中，持久化数据库等数据\n \n     restart :  unless-stopped  # 如果容器异常退出则自动重启，除非人为停止\n 启动容器服务： docker-compose  up  -d\n docker-compose  logs  -f\n ⚙️ 使用 Compose 可轻松管理配置版本，便于团队协作和恢复。 4.4 远程访问配置 提前设置容器 hostname（影响 TLS 证书 CN）： hostname :  myejbca.test.local\n 4.5 管理证书信任 下载超级管理员证书  .p12  后需双击导入证书存储 4.6 登录流程摘要 docker-compose logs -f 查找容器日志中  SuperAdmin URL  和一次性密码： ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *                                                                                                     *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *    URL:      https:\u002F\u002Fmyejbca.test.local:443\u002Fejbca\u002Fra\u002Fenrollwithusername.xhtml ? username = superadmin  *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *    Password: urAMy0He5c\u002FhHy+DYyDFNy4E                                                                *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *                                                                                                     *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *  Once the P12 is downloaded, use  \"urAMy0He5c\u002FhHy+DYyDFNy4E\"  to import it.                            *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *                                                                                                     *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  ******************************************************************************************************\n 访问领取 URL 填写密码 → 设置导出密码 → 下载  .p12 导入浏览器后访问： https:\u002F\u002Fmyejbca.test.local\u002Fejbca\u002Fadminweb 若提示未提供客户端证书，检查是否导入成功、代理关闭、域名正确解析 ✅ 至此，EJBCA 部署 + 持久化 + 管理登录流程即告完成。 4.7 重要提示（请务必遵守以下要求） ✅  必须  先将  myejbca.test.local  添加到  hosts  文件，或搭建本地 DNS 服务器，否则浏览器可能无法解析域名。 ✅  超级管理员证书算法默认是 DILITHIUM2 （根据版本默认算法会不一样），但  Windows 大概不能识别 ，建议改为  RSA 4096 ，以确保兼容性。 ✅  不能开代理 ，否则 EJBCA 可能无法正确处理客户端证书认证。 ✅  确保 Windows\u002FmacOS\u002FLinux 证书存储正确导入 ，避免  No client certificate was presented  错误。 ✅  第一次建议使用 chrome 浏览器无痕模式 ，避免缓存问题导致 No client certificate was presented 。  5. 初始 CA 创建与证书层级搭建 5.1 进入证书 Profile 管理 登录  EJBCA 管理控制台 。 依次点击  CA Functions → Certificate Profiles  进入管理页面。 5.2 创建证书 Profile 方法 1：克隆现有 Profile 在列表中找到合适的 Profile（如  ENDUSER ）。 点击  Clone ，输入新名称，保存。 方法 2：手动创建 Profile 点击  Add ，输入名称后进入编辑页面。 根据实际需求设置  Key Usage 、 Extended Key Usage 、有效期、Subject DN 设置等。 保存后返回列表查看。 5.3 创建 Crypto Token 进入  CA Functions → Crypto Tokens 。 点击  Create new  并填写： Name ：输入 Crypto Token 名称。 Type ：选择  SOFT 。 Auto-activation ：可选，勾选可自动激活。 Allow export of private keys ：如需导出私钥，勾选  Allow 。 Authentication Code ：输入认证码并重复确认。  dd if=\u002Fdev\u002Frandom bs=1 count=128 2>&1| sha256sum | awk '{print $1} 保存并在列表中确保状态为  Active 。 5.4 生成密钥对 进入  Crypto Token  详情页面。 在  Crypto Token currently does not contain any key pairs.  处输入密钥名称（如  signKey ）。 选择密钥算法（如  RSA 4096 ）。 点击  Generate new key pair  生成密钥。 注意 ：默认 Profile 不能修改，需克隆后新建。 5.5 创建 CA 打开  CA Functions → Certification Authorities 。 在顶部列表中会看到默认的  ManagementCA (Active) ； 无需选中它 。 滚动到页面底部的  Add CA  区域：\n 在文本框中输入新 CA 名称，例如  DemoCA 。 点击右侧  Create…  按钮，进入 CA 配置向导。 在  Create CA  页面完成相关字段： 点击最下方  Create  保存。若配置正确，页面将跳转回 CA 列表并看到  DemoSubCA (Active)  状态。 （可选）若要手动上传由根 CA 签发的证书，可在列表中选中新 CA，然后使用  Import CA certificate…  功能上传链文件。 到此，中间 CA 创建完成，后续即可用它签发终端实体证书。 5.6 Root CA 创建简要步骤案例 1️⃣ CA 类型与密钥配置 参数 说明 CA Type X.509 CA  ✅ 标准 X.509 证书 CA。 Crypto Token 选择已创建的  Crypto Token  ✅（如  demoCrypto ）。 Signing Algorithm SHA256WithRSA  ✅ 更安全的签名算法。 Alternative Signing Algorithm None  ❌ 无需备用签名算法。 Key Sequence Format Numeric (0-9)  ✅ 用于 CA 证书序列号。 Key Sequence 00000  ✅ 初始序列号，可修改。 Description Root CA 说明，可填写用途、管理单位等 ✅  2️⃣ 证书策略（Directives） 参数 说明 Enforce unique public keys ✅ 强制公钥唯一性，防止重复 Enforce key renewal ❌ Root CA 可不启用 Enforce unique DN ✅ 确保  DN  唯一（适用于小规模 CA） Enforce unique Subject DN SerialNumber ❌ 仅适用于大规模 CA（20 个以下证书可不启用） Use Certificate Request History ❌ 记录证书请求历史,Root CA 不启用 Use User Storage ✅ 存储用户信息 Use Certificate Storage ✅ 存储已颁发证书  3️⃣ 证书数据（CA Certificate Data） 参数 说明 Subject DN CN=test EnterpriseIT Root CA  ✅ Signed By Self Signed  ✅ Root CA 必须自签名 Certificate Profile ITROOTCA_profile  ✅ 选择克隆后的 ROOTCA，允许修改参数 Validity 20y  ✅ 证书有效期 20 年 Subject Alternative Name ❌ Root CA 通常不需要 Certificate Policy OID ❌ 可选，默认留空 Use UTF-8 in policy notice text ✅ 确保国际字符支持 PrintableString encoding in DN ❌ 不勾选，避免影响国际化 LDAP DN order ✅ 确保  DN  按 LDAP 规范排列 Serial Number Octet Size 20  ✅ 推荐 20 字节，确保唯一性 Name Constraints, Permitted ❌ Root CA 默认禁用，留空 Name Constraints, Excluded ❌ Root CA 默认禁用，留空  4️⃣ CRL 配置（证书吊销列表） 参数 说明 Microsoft CA Compatibility Mode ❌ Root CA 不启用，仅适用于 Windows 证书颁发机构（AD CS）。 Authority Key ID ✅ 启用，并标记  Critical ，用于标识 CRL 发行者。建议 Root CA 和中间 CA 都启用。 CRL Number ✅ 启用，并标记  Critical ，确保 CRL 版本唯一。建议 Root CA 和中间 CA 启用。 Issuing Distribution Point on CRLs ❌ Root CA 可不启用，仅适用于分层 CRL 结构的大规模 CA。 CA issuer URI ❌ 留空，证书下载后期由用户自行提供接口。 Keep expired certificates on CRL ❌ Root CA 不启用，中间 CA 视情况决定，启用后即使证书过期仍会出现在 CRL 中。 Use CRL partitions ❌ Root CA 负载小，不需要。适用于大规模证书管理的 CA。 CRL Expire Period 30d  ✅ Root CA 设长一些，如  30d ，中间 CA 采用较短的 CRL 过期时间。 CRL Issue Interval 7d  ✅ 定期更新 CRL，建议活跃 CA 采用  7d 。 CRL Overlap Time 12h  ✅ 旧 CRL 与新 CRL 重叠 12h，防止证书验证失败。 Delta CRL Period 0m  ❌ Root CA 不使用 Delta CRL，只有对实时性要求高的 CA 才需要启用。 Generate CRL Upon Revocation ❌ Root CA 不启用，中间 CA 需要时启用，证书撤销后立即生成新的 CRL。 Allow changing revocation reason ✅ 启用，允许修改证书撤销原因。适用于所有 CA。 Allow invalidity date ✅ 启用，允许设置证书失效日期。适用于所有 CA。  5️⃣ 审批设置 参数 说明 Add\u002FEdit End Entity None  ❌ Root CA 不管理终端实体 Key Recovery None  ❌ Root CA 不提供密钥恢复 Revocation None  ❌ Root CA 很少撤销自身证书 CA Service Activation None  ❌ Root CA 手动激活  6️⃣ 其他数据 参数 说明 Validators Finish User  ✅ 启用证书验证策略。 CMP RA Authentication Secret ❌ 留空，仅在使用 CMP 协议时需要配置。 Monitor if CA active (healthcheck) Activate  ✅ 启用 CA 运行监控，适用于所有 CA。 Request Processor None  ❌ Root CA 通常不需要外部请求处理。  7️⃣ 外部签名 CA 创建或更新（Externally signed CA creation\u002Frenewal） 参数 说明 Renew CA ❌ 建议创建新的 Root CA，而不是重新生成密钥并重新签名现有 CA，以避免同名 Root CA 证书带来的问题。 CA Chain Certificates ✅ 仅当 CA 由外部 CA 签名时才需要上传证书链文件（PEM\u002FDER 格式）。如果 Root CA 已安装在本地，则不需要上传此文件。  8️⃣ 完成 CA 创建 检查所有参数，确认无误后，点击  Create  生成 CA。 ① 下载并验证 Root CA 证书： 使用以下 OpenSSL 命令验证证书格式和有效性： # 验证 PEM 格式证书\n openssl  x509  -in  rootca.pem  -text  -noout\n \n # 验证 DER 格式证书\n openssl  x509  -in  rootca.der  -inform  DER  -text  -noout\n \n # 检查证书 SHA256 指纹信息\n openssl  x509  -noout  -fingerprint  -sha256  -in  rootca.pem\n \n # 验证证书的有效性（自签名证书验证）\n openssl  verify  -CAfile  rootca.pem  rootca.pem\n ② 部署并验证 CRL（证书吊销列表）： 若配置了 CRL URL，执行： # 验证 CRL 文件\n openssl  crl  -in  rootca.crl  -text  -noout\n 确保 CRL 可通过 Web 正常访问。 🚀  Root CA 现在已成功创建，可用于签发中间 CA！  🎉 5.7 中间 CA 创建简要步骤案例 1️⃣ CA 类型与密钥配置 参数 说明 CA Type X.509 CA  ✅ 标准 X.509 证书 CA Crypto Token 选择已创建的 Crypto Token ✅（如  demoCrypto ） Signing Algorithm SHA256WithRSA  ✅ 更安全的签名算法 Alternative Signing Algorithm None  ❌ 无需备用签名算法 Key Sequence Format Numeric (0-9)  ✅ 用于 CA 证书序列号 Key Sequence 00001  ✅ 初始序列号，与 Root CA 区分 Description 中间 CA 说明，可填写用途、管理单位等 ✅  2️⃣ 证书策略（Directives） 参数 说明 Enforce unique public keys ✅ 强制公钥唯一性，防止重复 Enforce key renewal ✅ 中间 CA 建议启用，保证安全 Enforce unique DN ✅ 确保 DN 唯一 Enforce unique Subject DN SerialNumber ❌ 规模小于 20 个证书时可不启用 Use Certificate Request History ✅ 记录证书请求历史 Use User Storage ✅ 存储用户信息 Use Certificate Storage ✅ 存储已颁发证书  3️⃣ 证书数据（CA Certificate Data） 参数 说明 Subject DN 例如  CN=test Intermediate CA  ✅ Signed By test EnterpriseIT Root CA  ✅ 中间 CA 必须由 Root CA 签名 Certificate Profile INTERMEDIATE_CA_profile  ✅ 克隆后配置适合中间 CA Validity 10y  ✅ 通常为 10 年，有效期小于 Root CA Subject Alternative Name ❌ 中间 CA 通常不需要 Certificate Policy OID ❌ 默认留空，或按需填写 Use UTF-8 in policy notice text ✅ 确保国际字符支持 PrintableString encoding in DN ❌ 不勾选，避免影响国际化 LDAP DN order ✅ 按 LDAP 规范排列 DN Serial Number Octet Size 20  ✅ 推荐 20 字节 Name Constraints, Permitted ❌ 默认禁用，留空 Name Constraints, Excluded ❌ 默认禁用，留空  4️⃣ CRL 配置（证书吊销列表） 参数 说明 Microsoft CA Compatibility Mode ❌ 一般不启用，仅用于 Windows AD 环境 Authority Key ID ✅ 启用，并标记为 Critical CRL Number ✅ 启用，并标记为 Critical Issuing Distribution Point on CRLs ❌ 通常不启用 CA issuer URI ❌ 留空，或按需填写下载地址 Keep expired certificates on CRL ❌ 中间 CA 建议启用，保留过期证书，目前不启用，会导致吊销列表越来越大 Use CRL partitions ❌ 通常不需要 CRL Expire Period 7d  ✅ 建议 7 天，确保及时更新 CRL Issue Interval 1d  ✅ 每天发布，确保及时更新 CRL Overlap Time 12h  ✅ 与旧 CRL 重叠 12 小时，确保平稳过渡 Delta CRL Period 0m  ❌ 不使用 Delta CRL Generate CRL Upon Revocation ✅ 启用，证书撤销后立即更新 Allow changing revocation reason ✅ 允许修改证书撤销原因 Allow invalidity date ✅ 允许设置证书失效日期  5️⃣ 默认 CA 验证数据（Default CA defined validation data） 参数 说明 Default CRL Distribution Point ❌ 默认留空或按需填写，用于 CRL 分发地址 Default CRL Issuer ❌ 默认留空，通常无需填写 Default Freshest CRL Distribution Point ❌ 默认留空，通常无需填写 OCSP Service Default URI ❌ 默认留空，按需填写 OCSP 地址 CA Issuer Default URI ❌ 默认留空或后期提供接口  6️⃣ 审批设置与其他数据 审批设置目前只有 None 选项，表示无需额外审批流程，如需开启需检查 EJBCA 的全局审批策略，Supervision Fuctions。 参数 说明 Validators Finish User  ✅ 启用证书验证策略 CMP RA Authentication Secret ❌ 留空，仅在使用 CMP 协议时需要配置 Monitor if CA active (healthcheck) Activate  ✅ 启用运行监控 Request Processor None  ❌ 一般不需外部请求处理  7️⃣ 完成中间 CA 创建 检查所有参数，确认无误后，点击  Create  生成 CA 请求文件 (CSR)。 提交 CSR 给 Root CA 签名后，下载签名后的证书并验证： openssl  x509  -in  intermediate_ca.pem  -text  -noout\n openssl  verify  -CAfile  rootca.pem  intermediate_ca.pem\n 🚀 中间 CA 已成功创建，可用于签发终端实体证书！🎉  6. RA 普通用户创建与权限配置 6.1 创建 RA 角色（Role） 进入 RA 管理界面 （RA Web），选择菜单： Role Management →Roles →Create New Role\n 填写角色信息 ： 字段 推荐填写值 Namespace No namespace Role name test RA Users 设置 Certificate Authorities 权限 ： 从Available列表选择对应CA（如  Intermediate CA ,  Root CA ），点击 Add 。 设置 End Entity 权限（permissions） （推荐配置）： ✅ Create end entities ✅ Create certificates\n ✅ ...by using username and password ✅ ...by using a request ID ✅ View end entities and certificates 设置 End Entity Profiles 权限 ： 从 Available 列表选择 EMPTY ，点击 Add 。 点击 Add 保存创建好的角色。 6.2 创建 RA 普通用户 (End Entity) 进入 EJBCA Admin Web 界面 ，选择： RA Functions → Add End Entity\n 填写用户详细信息： 字段 推荐填写值 End Entity Profile EMPTY Username test_signuser Password 123 Confirm Password 123 Batch generation 不勾选 E-mail cert-user@example.com CN test RA user S1 O test C CN Certificate Profile ENDUSER CA test Intermediate CA Token P12 file 点击 Add ，完成 End Entity 创建。 6.3 用户证书下载 用户进入 RA Web 界面 ，选择： Enroll → Use Username\n 使用刚创建的用户名和密码登录： Username:  test_signuser Password:  123 登录后选择密钥算法： 选择 RSA 4096 算法，生成并下载 .p12 用户证书。 6.4 将用户加入 RA 角色 进入 RA Web 界面，选择菜单： Search → End Entities\n 查找并复制刚才创建证书的 CN 。 进入 RA 管理界面，选择菜单： Role Management → Roles → Members → Add Role Member\n 填写 Role Member 信息： 字段 推荐填写值 Role test RA Users Token Type Certificate CA test Intermediate CA Match with CN Common Name Match Value 粘贴刚复制的证书 CN Description RA 普通用户 点击 Add ，完成角色成员添加。 重启 EJBCA 服务 ，使权限生效（推荐）： docker  restart  ejbca\n 6.5 用户登录 RA 界面 非管理员角色 将下载的 .p12 证书导入浏览器。 访问 RA Web 界面，自动认证并登录。 用户即可执行授权内的 RA 操作（如创建和查看证书等）。 6.6 重要提示（请务必遵守以下要求） ✅  第一次建议使用 chrome 浏览器无痕模式快速启动验证 ，避免缓存问题导致 No OAuth providers configured. Please log in using a valid certificate. 。 ✅  访问时候 使用 https 访问 ， https:\u002F\u002F192.168.xxx.xxx\u002Fejbca\u002Fra\u002F ,避免出现 No OAuth providers configured. Please log in using a valid certificate. 。  7. 证书模板设置说明 本节用于解释 EJBCA 中终端证书模板（Certificate Profile）设置项的具体含义及推荐用途，适用于 HTTPS\u002FWeb\u002F设备\u002F客户端等常见终端证书签发需求。  7.1 基本信息 配置项 描述 Certificate Profile ID 模板在数据库中的唯一标识，仅供系统内部识别 类型 可用终端实体，子 CA，根 CA Available Key Algorithms 可用密钥算法，如 RSA、ECDSA、Ed25519、 DILITHIUM 等 Available ECDSA curves ECDSA 可选曲线，当前未启用任何曲线 可用位长度 支持的密钥位数（针对 RSA），如 2048、4096 等 签名算法 用于签发证书时的签名哈希算法，如 SHA3-256withRSA Alternative Signature 是否启用替代签名算法，如 ECDSA, EdDSA 等 有效期 or end date of the certificate 默认有效期，如 \"2y\" 表示 2 年 Validity Offset 签发日期的偏移量，允许向前或向后设定起始时间 Expiration Restrictions 限制最大到期时间，用于合规控制 Profile Description 证书模板说明，用于备注用途（如“终端设备证书”）  7.2 权限控制（Permissions） 配置项 描述 推荐设置 Allow Validity Override 允许在签发证书时覆盖默认有效期 ✅，如需手动调整有效期时使用 Allow Expired Validity End Date 允许设置一个已过期的结束时间（用于测试或审计） ✅（调试用） Allow Extension Override 允许 CSR 中的扩展字段覆盖模板中预定义的扩展 ❌，若开启会破坏模板统一性，可能引入风险 Allow certificate serial number override 允许在签发时自定义证书序列号 ❌，仅特定需求下开启（如证书克隆、替换） Allow Subject DN Override by CSR 允许 CSR 中的主题信息（如 CN\u002FO）覆盖模板配置 ✅，适用于自动化签发流程 Allow Subject DN Override by End Entity Information 允许通过终端实体信息（用户输入）指定 Subject 字段 ✅，灵活性高，推荐开启 Allow Key Usage Override 允许 CSR 中设置 keyUsage 字段覆盖模板配置 ❌，开启会造成用途不一致，影响安全性 Allow Backdated Revocation 允许将吊销时间设置为历史时间，用于追溯性撤销 ✅，部分审计\u002F合规场景下需要 Use Certificate Storage 启用证书在数据库中存储（必须开启，除非特殊离线用途） ✅ Store Certificate Data 存储证书完整原文数据（配合 OCSP\u002FCRL 使用） ✅，建议与存储功能一同开启 ✅ 建议： 在生产环境中保持模板统一性，除非明确需要，否则尽量关闭 Override 类权限项，避免 CSR\u002FEnd Entity 越权操作。  7.3 X.509v3 扩展 - 基础信息 扩展项 描述 推荐设置 基本约束（Basic Constraints） 限制是否为 CA 证书（终端证书应设为 FALSE） ✅ 使用，关键 CA 密钥标识符 标识签发 CA 的信息 ✅ 使用 主题密钥标识符 生成此证书的唯一标识 ✅ 使用  7.4 X.509v3 扩展 - 密钥用途（Key Usage） 项目 描述 数字签名 (digitalSignature) 用于验证签名，如身份认证、代码签名 不可抵赖 (nonRepudiation) 表明签名不可否认（法律场景） 数据加密 (dataEncipherment) 用于加密非密钥数据 密钥加密 (keyEncipherment) 用于加密密钥材料，如对称密钥 密钥协议 (keyAgreement) 支持密钥协商协议（如 DH） CRL 签名 (cRLSign) 用于签署吊销列表（CA 用） 密钥证书签名 (keyCertSign) 用于签署证书（CA 用） 只用于加密 (encipherOnly) 与密钥协议联合使用（仅加密） 只用于解密 (decipherOnly) 与密钥协议联合使用（仅解密） Forbid encryption usage for ECC keys 禁止 ECC 密钥用于加密 7.5 X.509v3 扩展 - 扩展密钥用途（Extended Key Usage） 扩展用途 描述 TLS client 用于客户端 TLS 认证 TLS server 用于服务器 TLS 认证 EAP over LAN (EAPOL) 企业网身份认证 EAP over PPP 点对点协议身份认证 ETSI TSL Signing 用于 ETSI TSL 签名场景 ICAO Deviation List Signing ICAO 签名用途之一 ICAO Master List Signing ICAO 主列表签名 Intel AMT management Intel 管理认证专用 Internet Key Exchange for IPsec IPsec 密钥交换 Kerberos Client Authentication Kerberos 客户端认证 Kerberos KDC Kerberos 密钥中心 MS CA Key Exchange Microsoft CA 密钥交换用途 MS Commercial Code Signing Microsoft 商业代码签名 MS Document Signing Microsoft 文档签名 MS EFS Recovery Microsoft EFS 恢复用途 MS Encrypted File System Microsoft 加密文件系统用途 MS Individual Code Signing Microsoft 个人代码签名 MS 智能卡登录 Microsoft 智能卡登录验证 OCSP 签发者 在线证书状态协议（OCSP）签名证书用途 PDF Signing 用于 PDF 文件签名 PIV Card Authentication PIV 卡身份认证 RFC9336 Document Signing 符合 RFC9336 的文档签名用途 SCVP Client 简化证书验证协议客户端 SCVP Server 简化证书验证协议服务端 SIP Domain 用于 VoIP\u002FSIP 域名认证用途 SSH Client 用于 SSH 客户端认证 SSH Server 用于 SSH 服务器认证 代码签名 (codeSigning) 用于软件\u002F驱动程序签名 任意扩展的密钥用途 任意通用用途扩展支持 安全 Email (emailProtection) S\u002FMIME 邮件签名\u002F加密用途 客户身份验证 (clientAuth) 用于 TLS 客户端身份认证 时间戳 (timeStamping) 时间戳服务签名用途 服务器验证 (serverAuth) 用于服务器身份验证（HTTPS 等） 7.6 名称扩展 项目 描述 建议 主题别名（Subject Alt Name） 支持 IP\u002FDNS\u002FUEmail 作为证书标识 ✅ 使用 Issuer Alternative Name 可添加额外的 CA 名称信息 可选 Name Constraints 限定主题中可用的命名空间 可选（高安全场景使用） 7.7 验证扩展（Validation Data） 项目 描述 推荐 CRL 发布点 证书吊销列表地址 ✅ 使用，关键 Delta CRL（Freshest CRL） 增量吊销列表 按需开启 Authority Information Access (AIA) 提供 OCSP\u002FCA 信息 ✅  7.8 私钥使用期限制 项目 描述 Start Offset 私钥可用的起始偏移时间 Period Length 私钥的可使用周期（独立于证书有效期）  7.9 🇪🇺 ETSI 合规扩展（一般用于合规性要求高的 PKI 环境） 项目 描述 资质证书声明 用于标识法律或合规用途证书 Assured validity 确保短期证书的有效性  7.10 其他扩展（Other Extensions） 扩展 用途 OCSP No Check 禁用 OCSP 检查（通常仅对 OCSP responder 有用） Microsoft 模板值 用于 Windows AD 集成的特殊扩展 CA\u002FB Forum OID 用于 CA\u002FB 合规的组织标识扩展  7.11 审批设置 & 附加字段 配置项 说明 添加\u002F编辑终端实体 绑定的审批流程 密钥恢复 是否支持密钥找回（如用于备份恢复） 撤销审批 吊销时是否需审批 CN 后缀 在 Subject CN 后自动添加字符串 主题字段子集限制 限制允许使用的 Subject 字段  7.12 CA & 发布设置 项目 说明 可用的 CA 允许哪些 CA 使用此证书模板 发布器（Publisher） 可配置发布至 LDAP、数据库或外部服务 单证书限制 是否启用一个 End Entity 只能有一张有效证书 Account Binding Namespace 用于设备账户绑定场景（如 IoT）  如需配置 \"代码签名证书\" 模板，请在此基础上调整 keyUsage 与 extendedKeyUsage 字段即可。 📌 建议对不同应用（如：VPN、HTTPS、代码签名、客户端认证）创建不同模板，便于管理和合规控制。  8. 审批配置与管理 8.1 创建 Approval Profile（审批配置） 进入： 监察员功能 → Approval Profiles\n 在底部输入名称（如  test ）→ 点击  添加 。 在列表中点击  编辑  进入详细设置。 8.2 基本参数设置 字段 建议\u002F示例 Approval Profile Type Accumulative Approval（累计）；跨部门可用 Partitioned Approval（分区） Request Expiration Period 8h （超时未批作废） Approval Expiration Period 8h （结果过期需重批） Max Extension Time 0d （不允许延长） Allow Self Approved Request Editing 不勾选（生产禁用自批） 8.3 审批步骤（Approval Steps） 设置  Number of Required Approvals ： 开发\u002F测试： 1 （1-of-1）。 生产\u002F敏感操作： 2 （2-of-2）或分区审批。 通知邮件： Notification message email recipient ： approval-admin-group@example.org supervisor@example.org Notification message email sender ： no-reply@192.168.xxx.xx 主题模板示例： [AR-${approvalRequest.ID}-${approvalRequest.STEP_ID}-${approvalRequest.PARTITION_ID}] Approval Request\n 正文可引用变量： ${approvalRequest.TYPE} 、 ${approvalRequest.REQUESTOR} 、 ${approvalRequest.WORKFLOWSTATE}  等。 8.4 绑定到具体动作 End Entity Profile： CA Functions → End Entity Profiles → \u003CProfile> → Approval Settings → 勾选需要审批的操作（如Add\u002FEdit End Entity） → 选择上面创建的 Approval Profile → Save\n 常用勾选： Add\u002FEdit End Entity 、 Key Recovery （若启用）。 Certificate Profile： CA Functions → Certificate Profiles → \u003CProfile> → Approval Settings → 勾选相关操作 → 选择 Approval Profile → Save\n 管理员敏感动作：  中间 CA 变更、吊销等建议使用  2-of-2  或分区审批。 8.5 测试与验证 用一个普通 RA 账号在 RA Web 发起一次需要审批的操作（如创建 End Entity）。 到  监察员功能 → Approvals  查看待审批队列，使用另一个审批员账号完成审批。 确认操作自动执行，且邮件通知正常到达。 8.6 常见问题 邮件收不到 ：检查 SMTP 配置、防火墙、收件人拼写；查看容器日志。 一直待审批 ： Number of Required Approvals  设置过高或审批人不具备权限。 能自批 ：误勾选了  Allow Self Approved Request Editing ；生产应关闭。 过期作废 ： Request\u002FApproval Expiration  设置过短；可调到  8–24h 。  9. 终端实体模板设置 位置： RA Functions → End Entity Profiles 。终端实体模板（End Entity Profile）决定了“能填哪些字段”“哪些必填\u002F可改”“默认使用哪个证书模板\u002FCA\u002FToken”。 9.1 新建与进入 进入： RA Functions → End Entity Profiles\n 在底部输入模板名（如  test ）→  添加模板 。 在列表中选中该模板 →  编辑终端实体模板 。 9.2 基本信息（用户名\u002F密码\u002F邮箱） 是否必须提前填？  通常  不需要  在模板里写死具体“用户名\u002F密码”。模板里只定义“规则与方式”，具体的  Username\u002FPassword\u002FEnrollment Code  在 创建 End Entity 或申请时 填写即可。 推荐做法 Username ：选择  Auto-generated （批量\u002F自动化最方便），或在创建 End Entity 时手动指定。 Password (or Enrollment Code) ：勾选  Required ，作为一次性  Enrollment Code  使用；具体值在创建 End Entity 或 RA 端申请时再填。 Minimum password strength \u002F length ：保持策略（如长度 ≥ 8），但不在模板里填具体密码。 Maximum number of failed login attempts ：按需限制；可勾  Modifiable  便于临时调整。 Batch generation ：一般关闭；避免明文存储 Enrollment Code。 E-mail ：按业务是否  Required\u002FModifiable ，便于通知与标识。 不同申请路径对 Username\u002FPassword 的影响 RA Web → Enroll → Use Username ：创建 End Entity 时需要指定  Username  与  Password\u002FEnrollment Code ，用户用该账号登录领取证书。 RA Web → Enroll → Use Request ID ：由系统分配  Request ID ， Password\u002FEnrollment Code  在创建时设置，申请人用 ID+Code 领取。 User Generated（CSR 提交） ： Token=User Generated ；保留  Required  以生成一次性代码，申请人用 CSR+Code 完成签发。 Directives（指令） Reverse Subject DN and Subject Alt Name Checks ：不勾也可以。 Allow merge DN for all interfaces ：通常  不勾 ，仅在多接口需要聚合 DN 时启用。 Allow multi-value RDNs ：仅特殊需求启用（默认关闭更安全）。 9.3 主体 DN 属性（Subject DN Attributes）— 需要自己添加 左侧是“可选属性”，右侧是“已选属性”。把需要的字段添加到右侧，并为每个字段设置  Required \u002F Modifiable \u002F Validation 。 常见推荐（客户端\u002F通用）： 字段 建议 CN, Common name Required ； Modifiable  由 RA 决定 emailAddress, E-mail address in DN 选配；如需与邮件系统绑定可  Required O, Organization  \u002F  OU, Org. Unit 视业务；建议  Modifiable  关闭以避免乱填 C, Country 固定为  CN  或所在国家；通常不允许修改 若需要更严格的校验，可在  Validation  指定正则\u002F格式规则。 9.4 其他主体属性（Other Subject Attributes）— 需要自己添加 Subject Alternative Name（SAN） ： 客户端证书： RFC 822 Name (e-mail address) （与账户邮箱一致） 服务器证书： DNS Name 、 IP Address （按域名\u002FIP 添加） 设备证书： OtherName （写入设备 ID\u002FOID） Subject Directory Attributes （可选）： 仅在需要存档\u002F合规时使用，例如  Date of birth (YYYYMMDD)  等；默认不建议开启过多目录属性。 添加方法：在  Other Subject Attributes  区域选择条目 →  添加  到右侧；如界面支持，可设置  Required\u002FModifiable 。 9.5 主要证书数据（Main Certificate Data） 字段 建议\u002F说明 Default Certificate Profile 选择目标证书模板（如  ENDUSER  \u002F  SERVER ） Available Certificate Profiles 仅勾选允许使用的模板，避免误选 Default CA  \u002F  Available CAs 指定可签发的 CA； 注意：修改可用 CA 会影响角色对此 Profile 的访问 Default Token  \u002F  Available Tokens P12 file （RA 直接下载 p12）或  User Generated （用户自带 CSR） 9.6 其他证书数据（Other Certificate Data） Custom certificate serial number ：默认关闭 Certificate Validity Start\u002FEnd Time ：默认由  Certificate Profile  控制；如需临时证书可开启并  Modifiable Name Constraints (Permitted\u002FExcluded) ：一般用于中间 CA；终端实体模板通常不启用 Custom certificate extension data  \u002F  ETSI PSD2 QC Statement  \u002F  CA\u002FB Forum Organization Identifier ：按合规需要开启 9.7 其他数据与限制（Other Data \u002F Restrictions） 字段 建议 Number of allowed requests 1 （防多次重复签发） Allow renewal before expiration 例如  30  天；如不限制填  -1 Revocation reason to set after certificate issuance 默认  Active （一般不改） Redact Subject Name from logs 仅在隐私\u002F合规强需求时开启 Send Notification 按需；与 SMTP 配置关联 9.8 保存与授权 点击  保存 。 到  RA Web → Role Management  确认相关角色已被授权“使用此 End Entity Profile”（可见\u002F可创建）。 在  Search → End Entities  使用该模板创建测试用户，验证：\n DN\u002FSAN 是否按规则入库； 证书是否使用了期望的  Certificate Profile\u002FCA\u002FToken ； 下载\u002F导入是否成功（P12\u002FPEM\u002FCSR 流程）。  10. RA 普通用户申请终端证书 位置： RA Web → Enroll 。 默认建议：优先使用   By the CA （CA 端生成密钥），无需 CSR，流程最稳、最少出错。 10.1 路径与前置 已在  End Entity Profiles （第 9 节）与  Certificate Profiles  准备好模板；用户具备访问权限。 若启用审批（第 8 节），提交后会进入待审队列，审批通过才签发。 10.2 推荐：By the CA（无需 CSR） 进入： Enroll → Make New Request\n 选择  Certificate Type （End Entity Profile）与  Certificate subtype （Certificate Profile）。 在  Key‑pair generation  选择  By the CA 。 展开  Provide request info ，按模板要求填写  Subject DN \u002F SAN （如 CN、Email、DNS\u002FIP）。 下载  *.p12 。 10.3 可选：Provided by user（上传 CSR） 仅当 必须 在客户端\u002F服务器本地生成密钥（如合规要求、HSM\u002F专用设备、已有密钥迁移）时使用。 本地生成私钥与 CSR： 在页面选择  Provided by user ，将完整 CSR（含  BEGIN\u002FEND CERTIFICATE REQUEST ）粘贴到输入框。 提交并按提示下载证书（不会包含你的私钥）。 10.4 审批联动与通知 当 Profile 绑定了  Approval Profile  时，提交即进入待审；通过后自动签发或开放下载。 邮件主题\u002F正文遵循第 8 节的通知模板。 10.5 常见问题 字段不通过 ：DN\u002FSAN 与 Profile 约束不一致；按第 9 节调整。 不能下载 P12 ：浏览器拦截或口令策略冲突；更换浏览器\u002F检查口令长度与字符集。 CSR 被拒 ：CSR 中 Subject\u002FSAN 与模板冲突；按模板重建 CSR 或改用  By the CA 。 审批卡住 ：审批人数未满足或审批人权限不足；去“监察员功能 → Approvals”。 html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[255],{"_path":263,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":264,"description":265,"date":266,"category":13,"author":267,"_type":18,"_id":271,"_source":20,"_file":272,"_stem":273,"_extension":23,"coverImage":274,"plainText":275,"authorNames":276},"\u002Fzh\u002Fblogs\u002F202508071","openUBMC可观测技术：洞察系统全貌、引领BMC新视界","在数字化转型的浪潮中，系统复杂性与日俱增，如何高效监控和管理分布式系统成为关键挑战。BMC系统（Baseboard Management Controller，基板管理控制器）作为硬件与软件之间的桥梁，承担着设备管理、监控和维护的重要职责。为了提升openUBMC的可观测性，在25.06版本中我们构建了observability组件，基于openTelemetry构建了完整的可观测能力，帮助开发者更清晰地洞察系统运行状态，快速定位问题，优化系统性能。","2025\u002F08\u002F07",[268],{"name":269,"description":270},"许强","openUBMC Interface SIG Maintainer，专注提升openUBMC接口管理效率和BMC固件可定位性。","content:zh:blogs:202508071.md","zh\u002Fblogs\u002F202508071.md","zh\u002Fblogs\u002F202508071","\u002Fcategory\u002Fblog\u002F20250807\u002Fimg01.gif","openUBMC可观测技术：洞察系统全貌、引领BMC新视界 在数字化转型的浪潮中，系统复杂性与日俱增，如何高效监控和管理分布式系统成为关键挑战。BMC系统（Baseboard Management Controller，基板管理控制器）作为硬件与软件之间的桥梁，承担着设备管理、监控和维护的重要职责。为了提升openUBMC的可观测性，在25.06版本中我们构建了observability组件，基于openTelemetry构建了完整的可观测能力，帮助开发者更清晰地洞察系统运行状态，快速定位问题，优化系统性能。 本文将详细介绍openUBMC可观测能力的优势、价值以及未来展望，期待开发者共同参与openUBMC可观测能力的建设。 一、openUBMC可观测能力的优势 1. 统一的数据采集与管理 openUBMC通过openTelemetry实现了对指标、日志和跟踪数据的统一采集和管理。无论是硬件状态、系统性能，还是软件运行情况，所有数据都被整合上报到统一的平台中，确保数据的完整性和一致性。 标准编程接口  \nopenUBMC基于openTelemetry封装和提供了应用框架编程接口，简化了数据采集的实现。开发者可以通过简单的API调用，轻松地将遥测数据集成到BMC系统中。 标准数据格式  \n统一的遥测数据格式，包括指标（Metrics）、日志（Logs）和跟踪（Traces），这些格式确保了不同数据源之间的兼容性和一致性，便于后续的数据处理和分析。 标准传输协议  \n采用openTelemetry传输协议，包括gRPC和HTTP\u002FJSON。gRPC适用于高性能场景，提供高效的数据传输；HTTP\u002FJSON则提供了良好的兼容性，便于与现有系统和工具集成。  2. 与主流工具的无缝集成 借助openTelemetry Collector，openUBMC的可观测能力支持与Prometheus、Zipkin、Jaeger、ELK等工具无缝集成，提供强大的数据可视化和分析能力，帮助用户更好地理解和优化系统性能。 数据采集与处理  \nopenTelemetry Collector支持多种数据格式和协议，能够灵活地处理从各个数据源采集的遥测数据（指标、日志、跟踪）。 数据转换与导出  \nopenTelemetry Collector能够对采集到的数据进行转换和导出到多个目标系统，如Prometheus、Grafana、Jaeger等。这种多目标导出能力，使得BMC系统的可观测数据能够被多个工具同时利用，提升数据的利用率。  3. 强大的分布式追踪能力 借助Zipkin等平台的可视化分析能力，openUBMC能够清晰地展示完整调用路径。开发者可以轻松追踪从硬件到软件的每一个操作，快速定位性能瓶颈和故障点。  4. 高可扩展性和灵活性 openUBMC提供的应用框架编程接口，使得可观测能力具有高度的可扩展性。开发者可以根据需求定制数据采集和处理逻辑，满足不同场景下的观测需求。 二、openUBMC可观测能力的价值 数据驱动价值——通过实时监控硬件与软件运行状态，汇聚分析数据可精准识别系统瓶颈与潜在风险。定向数据采集更能快速定位异常，在研发阶段提前识别异常，有效预防故障发生，从而全面提升系统稳定性与可靠性。 故障定位时，清晰的调用链路与精准的性能数据可帮助开发者迅速定界问题范围，精准溯源根因，大幅缩短故障修复周期。以下是25.06版本研发时使用Observability组件识别出来的问题案例： FLASH日志刷屏问题  \n通过监控FLASH写入量，分析增长趋势，即可提前识别和拦截写入量过大导致的flash寿命受损问题。   硬件访问故障问题  \n选取监控硬件访问指标，并过滤硬件访问错误，通过观察硬件访问错误增长趋势，即可快速锁定故障硬件。   CSR配置不合理问题  \n同样通过监控硬件访问指标，通过数据识别CSR中器件访问不合理\u002F错误的配置，从而优化整体硬件访问周期、提升整体BMC运行性能。   三、未来展望：携手共建openUBMC可观测能力 openUBMC的可观测能力是开放的、可扩展的，我们欢迎更多的开发者和社区伙伴加入，共同完善和优化这一能力。未来，我们计划在以下几个方向上持续发力： 增强硬件与软件的深度集成  \n深化硬件与软件的协同观测能力，提供更全面的设备管理视角。 引入AI驱动的异常检测  \n利用AI技术对观测数据进行智能分析，提前发现潜在问题。 构建开发者友好工具链  \n提供更多易用的工具和插件，降低开发者使用openUBMC可观测能力的门槛。 推动社区共建  \n通过技术分享、开源贡献等方式，与社区开发者共同完善openUBMC可观测能力。 四、总结 “洞察系统全貌，引领BMC新视界” openUBMC的可观测能力基于openTelemetry构建，不仅提升了系统的稳定性和性能，还为开发者提供了一个高效、灵活的开发和观测平台。我们相信，通过社区和开发伙伴的共同努力，openUBMC的可观测能力将变得更加完善，为更多开发者和用户提供价值。 如果你对openUBMC的可观测能力感兴趣，欢迎加入我们的社区，与我们一起探索和实践！让我们携手共建更智能、更可靠的BMC系统！ 加入我们，共建openUBMC可观测能力！ 任何想法、问题，欢迎通过社区论坛、Issue、Interface SIG例会进行交流！ Gitcode仓库： https:\u002F\u002Fgitcode.com\u002FopenUBMC\u002Fobservability 社区论坛： https:\u002F\u002Fdiscuss.openubmc.cn",[269],{"_path":278,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":279,"description":280,"date":266,"category":13,"author":281,"_type":18,"_id":285,"_source":20,"_file":286,"_stem":287,"_extension":23,"coverImage":288,"plainText":289,"authorNames":290},"\u002Fzh\u002Fblogs\u002F202508072","利用大模型AI辅助研发快速实现openUBMC的NCSI协议命令字解析","NCSI是一种用于 BMC 与网络控制器通信的协议。在openUBMC 25.06版本项目开发过程中，我面临着以下几方面的挑战：",[282],{"name":283,"description":284},"钱昱霏","进入BMC领域4个月的BMC开发者，专注于软件开发与自动化效率提升，在AI辅助研发有独特的见解。","content:zh:blogs:202508072.md","zh\u002Fblogs\u002F202508072.md","zh\u002Fblogs\u002F202508072","\u002Fcategory\u002Fblog\u002F20250807\u002Fimg07.webp","利用大模型AI辅助研发快速实现openUBMC的NCSI协议命令字解析 背景：协议命令字开发遭遇重复劳动难题 NCSI （Network Controller Sideband Interface，网络控制器边带接口） 是一种用于 BMC 与网络控制器通信的协议。在openUBMC 25.06版本项目开发过程中，我面临着以下几方面的挑战： 模块代码重复率高：  不同命令之间，除了命令字的请求响应体存在差异外，其他代码的重复度极高。 测试数据需手动编写：  需要自己手动计算二进制测试数据，过程复杂且极易出错。 文档晦涩难懂：  NCSI 协议文档仅有英文版本，阅读需耗费大量精力，且容易对部分章节产生误解。 为保证高质量交付，我将目光投向了当下热门的 AI 辅助编码能力，期望借助大模型的力量辅助完成这项开发工作。 重复模式分析：抓住“可自动化”的核心 当前 AI 辅助编码能力尚未能完全替代人工手写，盲目让 AI 独立编写代码只会适得其反。因此，首要任务是对代码结构与功能模块进行分析，识别出适合 AI 发挥作用的场景。 1. 协议文档理解和命令字提取 经过多年迭代优化，当前大模型对自然语言的理解效率极高，尤其在英文文档理解方面表现突出，因此可通过大模型提取 NCSI 命令字的请求体和响应体封装格式。  2. 编写命令处理函数 为避免大模型自由发挥，预设协议请求和响应体函数格式能更有效地引导其生成所需代码。同时，为与 openUBMC 社区编码风格保持一致，可将已有代码作为上下文传递给大模型作为参考。 对于操作日志记录等 BMC 专有的要求，也可通过模板提供给大模型，要求其在所有设置类命令字函数中添加操作日志记录。 3. 编写测试用例，保证生成代码符合协议要求 为了保证生成代码的质量，利用openUBMC社区UT框架可以快速验证生成代码是否正确。同样，测试代码也可以利用大模型生成。 由于 NCSI 通讯采用二进制格式，利用大模型对协议的理解能力，可快速推导所需测试数据，省去手动编写二进制数据的繁琐过程。 编码实战：Prompt模板实用技巧 在工具选型上，采用 GPT-4.1 与 Cursor 组合。经过多轮实践，总结出一套高效 Prompt 模板，现分享如下。 实战成果： 自动生成80+个函数与测试用例，准确率超90%，UT覆盖率达86%以上。 整体开发效率提升65%，累计节省30+人天。 代码风格与社区通用规范一致，顺利通过 SIG Committer 审核。 知识背景设置： 得益于 Cursor 强大的上下文感知机制，同一仓库内的代码文件会被自动纳入大模型的分析范围，开发者无需额外配置 Lua 语法和编码风格。不过，由于 NCSI 协议文档不属于仓库内置文件，需单独处理。 值得一提的是，Cursor 支持将完整协议文档作为知识库集成到上下文环境中。笔者已将公开的 NCSI 协议文档导入 Cursor，为后续命令字解析工作提供了坚实的理论依据。  模板编写： 将任务拆解为多步骤，通过迭代式生成与问答交互，可进一步提升代码生成准确性。 我将任务分成三步，并编写了对应的Prompt： 1.生成NCSI命令字的响应和解析函数。 2.针对生成的函数，生成对应的UT函数和测试数据。 3.优化所有新增代码。 Prompt示例1：生成新函数 请基于以下现有代码模式，为新的NCSI命令 [COMMAND_NAME] 生成相应的函数：\n参考的头文件定义：\n命令类型宏定义：参考 test-main\u002Fncsi 路径下头文件中的命令常量\n包结构定义：参考头文件中的请求\u002F响应结构体定义\n长度宏定义：参考头文件中的 *_REQ_LEN、*_RSP_LEN、*_PAD_LEN 等宏\n现有模式：\nfunction ncsi_cmd.ncsi_enable_channel(package_id, channel_id, eth_name)\n要求：\n1. 函数名为 ncsi_[COMMAND_NAME]\n2. 参数为 package_id, channel_id, eth_name\n3. 包含相同的参数验证逻辑\n4. 调用对应的模块函数\n5. 返回相同的错误码\n请生成完整的函数代码。\n  Prompt示例2: 测试用例生成 请基于以下测试模式，为 [MODULE_NAME] 模块生成完整的测试用例：\n现有测试模式：\nfunction TestNCSIBroadcastFilter:test_enable_broadcast_filter()\n要求：\n1. 为 [MODULE_NAME] 创建测试类 TestNCSI[MODULE_NAME]\n2. 包含 setUp 和 tearDown 方法\n3. 为每个公共函数生成测试用例\n4. 包含成功和失败场景测试\n5. 验证请求报文格式\n6. 包含边界条件测试\n请生成完整的测试文件。\n  Prompt示例3: 代码优化 代码优化建议\n分析 src\u002Flualib\u002Fncsi\u002Fncsi_protocol\u002F 目录下的代码，\n识别可以进一步优化的重复模式。\n\n当前已优化的模式：\n1. 使用 handle_channel_operation 通用函数\n2. 使用 ncsi_utils.create_custom_cmd_table\n3. 使用命令表模式\n\n请分析还有哪些重复代码可以进一步优化，\n并提供具体的优化方案和代码实现。\n  高效 Prompt 编写技巧总结 最后，给大家分享一些我自己总结的有效Prompt编写技巧：  总结 尽管目前无法实现 “一键生成完整代码”，但大模型在研发辅助中仍具较高实用价值。这种新型开发模式有望颠覆传统开发流程，为 BMC、固件领域带来革新性体验。 期待在 openUBMC 社区看到更多 AI 辅助编码实践，激发更多创新思路。欢迎开发者分享经验、交流见解，共同探索 AI 辅助编码的无限可能。 欢迎关注我们 社区官网： https:\u002F\u002Fwww.openubmc.cn 代码仓地址： https:\u002F\u002Fgitcode.com\u002FopenUBMC\u002Fnetwork_adapter",[283],{"_path":292,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":293,"description":294,"date":295,"category":206,"author":296,"_type":18,"_id":300,"_source":20,"_file":301,"_stem":302,"_extension":23,"coverImage":303,"plainText":304,"authorNames":305},"\u002Fzh\u002Fblogs\u002F20250726","商业实践 | openUBMC社区开发流水线使能长江计算高质量交付","在软件开发流程中，构建环节至关重要，它直接影响着开发效率与软件质量。为保证openUBMC的本地化部署并提升开发效率，长江计算提出了一套面向企业开发者的构建方案与流水线构建方案。这一套基于离线部署的方案，涵盖了基础设施配置、构建方案设计等方面，有助于深入理解openUBMC构建体系的搭建与优化。","2025\u002F07\u002F26",[297],{"name":298,"description":299},"易重辉","武汉长江计算科技有限公司BMC软件开发工程师，专注openUBMC软件开发领域，在BMC构建方面有较深入的研究与丰富的实践经验，对开发流程优化有独到见解","content:zh:blogs:20250726.md","zh\u002Fblogs\u002F20250726.md","zh\u002Fblogs\u002F20250726","\u002Fcategory\u002Fblog\u002F20250726\u002Fimg01.webp","商业实践 | openUBMC社区开发流水线使能长江计算高质量交付 一、引言 在软件开发流程中，构建环节至关重要，它直接影响着开发效率与软件质量。为保证openUBMC的本地化部署并提升开发效率，长江计算提出了一套面向企业开发者的构建方案与流水线构建方案。这一套基于离线部署的方案，涵盖了基础设施配置、构建方案设计等方面，有助于深入理解openUBMC构建体系的搭建与优化。 二、基础设施配置 （一） 基础设施与资源更新总览  如同大多数公司一致，长江计算的开发活动主要位于纯内网环境，因此如何将社区的基础设施与公司常用的基础设施兼容是拥抱社区的一大难题。基于常用场景，长江计算设计了一套技术解决方案，将openUBMC社区的相关开发资源，经过外网-非涉密内网-涉密内网的单向数据流形式，部署到基础设施。这样的网络架构旨在保障数据安全与开发环境的稳定性。 因安全性而引入的额外部署流程，需要通过自动化提升效率。因此，在长江计算的部署流程中，源码和Conan组件的跨网络传输均支持脚本化的方式自动化运行。 （二）基础设施配置简介  长江计算为 openUBMC 的本地化部署配置的基础设施具备功能完整性、易用性和安全性，为自研openUBMC商用发行版提供了坚实的技术支撑，有力地推动了BMC软件开发流程的规范化和高效化，对于其他企业开发者在构建类似的开发环境和流程方面具有一定的参考价值和借鉴意义。 三、开发者构建方案  构建Docker镜像是开发者构建和流水线构建的基础。构建Docker镜像上传到编译服务器可直接为开发者构建服务；而上传到容器镜像仓则是为流水线构建服务。 在编译服务器上，为每位开发者创建独立编译容器，这样的设计保障了每位开发者的开发环境相对独立，避免相互干扰。 开发者可以通过SSH连接到编译容器，在容器内进行开发工作。实际场景中，开发者可以在涉密台式机环境下，借助预处理好的编译容器，专注于代码编写与调试，无需过多关注环境配置等复杂问题，从而提高开发效率。 另外，长江计算的编译容器支持个人数据持久化，同时也拥有只读公共目录。这样的设计便于后期维护时升级编译环境和开发材料传递。 四、流水线构建方案 （一）流水线需求分析  代码门禁需求： 组件门禁流水线：  当组件代码合入时，触发门禁检查，包括静态代码检查、单元测试以及单元测试覆盖率计算等，只有通过这些检查，代码才能顺利合入，确保组件代码的质量。 产品门禁流水线：  产品版本因组件版本变化时，需要进行门禁检查，主要验证是否能构建出产品包，保障产品版本的完整性和可用性。 版本构建发布需求： 组件版本发布时，需构建出二进制并归档，方便后续的使用与管理。 产品转测版本发布时，要构建出 hpm 包并归档，同时触发冒烟测试，初步验证产品版本的基本功能是否正常。 （二）组件流水线设计总览  组件仓Merge合入时，会触发组件门禁流水线，此时会拉取组件代码，执行合入门禁检查，包括 静态代码检查、单元测试和组件出包校验，将检查结果反馈给开发人员。门禁检查结果将作为是否合入的标准。  当涉及组件版本发布时，需要定时或者手动触发组件构建流水线，此时会拉取组件代码，进行版本构建，将组件版本发布到 Conan 仓库，实现组件的更新与共享。 （三）产品流水线设计总览  manifest仓代码Merge合入时，会触发产品门禁流水线，拉取组件代码，执行合入门禁检查，同时进行产品出包校验，确保能生成完整的产品包，之后可触发签名请求，保障产品安全性。  当涉及产品版本发布时，需要定时或者手动触发产品构建流水线，拉取组件代码，执行版本构建，发布产品版本，并进行冒烟测试，全面验证产品性能与功能 （四）流水线在软件开发过程中的模拟运用 为说明4种流水线的作用和机制，本文使用箭头表示各种类型的流水线来模拟三个组件（A、B、C）与产品的构建与发布过程。其中蓝色向下的箭头是门禁流水线，青色向右是构建流水线；黑色边框为组件流水线，红色边框是产品流水线。  由上图过程可知：此流水线的设计能深度贴合软件工程过程。 一般多次特性合入才会发布版本：  不管是组件还是产品，历经多次门禁流水线再通过一次构建流水线来发布版本。 保证产品仓一定能正常构建出版本：  只有当组件完成构建流水线发布之后，通过修改manifest仓库并合入来触发的产品门禁流水线才能成功。反之，如果组件未经过构建，那么产品门禁流水线一定会因为缺对应组件而失败报错； 多组件依赖的产品版本更新：  涉及到多组件依赖的需求时，多个组件的版本更新可以在产品的一次合入请求中实现。 产品仓的版本发布与组件版本发布分离：  组件通过构建流水线发布版本后，并不一定要立即合入到产品仓，完全按组件和产品自身的开发节奏进行发布和版本搭配。 通过组件门禁流水线、产品门禁流水线、组件构建流水线以及产品构建流水线的协同工作，全方位保障软件开发过程的质量与效率。门禁流水线对代码合入进行严格检查，构建流水线则负责版本的构建与发布，使得软件开发能按照既定的流程和标准顺利推进。 五、场景交流 部署场景 ：企业自建 Conan 仓，需要将社区 Conan 二进制迁移到企业自己的开发环境中去。   方案一 ：通过仓库级联，将社区 Conan 仓接入到企业本地 Conan 仓库。理论上能下载到社区所有二进制，这种方法适用于实时能和社区仓库沟通的场景，操作相对简便，但可能存在网络稳定性以及权限控制等问题。  方案二 ：通过 conan download 下载，再上传到企业本地 conan 仓库。理论上也能下载到社区所有二进制。  方案三 ：通过 bingo 构建来下载，再上传到本地 Conan 仓库。这种方式只能下载某个组件、产品版本依赖的二进制，针对性较强，但无法获取社区全部二进制，不过它在处理特定依赖关系时较为实用。 总之，如果能够访问到openUBMC社区的官方Conan远端，那么选择方案一做级联；如果想做离线部署，则选择方案二；如果只是需要打包特定某个组件、产品依赖的二进制，则选择方案三。 六、总结 长江计算基于 openUBMC 的开发者构建与流水线构建实践展示了完整且系统的构建流程搭建。从基础设施的合理配置到开发者构建的便捷实现，再到流水线构建的精细化设计，以及对Conan远端本地化部署的有效应对策略，都给予了openUBMC社区开发者诸多启示。在实际开发过程中，开发者可以借鉴这些实践经验，结合自身项目特点，不断优化构建体系，提升开发效率，保障软件质量，从而在激烈的市场竞争中占据有利地位，加速软件产品的交付与迭代，更好地满足用户需求与市场变化。",[298],{"_path":307,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":308,"description":309,"date":310,"category":191,"author":311,"_type":18,"_id":313,"_source":20,"_file":314,"_stem":315,"_extension":23,"coverImage":316,"plainText":317,"authorNames":318},"\u002Fzh\u002Fblogs\u002Fsig-meeting-guide","SIG组会议指南","openUBMC 开源社区按照不同的SIG（Special Interest Group）来组织开发及版本相关工作。","2025\u002F07\u002F17",[312],{"name":34,"description":35},"content:zh:blogs:sig-meeting-guide.md","zh\u002Fblogs\u002Fsig-meeting-guide.md","zh\u002Fblogs\u002Fsig-meeting-guide","\u002Fcategory\u002Fblog\u002Fsig-meeting-guide\u002Fimg01.png","SIG组会议指南 openUBMC 开源社区按照不同的SIG（Special Interest Group）来组织开发及版本相关工作。SIG组通常会有固定例会时间，用于管理SIG组开发任务、技术方案评审、技术方案讨论等工作事务。本篇文档用于指导开发者如何参与SIG组会议、以及SIG组关键成员如何组织会议。 会议召开形式 openUBMC 社区提供线上会议功能，SIG组例会通常以线上会议方式承载。  开发者可以在社区门户网站上查看openUBMC 开发者日历，查看所有会议。  会议平台通常使用welink、腾讯会议，请提前下载安装对应的会议软件。 Etherpad openUBMC 社区使用etherpad进行会议议题登记、内容记录、纪要记录。每个SIG组都有自己的永久etherpad链接，可以通过SIG中心，或者会议通知内获取。 通过社区帐号登陆后即可开始编辑，添加议题。 SIG组的Maintainer、Committer有义务维护SIG组Etherpad的内容、格式。Etherpad的管理格式可参考社区Etherpad模板： Etherpad 会议订阅 当会议创建时，会通过社区SIG公共邮箱进行通知。如需订阅会议，需要在社区邮箱管理页面中进行订阅。  选择对应SIG组的邮件订阅，输入自己的邮箱并点击Subscribe。  在邮箱中点击链接确认订阅，并确认即可。 会议管理 SIG组maintainer、Committer均有权限利用社区基础设施预订社区会议。  进入个人中心，点击创建会议。  选择对应的SIG组，填入会议信息即可。  创建成功后，即可在社区上查看会议信息。 高效会议 为了高效地组织SIG例会，本文列举一些常见的举措，供社区开发者参考。 会前准备：明确目标与议程 议题分类 议题申报者需明确议题的类别。不同类别的议题的开展方式是不同的，正确的分类可以有效地帮助会议组织者合理规划时间。 如果是  决策类议题 ，建议与会前提前通过issue、社区论坛等方式收集SIG组关键角色反馈，同时明确决策内容，避免会上漫议。 如果是  讨论类议题 ，提前分享背景资料（如设计文档、Issue 链接），并明确需要讨论目标，充分收集SIG关键角色的意见。 提前发布议程 SIG组例会固定周期，固定时间，方便SIG组成员提前规划时间。 选择合适的会议时间。 会议通知提前一周发出，基于与会人充分的时间进行安排。 提前一天确认会议议题，避免会上开展无效议题讨论。 鼓励社区成员  提前在 Issue\u002FPR\u002F社区论坛 中讨论 ，避免会议变成“读文档大会”。 会议执行：高效协作与记录 严格遵循议程 & 控制时间 指定  主持人（Moderator）  控制节奏，避免跑题。 采用  “时间盒（Timeboxing）”  方法，每项议题限时讨论。 鼓励异步沟通，减少同步会议依赖 能通过  Issues\u002FPRs、邮件列表、社区论坛  解决的问题，不占用会议时间。 确保会议核心时间用于  关键决策  或  复杂问题的实时讨论 。 确保透明 & 包容性 SIG组所有讨论均对外公开，允许任何开发者发表意见。 复杂问题讨论过程记录在etherpad中，允许未与会开发者也能大致理解讨论过程。 决策机制清晰 采用  Lazy Consensus（懒惰共识） ：如果没有强烈反对，提案默认通过。 重大决策采用  投票机制 （如 社区论坛、邮件投票等），并在会议纪要中记录。 关键原则 ✅  开放透明  – 所有讨论和决策公开可查，避免私下决策。  \n✅  包容协作  – 鼓励新人参与，避免核心成员垄断话语权。  \n✅  结果导向  – 每次会议必须有明确产出（决策、任务、文档）。  \n✅  尊重时间  – 准时开始\u002F结束，避免无效讨论。",[34],{"_path":320,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":321,"description":322,"date":323,"sig":204,"archives":324,"category":206,"author":325,"_type":18,"_id":329,"_source":20,"_file":330,"_stem":331,"_extension":23,"coverImage":332,"plainText":333,"authorNames":334},"\u002Fzh\u002Fblogs\u002FMigration_system","Hi3093开发板上手教学","当前openUBMC已支持Qemu仿真调试能力，但针对硬件相关调试，仍缺乏高效的调试手段。笔者在尝试多种开发板后，总结了一套基于的openUBMC启动心得，供社区开发者学习和参考。","2025\u002F07\u002F12","2025-07",[326],{"name":327,"description":328},"范信鑫","openUBMC社区开发者范信鑫。专注于为openUBMC开发者提供舒适又快捷的上手流程，同时又致力于openUBMC的社区和新特性开发。","content:zh:blogs:Migration_system.md","zh\u002Fblogs\u002FMigration_system.md","zh\u002Fblogs\u002FMigration_system","\u002Fcategory\u002Fblog\u002FMigration_system\u002Fimage35.png","Hi3093开发板上手教学环境搭建 前言 当前openUBMC已支持Qemu仿真调试能力，但针对硬件相关调试，仍缺乏高效的调试手段。笔者在尝试多种开发板后，总结了一套基于 米尔电子MYC-LHi3093开发板 的openUBMC启动心得，供社区开发者学习和参考。 物料准备 Hi3093核心板 核心板电源适配器 网线 typeC-USB线 8GB以上的SD卡（用于必要时恢复openeuler环境） 环境准备 鉴于 Hi3093 核心板出厂默认搭载 openEuler 操作系统，须将其替换为 openUBMC RTOS。为此，需依次完成以下前置工作： 定制并构建 openUBMC RTOS 镜像； 规划并格式化核心板存储分区，确保与 openUBMC 分区表兼容。 openUBMC RTOS 镜像制作 openUBMC 开发环境搭建请严格遵循官方文档   Ubuntu 开发环境搭建 | openUBMC 。 为便于后续与核心板进行网络通信， 建议采用虚拟机方式部署 Ubuntu 环境 ，并在虚拟机内完成全部初始化步骤。本章节将采用VirtualBox进行openUBMC开发环境搭建。 在VirtualBox，你需要遵守以下的步骤，完成环境搭建和openUBMC镜像制作： 1、Ubuntu24.04 iso下载，并在VirtualBox中安装，建议预留50GB的存储空间。 ⭐ 如果不想自己出包的话，可以直接下载 Hi3093预制镜像 ，下载后可直接跳过构建过程，将对应文件放置在下述的位置中。 2506_gx.zip 里面存放了烧录时所需的所有文件， *.hpm 为配套的固化开发板环境的 hpm 包。 ❗ 如果是自己出包，且采用的是openUBMC 25.03版本，请确保在 build\u002Fsubsys\u002Frc\u002Fsecurity.yml 中iam的版本 >=1.0.1  2、根据 ** Ubuntu 开发环境搭建 | openUBMC **进行openUBMC环境搭建。 3、安装openUBMC调试工具--  busybox , 并集成到manifest中。 4、在manifest目录下，执行 bingo build 完成openUBMC镜像制作。 最终在temp\u002Fbuild_openUBMC_debug_dev\u002Foutput可以找到对应的镜像文件 rootfs_BMC.img 。  同时还需要在 temp 目录下取出 initrd_boot.cpio.gz 还有 uImage 文件。其中 initrd_boot.cpio.gz 是Linux系统的初始RAM磁盘镜像， uImage 为Linux kernel内核镜像。  镜像烧录和分区表配置 核心板连接 现在我们需要通过串口等方式连接Hi3093核心板。核心板连接方式如下图所示：  ❗ 连接过程中，需要严格按照图中的端口进行连接，否则后续的操作必定会失败。 核心板启动 核心板的启动采用EMMC启动模式，将SW2的开关如此设置。  ⭐如果看不清晰，可以参考核心板提供的手册，里面详细介绍了如何通过EMMC启动。 核心板串口连接 通过typeC-USB线连接核心板后，可以通过串口连接软件进入核心板的串口界面。这里使用Xshell来建立连接：  选择SERIAL连接方式，并进入到串口页面。然后进行端口号配置。这里需要自己测试一下，看一下是使用COM多少。一般能用的话，会显示Connected的情况。  核心板启动与登录 Xshell连接到串口后，打开核心板的开关。可以在Xshell的串口中看到打印显示：  串口刷屏结束后，会提示登录，如果登录串口是黑屏的话，尝试敲几次回车，看看能不能出现登录界面。首次登录的话，账号是root，密码需要手动设置（会有提示）  SD卡准备 后续的操作会导致开发板的启动镜像发生改变，但同时SPI又不具备ssh连接的情况。所以需要提前准备一张sd卡进行镜像备份。步骤如下： fdisk -l  查看可用分区，找到sd卡分区，然后进行初始化（初始化命令可在网上查询，例如mkfs.vfat都可以，只要开发板能识别就行） 使用 mount 将sd卡分区挂在到某个目录 通过ssh上传米尔提供的SPI烧录文件，并拷贝到sd卡的分区中。 后续spi恢复openeuler环境时，只需重新挂载sd卡即可。 分区表配置 为确保 openUBMC 启动后能够正确访问 eMMC 的 user 区域，需预先完成手动分区并固化分区表。最终的分区配置如下所示：  执行动作如下所示： fdisk  \u002Fdev\u002Fmmcblk0\n \n \u002Fdev\u002Fmmcblk0p1  :  先执行n，然后选择p创建主分区，StartLBA输入16，EndLBA输入2097167\n \n \u002Fdev\u002Fmmcblk0p2  :  先执行n，然后选择p创建主分区，StartLBA输入2097168，EndLBA输入9269839  ,  然后执行t，输入c\n \n \u002Fdev\u002Fmmcblk0p3  :  先执行n，然后选择e创建扩展分区，StartLBA输入9269840，EndLBA输入12648447  \n \n \u002Fdev\u002Fmmcblk0p5  :  先执行n，然后选择l创建逻辑分区，StartLBA输入9269856，EndLBA输入9899001,  然后执行t，输入c\n \n \u002Fdev\u002Fmmcblk0p6  :  先执行n，然后选择l创建逻辑分区，StartLBA输入9899018，EndLBA输入11367023\n \n \u002Fdev\u002Fmmcblk0p7  :  先执行n，然后选择l创建逻辑分区，StartLBA输入11367040，EndLBA输入11891327\n \n \u002Fdev\u002Fmmcblk0p8  :  先执行n，然后选择l创建逻辑分区，StartLBA输入12615680，EndLBA输入12648447\n \n \u002Fdev\u002Fmmcblk0p9  :  先执行n，然后选择l创建逻辑分区，StartLBA输入11891344，EndLBA输入12615663\n \n 然后执行w保存所有的配置。\n 分区完成之后，需要进行各个分区的格式化。 对于Win95 FAT32的分区需要使用mkfs.vfat来格式化，例如mkfs.vfat \u002Fdev\u002Fmmcblk0p2 其他分区需要使用mkfs.ext4来格式化，例如mkfs.ext4 \u002Fdev\u002Fmmcblk0p1 镜像烧录 核心板网络配置 为了能够将相关的镜像文件烧录到核心板中，需要使用sftp等文件传输方式上传镜像文件到核心板中。首先在核心板中配置网络，执行 ifconfig eth2 up 192.168.1.123  Windows网络配置与镜像包上传 打开windows的网络连接界面。选择以太网（这里需要自己确定是哪一个以太网，可以通过插拔网线的方式确定）  配置以太网的ip地址，使其与核心板在同一个网段。   配置之后，在windows侧测试网络连接：  出现如上的连接则表示成功。之后就能够通过sftp的方式将镜像文件上传到核心板的 \u002Ftmp 目录中。这里可以用Xshell的sftp，也可以用winscp的传输。这里以winscp工具为例：  连接成功之后，上传MYD-LHI3093-V2\\SoftwareFiles\\02-Images中的这四个文件。⭐这些文件来自于米尔电子提供的核心板资料。同时上传制作的openUBMC镜像包 rootfs_BMC.img 到 \u002Ftmp 目录中，并且重命名为 Hi3093_ext4fs.img 。   镜像包烧录 Hi3093提供了升级脚本，只需要在核心板串口按照如下的步骤执行升级即可完成升级。 qemu-aarch64  ~  # cd \u002Ftmp\u002F\n qemu-aarch64  \u002Ftmp  # ls\n Hi3093_ext4fs.img       hi3093_upgrade.sh   l1fw_rsa_4096.bin\n Hi3093_ext4fs_cms.bin   l0fw_rsa_4096.bin   u-boot_rsa_4096.bin\n qemu-aarch64  \u002Ftmp  # \u002Fhi3093_upgrade.sh 4096\n \u002Fdev\u002Fmmcblk0gp0\n \u002Fdev\u002Fmmcblk0gp2\n \u002Fdev\u002Fmmcblk0gp1\n update  temp  L0FW...\n 70+1  records  in\n 70+1  records  out\n 72088  bytes  (72  kB,  70  KiB ) copied, 0.0156561 s, 4.6 MB\u002Fs\n update  temp  L1FW...\n 178+1  records  in\n 178+1  records  out\n 182876  bytes  (183  kB,  179  KiB ) copied, 0.0365372 s, 5.0 MB\u002Fs\n update  temp  u-boot...\n 504+1  records  in\n 504+1  records  out\n 516616  bytes  (517  kB,  505  KiB ) copied, 0.111703 s, 4.6 MB\u002Fs\n update  temp  rootfs_hdr...\n 36+0  records  in\n 36+0  records  out\n 36864  bytes  (37  kB,  36  KiB ) copied, 0.00683788 s, 5.4 MB\u002Fs\n update  temp  rootfs...\n 376+1  records  in\n 376+1  records  out\n 394268672  bytes  (394  MB,  376  MiB ) copied, 2.40696 s, 164 MB\u002Fs\n emmc  update  success,  please  reboot  your  board...\n 出现上述的 emmc update success, please reboot your board...  表示烧录成功，但在执行重启之前，通过ssh把当前核心板上的\u002Fboot\u002Fhi1711_asci.dtb文件下载到windows中作为备份。 执行 reboot 命令，进行重启。注意重启并不代表完全升级openUBMC镜像成功，我们还需要修改Uboot配置，来加载openUBMC的 initrd_boot.cpio.gz 还有 uImage 。 Uboot配置修改 因为我们在只修改了img文件，还没有修改Linux kernel的uImage文件，所以需要通过tftp的方式进行替换。重启后，一直敲回车键，进入Uboot配置界面：  配置之前，需要配置一下核心板的Uboot能够访问到Ubuntu开发服务器的tftp。首先在Ubuntu中安装tftpd sudo  apt  install  tftpd-hpa\n 安装之后把manifest准备阶段的 initrd_boot.cpio.gz 和 uImage 还有从核心板上下载下来的 dtb 文件（重命名为hi3093.dtb）放置到\u002Fvar\u002Flib\u002Ftftproot中。 然后Virtual Box Ubuntu中还需要进行网络配置。更多细节可参考： virtualbox网络配置实现PC、虚拟机、开发板互ping 打开virtualbox的网络管理器，按照如下的指示进行配置。    完成上述配置之后，在windows ping一下，测试是否能够访问Ubuntu24.04所在的网络。  但此时还无法通过Uboot去ping Ubuntu，所以需要建立网桥。 在windows网络连接配置页面，选中虚拟网卡和与核心板连接的以太网，右键打开选中 桥接 。  ⭐ 完成上述配置后，在Uboot中配置核心板的ip和网关 setenv  ipaddr  192.168.1.123\n setenv  netmask  255.255.255.0\n setenv  gateway  192.168.1.1\n setenv  serverip  192.168.1.111\n 上述设置之后，需要ping 192.168.1.111确定一下，如果没法ping通，需要确定网络连接状态。排查方法可以看 virtualbox网络配置实现PC、虚拟机、开发板互ping  确认通信已建立后，在Uboot中通过tftp协议下载 uImage 和 initrd_boot.cpio.gz 。 setenv  tftp_dtb  \"tftp ${ dtb_load_addr } hi3093.dtb\"\n run  tftp_dtb  # 下载dtb文件\n run  tftp_network_boot  # 执行之后，需要确定已下载\n run  run_linux  # 执行此步后，会自动启动系统\n  等待openUBMC RTOS系统启动，即可看到openUBMC的串口打印。  openUBMC环境配置 因为openUBMC的默认IP为 192.168.2.100，网关也是192.168.2.100。和我们之前的配置不在同一个网段，所以需要重新修改以太网的配置才能够登录openUBMC。在之前配置的网桥中取消核心板以太网的配置。  然后右键以太网，手动配置器ip地址。  配置之后能够通过telnet连接：  执行source \u002Fetc\u002Fprofile可开启busctl等命令。 openUBMC密码生成 初始的BMC是没有密码的，可以通过cat \u002Fetc\u002Fshadow来查看是否有很长的一段加密信息，没有的话就需要手动去添加密码： # 激活busctl\n source  \u002Fetc\u002Fprofile\n \n # 修改密码\n busctl  --user  call  bmc.kepler.account  \u002Fbmc\u002Fkepler\u002FAccountService\u002FAccounts\u002F2  bmc.kepler.AccountService.ManagerAccount  ChangePwd  a{ss}\n ay  3  Interface  Web  UserName  Administrator  ClientAddr  127.0.0.1  10  65  100  109  105  110  64  57  48  48  48\n 修改之后的密码就是 Admin@9000，当然也可以修改为自定义的密码， 65 100 109 105 110 64 57 48 48 48 对应 Admin@9000 的ASCII码，用户也能够根据此种方式自定义密码。 但此时还无法通过ssh登录。这是因为openssh缺少文件。但可以通过ipmi工具来测试密码是否正确： >  . \\i pmitool.exe -H 192.168.2.100 -I lanplus -p 623 -U Administrator -P Admin@9000 -C 17 mc info\n Device  ID                  :  1\n Device  Revision            :  1\n Firmware  Revision          :  25.00\n IPMI  Version               :  2.0\n Manufacturer  ID            :  2011\n Manufacturer  Name          :  Unknown  (0x7DB)\n Product  ID                 :  0  (0x0000)\n Product  Name               :  Unknown  (0x0)\n Device  Available           :  yes\n Provides  Device  SDRs       :  yes\n Additional  Device  Support  :\n     Sensor  Device\n     SDR  Repository  Device\n     SEL  Device\n     FRU  Inventory  Device\n     IPMB  Event  Generator\n     Chassis  Device\n Aux  Firmware  Rev  Info      :\n     0x00\n     0x00\n     0x00\n     0x01\n 显示mc info正常返回，表示账号和密码成功配置了 openUBMC ssh登录 在使用ssh连接过程中，出现了输入正确密码一直报错的问题。该问题是由于openssh中pam认证失败导致。 # 检查pam.d中ssh的依赖情况\n ls  -l  \u002Fdata\u002Ftrust\u002Fpam_faillock  \\\n       \u002Flib * \u002Fsecurity\u002Fpam_bmc_login.so  \\\n       \u002Flib * \u002Fsecurity\u002Fpam_selinux.so\n       \n # 检查是否存在common-auth common-account common-passwd\n # 一般都是存在的，不存在的是\u002Fdata\u002Ftrust\u002Fpam_faillock,需要手动创建一下， 如果存在就不用去创建了\n touch  \u002Fdata\u002Ftrust\u002Fpam_faillock\n chmod  644  \u002Fdata\u002Ftrust\u002Fpam_faillock\n BMC 网页登录 初始环境中，没有BMC的证书，可以通过openSSL进行证书的生成。有了此证书后，才能够完成Nginx的启动。 证书准备文件有： SSL.p12 通过sftp等方式，将 SSL.p12 上传到openUBMC的 \u002Ftmp 目录下，然后导入证书: date  -s  \"2025-06-09\"  &&  busctl  --user  call  bmc.kepler.certificate  \u002Fbmc\u002Fkepler\u002FCertificateService  bmc.kepler.CertificateService  ImportCertWithKey  a{ss}isss  3  Interface  Busctl  UserName  Adminitrator  ClientAddr  127.0.0.1  1  URI  \u002Ftmp\u002FSSL.p12  \"\"\n 💥 上述命令描述的 2025-06-09 需要设置为生成证书时间之后。否则会有导入错误。导入成功或Nginx和Web都能够正常使用了。即可通过网页登录openUBMC了。 openUBMC系统固化 （最后一步） 在Uboot中，我们配置了tftp下载内核文件等，但此过程无法固化，为此可以通过在网页中升级一次 hpm 包，升级过程中，会把内核文件等烧录到emmc中，之后重启核心板就会依旧是openUBMC系统。同时也会具备主备分区等能力。 QA 如何回滚到openEuler系统？ 1、进入SPI界面，进行环境烧录。参考HI3093提供的软件开发手册\n  2、下载提供的Hi3093的原始启动文件压缩包 ->  https:\u002F\u002Fgitcode.com\u002Ffxx551\u002FHi3093\u002Freleases\u002Fv1.2  \n3、解压压缩包后，将内容上传至ubuntu虚拟机中。并更新到\u002Fvar\u002Flib\u002Ftftpboot 注意这里的hi1711_asic.dtb文件名要变更为 hi3093.dtb  4、进入emmc的Uboot界面，并配置网络\n设置网络，使其能ping通虚拟机\n并配置tftp_network_boot setenv  tftp_network_boot  'tftp ${dtb_load_addr} hi3093.dtb;     \n ${kernel_load_addr} uImage;     \n tftp \n tftp ${initrd_load_addr} initrd_boot.cpio.gz;     \n bootm ${kernel_load_addr} ${initrd_load_addr} : ${initrd_size} ${dtb_load_addr}'\n  = >  ping  ${serverip}\n  Using  hi309x_gmac  device\n  ## Warning: gatewayip needed but not set\n  host  192.168.1.111  is  alive\n  = >  run  tftp_network_boot\n  = >  run  run_linux\n   EMMC 分区概念说明  烧录openUBMC之后，串口卡住 通常openUBMC启动后串口会打印到os侧，如果需要串口打印到串口界面，需要执行 ipmcset -d serialdir -v 1 。该命令可在ssh输入，或在telnet 执行 source \u002Fetc\u002Fprofile 之后执行。 html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[327],{"_path":336,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":337,"description":338,"date":339,"category":13,"author":340,"_type":18,"_id":342,"_source":20,"_file":343,"_stem":344,"_extension":23,"coverImage":345,"plainText":346,"authorNames":347},"\u002Fzh\u002Fblogs\u002F2506-bmc-studio","openUBMC新体验！BMC Studio 让开发更智能、更高效","25.06版本BMC Studio大更新，助您玩转openUBMC！立即体验，开启智能开发之旅！","2025\u002F07\u002F09",[341],{"name":34,"description":35},"content:zh:blogs:2506-bmc-studio.md","zh\u002Fblogs\u002F2506-bmc-studio.md","zh\u002Fblogs\u002F2506-bmc-studio","\u002Fcategory\u002Fblog\u002F2506-bmc-studio.webp","openUBMC新体验！BMC Studio 让开发更智能、更高效 25.06版本BMC Studio大更新，助您玩转openUBMC！立即体验，开启智能开发之旅！  BMC Studio下载地址： https:\u002F\u002Fwww.openubmc.cn\u002Fzh\u002Fmarketplace\u002FBMC%20Studio\u002F25.06 BMC Studio安装指南： https:\u002F\u002Fwww.openubmc.cn\u002Fdocs\u002Fzh\u002Fdevelopment\u002Fquick_start\u002Fprepare_environment\u002Fbmc_studio_installation.html BMC Studio用户指南： https:\u002F\u002Fwww.openubmc.cn\u002Fdocs\u002Fzh\u002Fdevelopment\u002Ftool_guide\u002Fbmc_studio_tool.html",[34],{"_path":349,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":350,"description":351,"date":352,"archives":353,"category":13,"author":354,"_type":18,"_id":358,"_source":20,"_file":359,"_stem":360,"_extension":23,"coverImage":361,"plainText":362,"authorNames":363},"\u002Fzh\u002Fblogs\u002Fsecure-and-reliable-application","基于openUBMC的可信安全应用","在当前复杂多变的网络安全形势下，固件安全威胁日益加剧，成为攻击者的重要目标。固件作为计算系统的基础层，其安全性直接影响到整个系统的安全韧性。在新的安全形势下，固件成为了攻击者的关键目标。由于固件位于计算系统的底层，拥有较高的权限，一旦被攻击，上层系统将无法有效防护。因此，提升固件的安全韧性显得尤为重要。","2025\u002F06\u002F25","2025-06",[355],{"name":356,"description":357},"李小川","华为技术有限公司计算硬件安全技术专家","content:zh:blogs:secure-and-reliable-application.md","zh\u002Fblogs\u002Fsecure-and-reliable-application.md","zh\u002Fblogs\u002Fsecure-and-reliable-application","\u002Fcategory\u002Fblog\u002Fsecure-and-reliable-application\u002Fimg0.webp","基于openUBMC的可信安全应用 本篇文章来源于第二届固件技术峰会的议题《基于openUBMC的可信安全应用》。\n 固件安全威胁的严峻性 在当前复杂多变的网络安全形势下，固件安全威胁日益加剧，成为攻击者的重要目标。固件作为计算系统的基础层，其安全性直接影响到整个系统的安全韧性。在新的安全形势下，固件成为了攻击者的关键目标。由于固件位于计算系统的底层，拥有较高的权限，一旦被攻击，上层系统将无法有效防护。因此，提升固件的安全韧性显得尤为重要。 计算系统具有以下特点： 权限约束：下层可以约束上层的权限，而上层无法约束下层的权限。这意味着固件层的攻击可以对上层系统造成严重影响。 攻击防护：下层对上层发起的攻击，上层无法有效防护。一旦固件被攻破，整个系统将面临巨大的安全风险。 权限层级：越往下层，权限越高，硬件权限最高。固件作为接近硬件的一层，其安全防护尤为重要。  根据BMC CVE漏洞统计表，从2012年到2021年，BMC固件的漏洞数量呈现逐年上升的趋势。其中，2021年漏洞数量达到39个，远高于往年。这些漏洞主要涉及执行代码（Exec Code）、远程攻击（Remote）等高危类型。例如，CVE-2013-1945、CVE-2012-2959等漏洞允许远程攻击者执行任意代码，对系统安全构成严重威胁。 随着AI基础设施的极速发展，内外置硬件可信根形态各异，各设备的安全能力参差不齐，协同困难，数据中心整体的安全性面临挑战，TPM、SGX、ARM Trust Zone、TPCM，业界有各种形态不一的硬件可信根，或内嵌于SoC中，或外置于单板之上。 因此，内外置硬件可信根成为固件信任的锚点。可信计算化体系中，信任链传递的源头，就是硬件可信根。一般主要用于保障平台的完整性。硬件可信根由密码学引擎、硬件真随机数、一次性烧写介质、安全SRAM等硬件和对应的安全固件软件构成。  一些常见的硬件可信根包括：TPM\u002FTCM中的RTM、RTS、RTR、安全启动中的BSBC启动代码和EFUSE中烧写的根公钥hash；可信计算3.0中的TPCM；微软的Caliptra开源可信根，含平台信任根(pROT)； 基于内置或外置硬件可信根，采用信任链技术实现系统防篡改，防供应连替换，防窜货等安全能力。云厂商基于可信根芯片构筑安全启动、硬件身份保护，基于内外置可信根实现数据中心基础设施智能部件可信度量和身份认证。国产CPU厂家普遍采用内置TPCM方案，实现服务器平台的可信计算3.0启动度量控制和运行度量控制。 openUBMC的可信安全应用实践  openUBMC基于Hi171x系列芯片的可信安全应用实践，已在计算服务器、存储设备、电信计算平台及边缘计算等多类场景中得到充分验证，为软硬件安全防护提供完整解决方案。  基于硬件可信根，分层可信链传递，建立系统级的全栈高安防护。openUBMC围绕固件韧性、可信启动、安全升级、安全启动、安全运行、数据安全等维度构建可信计算、机密计算能力。 通过组件化架构，将BMC功能合理地分配到不同的组件中，通过规范化交互接口、数据存储、权限管理等方式，最大化地看护组件间的交互。 同时，根据数据自身业务属性，设置不同的安全等级，利用数据分区能力保护不同数据的安全性，尽可能的减少数据泄露扩散风险。 openUBMC引入沙箱功能，根据组件的业务，设置不同的权限风险和最小韧性系统范围，建立多层防护体系。  围绕不同的可信分区，openUBMC制定了不同的数据恢复流程、接口权限降级流程，实现芯片级可信根启动安全，固件韧性保障篡改固件自动恢复。 openUBMC同样提供完整的签名身份认证能力，提供端到端的固件包签名、校验解密、秘钥管理等能力，最大化地保障固件完整性，保护防篡改。  openUBMC社区同时建立了透明的研发流程，从需求接纳管理，需求实现设计，代码编写，社区自动化构建，到社区正式发布。同时围绕社区源码，以及社区依赖的三方库，openUBMC建立了完整的漏洞管理体系，流程化地管理软件漏洞和风险，最大化保障软件安全。 总结  外置可信根标准化（硬件设计+接口）+内置可信根开源成为未来硬件可信根的趋势。异构可信计算体系下，内存池化增大了暴露面，传统的TPM可信启动技术、DICE的环境保护技术、可信根互联技术将深度融合统一，成为智能部件的必备基础安全能力。 信任链的传递、安全签名、代码交叉审计是国内安全生态建设中最缺失的；安全技术的复杂性导致推广落地缓慢，微软的徽标认证和OCP S.A.F.E固件签名体系值得国内固件安全生态借鉴。如何利用openUBMC社区，联合产业上下游共同打造国内的固件安全生态体系，是社区接下来的重点工作之一。 在此，openUBMC社区诚邀业界同行，共同建设固件领域新生态，打造国内一流的固件安全生态体系。 html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[356],{"_path":365,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":366,"description":367,"date":368,"sig":204,"archives":369,"category":191,"author":370,"_type":18,"_id":372,"_source":20,"_file":373,"_stem":374,"_extension":23,"coverImage":375,"plainText":376,"authorNames":377},"\u002Fzh\u002Fblogs\u002Fstart_openUBMC","从零开始，玩转openUBMC","openUBMC是一款架构领先、开发友好、开放标准的算力设备开源管理软件。在本博客中，我们将从零开始带你玩转openUBMC。","2025\u002F05\u002F10","2025-05",[371],{"name":327,"description":328},"content:zh:blogs:start_openUBMC.md","zh\u002Fblogs\u002Fstart_openUBMC.md","zh\u002Fblogs\u002Fstart_openUBMC","\u002Fcategory\u002Fblog\u002Fstart_openUBMC\u002Fimage0.png","从零开始，玩转openUBMC 前言 openUBMC是一款架构领先、开发友好、开放标准的算力设备开源管理软件。在本博客中，我们将从零开始带你玩转openUBMC。 环境准备 openUBMC的官网中介绍了多种环境准备的方法，本博客将会介绍自由度最高的Ubuntu安装方式。如果想要体验更快捷的安装方法，可以使用Docker来安装，参考 Docker开发环境搭建 | openUBMC 。 Ubuntu 准备openUBMC环境 1、配置gitcode账户 进入 项目首页 - manifest:manifest - GitCode ，然后点击 clone 按钮  会弹出如何配置gitcode账户和clone仓库的方法。  根据gitcode提供的配置，在Ubuntu命令行中执行 git config 命令  除此之外，还需要配置ssh公钥，根据如下的步骤2和步骤3提示完成即可  根据openUBMC中的推荐，使用ssh替换https下载，此步将跳过https的Token的复杂配置。 git  config  --global  url.\"git@gitcode.com:\".insteadof  \"https:\u002F\u002Fgitcode.com\u002F\"\n 2、下载manifest仓库 分别执行如下命令： mkdir  workspace\n cd  workspace\n git  clone  git@gitcode.com:openUBMC\u002Fmanifest.git\n  进入到manifest仓库中，执行其环境初始化命令。在执行之前需要先从 openUBMC社区软件应用中心 中下载 bmc_sdk.zip ，并放在manifest代码目录下。 执行 cd  manifest\n python3  init.py  -path  .\u002Fbmc_sdk.zip\n  在 init.py 中, 完成了如下的环境配置： 环境代理配置 sudo权限获取 Ubuntu 镜像配置 （使用华为镜像源） 安装Ubuntu软件包（例如 python3、gcc、dbus等等） python镜像源配置（使用华为镜像源） 安装openUBMC开发者套件（RTOS编译工具、SDK、lua-format等） 安装node和npm openUBMC构建工具bingo安装 conan远程仓库配置 Qemu开发依赖安装 Qemu运行时依赖安装 最终执行完成的标志为如下的输出：  至此已经完成了下载manifest和使用manifest配置openUBMC的开发环境。 3. 配置conan用户 在openUBMC的文档中提到要使用openUBMC社区用户名来完成配置。  因此在命令行中执行该配置，配置成功后会有如下的打印。  当然我们也能够通过conan的一些搜索命令来查看是否配置正确。  NOTE：如果你不知道openUBMC社区用户名如何获取，请登录 openUBMC官网 ,并查看红色框内的内容，此为你的openUBMC社区用户名。  开始你的openUBMC之旅 openUBMC固件升级包构建 在上一小节中，我们已经完成了openUBMC的开发环境的搭建。可以使用该环境开始开发openUBMC。manifest仓库除了能够一键初始化环境外，还能够自动化地完成openUBMC的整包构建。利用openUBMC提供的 bingo 工具，能够完成此项。 进入到manifest目录中，并执行如下命令： bingo  build\n  出现如上的输出及表示openUBMC的整包构建开始了。构建等待时间预计等待4~6分钟（Intel(R) Xeon(R) Gold 6161 CPU @ 2.20GHz 云服务），即可在 manifest\u002Foutput\u002Frootfs_openUBMC.hpm 找到用于openUBMC固件升级的 hpm 包。该包能够让BMC服务器完成固件升级。 openUBMC仿真启动 通常硬件调试资源比较紧缺，一次次地在硬件服务器上进行调试会变成非常的困难。openUBMC也提供了仿真启动方式，采用Qemu进行模拟openUBMC运行环境。在manifest中中执行如下命令，可构建出Qemu仿真启动的固件包。 bingo  build  -sc  qemu\n  当提示 任务 personal执行成功 后，表示固件包构建完成。同时能够在 manifest\u002Foutput\u002Fpacket\u002Finner 目录下找到 openUBMC_25.00.00.01_qemu.cpio.gz ,此为openUBMC仿真所需的固件包，其格式与hpm包有些差异，但内含的文件系统是一致的。  执行如下的命令，一键启动openUBMC的仿真环境： python3  build\u002Fworks\u002Fpacket\u002Fqemu_shells\u002Fvemake_1711.py\n  等待5~10分钟（视启动宿主机性能而定），可以通过ssh\u002Fweb\u002Fredfish\u002Fipmi等方法与openUBMC进行交互。 openUBMC使用 当我们启动了openUBMC之后，可以通过web界面访问openUBMC。 输入用户名密码登录后，可以看到openUBMC的主界面，更多的内容可以尝试在该界面中点击。  除此之外，还可以通过ssh连接进入到openUBMC的CLI界面。通过在命令行中执行： ssh  Administrator@ \u003C your  i p > :10022\n 并输入密码即可进入。  参考资料 探索openUBMC | openUBMC html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[327],{"_path":379,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":380,"description":381,"date":382,"category":191,"author":383,"_type":18,"_id":385,"_source":20,"_file":386,"_stem":387,"_extension":23,"coverImage":388,"plainText":389,"authorNames":390},"\u002Fzh\u002Fblogs\u002Fcla","《企业签加入 openUBMC 社区：CLA签署全流程指南》","CLA 是 Contributor License Agreement 的缩写，一般翻译为贡献者许可协议。","2025\u002F03\u002F30",[384],{"name":34,"description":35},"content:zh:blogs:cla.md","zh\u002Fblogs\u002Fcla.md","zh\u002Fblogs\u002Fcla","\u002Fcategory\u002Fblog\u002Fcla\u002Fimages\u002Fcla-zh-1.png","企业签署 CLA ，正式加入 openUBMC 社区 1. 企业加入 openUBMC 社区为什么要签署 CLA ？ CLA 是 Contributor License Agreement 的缩写，一般翻译为贡献者许可协议。开发者向开源项目贡献的时候通常被要求需要签署 CLA 协议，声明对贡献内容拥有所有权（或开发者得到了正确的授权进行贡献），贡献内容在项目的 License 下进行再次分发，同时保留 Copyright ；如果贡献的内容包括了专利，开放这些专利给项目使用。 2. 企业签署 openUBMC 社区 CLA 的流程 2.1 openUBMC 社区 CLA 签署地址 [ https:\u002F\u002Fclasign.osinfra.cn\u002Fsign\u002Fgitee_openubmc-1732941016829438030 )\n在页面点击 \"签署企业 CLA\"（英文页面为 \"Sign Corporation CLA\" ） 按钮进入签署页面 按钮进入。  2.2 企业签署人在签署页面点击 签署企业 CLA 按钮进入到签署页面填写签署表单，在填写完公司邮箱后，点击获取验证码后，公司邮箱会受到一封包含验证码的邮件，填写在表单后提交完成签署的第一步。 签署完成后，签署邮箱不可更改，请用相对稳定的邮箱来签署企业CLA。  2.3 公司邮箱会收到一封带有 PDF 附件的邮件，PDF 的内容包含了之前 2.2 步骤签署的 CLA 内容，请打印 PDF 文件并加盖公司公章。  2.4 将加盖公章以及签好名字和日期的 CLA 协议文件扫描为 PDF 文件，作为附件回复 2.2 步骤收到的邮件完成企业签署 CLA 。 2.5 在 openUBMC 开源社区的企业员工 CLA 管理系统中存在两种管理员，分别是 超级管理员和系统管理员 。openUBMC 系统的管理员收到邮件后，会对 PDF 进行核对检查。检查通过后签署企业 CLA 使用的邮箱会收到一封确认签署成功的邮件，其中包含了 超级管理员 帐号的用户名及初始密码。 超级管理员的权限是添加和删除系统管理员，系统可以创建多名系统管理员，每名系统管理员都有相同的权限管理企业员工的贡献。超级管理员和系统管理员不能是同一个账号。  如果签署遇到困难，可添加微信“openUBMC123”或者是发送邮件至 【cla@public.openUBMC.org】。 3. 企业员工 CLA 贡献管理系统使用说明 3.1 企业员工 CLA 管理系统的登录页面地址为  https:\u002F\u002Fclasign.osinfra.cn\u002Fsign\u002Fgitee_openUBMC-1611298811283968340  在此页面点击 \"企业管理员\" 按钮（英文页面为 \"Corporation Manager\" ）。  页面会跳转到包含登录用户名和密码输入表单的登录页面，输入后点登录按钮进入到管理员页面  3.2 超级管理员进入到系统后，需要创建系统管理员来进行管理。超级管理员在 CLA 系统的主要工作是创建和删除系统管理员，当系统管理员被创建后，他的邮箱将受到一封通知邮件。超级管理员和系统管理员两者之间的区别请参考  5.1 openUBMC 企业员工 CLA 管理系统的超级管理员和系统管理员的区别  3.3 系统管理员登录后会看到当前已经签署 CLA 且未激活的员工列表，根据实际情况选择激活员工向 openUBMC 社区贡献的权限或者删除员工的贡献请求。  在已经激活的员工列表界面，可以通过点击按钮将员工设为未激活的状态。  4. 企业员工贡献前需要签署员工 CLA 4.1 企业员工在该企业完成签署 CLA 后，在正式贡献前，需要签署员工 CLA ，签署地址  https:\u002F\u002Fclasign.osinfra.cn\u002Fsign\u002Fgitee_openUBMC-1611298811283968340  在页面点击 \"签署员工 CLA\" （英文页面为 \"Sign Employee CLA\"）  4.2 企业员工在签署时应使用企业邮箱签署，在填写完公司邮箱后，点击获取验证码后，公司邮箱会受到一封包含验证码的邮件，填写在表单后提交完成签署。  4.3 签署后会自动通知该企业的 CLA 贡献系统管理员，由系统管理员确定是否容许该员工是否可以进行贡献。系统管理员部分的工作参考 4.3 章节。  5. openUBMC 社区 CLA 系统相关问题 5.1 openUBMC 企业员工 CLA 管理系统的超级管理员和系统管理员的区别 在 openUBMC 开源社区的企业员工 CLA 管理系统中存在两种管理员，分别是超级管理员和系统管理员。当企业 CLA 创建完成后，签署 CLA 使用的企业邮箱会收到超级系统管理员的帐号和初始密码，请尽快登录到系统修改初始化密码。 通常签署 CLA 的是公司的管理人员或者法务人员，通常并不进行开发者贡献管理工作。可以通过创建系统管理员来进行实际的管理工作。系统可以创建多名系统管理员，每名系统管理员都有相同的权限管理企业员工的贡献。 5.2 openUBMC 社区对于 Issue 和 CVE 解决是否承诺 SLA ？ 在 openUBMC 开源社区，所有的 Issue 和 CVE 解决都是由社区贡献者完成，是开源社区的贡献者共同解决，不存在商业行为，所以也不承诺 SLA 。 5.3 openUBMC 企业 CLA 签署邮箱的使用 对于 126.com、qq.com、gmail.com 之类的通用个人邮箱是无法用于企业 CLA 的签署，但是对于个人开发者签署个人 CLA 是不受影响 5.4 是否需要法人签署企业 CLA ？ 签署企业 CLA 的人是公司的授权代表，不必须是法人代表进行签字。",[34],{"_path":392,"_dir":7,"_draft":8,"_partial":8,"_locale":9,"title":393,"description":394,"date":382,"archives":395,"category":191,"author":396,"_type":18,"_id":398,"_source":20,"_file":399,"_stem":400,"_extension":23,"plainText":401,"authorNames":402},"\u002Fzh\u002Fblogs\u002Fcontribution-guide","openUBMC博客贡献指南","注册openUBMC账号，成为社区的一员","2020-03",[397],{"name":34,"description":35},"content:zh:blogs:contribution-guide.md","zh\u002Fblogs\u002Fcontribution-guide.md","zh\u002Fblogs\u002Fcontribution-guide","openUBMC博客贡献指南 准备 注册openUBMC账号，成为社区的一员。 注册  openUBMC论坛  账号，学习和理解论坛运作规则。 博客贡献形式1：论坛精华帖子 每个月 sig-docs 组会定期审视社区论坛中浏览量、讨论量较多的经验分享帖，作为openUBMC社区博客。  月度例会时会公布本次博客清单。 为了简化后续博客格式转换，在发帖时建议参考博客文档格式进行编写。 博客贡献形式2：向sig-docs组自荐文档 sig-docs 也公开收集博客，可以通过邮件形式将博客内容、个人简介发送至  docs@public.openubmc.cn 。sig组会在1周内给与答复。 月度例会时会公布本次博客清单。 理解博客格式 openUBMC 是用 markdown 格式写博客的。 文件头需要包含如下信息： ---\n title :  'Sample Post'\n date :  '2025\u002F03\u002F30'\n tags :\n   -  Sample\n   -  ABC\n   -  cccc\n sig :  sig-xxx\n archives :  '2020-03'\n author :\n   -  name :  '《your name》'\n     title :  'title'\n     description :  'description'\n     avatar :  'avatar'\n description :  \"Just about everything you'll need to style in the theme：headings, paragraphs, blockquotes, tables, code blocks, and more.\"\n ---\n Here you can edit your blog.\n html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[34],1783589616856]