---
https://www.openubmc.cn/en/
---
# Join openUBMC Community
Open source computing device management software with advanced architecture and open standards
View More
- Docs Center
Detailed instructional documentation.
- Community Forum
Connect with fellow developers.
- Community Events
Stay updated with key events, conferences, and releases.
- App Marketplace
A download hub for software tools.
## Open-Source Computing Device Management Software for Global Developers
Simplified and Efficient Development
Bridging diverse hardware and mainstream industry standards, leveraging a micro-component architecture to enable one set of code for all scenarios, and driving differentiated customization through community collaboration
One-Click Deployment for Quick Start
3-step local build with comprehensive tools for a frictionless developer experience
AI-Assisted Programming
Seamless coding agent integration within openUBMC Studio, one-click community skill import, and embedded knowledge bases
Flexible Scalability
Support for multi-level customization—configurable, pluggable, and modular—to meet the dynamic tailoring needs of diverse computing power scenarios
Specification-Driven Development
Centering on models and specifications to clarify capabilities, streamline community collaboration, and fortify release stability
Flexible Northbound Access
Autonomous northbound access, accelerating service efficiency and empowering AI-driven O&M
Cluster Management Platform
AI Training Framework
O&M Monitoring System
...
Autonomous Northbound Access Standards
Chip Acceleration
Reliability Improvement
Intelligent Fault Prediction
Energy Efficiency Optimization
Robust Security
...
Southbound Standardization & Innovation
Pioneering driver standards for day-level hardware adaption, with broad card compatibility to accelerating diverse computing power deployment
Versatility
Out-of-Band Component Interfaces
Fan Interface
Fan Driver
Storage Interface
Storage Driver
xPU Interface
xPU Driver
Out-of-Band interface
XX Driver
Hardware
Open Ecosystem
openUBMC Studio, a one-stop development platform with AI-enhanced coding to boost server adaptation across the entire development lifecycle
Universal Protocol Compatibility
Redfish / IPMI / SNMP /......
Autonomous Northbound Access
Customized agents, flexibly interconnecting with service systems
Self-Healing Robust Security
Concurrent firmware upgrade/Password security...
NIC
SSD
DPU
HDD
NPU
GPU
RAID Controller Card
## Join the openUBMC Community
### Get Started
Become a part of the openUBMC community. From committing code and perfecting documents to rigorous testing, your expertise drives our innovation.
Explore How to Contribute
### Join a SIG
A special interest group (SIG) is the heartbeat of community collaboration. openUBMC operates through SIGs to ensure a streamlined and efficient development workflow. Every SIG is open to everyone. Join us and make your impact now.
Explore SIGs
### openUBMC Momentum
- 0
Contributors
- 0
Downloads
- 0
Organizations
- 0
Repositories
- 0
PRs
Learn More
## What's New
...
(Sensor Function Adaptation and Debugging for the Hi3093 Development Board (openubmc.cn))[/en/blogs/hi3093-dev-board-i2c] (Business Practice | PowerLeader Computer's Smart UART HMI Based on openUBMC)[/en/blogs/20250815] (PKI Practice: Building a Complete Certificate Service System (openubmc.cn))[/en/blogs/pki-cert-service-guide] (openUBMC Observability: Full Insight into the System for a New BMC Vision)[/en/blogs/202508071] (AI-Powered R&D: Rapid NCSI Protocol Command Parsing in openUBMC)[/en/blogs/202508072] (Business Practice | How the openUBMC Community Development Pipeline Drives High-Quality Delivery for Yangtze Computing)[/en/blogs/20250726]
View More
## Community Partners
Listed in no particular order
---
https://www.openubmc.cn/en/ai-coding-assistants/
---
# Technical Committee Operations Rules
# Policies & Rules
Learn about the operational regulations, code of conduct, and AI contribution policies of the openUBMC community.
Technical Committee Operations RulesCommunity Code of ConductAI Contribution Policy
# Community Code of Conduct
# AI Contribution Policy
openUBMC Community Generative AI Use and Open Source Contribution Policy
## 1\. Openness Strategy
Guided by the spirit of openness, collaboration, and innovation, the openUBMC community recognizes generative AI and intelligent agents as essential drivers for advancing community technologies. While we allow the use of generative AI tools in making contributions, provided such use is reasonable, transparent, and reviewable, we strictly adhere to the following principles:
- **Core Principle 1: Open & AI-Development-Oriented**
The openUBMC community actively embraces new technologies. Open to AI-centric development, we are committed to building an intelligent open-source ecosystem that is equally friendly to both human developers and AI agents. The openUBMC community welcomes both developers and automated agents to contribute deeply to the community, whether through code writing, document translation, test case generation, or O&M automation.
- **Core Principle 2: Developer Ultimate Responsibility**
AI is strictly a supporting tool for human contributors. **Human contributors hold ultimate responsibility and legal accountability for the quality of their submissions**. Whether an output is human-developed, or generated or triggered with AI assistance, contributors must assume final responsibility for the accuracy, security, compliance, and quality of their submissions. Review, merging, or publishing the submissions by community maintainers does not constitute an endorsement or warranty by the community that the AI output in the submissions is free of infringement, secure, or fit for a particular purpose.
- **Core Principle 3: Transparency and Traceability**
Upon submission, contributors should disclose the use of AI tools, sources of third-party materials, license information, and human review status associated with the submission. The openUBMC community enforces a strict metadata tracking system to fully log **critical metadata for AI-generated content, including the agent platform, model, and prompt summaries**. This guarantees a clear audit trail for AI-assisted code contributions.
## 2\. Scope of Application
This policy applies to all forms of contributions submitted to the openUBMC community (including but not limited to all code and documentation repositories under the openUBMC organization):
- **Source code and scripts**: including various core code, test cases, and build scripts.
- **Technical documents and community content**: including API references, deployment guides, release logs, and Wiki pages.
- **Configurations and metadata**: including Containerfiles/Dockerfiles, and CI/CD configuration files.
## 3\. Legal & Compliance
Any submissions incorporating AI-generated content to the openUBMC community shall be governed by the following legal and compliance frameworks:
### 3.1 Contributor License Agreement (CLA)
The openUBMC community implements a **Contributor License Agreement (CLA)**.
- Contributors must sign the CLA before submitting any contributions.
- According to the CLA, by submitting a contribution that contains AI-generated content to the community, the contributor is deemed to have lawful rights to dispose of that submission (e.g., having obtained sufficient authorization). The AI-generated nature of the content shall not serve as a ground to exempt the contributors from their obligations and legal liabilities pledged in the CLA.
### 3.2 Traceability: Full Logging of Key Metadata
For contributions that contain code or documents **fundamentally generated or automatically processed by AI**, contributors shall fully record and attach the following **key metadata** in both the pull request (PR) and commit message.
Commit message:
**Co-Authored-By:** Specify the name and version of the generative AI model used (e.g., `GPT-4o`, `DeepSeek-V3`, etc.).
PR:
- **Agent Platform:** Specify the name and version of the agent platform used (e.g., `Claude Code 2.1.156`, `Qwen Code 0.16.1`, etc.).
- **Model:** Specify the name and version of the generative AI model used (e.g., `GPT-4o`, `DeepSeek-V3`, etc.).
- **Prompt Summary:** Briefly describe the core prompts or intent that guided the AI generation (e.g., `"Optimize memory allocation for Spec file"`). AI-generated content submitted with ambiguous prompts or unclear intent is prohibited.
**Example (PR):**
### AI involvement in this PR:
[] No
[x] Yes
__1. Agent platform: Claude Code 2.1.156
__2. Model: DeepSeek-V3
__3. Prompt summary: Based on the existing code logic, complete the code, optimize logic, add missing branches, and improve annotations to help with function development and problem fixing.
### Notes for reviewers:
1. The code was developed with AI assistance. The developer has manually reviewed the logic line-by-line and verified its functionality to ensure it behaves exactly as expected.
**Example (commit message):**
Co-Authored-By: DeepSeek-V3
_Note: The openUBMC CI gate checks whether the AI model name in the Co-authored-by commit trailer matches the model declared in the PR. Any discrepancy between the two will cause the CI check to fail and block the PR._
## 4\. Standard Prompt for Agents
To ensure that various AI programming assistants and automated agents (such as automated PR reviewers and auto-fixing agents) strictly comply with the preceding policies when serving the openUBMC community, the following **system prompt** is formulated:
# Role and objective:
You are an AI agent dedicated to serving the openUBMC community. Your goal is to assist human developers in contributing efficiently while strictly adhering to the compliance baseline, ensuring all outputs meet the openUBMC community's compliance and quality standards.
# Core Code of Conduct
## 1. Clarify responsibilities and development orientation.
- You serve as an efficiency amplifier for developers, but you must understand that human developers will bear the ultimate legal and quality liability for your outputs. Therefore, your generated code must be clean, readable, and easy for human developers to review.
- Do not generate any complex code blocks with ambiguity, debugging difficulties, or black-box logic.
## 2. Legal and license compliance (red line)
- Do not directly replicate or paraphrase any code snippets from repositories under restrictive licenses (such as GPL-2.0, GPL-3.0, etc.) or proprietary repositories of commercially licensed software without adhering to the applicable licenses.
- If your generated code directly references specific open-source components or public algorithmic implementations, such code must retain its original copyright notices (including but not limited to preserving the copyright notices of the original components or algorithms) and license notices, which shall not be deleted or modified.
## 3. Explicit exposure of key metadata
- When assisting humans in code generation or when independently submitting PRs to openUBMC repositories as an automated agent, compliance with the designated PR and commit message templates is mandatory.
Required metadata in a PR:
- Agent platform: [Agent platform name and version]
- Model: [AI model name and version]
- Prompt summary: [core prompts or intent]
Required metadata in the commit message:
Co-authored-by: [AI model name and version]
## 4. openUBMC technology stack adaptation
- Code style: Before submitting any code to the openUBMC community, analyze the coding style of the target repository. Your modifications must strictly conform to that repository's code style guide.
- Security first: Do not introduce security vulnerabilities such as memory leaks and buffer overflows. Always prefer secure functions verified by the openUBMC community.
## 5\. Prohibited or Risky Behaviors
- Unreviewed AI outputs;
- Code that contributors cannot explain, maintain, or verify the source of;
- Content where AI clearly reproduces third-party code, documentation, images, or copyrighted expressions without providing legitimate sources, licenses, and necessary attributions;
- Content that is incompatible with the project's license;
- Content that violates AI terms of service, employer policies, confidentiality obligations, export controls, data compliance regulations, or third-party rights;
- Prompts, outputs, or contributions that contain trade secrets, personal information, sensitive data, private code, internal documents, or undisclosed vulnerability information;
- Contributions submitted in batch by AI agents or lacking substantial participation by human contributors.
## 6\. Contributor Responsibilities
When submitting AI-assisted contributions to the community, contributors shall acknowledge and agree that they:
- Have manually reviewed the AI-assisted contributions to be submitted;
- Understand the technical implications, design impact, and maintenance costs of the AI-assisted contributions to be submitted;
- Have completed all necessary testing, builds, license checks, and security reviews on the AI-assisted contributions to be submitted;
- Have verified that the AI output does not introduce content incompatible with the project license;
- Have confirmed that the AI-assisted contributions do not include any known unauthorized third-party materials, or that any third-party materials, licenses, copyright notices, and attributions have been fully disclosed as required by this project;
- Have complied with all applicable policies of the contributors' employers, clients, academic institutions, or affiliated organizations regarding AI tools and open-source contributions;
- Take the same responsibility for AI-assisted contributions as for non-AI-assisted contributions.
## 7\. Review and Merging Rules
Community maintainers may request modifications, additional explanations, resubmissions of AI-assisted contributions by the contributors, or reject AI-assisted contributions for any of the following reasons:
- The contributor fails to disclose information regarding the AI-assisted contribution as required;
- The contributor is unable to explain the logic or source of the submitted code;
- The contribution is substantially similar to unauthorized third-party code, documentation, or images;
- The licensing, copyright, or attribution information is unclear;
- The AI-assisted contribution is of poor quality, untested, unmaintainable, or introduces security risks;
- Automated, mass submissions of low-quality AI-assisted contributions disrupt the maintainability and operations of the community;
- The community maintainers consider the AI-assisted contribution inappropriate for merging based on the openUBMC project's risk control.
---
https://www.openubmc.cn/en/charter/
---
# Technical Committee Operations Rules
# Policies & Rules
Learn about the operational regulations, code of conduct, and AI contribution policies of the openUBMC community.
Technical Committee Operations RulesCommunity Code of ConductAI Contribution Policy
# Community Code of Conduct
# AI Contribution Policy
---
https://www.openubmc.cn/en/code-of-conduct/
---
# Technical Committee Operations Rules
# Policies & Rules
Learn about the operational regulations, code of conduct, and AI contribution policies of the openUBMC community.
Technical Committee Operations RulesCommunity Code of ConductAI Contribution Policy
# Community Code of Conduct
openUBMC Community Code of Conduct
## General Provisions
For reporting insults, harassment, or other unacceptable conduct, send an email to complain@public.openubmc.cn for review by the openUBMC Technical Committee.
## Contributor Covenant
To build an open and friendly environment, we as contributors and maintainers pledge to make participation in our community a harassment-free experience for participants of the program and community, regardless of age, body size, visible or invisible disability, ethnicity, level of experience, education, socioeconomic status, nationality, personal appearance, or race.
## Code of Conduct
Conducts that contribute to a positive environment for our community include:
- Friendly and inclusive wording;
- Respecting different viewpoints and experiences;
- Gracefully accepting constructive feedback;
- Focusing on what is best for the community;
- Demonstrating kindness toward others.
- Compliant code submissions, proper use of permissions, and safeguarding project supply chain and infrastructure security.
Unacceptable conducts in the community include:
- Posting sexually explicit comments or images, or engaging in unwelcome sexual advances;
- Disruption, incitement, rumor-making, insulting, derogatory comments, and personal and political attacks;
- Public or private harassment to participants in the community;
- Publishing others' information, such as physical and email addresses, without their explicit authorization;
- Other conduct that can reasonably be considered as a violation of this Code of Conduct.
- Implanting malicious backdoors, polluting project dependencies, destroying project assets, and other violations that endanger community security;
## Project Maintainer Obligations
Community project maintainers are responsible for clarifying and enforcing the standards of "improper conduct" and will take appropriate and fair corrective action in response to any conduct that they deem inappropriate.
Community project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, and issues that violate this Code of Conduct, and will temporarily or permanently ban any participants because of behavior that the maintainers deem to be threatening, offensive, or harmful.
## Scope
This Code of Conduct applies to all community spaces, and also applies when an individual represents the community in public spaces.
Examples of representing the community include using an official email address, posting through an official media account, and participating in online or offline events as an appointed representative.
The project maintainers can further define and interpret the conduct of representing the community.
# AI Contribution Policy
---
https://www.openubmc.cn/en/contact-us/
---
# Contact Us
Engage with openUBMC through the following ways.
## Community Contact
Got a question? Send us an email, and we'll respond within 3–5 business days.
Events
contact@openubmc.cn
Media/PR
contact@openubmc.cn
Community Discussions
discuss@openubmc.cn
## Follow Us
### Find us on social media
- WeChat
- Community Assistant
## Handy Materials
(Community Documentation)[/zh/docs]
(Get the Latest openUBMC Releases)[/zh/download]
(Join Community)[/zh/contribution]
---
https://www.openubmc.cn/en/contribution/
---
# Contribution Guide
...
# Overview
The openUBMC community fosters a friendly environment for development and collaboration. Please read and adhere to the Code of Conduct before contributing.
# Contribution Procedure
## Step 1: Register a AtomGit Account
- openUBMC uses AtomGit as its code hosting repository. https://atomgit.com/org/openUBMC
- Refer to the AtomGit User Guide to register your AtomGit account and set your primary email in user settings.
## Step 2: Sign the CLA
- Before participating in community contributions, you must sign the Contributor License Agreement (CLA).
## Step 3: Find a SIG You Are Interested In
- openUBMC community content is structured around Special Interest Groups (SIGs) to streamline management and workflow. All SIGs are open and welcome contributions from everyone.
### To get started, Find a SIG that Aligns with Your Interests.
- View SIG organizational details via the SIG Center page or the repository. All SIG meetings are public and open for you to join anytime.
- We also encourage interaction with SIG members via the Forum or email.。
- Interested SIG not listed? Start a new one! Send your application to tc@public.openubmc.cn，. Refer to the Application Process for the email template.
## Step 4: Start Your Contribution
Contribution extends beyond code. Your input is valuable in every facet of the community.
### Code Contributions
Each SIG maintains its own planned issues. You can select and resolve an issue based on your interest.
#### Assign an Issue to Yourself
Type **/assign** in the comment box, and the bot will assign the issue to you. If there is an ongoing discussion, feel free to post your feedback or join the conversation in the comments.
#### Submit an Issue
To report a bug or submit a feature request, create an issue in the corresponding openUBMC community repository. If you are unsure which repository to use, post a query on the Forum first.
You can also propose ideas or suggestions via an issue or by starting a topic on the Forum. Refer to the AtomGit Issue Submission Guide for details.
#### Submit a Pull Request (PR)
Refer to the openUBMC Community Pull Request Submission Guide. For substantial contributions, you are highly advised to break down the content into a series of smaller, logically segmented commits for easier code review.
If your PR stalls, you can escalate it and request help through the SIG's mailing list or the forum.
#### Review Code
As an open community, we expect all participants to be active reviewers. For guidance on code review, refer to the The Gentle Art of Patch Review. Key review points to focus on:
- **Contribution relevance:** Evaluate if the contributor's idea is reasonable and aligns with the project's goals and needs.
- **Architectural adherence:** Check if the contributed code adheres to the correct architectural design and is consistent with existing codebase and design principles.
- **Contribution completeness:** Assess if the code is comprehensive, includes all necessary features and tests, and demonstrates maintainability and extensibility.
### Non-Code Contributions
A thriving community is built on more than just code. It relies on the continuous efforts of active developers across all domains. Non-code contributions include, but are not limited to:
#### Documentation Development
- If you find issues while reading openUBMC community documentation, provide feedback by submitting an issue or posting on the Forum.
- Have your own insights? Feel free to publish your own documentation. Refer to the openUBMC Blog Contribution Guide or contact sig-docs via email/forum for available submission methods.
#### Testing and Validation
- Ready to harden the quality of community releases? Get involved with sig-QA.
#### Other Work
- Community interaction: Engage in discussions, mentor new contributors, and answer community queries on the Forum.
- Community operations support: Assist SIG maintainers in improving SIG homepage information, organizing community meetings, and more.
- Becoming a community evangelist: Co-organize community gatherings, including meetups, live streams, and the Developer Day.
- Community promotion and content creation: Submit event news, technical posts, courseware, or videos to the Technical Committee (TC).
- Community infrastructure development: Join sig-infrastructure.
- Community visual design: Contact the TC.
- Community translation services: Reach out to the TC.
## Step 5: Grow with the Community
- We welcome all contributions to the openUBMC community. Our goal is to foster an active and healthy community driven by its contributors. For details on roles like maintainer and committer, refer to the SIG Center page.
---
https://www.openubmc.cn/en/course/
---
# Courses
Explore our curated openUBMC learning collection.
(KPTest Framework Overview)[/en/course/course_kptest_introduction]
(Rapid Setup of the KPTest Local Development Environment)[/en/course/course_kptest_quick_start]
---
https://www.openubmc.cn/en/course/course_kptest_introduction/
---
Courses
KPTest Framework Overview
# KPTest Framework Overview
2025-09-15 19:00
KPTest Framework Overview
吴
吴伟誉
...
## About This Course
This course provides a comprehensive introduction to the KPTest framework, detailing its market positioning, key features, core capabilities, and architectural analysis. KPTest is an ecosystem-oriented automated testing framework designed to accelerate the development of test scripts. Built on Python, it boasts a highly decoupled, layered design and an open architecture, enabling rapid extension and flexible adaptation across various testing environments. The framework seamlessly integrates with platforms like iTestSmart and Darwin, providing a unified solution for diverse domains: WebUI, API, desktop, and operating system testing.
## Instructor Bio
KPTest Framework Development Engineer
---
https://www.openubmc.cn/en/course/course_kptest_quick_start/
---
Courses
Rapid Setup of the KPTest Local Development Environment
# Rapid Setup of the KPTest Local Development Environment
2025-09-15 19:00
Rapid Setup of the KPTest Local Development Environment
吴
吴伟誉
...
## About This Course
This course provides a foundational introduction to quickly setting up a local development environment based on KPTest. We cover environment configuration, project initialization, test case execution, and results viewing, which lays the groundwork for subsequent automated testing script development.
## Instructor Bio
KPTest Framework Development Engineer
---
https://www.openubmc.cn/en/docs/
---
# Docs Center
**0**/100
## Community Guidelines
Community Journey Map
New to openUBMC? Start your journey here!
Contribution Guide
Find your contribution path now!
Release Notes
Discover what's new in openUBMC.
## Developer Guides
Getting Started
A hands-on guide to development.
Developer Guide
openUBMC customization and development guide.
References
Design philosophy and value-added feature development references.
Tool Guide
All-in-one development tooling guide.
Interface Specifications
OpenUBMC interface specifications for seamless collaboration.
---
https://www.openubmc.cn/en/docs/result/
---
# Docs Center
**0**/100
---
https://www.openubmc.cn/en/download/
---
# Download Center
Find all the resources in one place.
Community Releases
Driven by and dedicated to the openUBMC community.
Commercial Releases
Commercial releases built on openUBMC.
Download CenterCommunity Releases
## Community Releases
Find and download the latest and previous releases, along with their release notes, to quickly integrate and customize openUBMC.
...
openUBMC 26.09
Latest Release
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 26.09 | 656.74 MB | 2026/09/29 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_26.09.00.01.zip | 26.09 | 83.85 MB | 2026/09/29 | SHA256 | Download |
| openUBMC-CMT_unsigned_26.09.00.01.zip | 26.09 | 83.84 MB | 2026/09/29 | SHA256 | Download |
openUBMC 25.12 LTS SP3
LTS
Maintenance deadline: 2026/12/31
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP3 | 280.1 MB | 2026/09/09 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.03.01.zip | 25.12 SP3 | 74.58 MB | 2026/08/31 | SHA256 | Download |
openUBMC 26.06
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 26.06 | 293.75 MB | 2026/07/06 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_26.06.00.01.zip | 26.06 | 77.27 MB | 2026/06/30 | SHA256 | Download |
## Download Resources
(App Marketplace)[/zh/marketplace]
(Community Docs)[/zh/docs]
## Support & Services
(FAQs)[/docs/en/development/faq/general.html]
(Community Forum)[https://discuss.openubmc.cn/]
---
https://www.openubmc.cn/en/download/business-releases/
---
# Download Center
Find all the resources in one place.
Community Releases
Driven by and dedicated to the openUBMC community.
Commercial Releases
Commercial releases built on openUBMC.
Download CenterCommercial Releases
## Commercial Releases
- ### What Is a Commercial Release?
- A commercial release is an enterprise-level solution built on the openUBMC community release, tailored and enhanced for business needs.
- It adds professional enterprise features to the community release, including advanced security management, enhanced O&M, compliance certification, custom functionality, and commercial technical support.
- Fully tested and optimized for stability in complex enterprise IT settings, the commercial releases reduce O&M risks, increase management efficiency, and meet diverse industry needs.
- ### How Do Commercial and Community Releases Differ?
- Commercial releases deliver enterprise-level reliability and professional support needed for high stability and security of production environments. They offer enhanced, device-validated functionality, regular security updates, and responsive technical services to help enterprises mitigate potential risks. In addition, commercial releases usually allow customizations to address specific hardware or service needs.
- Commercial releases provide guaranteed long-term maintenance, freeing the team from foundational technical concerns.
- ### How to Become a Partner?
- We warmly welcome hardware vendors, solution providers, and system integrators to participate in our partnership initiative. As a certified partner, you will gain collaborative marketing and promotional support from the openUBMC community. We are excited to partner with you to build a thriving BMC ecosystem and deliver superior products and services to end customers.
- Please reach out to us at contact@openubmc.cn to discuss partnership specifics and advantages, and together drive the commercial adoption and innovation of open source technology.
- ### BYOSOFT openUBMC 25.09 Commercial Release
- The BYOSOFT commercial release is derived from the 25.06 community release, augmenting it with multiple verified new features. Major new features include the real-time monitoring dashboard, flexible sensor alarm policies, and Web SOL, which greatly boost operational and management efficiency. Throughout the development cycle, we stay aligned with community updates and refine features according to internal needs. Its release adheres to a rigorous procedure: from internal testing to public beta and the final official launch, ensuring its stability and availability.
Vendor: Nanjing Byosoft Co., Ltd.
Release Date: 2025/9/30
View More
- ### KunlunTech openUBMC Commercial Release
- Kunlun BMC-U, KunlunTech's openUBMC commercial release derived from the 25.09 community release, undergoes deep optimizations in its features, peripheral support, customization, and documentation. Kunlun BMC-U improves Kunpeng BMC products with enhanced performance, extended functionalities, and easy maintenance. It offers a reliable, efficient enterprise‑grade BMC firmware solution for partners.
- Kunlun BMC‑U will keep pace with openUBMC community updates and continuously enhance its capabilities to support partners in new product launches and value creation.
Vendor: Kunlun Technology (Beijing) Co., Ltd.
Release Date: 2025/10
View More
---
https://www.openubmc.cn/en/download/community/all/
---
# Download Center
Find all the resources in one place.
Community Releases
Driven by and dedicated to the openUBMC community.
Commercial Releases
Commercial releases built on openUBMC.
Download CenterCommunity Releases
## Community Releases
Find and download the latest and previous releases, along with their release notes, to quickly integrate and customize openUBMC.
...
Version
All
LTS
New
| Package Type | Release Date | Maintenance Deadline | Download Link |
| --- | --- | --- | --- |
| openUBMC 26.09 | 2026/09 | 2026/12 | Download |
| openUBMC 25.12 LTS SP3 | 2026/08 | 2026/12 | Download |
| openUBMC 26.06 | 2026/06 | 2026/07 | Download |
| openUBMC 25.12 LTS SP2 | 2026/05 | 2026/12 | Download |
| openUBMC 26.03 | 2026/03 | 2026/06 | Download |
| openUBMC 25.12 LTS SP1 | 2026/02 | 2026/12 | Download |
| openUBMC 25.12 LTS | 2025/12 | 2026/12 | Download |
| openUBMC 25.09 | 2025/09 | 2025/12 | Download |
| openUBMC 25.06 | 2025/07 | 2025/09 | Download |
| openUBMC 25.03 | 2025/04 | 2025/06 | Download |
## Download Resources
(App Marketplace)[/zh/marketplace]
(Community Docs)[/zh/docs]
## Support & Services
(FAQs)[/docs/en/development/faq/general.html]
(Community Forum)[https://discuss.openubmc.cn/]
---
https://www.openubmc.cn/en/download/community/detail/openUBMC 25.12 LTS/
---
Versions
Reset
Confirm
Downloads
All Versions
openUBMC 25.12 LTS
Versions
openUBMC 26.09
openUBMC 25.12 LTS SP3
openUBMC 26.06
openUBMC 25.12 LTS SP2
openUBMC 26.03
openUBMC 25.12 LTS SP1
openUBMC 25.12 LTS
openUBMC 25.09
openUBMC 25.06
openUBMC 25.03
openUBMC 25.12 LTS
LTS
Maintenance deadline: 2026/12/31
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 | 71.15 MB | 2025/12/31 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.00.01.zip | 25.12 | 77.58 MB | 2025/12/31 | SHA256 | Download |
---
https://www.openubmc.cn/en/download/community/detail/openUBMC 25.12 LTS SP1/
---
Versions
Reset
Confirm
Downloads
All Versions
openUBMC 25.12 LTS SP1
Versions
openUBMC 26.09
openUBMC 25.12 LTS SP3
openUBMC 26.06
openUBMC 25.12 LTS SP2
openUBMC 26.03
openUBMC 25.12 LTS SP1
openUBMC 25.12 LTS
openUBMC 25.09
openUBMC 25.06
openUBMC 25.03
openUBMC 25.12 LTS SP1
LTS
Maintenance deadline: 2026/12/31
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP1 | 75.33 MB | 2026/02/14 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.01.01.zip | 25.12 SP1 | 66.08 MB | 2026/06/29 | SHA256 | Download |
---
https://www.openubmc.cn/en/download/community/detail/openUBMC 25.12 LTS SP2/
---
Versions
Reset
Confirm
Downloads
All Versions
openUBMC 25.12 LTS SP2
Versions
openUBMC 26.09
openUBMC 25.12 LTS SP3
openUBMC 26.06
openUBMC 25.12 LTS SP2
openUBMC 26.03
openUBMC 25.12 LTS SP1
openUBMC 25.12 LTS
openUBMC 25.09
openUBMC 25.06
openUBMC 25.03
openUBMC 25.12 LTS SP2
LTS
Maintenance deadline: 2026/12/31
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP2 | 84.93 MB | 2026/06/03 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.01.01.zip | 25.12 SP2 | 66.46 MB | 2026/06/29 | SHA256 | Download |
---
https://www.openubmc.cn/en/download/community/detail/openUBMC 25.12 LTS SP3/
---
Versions
Reset
Confirm
Downloads
All Versions
openUBMC 25.12 LTS SP3
Versions
openUBMC 26.09
openUBMC 25.12 LTS SP3
openUBMC 26.06
openUBMC 25.12 LTS SP2
openUBMC 26.03
openUBMC 25.12 LTS SP1
openUBMC 25.12 LTS
openUBMC 25.09
openUBMC 25.06
openUBMC 25.03
openUBMC 25.12 LTS SP3
LTS
Maintenance deadline: 2026/12/31
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP3 | 280.1 MB | 2026/09/09 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.03.01.zip | 25.12 SP3 | 74.58 MB | 2026/08/31 | SHA256 | Download |
---
https://www.openubmc.cn/en/download/community/latest/
---
# Download Center
Find all the resources in one place.
Community Releases
Driven by and dedicated to the openUBMC community.
Commercial Releases
Commercial releases built on openUBMC.
Download CenterCommunity Releases
## Community Releases
Find and download the latest and previous releases, along with their release notes, to quickly integrate and customize openUBMC.
...
openUBMC 26.09
Latest Release
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 26.09 | 656.74 MB | 2026/09/29 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_26.09.00.01.zip | 26.09 | 83.85 MB | 2026/09/29 | SHA256 | Download |
| openUBMC-CMT_unsigned_26.09.00.01.zip | 26.09 | 83.84 MB | 2026/09/29 | SHA256 | Download |
openUBMC 25.12 LTS SP3
LTS
Maintenance deadline: 2026/12/31
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP3 | 280.1 MB | 2026/09/09 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.03.01.zip | 25.12 SP3 | 74.58 MB | 2026/08/31 | SHA256 | Download |
openUBMC 26.06
Release Notes
Technical White Paper
Lifecycle
### Source Code
Complete source packages of the openUBMC community release for custom development.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 26.06 | 293.75 MB | 2026/07/06 | SHA256 | Download |
### Firmware
Firmware packages of the openUBMC community release, ready for immediate update on servers running the openUBMC community release.
| Package Name | Version | Size | Release Date | Integrity Check | Download Link |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_26.06.00.01.zip | 26.06 | 77.27 MB | 2026/06/30 | SHA256 | Download |
## Download Resources
(App Marketplace)[/zh/marketplace]
(Community Docs)[/zh/docs]
## Support & Services
(FAQs)[/docs/en/development/faq/general.html]
(Community Forum)[https://discuss.openubmc.cn/]
---
https://www.openubmc.cn/en/download/lifecycle/
---
Community Releases
Lifecycle
# lifecycle
Community releases are named by delivery year and month (YY.MM). For example, openUBMC 25.09 was released in September 2025.
Community releases are categorized into long-term support (LTS) releases and innovation releases.
• LTS releases: Released annually and provided with 12-month community support. The first openUBMC LTS release 25.12 is planned for December 2025.
• Innovation releases: Released every 3 months, offering 3-month community support. The first openUBMC innovation release was launched in March 2025.
Maintenance support: CVE & Bugfix, new hardware support, and limited new features (with LTS forward compatibility).
---
https://www.openubmc.cn/en/maillist/
---
# Mailing Lists
Mailing lists are the core, efficient channel for all openUBMC community SIGs.
Engage directly in technical reviews, shape proposals, and drive project direction with real-time updates.
Subscribe to a SIG
Select Your SIG
Select the SIG you want to subscribe to and click Subscribe.
Enter Details
On the subscription page, fill in the required personal information and click Subscribe.
Review & Confirm
Your mailbox will receive an e-mail from the mailing list, asking you to confirm your subscription. Click the confirmation link to complete the process.
You're Subscribed!
Your mailbox receives a welcome e-mail from the mailing list, indicating that you have subscribed to the mailing list successfully.
SIG Mailing Lists
| SIG Name | Description | Mailing Lists | Archive | Subscribe |
| --- | --- | --- | --- | --- |
No Data
---
https://www.openubmc.cn/en/news/
---
# News
Dive into the latest industry and community news.
(openUBMC 25.09 Is Now Available!)[/en/news/2509-release]
(openUBMC Xi'an Meetup Recap)[/en/news/xian-meetup-review]
(openUBMC Open Source Development Committee Launches Trial Operation with Inaugural Meeting)[/en/news/20250724]
(openUBMC 25.06 Released!)[/en/news/2506-release]
(openUBMC Hangzhou Meetup 2025 Wrap-Up: Shaping the Future of Computing Power Management)[/en/news/hangzhou-meetup-review]
(openUBMC Technical Session: Building an Intelligent Foundation for Computing Power Management)[/en/news/kadc-2025]
(openUBMC 25.03 Release: Starting a New Journey of Open Source)[/en/news/2503-release]
---
https://www.openubmc.cn/en/news/20250724/
---
News
openUBMC Open Source Development Committee Launches Trial Operation with Inaugural Meeting
# openUBMC Open Source Development Committee Launches Trial Operation with Inaugural Meeting
2025/07/24
# openUBMC Open Source Development Committee Launches Trial Operation with Inaugural Meeting
The openUBMC Open Source Development Committee officially launched its trial operation in Shenzhen, China, on July 18, 2025, marked by its inaugural onsite meeting. This milestone event convened leaders and technical experts from over 30 companies, representing diverse fields including Internet, carriers, server vendors, independent BIOS vendors, component suppliers, and standards organizations.
The meeting focused on core topics such as technological innovation, ecosystem co-construction, and community governance, establishing clear goals and strategic directions for openUBMC's next phase of development.
Mr. Ma Yinchuan, Chairperson of the openUBMC Open Source Development Committee, attended the meeting and delivered a speech. He summarized the progress since openUBMC's initial open-sourcing, expressed gratitude for the contributions of all member organizations, and invited the committee to offer suggestions and ideas for the community's future work, emphasizing the need to build consensus and jointly advance the community's development.
Following this, Mr. Song Tongling, Chairperson of the openUBMC Technical Committee, addressed the openUBMC Open Source Development Committee on the major technical features of the newly released version 25.06 and the technical roadmap for the second half of the year 2025.
- **Major upgrades in version 25.06**
As the second release of openUBMC in 2025, openUBMC 25.06 achieves significant progress. Key improvements include enhanced standardized interfaces, broader hardware compatibility, stronger O&M capabilities, and an optimized developer experience.
- **Technical roadmap for H2 2025**
In the second half of 2025, the openUBMC community will focus on optimizing and upgrading core areas: BMC O&M features, developer usability, and community infrastructure. The aim is to create a more user-friendly and efficient BMC software and community ecosystem. Meanwhile, the openUBMC Technical Committee will uphold its commitment to technical work across H2, ensuring a strong foundation for the continuous development of community versions and technologies.
A sustained, prosperous ecosystem is critical for the growth of any open source community. The openUBMC Ecosystem Development Team provided the openUBMC Open Source Development Committee with an update on the community's progress.
- **Expanding industry ecosystem:** The openUBMC community has laid the foundation for a robust and comprehensive industry chain. Looking ahead, it will continue to broaden hardware and software support to accommodate a wider range of application scenarios.
- **Enhanced standards and certification system:** The openUBMC Component Driver SIG will develop specifications for BMC southbound driver interfaces. Collaborating with community members and standards organizations, this SIG aims to establish unified component driver standards and a formal certification system.
- **Impressive initial scale of commercial adoption:** Nearly 20 commercial versions based on the openUBMC community release have already been delivered by member organizations, spanning critical sectors such as cloud services, finance, and public utilities.
- **Efficient and healthy organizational operations:：** The openUBMC community has formed nine technical SIGs focused on key areas including northbound interface management, southbound component integration, BMC O&M, and component drivers. These SIGs have attracted over 200 developers and fostered an effective collaboration model.
During the open discussion session, the openUBMC Development and Growth Committee conducted in-depth discussions on several key topics, including upstream and downstream collaboration for version releases, southbound component driver standards, joint ecosystem expansion and influence building, and community governance and operations. The session yielded broad consensus across multiple fronts.
Finally, Mr. Wang Ruifeng, Secretary-General of the openUBMC community, concluded the meeting by emphasizing that its successful convening represented a significant milestone in the community's evolution. It laid a strong foundation for openUBMC's long-term, sustainable growth. Moving forward, the community will take this meeting as a new starting point—upholding the principles of co-construction, sharing, and co-governance, and working collectively to drive sustained development of the openUBMC ecosystem.
### Join the openUBMC community:
Community website: https://www.openubmc.cn/en
Code repository: https://gitcode.com/openUBMC
Corporate cooperation: contact@openubmc.cn
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/news/2026Wuhan-meetup-review/
---
No data
---
https://www.openubmc.cn/en/news/2503-release/
---
News
openUBMC 25.03 Release: Starting a New Journey of Open Source
# openUBMC 25.03 Release: Starting a New Journey of Open Source
2025/05/08
# openUBMC 25.03 Release: Starting a New Journey of Open Source
Elevate your open source capabilities with the latest openUBMC solution! We are excited to introduce openUBMC 25.03, a release built to offer you greater quality and flexibility. Discover a suite of new innovations in this first annual release for your baseboard management controller (BMC) jobs.
## 1.1 Features of the Release: A Major Overhaul
### 1.1.1 Northbound Interface Ecosystem
- Security enhancements: The upgraded security framework supports customization of password and username policies, and comes with a new foundational module for certificate management.
- O&M optimizations: Configuration import and export are standardized. Factory reset now preserves user data. The MCU/VRD firmware upgrade architecture has been refactored to support the standard HPM package format.
### 1.1.2 Southbound Component Extension
- Management enhancements: Speed adjustment policies and loading of multiple SML libraries are now supported.
- Component compatibility: SP322D/SP323D NICs and NVMe-MI v1.7 linkspeed query are now supported.
### 1.1.3 Development Experience Optimization
- Tooling upgrades: Local debugging and model check based on bingo are supported, and the BMC Studio is open source.
- Function expansion: CSR configuration check and full model check are supported.
## 1.2 Download to Experience for Yourself
Download link: https://openubmc.cn/en/download
For details about the release, visit https://openubmc.cn/en/version/25.03.
## 1.3 Source Code Release
openUBMC 25.03 operates under Mulan PSL v2. You are free to copy, use, modify, and redistribute the software. Whether you're an independent developer or an enterprise user, you can customize it to fit your needs within legal and regulatory boundaries. The source code for openUBMC 25.03 is now live on the community website. Open source is all in when we share and collaborate. We invite all developers to join in the openUBMC project for even better outcomes. Repository link: https://gitcode.com/openUBMC
## 1.4 Acknowledgment
A huge thank you to all the community developers behind our openUBMC project! This release would not have been possible without your brilliant contributions and hard work. We invite more partners to join our community. Together, we're starting a new journey of open source.
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/news/2506-release/
---
News
openUBMC 25.06 Released!
# openUBMC 25.06 Released!
2025/07/07
# openUBMC 25.06 Released!
🥳 A huge thank-you to all the developers who contributed to the 25.06 release!
The new version of openUBMC 25.06 is here on schedule—packed with major updates, new features, and community-driven improvements.
✅ 1,272 issues resolved
✅ 1,582 PRs merged
✅ 334k lines of code added
✅ 179 contributors from multiple organizations
## 🔑 Key Highlights in openUBMC 25.06
### Hardware SIG
🔥 Completed NCSI sideband management feature for NICs.
🔥 Enhanced NVME-MI protocol command set.
🔥 Improved smart data retrieval for drives.
🔥 Added support for parallel protocol library loading for RAID management.
🔥 Enabled manual/automatic fan mode switching with persistent configuration.
🆕 Added power efficiency curve interface, enabling dynamic power mode switching.
🆕 Introduced parallel upgrade capability for multiple component types.
🆕 Expanded management support for devices including BF2/BF3 NICs, and RAID cards 9540-8i, 9560-8i, 9440-8i, SP686C-M 16i 4G.
### 🌐 Interface SIG
🔥 Completed several Redfish 1.20 standard interfaces.
🆕 Introduced Observability, a new component for real-time BMC performance monitoring and faster issue debugging.
🆕 Added libirc, a remote communication library to simplify customized client development.
🐞 Fixed multiple WebUI bugs and enhanced KVM capabilities.
### ⚙️ bmc\_core SIG
🔥 Implemented some missing parts of the "Sensor" section in IPMI Specifications.
🔥 Strengthened e-label and power-on/power-off strategy customization.
🐞 Fixed sensor component bugs and improved fault localization.
### CICD SIG
🔥 Optimized BMC Studio hardware adaptation UI for a more intuitive configuration experience.
🔥 Enhanced CSR check functionality in BMC Studio.
🆕 QEMU now supports Tianchi component simulation.
🐞 Fixed several build issues in bingo, with support for installation via apt and pip.
🆕 Added CMS signing capability for HPM packages in bingo.
### 📦 Get openUBMC 25.06
Download: https://www.openubmc.cn/en/download
Release notes: https://www.openubmc.cn/en/version/latest
Application store: https://www.openubmc.cn/en/marketplace
Documentation: https://www.openubmc.cn/en/docs
🙌 Thanks to every contributor for making openUBMC better with each release. Your passion and collaboration drive the community forward. Stay tuned—and join us to keep building a more open, intelligent, and powerful ecosystem together!
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/news/2509-release/
---
News
openUBMC 25.09 Is Now Available!
# openUBMC 25.09 Is Now Available!
2025/09/30
# openUBMC 25.09 Is Now Available!
# 🥳 openUBMC 25.09 Is Now Available!
A huge thank you to all the developers and organizations who contributed to this release—openUBMC 25.09 is here, right on schedule!
✅ 1,313 issues resolved
✅ 1,923 PRs merged
✅ 565k new lines of code
✅ Contributions from developers across 17 organizations
## 🔹 What's New in 25.09
### Security SIG
🆕 Added support for historical password reuse prevention, configurable failed login lockouts, and extended password lengths.
🆕 Added support for web SSO login, IPMI channel permission control, and frontend sensitive data encryption.
### Interface SIG
🆕 Added openUBMC plugins for Zabbix, Ansible, Cmdlets, and Nagios.
🚀 Completed resource management interfaces for Redfish Manager, Processor, SEL, NTP, and timezone.
🆕 Added support for User Access/Password, User Name, and DCMI Power commands.
🚀 Upgraded multiple firmware in a single HPM package, with auto-recovery upon BMC upgrade failure.
🚀 Prevented host power-on during VRM and NPU upgrades.
### Hardware SIG
🆕 Added support for I3C/CAN-FD and network controller information retrieval via NC-SI over MCTP over I2C/SMBus.
🆕 Added support for Emulex PLDM OEM protocol.
🆕 Added support for PCIe and OCP cards such as E810XXVDA2G1P5, E810CQDA2G2P5, and MCX755106AS-HEAT.
🆕 Added support for RAID cards (SP686C-M series), drives, NVMe SSDs (Samsung PM9D3A, Memblaze PBlaze7, and Solidigm D7-PS1010).
🆕 Added support for GPU (NVIDIA A6000) and NPU modules.
🆕 Added support for TPSU/PSU management capabilities, such as module information query, turbo capacitor management, dual CAN power redundancy, power capping & monitoring, and output limit configuration.
🚀 Added support for persistent critical component logs (VRM/power).
🚀 Added support for BIOS firmware export & critical component firmware upgrade.
🚀 Added support for NIC flash recovery, optical module key info logging & link failure detection.
🚀 Added support for high-speed link detection, CPU & peripheral link anomaly alerts.
### Component Driver SIG
🆕 Added a new device driver management framework to support driver-based component adaptation and management.
🚀 Enabled driver-based management for components such as AWM M11P, SP670, and RP1000P2SFP-A03.
### CICD SIG
🚀 Enhanced QEMU simulation with support for complex protocol emulation (SMBus, MCTP) and device emulation (MCUs, PCIe, and IMU sensors).
🚀 Optimized QEMU smoke tests & driver dependency synchronization with OS updates.
🆕 Built Conan 2.0 main repo, support for profile configuration & parallel builds.
🚀 Bingo integrated GoogleTest framework and optimized developer test hardening & CI automated tests.
🆕 Added I2C scan & read/write tools, configurable metrics collection & observability tracing.
### Docs SIG
🆕 Added configuration guides for SNMP interface mapper, TRAP alerts, equipment customization, and CLI mapper.
🚀 Updated BMC Studio user guide & online help pages.
### Infra SIG
🆕 Added community contribution dashboard for statistics on individual contributions, CLA-signed organization contributions, and SIG contribution rankings.
🆕 Added support for creating routine meetings and improved recording features including speech-to-text transcription and screen recording.
### 🔹 Resources
- Download: https://www.openubmc.cn/en/download
- Release notes: https://www.openubmc.cn/en/version/latest
- Marketplace: https://www.openubmc.cn/en/marketplace
- Installation docs: https://www.openubmc.cn/en/docs
A big shoutout to every developer—your contributions are what keep openUBMC moving forward. 💪 Stay tuned and join us to continue driving our community's growth! 🚀
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/news/hangzhou-meetup-review/
---
News
openUBMC Hangzhou Meetup 2025 Wrap-Up: Shaping the Future of Computing Power Management
# openUBMC Hangzhou Meetup 2025 Wrap-Up: Shaping the Future of Computing Power Management
2025/05/30
# openUBMC Hangzhou Meetup 2025 Wrap-Up: Shaping the Future of Computing Power Management
On May 26, 2025, the openUBMC open source community held its first meetup in Hangzhou, Zhejiang. Over 60 maintainers and developers, representing key sectors like server, Internet, IBV, component, and chip, gathered to discuss openUBMC's technical evolution and share practical industry experiences.
The full-day meetup started with an opening session, followed by morning presentations on key topics and an immersive, hands-on workshop in the afternoon.
## 1 Opening Session
Zhang Yubo, representing the openUBMC Technical Committee, opened the meetup by introducing the agenda and sharing community updates, including new features in version 25.03, plans for version 25.06, community operational data, BMC Studio RC, and next steps for the community website.
### 2 Presentations
After the opening session, community developers from several companies presented their technical topics.
### 2.1 Developer Test (DT) Best Practices on Northbound Interfaces
Huang Han from the Interface Special Interest Group (SIG) introduced a method for performing unit tests (UTs) on northbound mapping configurations, which significantly shortens development and debugging cycles while improving the community's ability to maintain code quality. He called on community developers to continue improving the UT capabilities for northbound interfaces and enhancing the stability of the openUBMC northbound interfaces.
### 2.2 Southbound Component Driver Standardization
Liu Xingsen from the Hardware SIG shared how standardized component compatibility approaches can address hardware adaptation challenges. He also explained how the open architecture allows vendors to independently develop BMC component drivers within the community. Finally, he invited more community members to join the discussion on standardization.
### 2.3 Pipeline Build Practices
Yi Zhonghui from Wuhan Yangtze Computing Technology explained how they constructed their own build pipeline system using the Conan repository of the openUBMC community. He discussed the technical challenges encountered and offered practical solutions based on real-world examples, providing valuable references for developers.
### 2.4 iNIC Adaptation Experience Sharing
Bao Minmin from Henan Kunlun Technology shared practical experiences from their openUBMC intelligent NIC (iNIC) project, detailing the technical challenges faced during delivery and the lessons learned in overcoming them.
### 2.5 Development Challenges and Lessons Learned
Xiong Zirui from Henan Kunlun Technology, a developer new to the BMC domain, shared his experience in overcoming the hurdles he encountered when getting started with openUBMC to facilitate a smoother start for other developers.
### 2.6 In-House Components for Smart Serial Port Screens
Qiu Hao from Powerleader Computer System explained how the company used its in-house components to make innovative breakthroughs in serial port screen functionality on the openUBMC platform, covering technical details and implementation approaches. Another speaker, Zhu Junjie, discussed the full-process management of these new components, offering developers a practical, step-by-step guide.
### 2.7 Practical Experience in Northbound Interface Adaptation
Zhang Qiang from Sichuan Huakun Zhenyu Intelligent Technology detailed how they adopted a northbound mapping mechanism to reduce interface adaptation workload from 1.5 person-months to just 3 person-days. This innovative approach significantly boosted efficiency and saved resources, sparking keen interest and discussions among attendees.
## 3 Hands-on Workshop
Organized by the Technical Committee, the hands-on workshop offered developers an opportunity to engage with core technologies and hot topics through immersive activities like coding, collaborative problem-solving, and open discussions. By writing and debugging code for key modules and validating solutions, participants gained firsthand experience in creative, collaborative open source work. Positive feedback highlighted effective knowledge exchange and expert support, demonstrating how the workshop successfully deepened technical skills and fostered community co-construction.
## 4 Looking Ahead
Through experience sharing and technical insights, the meetup showcased the openUBMC community developers' expertise and passion, providing an open, tech-driven platform for BMC developers. The openUBMC community intends to host more offline technical events and welcomes more developers to join.
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/news/kadc-2025/
---
News
openUBMC Technical Session: Building an Intelligent Foundation for Computing Power Management
# openUBMC Technical Session: Building an Intelligent Foundation for Computing Power Management
2025/05/27
# openUBMC Technical Session: Building an Intelligent Foundation for Computing Power Management
On May 24, 2025, the Kunpeng & Ascend Developer Conference (KADC) was held at the Beijing ZhongGuanCun International Innovation Center. As one of the key sessions, the openUBMC technical session, titled "Building an Intelligent Foundation for Computing Power Management," brought together developers and industry experts from cloud vendors, OEMs, component manufacturers, standards organizations, and academia to explore the future of open source device management software.
## 1.1 Opening Remarks: Open Source Collaboration on Shaping the Future
Ren Chao, Director of Huawei's Cloud BU Hardware Department, delivered the opening remarks. He reviewed Huawei's deep-rooted expertise in the baseboard management controller (BMC) domain since the company began server R&D in 2003, emphasizing that Huawei's BMC solutions are built on robust security to enable intelligent management of computing devices worldwide. He noted, "The computing industry is ecosystem-driven. As a critical component, BMC offers us a path to open source development where we can consolidate collective expertise and build a computing power management ecosystem."
As the initiator of the openUBMC community, Huawei has contributed its open source expertise accumulated over the past two decades and continues to invest in community governance, technological innovation, and ecosystem development. Mr. Ren called on global developers to jointly build the openUBMC community into a world-leading digital infrastructure management platform—one that is open, collaborative, and transparent through co-construction, sharing, and co-governance.
## 1.2 Themed Speeches: Open Source in Action, Ecosystem in Growth
During the session, six targeted talks highlighted openUBMC's technical innovations and industry applications.
### 1.2.1 Co-Building the openUBMC Community and the Intelligent Computing Management Foundation
Wang Ruifeng, General Secretary of the openUBMC Community, analyzed the challenges and opportunities of managing diverse computing power in the AI era. He outlined the community's vision to deliver open source and standardized digital infrastructure management software through collaboration with global developers, and to drive continuous innovations across platforms, domains, and the industry chain.
Mr. Wang also introduced the architecture, toolchain features, and innovative development roadmap of the community, and officially announced the release of openUBMC 25.03. At the end of his speech, he encouraged all developers to collaborate in future iterations and innovations.
### 1.2.2 Redefining Management Software Platforms with a New Open Architecture
Song Tongling, Member of the openUBMC Technical Committee, explained the evolving demands for device management across the computing industry and proposed a micro-component architecture to address challenges from single-server to cluster-level management. He emphasized standardized interfaces and a unified component framework to ensure the openness and compatibility of hardware and software management, and introduced a one-stop development platform that empowers developers to drive technical innovation in the community.
### 1.2.3 Test Building and Automation Practices
Liu Song from Sichuan Huakun Zhenyu Intelligent Technology shared insights into openUBMC-based test building and automation practices, explaining how modular design dramatically improved integration efficiency, shortened release cycles, and ensured high-quality project delivery.
### 1.2.4 End-to-End Delivery Practices
Wang Qindong from Henan Kunlun Technology presented Kunlun's integrated openUBMC solution, demonstrating end-to-end commercial deployment on Kunpeng and Ascend servers. He also analyzed how community collaboration accelerates commercialization and effectively facilitates industry adoption.
### 1.2.5 BMC Studio Toolchain Application Practices
Wang Yazhou from Beijing KunlunTech demonstrated the powerful capabilities of the BMC Studio toolchain, particularly its efficiency in building development environments and customizing components. He recognized openUBMC in terms of usability and scalability, believing it will tangibly inspire and empower developers.
### 1.2.6 Build and Management Practices for Conan Components
Wang Tao from Nanjing BYOSOFT presented in detail their practices for building Conan components, as well as expertise in related development scenarios. He highlighted that centralized dependency management within the community can significantly improve responsiveness to customer needs, providing strong support for both enterprise technology development and client services.
This session, through technical presentations and case sharing from different enterprises, demonstrated the diverse value and impact of the openUBMC community in advancing intelligent computing power management foundations, providing the industry with more open and efficient open source device management software.
## 1.3 Join us
The openUBMC community will continue to bring together developers from around the world to jointly build a leading open source system for digital infrastructure management. We welcome developers to join us and collaborate in shaping the computing power management ecosystem.
Scan the QR code for more community updates!
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/news/xian-meetup-review/
---
News
openUBMC Xi'an Meetup Recap
# openUBMC Xi'an Meetup Recap
2025/08/22
# openUBMC Xi'an Meetup Recap
On August 18, the openUBMC Xi'an Meetup, co-hosted by KunlunTech, wrapped up successfully, bringing together nearly 30 developers from various companies. This meetup centered on openUBMC 25.06, offering hands-on workshops across **observability practices, community testing capabilities, and software development enhancements**. Developers dove into real-world scenarios, exchanged ideas, and gained a deeper grasp of the technologies driving openUBMC forward.
## openUBMC Community Updates
**Zhang Yubo, a member of the openUBMC Technical Committee, kicked off the event with updates on the community's latest progress and its organizational and operational mechanisms**. Highlights from the 25.06 release, especially its stronger traceability and user-friendly tools, drew great interest, and the sneak peek at 25.09 fueled excitement for what's next. His talk also shed light on openUBMC's open and transparent governance, inspiring more developers to get involved.
## Observability Practice
**Li Siguang from the openUBMC Interface SIG delivered an in-depth session on observability, covering everything from technical principles to real-world applications**. The workshop illustrated how effective data collection, metrics, and log analysis enhance visibility across BMC software.
## Community Testing Capability Enhancement
**Representing the CICD SIG, Zhang Yubo and Lin Wanmin introduced the smoke testing implemented in openUBMC 25.06, built on Robot Framework and QEMU**. Lin demonstrated how to develop BMC northbound interface test cases using Robot Framework, showing the efficiency and ease of automated testing.
## AI-Powered Coding Practice
**Zhang Yubo and Li Zhaotian illustrated community feature design workflows, coding strategies, and test case design processes through real openUBMC cases across design, coding, and testing phases**. Li showcased how AI toolchains can auto-generate design documents, test cases, and DT code, offering developers new ways to boost productivity. They encouraged participants to further experiment with AI-assisted development and contribute innovative ideas to the community.
## 🚩 See You at the Next openUBMC Meetup!
Innovation never stops—and neither does openUBMC. The community will continue bringing cutting-edge technologies and practical workshops to more cities, empowering developers everywhere. openUBMC remains committed to building a thriving, collaborative ecosystem where every developer can grow, contribute, and make an impact.
### Learn More about openUBMC ⬇️
- Official website: https://www.openubmc.cn/en
- Community forum: https://discuss.openubmc.cn/
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/operations-rules/
---
# Technical Committee Operations Rules
# Policies & Rules
Learn about the operational regulations, code of conduct, and AI contribution policies of the openUBMC community.
Technical Committee Operations RulesCommunity Code of ConductAI Contribution Policy
openUBMC Community Technical Committee Operations Rules
## General Provisions
The openUBMC Technical Committee (TC) is the primary technical governance body for openUBMC community projects, responsible for providing technical guidance, decision-making, and oversight.
## Key Responsibilities
The TC serves as the community's technical leadership organization. Its primary authorities are:
1. Holding the final authority on all technical decisions;
2. Determining the technical development vision and direction for the community;
3. Deciding on matters such as the formation, dissolution, or merger of SIGs. Resolving collaboration conflicts between SIGs, and mentoring, reviewing, and overseeing their daily operations;
4. Implementing daily development work and ensuring the high-quality release of the openUBMC community distributions;
5. Leading the establishment of proprietary open source projects and continuously building the community's technical influence.
## Composition
The TC is chaired by one Chairperson, whose duties are:
1. Calling and presiding over TC meetings, and ensuring all attendees have the right to fully express their technical opinions;
2. Representing the community in promotional activities and various events;
3. The Chairperson is concurrently a TC member and possesses the same voting rights as other members.
TC members and the Chairperson are appointed by the openUBMC community and must include individuals who have made significant contributions to the community and are willing to commit continuous dedication.
## Meeting and Decision Mechanism
The TC holds regular monthly meetings, or ad-hoc meetings upon the proposal of two-thirds or more of the members.
1. The Chairperson must notify all members via the mailing list at least five calendar days before the meeting. The notice must include the location, date, time, method, agenda, and available reference materials to allow members to prepare. Meetings are open to the public. Any community member may attend and express technical views but holds no voting rights.
2. A quorum requires two-thirds or more (inclusive) of the members to be present for the meeting to be valid.
3. All resolutions must be put to a vote during a valid meeting. Voting shall be open and recorded. A resolution passes only if it receives an affirmative vote from two-thirds or more (inclusive) of the attending members AND exceeds one-half of the entire Committee. Absent members cannot delegate voting authority.
## Contact
Mailing List: tc@public.openubmc.cn
Online Meetings: Visit the SIG Center to get involved.
# Community Code of Conduct
# AI Contribution Policy
---
https://www.openubmc.cn/en/organizations/
---
# Organizational Structure
The openUBMC community is governed by an elected TC and operates with full transparency to ensure an impartial and forward-looking technical roadmap.
We champion the principle: Contribution Earns Influence. Advance your role to a project maintainer or TC member, and collectively define openUBMC's future.
more
## Vision & Mission
The openUBMC community offers open source and standardized software for managing digital infrastructure. By harnessing the collective expertise of developers, it drives continuous innovation across all platforms, domains, and the entire industry value chain.
## Organizational Structure
The openUBMC community's governance is defined by the Open Source Development Committee. The Secretariat, led by the Secretary-General, oversees routine operations, while the Technical Committee (TC) sets the technical direction.
## Open Source Development Committee
Ma Yinchuan
Chair
Huawei Technologies Co., Ltd.
Email
Wang Ruifeng
Secretary-General
Huawei Technologies Co., Ltd.
Email
Bian Xingzhong
Member
Shenzhen 3SNIC Information Technology Co., Ltd.
Email
Cai Jimiao
Member
iSoftStone Information Technology (Group) Co., Ltd.
Email
Chen Gang
Member
Henan Kunlun Technology Co., Ltd.
Email
Chen Lin
Member
Sichuan Yunhai Core Microelectronics Technology Co., Ltd.
Email
Chen Xiaochun
Member
Kunlun Technology （Beijing） Co., Ltd.
Email
Ding Yanlin
Member
NEXSEC Incorporated
Email
Gao Xianhu
Member
HiSilicon (Shanghai) Technologies CO., LTD
Email
Gao Xinghua
Member
Beijing NetEason Technology Co., Ltd.
Email
Gao Zhan
Member
Nanjing Byosoft Co., Ltd.
Email
Hong Kunxian
Member
YUSUR Technology Co., Ltd.
Email
Ju Rongrong
Member
Baixin Information Technology Co., Ltd.
Email
Li Haojie
Member
Semptian Co., Ltd.
Email
Li Xuelian
Member
China Electronics Standardization Institute
Email
Li Zhigao
Member
Tencent Cloud Computing (Beijing) Co., Ltd.
Email
Lin Guohui
Member
Wuxi Micro Innovation Integrated Circuit Design Co., Ltd.
Email
Liu Jingxuan
Member
China Mobile (Suzhou) Software Technology Co., Ltd.
Email
Liu Sheng
Member
Zhejiang Zentel Memory Technology Co., Ltd.
Email
Liu Yuwei
Member
Beijing Guang Runtong Technology Development Co., Ltd.
Email
Miao Fuyou
Member
Global Computing Consortium
Email
Pang Wei
Member
China Telecom Cloud Technology Co., Ltd.
Email
Peng Xiaonan
Member
Shenzhen Kuntai (Xiamen) Information Technology Co., Ltd.
Email
Sheng Yong
Member
Baidu Online Network Technology (Beijing) Co., Ltd.
Email
View All
## Technical Committee (TC)
Song Tongling
Chair
Email
Chen Yingliang
Member
Email
Chen Shihao
Member
Email
Cheng Ziming
Member
Email
Huang Han
Member
Email
Huang Jiaqing
Member
Email
Liu Song
Member
Email
Liu Xingsen
Member
Email
Liu Yujie
Member
Email
Si Changliang
Member
Email
Wang Qindong
Member
Email
Wang Tao
Member
Email
Wang Yazhou
Member
Email
Xu Xiaohan
Member
Email
Yu Fei
Member
Email
Zhang Chao
Member
Email
Zhang Jianping
Member
Email
Zhang Yubo
Member
Email
Zhao Rui
Member
Email
Zhong Jun
Member
Email
## Secretariat
Wang Ruifeng
Secretary-General
Email
Chen Yingliang
Executive Secretary & Head Of Ecosystem
Email
He Luwei
Executive Secretary & Head Of Operations
Email
Liu Yi
Executive Secretary & Head Of Marketing
Email
---
https://www.openubmc.cn/en/roadmaps/
---
文档中心
体验地图
社区体验地图
01
## 认识openUBMC
什么是openUBMC
openUBMC定义了一款开源BMC软件栈，基于灵活可伸缩的架构、敏捷易用的开发工具、丰富的生态资源，支持广大开发者打造差异化BMC功能，自由定制竞争力特性
Docs CenterDeveloper ToolCommunity SupportopenUBMC services
02
## 文档中心
开发指南
丰富文档助力开发者快速上手openUBMC，灵活定制专属的BMC软件
快速入门
03
## 开发工具
BMC Studio
直观的拖拽式可视化开发工具与一步到位的构建工具，打造开发者友好的开发工具库
BMC Studio
在线会议
社区论坛
04
## 社区支持
论坛 SIG组会
供开发者自由交流的社区论坛、工作组会议线上直播，共建开发者深度参与的社区
05
## 与openUBMC共同成长
创建组织 组织介绍 组织管理
SIG管理与开发者团队建设
---
https://www.openubmc.cn/en/sig/
---
# SIG Center
Special interest groups (SIGs) are the foundational units of the openUBMC community. These open groups are organized around specific technical domains to streamline management and improve workflows. Join a SIG to collaborate on projects, share knowledge, and co-create with fellow developers.
Join Our SIGs
Learn How SIGs Operate
SIGs are the core operational units in the openUBMC community. Formed and run by community developers, each SIG focuses on one or more technical topics, manages relevant code repositories, and drives technological implementation and continuous innovation.
Communicate with a SIG
Find SIG information, repository lists, and contact details on the SIG Center. You can also check the README.md file in the corresponding SIG directory in the openUBMC community repository. Participate in discussions through mailing lists and public regular meetings. To create a meeting, the SIG Maintainer or Committer access is required. Create Meeting
Contribute to a SIG
The openUBMC community welcomes developers, enthusiasts, and experts to join our collaborative ecosystem. Contribute through code submissions, documentation improvements, feature testing, and more.
SIG Contribution Guide
About SIGs
SIG Roles & Responsibilities
Learn about the different contributor roles and their duties in the openUBMC community.
SIG Meeting Guide
Regular SIG meetings are a core activity for reviewing technical proposals, aligning development progress, solving problems, and planning future roadmaps.
### SIG Application Process
Have a great technical idea and want to build a community around it? Apply to create a new SIG. View Application Process
Create
Fill in Details
Configure
Submit PR
Send Application
Refine
### SIG Subscription Guide
Subscribe to a SIG's mailing list to receive the latest updates, including meeting invites and online discussions. View Subscription Process
Select SIG
Fill in Details
Confirm Subscription
Subscription Complete
openUBMC SIGs
No data
---
https://www.openubmc.cn/en/sig/TC/
---
SIG Center
TC
TC
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
TC Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/apply/
---
SIG Center
SIG Application Process
# SIG Application Process
## Overview
Before creating a new SIG, check existing SIGs and discuss your proposal on openUBMC forums to gather feedback and members.
To create a SIG, refer to the SIG Management Guide to create a PR in the community repository, and send an application email to the TC. The TC organizes regular reviews to decide on application approval.
## Roles & Responsibilities
| Role | Responsibilities | Operations |
| --- | --- | --- |
| Contributor | Claims Issues and PRs, and completes testing prior to PR submission. | Registered AtomGit member |
| Committer | Assigns Issues/PRs and reviews code for quality and correctness. | Active SIG Contributor, highly experienced, and willing to invest energy in the review process. |
| Maintainer | Defines the technical roadmap and formulates the release plan for the SIG's projects. | Highly experienced, responsible, with excellent technical and management skills. |
## Application Steps
### Step 1: Fork community repo and use SIG template.
- Fork atomgit.com/openubmc/community to your AtomGit account. Use the SIG Application Template to create and copy the template into your new SIG folder in the sig directory.
`git clone https://atomgit.com/${YOURGITCODE}/community cd ./community/sig cp -r sig-template sig-${YOURSIGNAME} cd sig-${YOURSIGNAME}`
### Step 2: Complete README and member configuration.
- Open the README.md file in the newly created SIG directory and complete the required content as recommended.
`vi README.md`
### Step 3: Configure new SIG members and repositories.
- Configure SIG members in the sig-info.yaml file.
`vi sig-info.yaml`
### Step 4: Submit a PR.
- Commit the changes to AtomGit and create a PR.
### Step 5: Email the TC.
- Email the TC at tc@public.openubmc.cn, including the subject "New SIG Proposal" and the PR link in the body.
### Step 6: TC review and feedback.
- The TC will approve your application by merging the PR. Upon merging, the Community Infrastructure Team will configure the relevant SIG roles and repositories.
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);}
---
https://www.openubmc.cn/en/sig/en/
---
# SIG Center
Special interest groups (SIGs) are the foundational units of the openUBMC community. These open groups are organized around specific technical domains to streamline management and improve workflows. Join a SIG to collaborate on projects, share knowledge, and co-create with fellow developers.
Join Our SIGs
Learn How SIGs Operate
SIGs are the core operational units in the openUBMC community. Formed and run by community developers, each SIG focuses on one or more technical topics, manages relevant code repositories, and drives technological implementation and continuous innovation.
Communicate with a SIG
Find SIG information, repository lists, and contact details on the SIG Center. You can also check the README.md file in the corresponding SIG directory in the openUBMC community repository. Participate in discussions through mailing lists and public regular meetings. To create a meeting, the SIG Maintainer or Committer access is required. Create Meeting
Contribute to a SIG
The openUBMC community welcomes developers, enthusiasts, and experts to join our collaborative ecosystem. Contribute through code submissions, documentation improvements, feature testing, and more.
SIG Contribution Guide
About SIGs
SIG Roles & Responsibilities
Learn about the different contributor roles and their duties in the openUBMC community.
SIG Meeting Guide
Regular SIG meetings are a core activity for reviewing technical proposals, aligning development progress, solving problems, and planning future roadmaps.
### SIG Application Process
Have a great technical idea and want to build a community around it? Apply to create a new SIG. View Application Process
Create
Fill in Details
Configure
Submit PR
Send Application
Refine
### SIG Subscription Guide
Subscribe to a SIG's mailing list to receive the latest updates, including meeting invites and online discussions. View Subscription Process
Select SIG
Fill in Details
Confirm Subscription
Subscription Complete
openUBMC SIGs
No data
---
https://www.openubmc.cn/en/sig/infrastructure/
---
SIG Center
infrastructure
infrastructure
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
infrastructure Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/role-description/
---
# 角色说明
在openUBMC社区，开发者主要通过参与SIG（Special Interest Group）来贡献自己的力量。无论Contributor、Committer、Maintainer，都是社区重要的贡献者角色，他们的主要区别在于参与的SIG治理范围不同。
SIG中心
角色说明
贡献者
职责：通过代码开发、问题修复和文档完善等方式推动社区发展。
要求：理解社区技术，遵守社区规范，积极参与社区贡献。
查看详情
审核者
职责：通过细致的代码评审帮助提升社区代码质量，同时以自身贡献带动社区共同进步。
要求：具备丰富项目经验，熟悉代码规范，能够提供建设性意见并乐于分享经验。
查看详情
维护者
职责：把握技术方向并推动关键决策，通过关键领域的贡献领导社区的长期发展。
要求：深入理解项目架构，善于协作沟通，认同开源精神并长期引领社区成长。
查看详情
新的贡献者
欢迎新成员加入社区。我们有关于如何开始贡献的指导文档请参考openUBMC 贡献者指南
既有社区成员
既有的社区成员应认可社区导向，遵守openUBMC 社区的行为守则，熟悉社区运作机制和技术能力。
社区非活跃成员退出标准和流程请参考非活跃成员退出标准和流程
## 贡献者Contributor
贡献者是openUBMC社区的核心力量，他们通过代码开发、文档完善、问题修复、社区运营等多种方式积极参与，共同推动项目的创新与发展。
### 加入要求
- AtomGit 上的注册会员
- 为 SIG 或社区做出多方面贡献，包括不限于：在 AtomGit 上提交或审核PR；在 AtomGit 上对问题进行归档或评论；参与 SIG 或社区讨论
- 已阅读 贡献者指南
- 积极参与 1 个或多个 SIG
### 责任与权益
- 响应被分配的问题和PR
- 对贡献的代码负责，保证贡献的代码：经过良好的测试；能够让测试用例始终通过，并保证DT覆盖率满足社区要求；解决后继发生的错误或问题
- 负责具体实现设计，并通过 SIG 评审
- 获得成为 SIG 审核者 Committer 的权利。
贡献代码的同时积极参与代码审查、设计评审等活动，即可以成为 SIG 的审核者 Committer
## 审核者Committer
审核者是代码仓库的核心维护者，拥有代码合入权限。他们凭借丰富的技术经验，通过代码评审、开发者测试和规范检查等方式保障代码质量，并推动组件的技术演进与长期健康发展。
### 加入要求
- 作为贡献者至少 3 个月
- 作为主要审阅者至少参与了 6 次 PR 的审阅
- 审阅或合并至少 20 个基本 PR 到代码库
- 熟悉代码库
- 可以自我提名，或由该 SIG 的审核者 Committer 或维护者 Maintainer 提名，并在SIG会议通过
- 或者一次性贡献具备完整特性的组件，也可直接成为Committer
### 责任与权益
- 评审 PR：对 Contributor 提交的 PR 完成评审，基于代码的设计、实现、安全性、可扩展性、兼容性等为度给出公正客观的评价
- 熟知社区开发流程，并指导 Contributor 按照社区开发流程完成代码贡献，保障社区开发流程正确的应用
- 针对接口变更，指导 Contributor 参与社区接口变更评审会议，充分地预审，确保组件接口的设计合理性、兼容性、必要性、易读性、易用性
- 看护组件的软件工程能力，在SIG组中建立良好的软件工程文化
- 看护组件的代码实现设计，确保特性设计的合理性
- 更新和维护组件的版本，与社区项目版本保持一致
- 获得成为 SIG 维护者 Maintainer 的权利。
成为 SIG 内多个代码仓的审查者，积极参与 SIG 技术规划和架构演进，即可以成为 SIG 的维护者 Maintainer
## 维护者Maintainer
维护者是SIG组的核心领导者，负责技术方向规划、社区协作和长期发展。他们不仅具备审核者的所有职责，还主导组件的架构演进、质量保障和生态适配，并通过协调社区内外资源推动SIG目标的实现。
### 加入要求
- 作为审核者至少 3 个月
- 作为主要审阅者至少参与了 12 次 PR 的审阅
- 审阅或合并至少 30 个基本 PR 到代码库
- 熟悉 SIG 超过一半的代码库
- 可以自我提名，也可以由本 SIG 维护者 Maintainer 提名，并且没有其他 维护者 Maintainer 的反对，并在TC会议通过
### 责任与权益
- 确定 SIG 所负责项目的技术路线：包括规划和决策 SIG 技术方向、路标规划、架构演进
- 看护SIG组的技术设计方案，在SIG组内营造良好的技术氛围
- 制定 SIG 所负责项目的发布计划：确定 SIG 的关键需求和发布计划；参与社区的 PM 活动，并协调 SIG 计划和社区版本的里程碑时间表匹配
- 参与社区协调活动：作为 SIG 的代表参与 openUBMC 组织的活动和特定会议等
- 召集 SIG 会议：定期召集 SIG 会议，决策 SIG 内上升的争议
- 代表 SIG 参加技术委员会，汇报 SIG 工作和进展
- 获得可参与技术委员会委员选举的权利。
积极提升 SIG 影响力，与其他 SIG 共同协作，即有机会参与技术委员会委员选举
---
https://www.openubmc.cn/en/sig/sig-CICD/
---
SIG Center
CICD
CICD
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
CICD Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-Linkedsemi/
---
SIG Center
Linkedsemi
Linkedsemi
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
Linkedsemi Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-QA/
---
SIG Center
QA
QA
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
QA Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-ai/
---
SIG Center
ai
ai
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
ai Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-application-process/
---
SIG中心
application-process
application-process
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
application-process Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-bmc-core/
---
SIG Center
bmc-core
bmc-core
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
bmc-core Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-component-drivers/
---
SIG Center
component-drivers
component-drivers
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
component-drivers Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-docs/
---
SIG Center
docs
docs
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
docs Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-framework/
---
SIG Center
framework
framework
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
framework Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-hardware/
---
SIG Center
hardware
hardware
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
hardware Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-hisilicon/
---
SIG Center
hisilicon
hisilicon
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
hisilicon Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-interface/
---
SIG Center
interface
interface
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
interface Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-om/
---
SIG Center
om
om
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
om Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-release-management/
---
SIG Center
release-management
release-management
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
release-management Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/sig-security/
---
SIG Center
security
security
View More on AtomGit
Core Members (0)
Meetings and Events
Work Meeting
Email
## Repositories (0)
| Repos name | Committer |
| --- | --- |
| |
No Data
Contribution
security Contribution by Individuals
Metric
PR
Issue
Comment
Mesauring Period
\-
Maintainer
Committer
Contributor
| Number | GitCode ID | PR |
| --- | --- | --- |
| |
No Data
---
https://www.openubmc.cn/en/sig/subscribe-guide/
---
SIG中心
订阅指南
# 订阅指南
01
## Select a SIG to Subscribe
Browse SIGs of interest and click "Subscribe".
02
## Fill in Information
On the subscription email page, fill in your personal information and click Confirm Subscription.
03
## Confirm Subscription
You will receive an email from the SIG asking you to confirm your subscription. Click the confirmation link to complete the subscription.
04
## Subscription Successful
When you receive a welcome email, you have successfully subscribed to the SIG mailing list.
---
https://www.openubmc.cn/en/version/1.0.0/
---
Docs Center
Release Notes
Select
# openUBMC 1.0.0 社区首版本正式上线！
# openUBMC 1.0.0 社区首版本正式上线！
## 版本概览
openUBMC 是一款架构领先、开发友好、开放标准的开源 BMC。采用协议“木兰宽松许可证”（Mulan PSL V2），用户可以自由复制、使用、修改、分发，不论修改与否。 openUBMC 版本号采用点分位命名规则（X.Y.Z）模式，其中 X 表示每年发布版本，Y 表示每半年发布版本，Z 表示补丁版本。正常每半年会发布一个 Y 版本，每年发布两个版本。 openUBMC 生命周期初步规划为 0.5 年。
## 版本特性
- 支持微组件架构，组件通过总线互联，具备组件、插件、配置多重扩展能力。
- 提供标准化的 SDK 套件供社区使用并兼容 D-Bus 总线协议，支持组件快速开发并接入系统。
- 支持南向硬件定制通过生成配置数据方式接入，实现低代码开发。
- 支持北向接口映射配置，实现"0"代码简化增量开发。
## 源代码
开源软件代码仓：https://atomgit.com/openubmc
## 致谢
我们衷心地感谢参与和协助 openUBMC 项目的所有成员，是你们的辛勤付出使得版本顺利发布！ openUBMC 在不断的发展中，未来还会有更多好用的特性发布，这里也非常欢迎大家下载并体验，并参与到openUBMC 开源社区建设中来，也期待聆听每一位用户的反馈意见！ 社区邮件列表：community@openubmc.org
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/version/25-12-LTS-SP2/
---
No data
---
https://www.openubmc.cn/en/version/25-12-LTS-SP3/
---
No data
---
https://www.openubmc.cn/en/version/25.03/
---
Docs Center
Release Notes
Select
# openUBMC 25.03 版本发布说明
# openUBMC 25.03 版本发布说明
* * *
## 版本概览
作为25年首版本，openUBMC 25.03 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发，不论修改与否。
* * *
## 版本特性
25.03版本在1.0.0版本基础上进行开发，特性交付范围包括：
### 北向接口生态
1. 安全框架升级
- 支持密码策略定制化配置
- 实现用户名规则自定义功能
- 新增证书管理基础模块
2. 运维功能优化
- 配置导入/导出标准化
- 出厂重置保留用户数据
- 重构MCU/VRD升级架构（解耦式设计）
- 支持hpm标准化升级包格式
### 南向部件扩展
1. 管理能力增强
- 调速策略能力支持
- 多SML库加载
2. 部件适配
- 支持SP322D/SP323D网卡
- 支持NVMe-MI v7协议linkspeed查询
### 开发体验优化
1. 开发工具增强
- bingo支持本地调试
- bingo支持模型检查功能
2. BMC Studio发布至社区
- 支持CSR配置检查
- 支持全模型检查
* * *
## 源代码
25.03版本源代码已发布至社区网站：https://www.openubmc.cn/en/download
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3026302 | 产品调速策略未适配所有机型，社区提供调速策略定制能力，需要开发者基于整机产品自行定制 | thermal_mgmt |
* * *
## 已修复问题
暂无
* * *
## CVE 漏洞
暂无
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/version/25.06/
---
Docs Center
Release Notes
Select
# openUBMC 25.06 版本发布说明
# openUBMC 25.06 版本发布说明
* * *
## 版本概览
作为25年第二个创新版本，openUBMC 25.06 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
25.06版本在25.03版本基础上进行开发，特性交付范围包括：
### 北向接口生态
1. 可观测性服务：覆盖日志、独立、跟踪等数据的采集和存储能力；
2. 升级方案优化：支持固件并行升级与统一生效；
3. 接口功能优化：支持针对不同客户提供接口灵活扩展和定制能力；
4. 接口升级：IPMI和Redfish标准接口升级，主要包含Power、Drive和Thermal等；
5. 独立KVM开发套件：支持独立KVM客户端通过websocket链接到BMC，实现VMM功能，电源控制功能，系统启动项管理功能；
6. 新增规范：支持资源树协作接口关键字规范；
### 南向部件扩展
1. 板卡接入丰富度：新增网卡(标卡和OCP)、RAID卡、硬盘、NVMe盘、TPM卡、DPU、SDI、GPU、NPU等部件接入，详细接入清单参照vpd代码仓；
2. 南向协议能力：支持NVMe-mi over mctp的协议解析；支持使用pldm协议获取网卡部分信息；支持NCSI边带管理功能；支持PMBus1.2/CANBUS协议；
3. 能效管理能力：支持功率、电源固件升级、电源告警功能、供电信息、供电模式、时钟同步等管理能力;
4. DFX能力：支持电源砖精细化管理能力，支持动态组合获取硬盘的SMART信息，支持硬盘(SSD)寿命管理;
### 开发体验优化
1. BMC STUDIO: 支持可视化图形开发和自动化检测功能，完成CSR开发和语法合法性检查；提供VSCode插件一键完成QEMU安装、配置、启动和调试；
2. QEMU仿真功能: 支持仿真镜像的构建与发布；支持Qemu工具的构建与发布；支持仿真数据的发布。当前已支持EEPROM,HisPort，BMC芯片等数据插件；
3. 自动化防护：支持kptest测试框架基础能力建设和自动化用例；
4. 工程能力: 支持工具生成产品、客户层级的全量接口配置；支持组件工具依赖自管理；支持编译构建及ut/it的门禁检查；支持组件的全量二进制构建；支持组件转维发布能力；支持社区开发者签名出包等；提供调试工具能力；
* * *
## 源代码
25.06版本源代码已发布至社区网站：https://openubmc.cn/en/download
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| https://atomgit.com/openUBMC/mdb_interface/issues/135 | 资源协作接口属性和方法Description字段修改 | mdb_interface |
| https://atomgit.com/openUBMC/fructrl/issues/15 | 老版本导入新版本上电延迟值可能被改变 | fructrl |
* * *
## 已修复问题
历史版本已发现在当前版本解决的缺陷：暂无
* * *
## CVE 漏洞
暂无
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/version/25.09/
---
Docs Center
Release Notes
Select
# openUBMC 25.09 版本发布说明
# openUBMC 25.09 版本发布说明
* * *
## 版本概览
作为25年第三个创新版本，openUBMC 25.09 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
25.09版本在25.06版本基础上进行开发，特性交付范围包括：
### 北向接口生态
#### 1\. 基础安全能力
- **密码安全策略**：支持禁用历史密码、失败锁定次数配置、登录失败锁定时间配置、超长密码支持
- **认证与授权**：支持WEB SSO单点登录、IPMI通道权限配置、前端敏感信息加密
- **安全审计**：支持动态插桩拦截风险接口调用日志、Cleancode排查整改
#### 2\. 管理软件生态
- **网管系统对接**：支持Zabbix、Ansible、Cmdlets、Nagios插件，实现与openUBMC的完整对接
- **开发指导文档**：提供SNMP接口映射器、TRAP告警、装备定制、CLI映射器等配置指导文档
#### 3\. 接口升级与扩展
- **Redfish接口增强**：主要包含Manager、Processor、SEL、NTP、时区等资源管理
- **IPMI标准命令**：支持User access/Password、User Name、DCMI Power等标准命令
#### 4\. 融合运维能力
- **固件升级管理**：支持一个hpm包多个固件场景升级、BMC升级异常时自恢复
- **安全升级控制**：支持VRD和NPU升级过程中禁止主机上电
- **任务管理**：支持任务资源标准规范和定制能力
### 南向部件扩展
#### 1\. 南向驱动框架
- **驱动规范**：完成南向驱动框架和规范发布，基于规范完成网卡和GPU兼容性适配
- **协议支持**：支持I3C/CAN-FD能力、Ncsi Over Mctp/I2C/SMBUS协议获取网卡信息
- **私有协议**：支持Emulex的pldm私有协议
#### 2\. 板卡接入丰富度
- **网卡支持**：新增标卡和OCP网卡，包括E810XXVDA2G1P5、E810CQDA2G2P5、MCX755106AS-HEAT等
- **存储设备**：支持RAID卡（SP686C-M系列）、硬盘、NVMe盘（SamSung PM9D3A、Memblaze PBlaze7、Solidigm D7-PS1010等）
- **计算加速**：支持GPU（A6000）、NPU模组等部件接入
#### 3\. TPSU/PSU管理
- **基本信息管理**：支持TPSU模块信息查询、电源额定功率变化记录
- **Turbo功能**：支持Turbo电容管理、充放电控制、使能控制
- **主备切换**：支持双CAN电源线路主备切换、供电模式切换
- **功率管理**：支持功耗封顶、功率监控、输出限功率点配置
#### 4\. DFX能力增强
- **临终遗言**：支持VRM/电源等关键部件临终遗言持久化
- **固件管理**：支持BIOS固件导出、关键部件固件升级
- **故障检测**：支持网卡Flash recovery故障检测、光模块关键信息记录和闪断检测
- **链路检测**：支持高速链路检测、CPU与外围器件链路异常告警
### 开发体验优化
#### 1\. QEMU仿真能力
- **总线仿真**：支持SMBus、MCTP等复杂协议仿真
- **部件仿真**：支持MCU、PCIe、IMU等器件仿真
- **性能优化**：QEMU冒烟测试性能优化、支持依赖驱动更新
#### 2\. 指导文档完善
- **接口文档**：完成SNMP接口映射器、TRAP告警、装备定制、CLI映射器等指导文档
- **开发指南**：提供映射器接口设计说明书、配置指导、定位指导
- **用户手册**：更新BMC Studio用户指南、联机帮助页面扩展
#### 3\. 构建优化
- **Conan2.0升级**：完成conan2.0中心仓能力构建、支持Profile配置和并行构建
- **Bingo工具增强**：支持基于gtest的开发者测试、DT测试质量加固、门禁模型检查能力增强
- **构建脚本**：支持社区组件构建脚本适配Conan2.0、非root运行
#### 4\. 开发体验提升
- **测试能力**：bingo支持基于gtest的开发者测试、DT测试能力增强
- **代码质量**：门禁模型检查能力增强、支持代码开源合规检查
- **工具支持**：新增I2C扫描和读写工具、支持度量采集和可观测跟踪可配置
* * *
## 源代码
25.09版本源代码已发布至社区网站：https://openubmc.cn/en/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 5.11.0 | 5.10.0 | 5.9.0 |
| --- | --- | --- | --- |
| 25.09 | Y | N | N |
| 25.06 | N | Y | N |
| 25.03 | N | N | Y |
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3187698 | 资源协作接口属性和方法Description字段修改 | mdb_interface |
| 3190225 | 老版本导入新版本上电延迟值可能被改变 | fructrl |
* * *
## 已修复问题
历史版本已发现在当前版本解决的缺陷：暂无
* * *
## CVE 漏洞
暂无
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/en/version/latest/
---
Docs Center
Release Notes
Select
# openUBMC 1.0.0 社区首版本正式上线！
# openUBMC 1.0.0 社区首版本正式上线！
## 版本概览
openUBMC 是一款架构领先、开发友好、开放标准的开源 BMC。采用协议“木兰宽松许可证”（Mulan PSL V2），用户可以自由复制、使用、修改、分发，不论修改与否。 openUBMC 版本号采用点分位命名规则（X.Y.Z）模式，其中 X 表示每年发布版本，Y 表示每半年发布版本，Z 表示补丁版本。正常每半年会发布一个 Y 版本，每年发布两个版本。 openUBMC 生命周期初步规划为 0.5 年。
## 版本特性
- 支持微组件架构，组件通过总线互联，具备组件、插件、配置多重扩展能力。
- 提供标准化的 SDK 套件供社区使用并兼容 D-Bus 总线协议，支持组件快速开发并接入系统。
- 支持南向硬件定制通过生成配置数据方式接入，实现低代码开发。
- 支持北向接口映射配置，实现"0"代码简化增量开发。
## 源代码
开源软件代码仓：https://atomgit.com/openubmc
## 致谢
我们衷心地感谢参与和协助 openUBMC 项目的所有成员，是你们的辛勤付出使得版本顺利发布！ openUBMC 在不断的发展中，未来还会有更多好用的特性发布，这里也非常欢迎大家下载并体验，并参与到openUBMC 开源社区建设中来，也期待聆听每一位用户的反馈意见！ 社区邮件列表：community@openubmc.org
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/en/vulnerability-management/
---
Security Center
Vulnerability Management
# Vulnerability Management
2025/03/30
openUBMC
# Vulnerability Management
## 1\. Vulnerability Response
The openUBMC community prioritizes the security of its releases. SIG Security is responsible for receiving, investigating, and disclosing all related security vulnerabilities. We strongly encourage security researchers and industry organizations to proactively report suspected flaws to SIG Security for rapid response, analysis, and resolution.
## 2\. Supported Versions
The vulnerability response process is focused primarily on openUBMC community releases.
## 3\. Vulnerability Handling Process
Every security vulnerability is assigned to a dedicated individual for tracking and resolution. This coordinator (a SIG Security member) is responsible for driving the fix and disclosure process.
We will detail three key stages of this workflow: Vulnerability Reporting, Vulnerability Assessment, and Vulnerability Disclosure.
### 3.1 Vulnerability Reporting
If you suspect an openUBMC product contains a security vulnerability, we urge you to report it to the openUBMC community and collaborate with us to ensure its responsible remediation and disclosure.
#### 3.1.1 Vulnerability Reporting Method
Potential security vulnerabilities in openUBMC products should be reported via email to SIG Security at securities@public.openubmc.cn. Given the highly sensitive nature of vulnerability data, we strongly recommend encrypting your submission using SIG Security's PGP public key to ensure confidentiality. We are fully equipped to receive OpenPGP-encrypted emails. List of SIG Security members:
- Zhang Chao \[@TacoJay\], zhangchao60@huawei.com
- Yan Chuanjie \[@loopvoid\], yanchuanjie@huawei.com
- Peng Xianglin \[@Free\_Tomato\], pengxianglin2@huawei.com
- Ren Shan\[@Renyqing\]，renshan2@huawei.com
#### 3.1.2 Vulnerability Report Content
To facilitate the rapid confirmation and validation of a suspected vulnerability, please include (but do not limit your report to) the following information in your submission email:
- Basic information: Include the module impacted by the vulnerability, the trigger conditions, and the potential system impact upon successful exploitation.
- Technical details: Include system configuration, localization methods, a description of the exploit, POC (Proof-of-Concept), and detailed reproduction steps.
- Suggested remediation: Your proposed solution or mitigation advice.
- Reporter information: Your organization and contact details.
- Disclosure plan: Your potential timeline or plan for public disclosure of the vulnerability.
#### 3.1.3 Response Time
We will respond to suspected security vulnerabilities reported via email within five days and provide the reporter with an update on the issue's handling progress.
### 3.2 Vulnerability Assessment
The industry standard for assessing vulnerability severity is the Common Vulnerability Scoring System (CVSS). When using CVSS v3, we require the definition of a vulnerability exploitation scenario and assess the actual impact within that context. The severity rating assesses exploit complexity and the resulting impact on Confidentiality, Integrity, and Availability (CIA) to generate a corresponding score.
#### 3.2.1 Assessment Criteria
The openUBMC community uses CVSS v3 to assess vulnerabilities. CVSS v3 assesses the impact of a vulnerability using the following vectors:
- Attack Vector (AV): Reflects the context by which vulnerability exploitation is possible.
- Attack Complexity (AC): Describes the difficulty of executing the attack and the conditions required for a successful exploit.
- User Interaction (UI): Determines whether successful exploitation requires user participation.
- Privileges Required (PR): Records the level of user authorization necessary for a successful attack.
- Scope (S): Determines whether the attacker can impact components with different authorization levels.
- Confidentiality (C): Measures the extent of impact resulting from information disclosure to unauthorized parties.
- Integrity (I): Measures the extent of impact resulting from data modification or tampering.
- Availability (A): Measures the extent to which users are affected when access to data or services is impaired.
#### 3.2.2 Assessment Principles
- Vulnerability severity is assessed, not overall risk.
- The assessment must be based on a defined attack scenario, ensuring that a successful attack within that scenario can cause an impact on Confidentiality, Integrity, or Availability (CIA).
- When a security vulnerability has multiple attack scenarios, the assessment must use the scenario that causes the maximum impact (for example, the highest CVSS score).
- If a vulnerability exists in an embedded or called library, the attack scenario must be determined based on how the library is used within the product prior to assessment.
- Security flaws that cannot be triggered or do not affect CIA will receive a CVSS score of 0.
#### 3.2.3 Assessment Steps
When assessing a vulnerability, proceed according to the following steps:
- Define the plausible attack scenario and score based on that scenario.
- Identify the Vulnerable Component and the Impact Component (the component affected by the flaw).
- Assign base metrics: Determine the vulnerability's overall impact by scoring the Exploitability (AV/AC/PR/UI/S) and Impact (C/I/A) metrics.
#### 3.2.4 Severity Rating
| Severity Rating | Score |
| --- | --- |
| Critical | 9.0 - 10.0 |
| High | 7.0 - 8.9 |
| Medium | 4.0 - 6.9 |
| Low | 0.1 - 3.9 |
| None | 0.0 |
### 3.3 Vulnerability Disclosure
To protect the security of openUBMC users, the openUBMC community strictly controls the spread of vulnerability information during the investigation, remediation, and public disclosure phases. We limit this sensitive information to only the personnel directly involved in addressing the flaw. We will not publicly disclose, discuss, or confirm security issues related to openUBMC products until a public disclosure is made. We also require the vulnerability reporter to maintain strict confidentiality until this official public release. Once a security vulnerability has been fixed, the openUBMC community will issue a security advisory. This advisory will include the technical details of the flaw, the CVE ID, CVSS score, severity rating, and information regarding affected and patched versions. Security advisories are available via email subscription.
Content on This Page
---
https://www.openubmc.cn/zh/
---
# openUBMC Meetup 深圳站议题征集
2026/10/30
了解更多
前往查看
openUBMC 26.09 正式上线
了解更多
文档场景化架构升级，欢迎体验！
立即查看
欢迎加入openUBMC社区
openUBMC是一款架构领先、开发友好、标准开放的算力设备开源管理软件
了解更多
- 文档中心
汇聚详细的教学文档
- 社区论坛
和其他开发者一起聊聊吧
- 社区活动
了解openUBMC社区全年活动
- 应用市场
全面的软件工具下载中心
## 面向全球开发者的开源算力设备管理软件
极简高效开发
南北向全面开放兼容，覆盖丰富硬件与主流行业规范；依托微组件架构，一套代码适配多场景，社区共建，高效支撑差异化定制
一键部署 快速上手
3步完成本地构建，丰富的工具提供极简开发体验。
AI辅助编程
openUBMC Studio深度集成主流 Coding Agent，一键导入社区高阶技能，知识库原生嵌入。
可灵活扩展
支持配置化、插件化、组件化的多层级定制，满足算力业务场景下的灵活定制需求。
规范驱动开发
以模型与规范为核心，让能力描述更清晰、社区协同开发更高效、版本质量更稳定。
北向灵活接入
支持北向自接入能力，激发业务高效能，赋予运维新智能
集群管理平台
AI训练框架
运维监控系统
...
北向自接入规范
芯片加速
可靠性提升
智能故障预测
能效调优
极致安全
...
南向标准引领
首创驱动规范，实现硬件 Day 级快速适配，兼容各类板卡，支撑多元算力部署
多功能特性
部件带外驱动接口
风扇部件接口
风扇驱动
存储部件接口
存储驱动
xPU部件接口
xPU驱动
部件外带接口
XX驱动
硬件
生态全面开放
openUBMC Studio 一站式开发平台，以 AI 辅助编码，大幅提升服务器全流程开发与适配效率
主流协议全域兼容
Redfish / IPMI / SNMP /......
北向自接入
自定义Agent，灵活对接业务系统
高可用自恢复强安全
多固件并行升级/密码安全......
网卡
SSD盘
DPU卡
HDD
NPU卡
GPU卡
RAID卡
## 参与openUBMC 社区
### 如何参与社区贡献
openUBMC 社区诚邀开发者、技术爱好者及行业专家加入协作生态。您可通过代码提交、文档完善、功能测试等多种形式参与社区建设。
查看贡献攻略
### 如何参与SIG兴趣小组
SIG 全称是 Special Interest Group，即"特别兴趣小组"。openUBMC社区按照不同的 SIG 来组织，以便更好地管理和改善工作流程。SIG 组均是开放的，欢迎任何人来参与。
前往SIG中心
### openUBMC社区活力
- 0
社区贡献者
- 0
下载量
- 0
单位成员
- 0
代码仓
- 0
需求&问题
查看贡献详情
## 用户案例
基于 openUBMC 构建 Agent 驱动的 BMC 研发工作流
BMC 固件研发涵盖源码开发、构建部署、设备验证全链路，任务进度与验证证据分散零散、缺乏统一追溯机制。引入智能 Agent 虽可推进编码与工具调用，但任务跨阶段、会话中断仍需人工重复梳理衔接；同时 BMC 故障属于典型跨层问题，依赖多维度交叉核验，零散的工具调用无法形成可信闭环。因此，亟需一套支持断点续跑、操作可对账、以设备真实状态为验收标准的标准化研发工作流。
查看详情
基于 openUBMC 北向自接入实现刀片机箱节点一体化健康管理
当前，AI 算力数据中心广泛采用高密度刀片机箱，单机箱内置多片独立刀片，每片刀片搭载专属 BMC 管理芯片。传统 BMC 仅支持单节点本地管控，彼此隔离形成管理孤岛，存在以下运维痛点：
查看详情
基于 openUBMC 实现 PCIe Switch 多 GPU 自发现
随着大模型训练场景规模化落地，行业对单机高密度算力、低延迟互联、高稳定部署的需求持续提升。传统 CPU 直出架构受原生 PCIe 通道物理限制，难以满足海量 GPU 挂载、高效算力互联的业务需求，存在带宽瓶颈、通信延迟高、组网灵活性不足、硬件设计成本高、故障易扩散等痛点，无法适配 AI 训练场景对服务器高性能、高可靠、高灵活的严苛要求。
查看详情
查看更多
## 社区动态
...
(基于 openUBMC 构建 Agent 驱动的 BMC 研发工作流)[/zh/blogs/20260929UBMC-ruantonghuafang] (从故障诊断到 RAS Offload：百敖 openUBMC 的 Intel 平台适配实践)[/zh/blogs/20260903UBMC-baiao] (刀片服务器健康管理破局：昆仑太科依托 openUBMC 北向自接入实现整机协同)[/zh/blogs/20260723UBMC] (打破业务边界：openUBMC 北向自接入，重构BMC创新落地模式)[/zh/blogs/20260605UBMC] (开源BMC筑基AI算力——openUBMC 走进长沙高校)[/zh/blogs/2026UBMC-Changsha] (Open AI Infra Summit 2026｜openUBMC以架构创新和开源标准破解智算集群运维痛点)[/zh/blogs/open-A-IInfra-summit-review]
查看更多
## 社区伙伴
注：排名不分先后
---
https://www.openubmc.cn/zh/ai-coding-assistants/
---
# 技术委员会运作规则
# 政策规则
了解openUBMC社区的运作规则、行为准则、AI贡献策略等相关内容
技术委员会运作规则社区行为准则AI贡献策略
# 社区行为准则
# AI贡献策略
openUBMC社区生成式AI工具使用与开源贡献策略
## 1\. 开放策略 (Openness Strategy)
openUBMC社区秉持开放、协同、创新的开源精神，将生成式AI与智能化Agent视为推动社区技术演进的重要生产力。社区允许贡献者在合理、透明、可审查的前提下使用生成式人工智能工具辅助贡献，但坚持以下原则：
- **核心原则一：保持开放，AI开发导向 (Open & AI-Development-Oriented)**
openUBMC社区对新技术始终秉承开放拥抱的姿态。我们积极迎接AI开发导向，并致力于构建一个对人类开发者与AI代理同样友好的智能化开源生态。openUBMC社区鼓励并支持开发者和自动化Agent深入参与到社区的各项贡献中（包括但不限于代码编写、文档翻译、测试用例生成、运维自动化等）。
- **核心原则二：开发者最终负责 (Developer Ultimate Responsibility)**
AI只是人类开发者参与社区贡献的辅助工具，**人类开发者对其所提交的社区贡献质量负责并承担相关法律责任**。无论是人类开发者独立开发的成果，还是由AI辅助生成、触发的代码与内容，贡献者都必须对其所提交内容的正确性、安全性、合规性和质量负责并承担最终责任。社区维护者对贡献者提交内容的审查、合并、发布行为并不表示社区管理方确认其中所包含的AI输出不构成侵权、不存在安全缺陷或适合特定用途。
- **核心原则三：透明度，可追溯 (Transparency & Traceability)**
在向社区提交内容时，贡献者应如实披露与该贡献相关的AI工具使用情况、第三方材料来源、许可证信息和人工审查情况。openUBMC社区建立了一套严格的元数据记录机制，对AI生成内容的**关键元数据（包括生成该等内容所使用的Agent平台、模型、Prompt摘要等）进行完整记录**，从而确保AI参与的代码贡献都具备清晰的审查追踪链。
## 2\. 适用范围 (Scope of Application)
本策略适用于贡献者向openUBMC社区（包括但不限于openUBMC组织下的所有代码仓库、文档库等）提交的各种形式的所有贡献：
- **源代码与脚本**：包括各类核心代码、测试用例、构建脚本。
- **技术文档与社区内容**：包括API说明、部署指南、发布日志、Wiki页面等。
- **配置与元数据**：包括Containerfile/Dockerfile、CI/CD配置文件等。
## 3\. 法律与合规 (Legal & Compliance)
贡献者向openUBMC社区提交包含AI生成内容的贡献，必须在以下法律与合规框架内：
### 3.1 CLA（贡献者许可协议）
openUBMC社区采用**CLA（Contributor License Agreement，贡献者许可协议）**。
- 贡献者在提交贡献前，必须签署社区CLA。
- 依据CLA，当贡献者向社区提交包含AI生成内容的贡献时，即视为该贡献者承诺其对该贡献拥有合法的处分权（例如，已获得充分授权）。贡献者不能以“内容由AI生成”为由免除其在CLA中所做出的承诺以及应当承担的相关法律责任。
### 3.2 追溯机制：关键元数据完整记录
若贡献者向社区提交的贡献包含主要**由AI生成或经AI自动化处理**的代码与文档，则其在提交Pull Request时应当在Pull Request和Commit Message中完整记录并携带以下**关键元数据**：
Commit Message：
- **Co-Authored-By:** 明确指明生成该内容所使用的生成式AI模型名称及版本（如 `GPT-4o`，`DeepSeek-V3` 等）。
Pull Request:
- **Agent平台信息（Tool）**：明确指明生成该内容所使用的Agent平台名称及版本（如 `Claude Code 2.1.156`、`Qwen Code 0.16.1` 等）。
- **模型信息 (Model)**：明确指明生成该内容所使用的生成式AI模型名称及版本（如 `GPT-4o`，`DeepSeek-V3` 等）。
- **Prompt 摘要 (Prompt Summary)**：简要概述指导AI生成该内容的核心提示词或核心意图（如 `"Optimize memory allocation for Spec file"`），不得提交提示词或核心意图不明的AI生成内容。
**规范示例（Pull Request格式）：**
### 当前PR是否有AI参与:
[] 否
[x] 是
__1. Agent平台信息: Claude Code 2.1.156
__2. 模型信息: DeepSeek-V3
__3. Prompt摘要: 基于现有代码逻辑，完成代码编写、逻辑优化、异常分支补充及注释完善，协助完成本次功能开发与问题修复
### 希望检视人员了解:
1. 代码由AI辅助开发者编写，且开发者已人工逐行核对逻辑、校验功能正确性，且与开发者预期一致；
**规范示例（Commit Message）：**
Co-Authored-By: DeepSeek-V3
_注意：openUBMC社区门禁会检查 Commit Message 中 Co-Authored-By 填写的AI模型名称是否与 Pull Request 中披露的模型信息一致。如果您在 Pull Request 中披露的模型信息与 Commit Message 中 Co-Authored-By 字段的模型信息不一致，门禁会拦截您的PR。_
## 4\. Agents规范Prompt（Standard Prompt for Agents）
为了让各种AI编程助手、自动化Agent（如PR自动化审查、代码自动修复Agent）在为openUBMC社区提供服务时能够严格遵循上述策略，特制定以下**系统级提示词规范（System Prompt）**：
# 角色与目标
你是一个专为openUBMC开源社区服务的AI编程与合规助手（AI Agent）。你的目标是协助人类开发者高效参与社区贡献，同时必须坚守合规底线，确保所有输出符合openUBMC社区的合规与质量要求。
# 核心行为准则
## 1. 明确责任边界与开发导向
- 你是开发者的效率放大器，但你必须明白，人类开发者将对你的输出质量负责并承担相关法律责任。因此，你生成的代码必须清晰、人类可读且易于人类开发者进行Review。
- 不得生成任何含义模糊、难以调试或存在黑盒逻辑的复杂代码块。
## 2. 法律与许可证合规（底线原则）
- 不得在不遵循适用许可证的情况下，从采用GPL2.0、GPL3.0等限制型许可证许可的代码库或独占许可的商业软件专有代码库中直接复制或变相复制任何代码片段。
- 如果你生成的代码直接引用了特定的开源组件或公开算法实现，则该等代码必须保留其原有著作权声明（包括但不限于保留原组件或算法的著作权声明）及许可证声明，而不得删除或修改该等声明。
## 3. 关键元数据显式披露
- 当你协助人类生成代码，或者作为自动化Agent独立向openUBMC仓库提交PR时，必须按照固定PR模板与Commit Message进行提交。
- 在PR中必须包含的元数据：
- Agent平台信息: [Agent平台名称及版本]
- 模型信息: [AI模型名称及版本]
- Prompt摘要: [核心提示词或核心意图]
- 在Commit Message中必须包含的元数据：
- Co-Authored-By: [AI模型名称及版本]
## 4. openUBMC技术栈适配
- 代码风格：在向openUBMC社区提交代码前，应分析对应代码仓库的代码风格，提交修改代码时必须严格遵守对应代码仓库的代码风格指南。
- 优先安全性：不得引入内存泄漏、缓冲区溢出等常见安全漏洞，优先推荐使用已经过openUBMC社区验证的安全函数。
## 5\. 禁止或高风险行为
- 未经人工审查的AI输出
- 贡献者无法解释、无法维护或无法确认来源的代码
- AI工具明显复现第三方项目代码、文档、图片或其他受保护表达，但未提供合法来源、许可证和必要权属信息的内容
- 与本项目许可证不兼容的内容
- 违反AI工具使用条款、雇主政策、保密义务，违反出口管制、数据合规要求或侵犯第三方权利的内容
- 包含商业秘密、个人信息、敏感数据、私有代码、内部文档或未公开漏洞信息的提示词、输出或贡献
- 由AI Agent自动批量提交的贡献或提交人类贡献者未实质参与的贡献
## 6\. 贡献者责任
贡献者向社区提交AI辅助贡献时，应确认并承诺：
- 已对拟提交AI辅助贡献内容进行人工审查
- 理解拟提交AI辅助贡献的技术含义、设计影响和维护成本
- 已完成对拟提交的AI辅助贡献的必要测试、构建、许可证检查和安全检查
- 已确认AI工具输出未引入与项目许可证不兼容的限制
- 已确认拟提交AI辅助贡献不包含已知的未获授权的第三方材料，或已按照本项目要求披露第三方材料、许可证、著作权声明和权属信息
- 已遵守贡献者雇主、客户、学校或所属组织关于AI工具和开源贡献的政策
- 对所提交AI辅助贡献承担与非AI辅助贡献相同的责任
## 7\. 审查与合入规则
社区维护者可以基于以下原因要求贡献者修改、补充说明、重新提交AI辅助贡献或拒绝合入AI辅助贡献：
- 贡献者未按要求披露AI辅助贡献的相关信息
- 贡献者无法解释其所提交的代码逻辑或来源
- 贡献内容与未经授权的第三方代码、文档或图片实质性相似
- 许可证、著作权或权属信息不清晰
- 未经测试、不可维护或增加安全风险的低质量AI辅助贡献
- 自动化、批量化提交影响社区正常维护秩序的低质量AI辅助贡献
- 社区维护者基于openUBMC项目风险偏好认为AI辅助贡献不适合合入
---
https://www.openubmc.cn/zh/brand/
---
# 品牌
## 品牌使用说明
在使用openUBMC项目相关的全部品牌前，请查阅 《openUBMC标志视觉识别规范》，确保规范使用。
openUBMC网站上使用和显示的所有商标、标志皆属openUBMC社区所有，但注明属于其他方拥有的商标、标志除外。未经openUBMC社区或其他方书面许可，openUBMC网站所载的任何内容不应被视作以暗示、不反对或其他形式授予使用前述任何商标、标志的许可或权利。未经事先书面许可，任何人不得以任何方式使用openUBMC社区的名称及openUBMC社区的商标、标记，除非你使用前述名称、商标和标记是出于个人、教育和非商业目的。任何人不得在未获得第三方同意的情况下使用第三方拥有的商标和标志。
咨询联系方式 contact@openubmc.cn
## Logo 下载
Standard
下载
Monochrome
下载
Black
下载
Standard
下载
Monochrome
下载
Black
下载
## PPT 模板下载
中文模板
下载
---
https://www.openubmc.cn/zh/brand/standard/
---
品牌
openUBMC标志视觉识别规范
## 标志诠释
以 “UnifiedBMC” 首字母 “U” 为核心载体，通过简洁现代的图 形语言，传递出社区开放、协作、友好的价值观。
形态寓意：U 形曲线自然勾勒出“微笑”弧线，与上方两点共同构成 一张温暖的笑脸。笑脸象征 开放协作带来的愉悦与共赢，呼应开源社 区友好、互助的文化内核
符号叙事：上方的两个圆点，形似交握的双手，直观诠释 “Unified” (联合)的品牌主张，强化社区“去中心化、人人参与” 的开源理念。
品牌理念：左侧圆点同时作为英文 “open” 的首字母 “o”，在图 形中隐性锚定“开放”属性，实现 “符号形态→品牌理念” 的精准关 联。
## 标志形态
标准标志
图形标志与字体标志的组合是openUBMC的标准标志，代表 openUBMC提供开源的、标准的数字基础设施设备管理软件，适用 于介绍openUBMC品牌营销物料，例如平面广告、社区网站、线上 海报等，请优先使用标准版标志。在所有标志的使用中，务必确保使 用标志源文件，不得自行创造、设计、调整标志。
单独字标及图形
所有营销物料都以标准标志优先使用，根据画面整体需求，图形及文字也可以单独使用。
## 标志网格的正确比例
标志是一个平衡的整体，使用中不得改变其形状、结构和比例。
竖版标志：设定标志图标的高度为16x，标志的宽度为23x，图形与字标距离2x， 字标高度为4x。
横版标志：设定标志图标的高度为 11x，标志图标的宽度为 9x，字标与图标的 距离 2x，字标高度为6x，字标宽度为34x。
单独图形：设定图标的高度为11x ，则图标的宽度为9x。
单独文字：设定图标的高度为6x，则图标的宽度为34x。设定图标的高度为6x，则图标的宽度为34x。
## 标志的保护空间及最小尺寸
标志的四周设置有最小保护空间，该空间不能与其他图形元素连接。
最小尺寸的设置是为了确保标志使用过程中的品质，使其清 晰、易识别。
保护空间原则
竖版标志设定标志高度为X，竖版标志的安全距离为 1/4X。
横版标志设定标志高度为X，横版标志的安全距离为1/2X。
单独图形标志设定高度为X，则 安全距离为1/4AX。
单独文字标志设定高度为X，则安全距离为X。
最小尺寸使用原则
竖版公司标志和单色红标志的最小打印尺寸为长度 15mm， 最小数码尺寸为 50px。
横版公司标志和单色红标志的最小打印尺寸为长度 25mm， 最小数码尺寸为 100px。
最小尺寸使用原则特殊情况
最小尺寸的应用如有特殊情况，请在品牌管理系统咨询专家， 特殊情况特殊处理。
在所有标志的使用中，务必确保使用品牌管理系统的标志源 文件。不得自行创造、设计标志，如有疑问请在品牌管理系 统咨询专家。
## 标志颜色
本页列举了openUBMC蓝标志的色彩控制，色彩模式包括: CMYK 模式、Pantone 色模式、RGB 模式、网络安全色模式。
所有视觉应用设计优先使用渐变蓝标志，在特殊情况下可以使用单色黑、反白标志。
## 单色黑和反白标志
所有视觉应用设计优先使用克莱因蓝标志，单色黑和反白标志 是对openUBMC标志使用形式的有力补充，它适用于特定场景。
适用场景
1.适用于因材质、工艺、成本等问题不能使用品牌蓝标志的应用场景 (如周边产品、环境导视等);
2.适用于当品牌蓝标志与背景色冲突、识别不清晰时;
3.其他应用场景
## 标志位置规范总览
严格控制标志在版面(包含印刷、数字多媒体、户外广告)中的位置 , 有助于保证标志在视觉传播中的品牌识别度。本页列举了标志在不同 应用系统(如广告系统、数字多媒体系统、展览展示系统、印刷系统 等)中各个接触点的位置。
A.标志位于版面右下角，右下角为公司标志在相关应用中 的优选位置 ( 如印刷系统中的彩页、宣传册、投标书、刊物， 广告系统中的各类纸质广告等 );
B.标志位于版面右上角(如展览喷绘应用的背景板、户外落地广告 );
C.标志位于版面左上角(如数字多媒体系统中的网站、线 上广告、Social Banner、EDM、Demo 等 );
D.标志位于版面正中心 ( 如视频、展览中的联合品牌背景板等 );
E.标志位于版面下方居中对齐(如PPT模版(特殊场景发布 / 大会演 讲，深色版等);
F.标志位于版面右下角(如横版超长广告满版版面等);
G.标志位于版面右侧白色区域居中对齐 ( 如横版超长广告分栏版面等 );
H.标志位于版面下方居中对齐 ( 如竖版超长广告满版版面等);
I.标志位于版面下方白色区域居中对齐 ( 如竖版超长广告分栏版面等 );
J.标志位于版面右上角或上部居中 ( 如户外挂旗、易拉宝等 )。
设定公司标志图标的高度为 X，公司标志距离边栏及图片的距离为 0.5X-1.0X，当版面的尺寸变化时，X 的数值也会相应变化。
## 主色/辅助色
品牌色彩是品牌为塑造独特的企业形象而确定的某一特定的色彩，适用在所有视觉传播接触点上，通过色彩特有的视觉刺激与心理反应，以表达企业的经营理念。
openUBMC品牌色(PANTONE 2727C )
辅助色用于衬托和丰富品牌色的使用，表达热情、积极，使品牌形象更加统一、聚焦，更易于与公众情感连接。辅助色以暖色系和灰色系为主。
品牌色(Pantone 2727C )可用于品牌层面，产品层面，传播 层面等全部应用接触点。
---
https://www.openubmc.cn/zh/charter/
---
# 技术委员会运作规则
# 政策规则
了解openUBMC社区的运作规则、行为准则、AI贡献策略等相关内容
技术委员会运作规则社区行为准则AI贡献策略
# 社区行为准则
# AI贡献策略
---
https://www.openubmc.cn/zh/code-of-conduct/
---
# 技术委员会运作规则
# 政策规则
了解openUBMC社区的运作规则、行为准则、AI贡献策略等相关内容
技术委员会运作规则社区行为准则AI贡献策略
# 社区行为准则
openUBMC社区行为准则
## 总则
如需举报侮辱、骚扰或其他不可接受的行为，您可以发送邮件至complain@public.openubmc.cn，联系openUBMC技术委员会处理。
## 贡献者承诺
为建设开放友好的环境，我们贡献者和维护者承诺：不论年龄、体型、身体健全与否、民族、性征、性别认同与表征、经验水平、教育程度、社会地位、国籍、相貌、种族、信仰、性取向，我们项目和社区的参与者皆免于骚扰。
## 行为准则
有助于创造积极环境的行为包括但不限于：
- 措辞友好且包容
- 尊重不同的观点和经验
- 耐心接受有益批评
- 关注对社区最有利的事情
- 与社区其他成员友善相处
- 合规提交代码、规范使用权限、保障项目供应链和基础设施安全
参与者不应采取的行为包括但不限于：
- 发布与性有关的言论或图像、不受欢迎地献殷勤
- 捣乱/煽动/造谣行为、侮辱/贬损的评论、人身及政治攻击
- 公开或私下骚扰
- 未经明确授权便发布他人的资料，如住址、电子邮箱等
- 其他有理由认定为违反职业操守的不当行为
- 植入恶意后门、污染项目依赖、损毁项目资产等危害社区安全的违规操作
## 项目维护者义务
项目维护者有义务诠释何谓“妥当行为”，并妥善公正地纠正已发生的不当行为。
项目维护者有权利和义务去删除、编辑、拒绝违背本行为标准的评论（comments）、提交（commits）、代码、wiki 编辑、问题（issues）等贡献；项目维护者可暂时或永久地封禁任何他们认为行为不当、威胁、冒犯、有害的参与者。
## 适用范围
本行为准则适用于本项目。当有人代表本项目或本社区时，本准则亦适用于此人所处的公共平台。
代表本项目或本社区的情形包括但不限于：使用项目的官方电子邮件、通过官方媒体账号发布消息、作为指定代表参与在线或线下活动等。
代表本项目的行为可由项目维护者进一步定义及解释。
# AI贡献策略
---
https://www.openubmc.cn/zh/compatibility/list/
---
# 兼容性列表
查看 openUBMC 支持的硬件板卡兼容性信息，涵盖网卡、xPU、RAID 卡及硬盘等部件类型，帮助您快速确认硬件适配情况
部件类型
网卡
RAID卡
硬盘
xPU
部件厂商
全部
BeiJingGuangRunTong
Broadcom
CMCC
Emulex
GuangRunTong
Huawei
Intel
JINGSHIJI
LR-LINK
Mellanox
Mucse
Netswift
Nvidia
QLogic
Wangxun
YUSUR
| 型号 | 厂商 | VID/DID | Sub VID/DID | 首次支持版本 |
| --- | --- | --- | --- | --- |
| SP670 | Huawei | 0x19e5/0x0222 | 0x19e5/0x00a1 | openUBMC 25.03 |
| MCX631432AN-ADAB | Mellanox | 0x15b3/0x101f | 0x15b3/0x0004 | openUBMC 25.06 |
| MCX631102AN-ADAT | Mellanox | 0x15b3/0x101f | 0x15b3/0x0001 | openUBMC 25.06 |
| SP680 | Huawei | 0x19e5/0x0222 | 0x19e5/0x0052 | openUBMC 25.06 |
| SF221Q | Huawei | 0xffff/0xffff | 0xffff/0xffff | openUBMC 25.06 |
| SF223D-H | Huawei | 0xffff/0xffff | 0xffff/0xffff | openUBMC 25.06 |
| SP625D | Huawei | 0x19e5/0x0222 | 0x19e5/0x01a1 | openUBMC 25.06 |
| SF400HT | Netswift | 0x8088/0x0107 | 0x8088/0x0402 | openUBMC 25.06 |
| SF200HT | Netswift | 0x8088/0x0105 | 0x8088/0x0202 | openUBMC 25.06 |
| LPE31002-AP | Emulex | 0x10df/0xe300 | 0x10df/0xe310 | openUBMC 25.06 |
共 96 条
1
2
3
4
5
6
7
10
前往
---
https://www.openubmc.cn/zh/contact-us/
---
# Contact Us
Engage with openUBMC through the following ways.
## Community Contact
Got a question? Send us an email, and we'll respond within 3–5 business days.
社区活动请联系
contact@openubmc.cn
品牌合作请联系
contact@openubmc.cn
其他联系方式
discuss@openubmc.cn
## Follow Us
### Find us on social media
- 微信公众号
- 社区小助手
## Handy Materials
(openUBMC 社区文档)[/zh/docs]
(获取openUBMC最新版本)[/zh/download]
(参与社区贡献)[/zh/contribution]
---
https://www.openubmc.cn/zh/contribution/
---
# Contribution Guide
...
# 总则
openUBMC是一款开源社区，完全依赖于社区提供友好的开发和协作环境。在参与社区贡献之前，请先阅读并遵守openUBMC社区行为守则。
# 贡献步骤
## 步骤一：注册 AtomGit 账号
- openUBMC使用AtomGit作为代码托管仓：https://atomgit.com/org/openUBMC
- 请参考AtomGit用户指南注册AtomGit账户，并在用户设置中设置您的主邮箱。
## 步骤二：签署 CLA
- 在参与社区贡献前，您还需要签署openUBMC社区贡献者许可协议（CLA）。
## 步骤三：找到您感兴趣的 SIG
- openUBMC社区内容按照不同的SIG来组织，以便于更好的管理和改善工作流程。openUBMC所有SIG组均是开放的，欢迎任何人来参与贡献。
### 因此，参与社区的正确方式：首先找到您感兴趣的SIG组。
- SIG的组织信息在openUBMC的SIG中心进行查看，也可以在Community仓库中查询。每个SIG组也会有各自的例会，SIG组例会是公开的，欢迎大家随时接入收听。
- 也欢迎通过社区论坛、邮件的方式与SIG组的成员进行互动交流。
- 感兴趣的 SIG 组还未出现？新的 SIG 组等你来发起！欢迎发送申请邮件至：tc@public.openubmc.cn，邮件申请模板请参考申请流程。
## 步骤四：开始您的贡献
社区的贡献不仅限于代码的开发，社区的每一个环节都欢迎大家进行贡献。
### 代码类贡献
每个SIG小组都会有各自规划的issue，您可以根据自己的兴趣挑选issue并解决它。
#### 给自己分配Issue
首先在评论框内输入 **/assign**，机器人就会将问题分配给您。 每个Issue下面可能已经有参与者的交流和讨论，如果您感兴趣，也可以在评论框中发表自己的意见参与Issue讨论。
#### 提交Issue
如果您准备向社区上报Bug或者提交需求，请在openUBMC社区对应的仓库上提交Issue。若不确定问题应提交到哪个仓库，请先在社区论坛发帖咨询。
您也可以以Issue的方式，或社区论坛发起话题的方式提出自己的意见或建议。提交Issue请参考AtomGit Issue提交指南。
#### 提交Pull Request
提交Pull Request请参考openUBMC社区Pull Request提交指南。 如果一次提交的代码量较大，建议将大型的内容分解成一系列逻辑上较小的内容，分段提交便于代码审查。
如果您的 Pull Request 没有引起足够的关注，可以通过对应 SIG 的邮件列表或者论坛上发帖进行求助。
#### 检视代码
openUBMC 作为一个开放的社区，我们希望所有参与社区的人都能成为活跃的检视者。 在进行代码审查时，可以参考《The Gentle Art of Patch Review》（补丁审核的柔和艺术）这篇文章。文章中提出了一些关键的审查点，强调代码审查不仅能够帮助新贡献者更积极地参与进来，同时避免代码中出现细微的错误。在审查过程中，可以特别关注以下几个方面：
- **贡献的合理性：** 首先评估贡献者提出的想法是否合理，是否符合项目的目标和需求。
- **架构的准确性：** 检查贡献的代码是否遵循了正确的架构设计，是否与现有的代码库和设计原则相一致。
- **贡献的完整性：** 评估贡献的代码是否全面，是否包含了所有必要的功能和测试，以及是否考虑到了代码的可维护性和扩展性。
### 非代码类贡献
一个优秀的社区，不仅仅只是一些代码仓，而是拥有活跃的开发者在社区的各个角落持续的建设。非代码类的贡献包括但不限于以下的几个方式：
#### 文档建设
- 在阅读openUBMC社区文档时，若发现文档问题，请通过提交issue的方式，或者社区论坛发帖的方式进行反馈。
- 有自己的见解？欢迎发表自己的文档。openUBMC社区有多种文档贡献方式，详情请参考博客贡献指南，或者通过邮件、论坛联系sig-docs小组。
#### 测试验证
- 希望加固社区的版本质量？请加入 sig-QA。
#### 其他工作
- 参与社区交流，通过社区论坛，帮助引导社区新人贡献社区，回答社区上的疑问等；
- 运维社区通信工具，包括协助 SIG 组的 Maintainer 完善 SIG 主页信息、组织社区例会等；
- 成为社区布道师，共同组织社区聚会，包括 Meetups、直播、社区开发者大会等；
- 参与社区宣传推广与内容制作，事件/技术/课程/视频请投稿至 TC；
- 参与社区基础设施建设，请加入 sig-infrastructure
- 参与社区视觉设计，请联系 TC
- 参与社区翻译服务，请联系 TC
## 步骤五：与社区一起成长
- 我们欢迎所有人参与 openUBMC 社区贡献，我们的目标是发展一个由贡献者组成的活跃、健康的社区。关于 Maintainer、Committer 等社区角色，请参考SIG中心。
---
https://www.openubmc.cn/zh/course/
---
# Courses
Explore our curated openUBMC learning collection.
(openUBMC架构概念设计介绍)[/en/course/openUBMC_architectural_conceptual_design_introduction]
(openUBMC Community Updates)[/en/course/openUBMC_community_updates]
(构建可信计算安全体系的设计和测试能力)[/en/course/trusted_computing_security_design_testing]
(板卡管理常见问题定位指导)[/en/course/board_management_troubleshooting]
(基于openUBMC的集群管理设计)[/en/course/openUBMC_cluster_management_design]
(openUBMC适配 intel x86功能包经验分享)[/en/course/openUBMC_intel_x86_porting_experience]
(openUBMC Agent 从缺陷定位到升级验证的全链路工作流实践)[/en/course/defect_upgrade_workflow_practice]
(基于南向驱动规范的RAID卡适配实践)[/en/course/southbound_driver_spec_raid_card_porting_practice]
(基于openUBMC的开发工具提升效率实践)[/en/course/openUBMC_dev_tools_efficiency_practice]
共 21 条
1
2
3
前往
---
https://www.openubmc.cn/zh/docs/
---
# 文档中心
**0**/100
9月社区文档更新清单
更新时间：2026/10/12
查看详情
暂无数据
本页内容
---
https://www.openubmc.cn/zh/docs/result/
---
# 文档中心
**0**/100
---
https://www.openubmc.cn/zh/download/
---
# 下载中心
一站式资源获取
社区发行版
由社区驱动、为社区服务的openUBMC发行版
商业发行版
基于openUBMC发布的商业发行版
下载中心社区发行版
## 社区发行版
openUBMC社区发行页面，提供最新稳定版本、历史版本下载及版本发布说明，方便开发者快速集成和定制。
...
openUBMC 26.09
最新版本
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 26.09 | 656.74 MB | 2026/09/29 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_26.09.00.01.zip | 26.09 | 83.85 MB | 2026/09/29 | SHA256 | 立即下载 |
| openUBMC-CMT_unsigned_26.09.00.01.zip | 26.09 | 83.84 MB | 2026/09/29 | SHA256 | 立即下载 |
openUBMC 25.12 LTS SP3
长期支持版
维护截止时间：2026/12/31
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP3 | 280.1 MB | 2026/09/09 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.03.01.zip | 25.12 SP3 | 74.58 MB | 2026/08/31 | SHA256 | 立即下载 |
openUBMC 26.06
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 26.06 | 293.75 MB | 2026/07/06 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_26.06.00.01.zip | 26.06 | 77.27 MB | 2026/06/30 | SHA256 | 立即下载 |
## 获取相关资源
(应用市场)[/zh/marketplace]
(社区文档)[/zh/docs]
## 支持与服务
(常见FAQ)[/docs/zh/development/faq/general.html]
(社区论坛)[https://discuss.openubmc.cn/]
---
https://www.openubmc.cn/zh/download/business-releases/
---
# 下载中心
一站式资源获取
社区发行版
由社区驱动、为社区服务的openUBMC发行版
商业发行版
基于openUBMC发布的商业发行版
下载中心商业发行版
## 商业发行版
- ### 什么是商业发行版
- 商业发行版是基于openUBMC社区版进行定制和增强的企业级解决方案。
- 它在社区版的核心功能之上，增加了企业所需的专业特性，如高级安全管理、增强运维特性、合规性认证、定制化功能以及商业技术支持服务。
- 商业发行版经过严格测试和优化，确保在复杂的企业IT环境中稳定运行，帮助客户降低运维风险，提升管理效率，满足不同行业和应用的特定需求。
- ### 商业发行版相较社区发行版有什么不同
- 商业发行版提供企业级可靠性和专业支持，适合需要高稳定性和安全性的生产环境。与社区版相比，它包含在特定机型下经过验证的增强功能、定期安全更新和及时的技术服务，帮助企业规避潜在风险。此外，商业发行版通常提供定制化选项，能够更好地适配特定硬件或业务需求。
- 选择商业发行版，意味着获得长期维护保障，让团队更专注于核心业务，而非底层技术问题
- ### 如何成为商业发行版的合作伙伴
- 我们诚邀硬件厂商、解决方案提供商及系统集成商加入我们的合作伙伴计划。成为认证合作伙伴后，您将获得openUBMC社区联合市场推广和宣传机会。我们期待与您共同打造更完善的BMC生态，为终端客户提供更优质的产品与服务。
- 如有需求，请通过邮件contact@openubmc.cn与我们联系，了解合作细节与权益，携手推动开源技术的商业应用与创新。
- ### 百敖openUBMC 25.09商业发行版
- 百敖商业发行版基于社区25.06版本开发，在基础功能之上完成了多项特性功能的开发和稳定性验证。主要新增功能包括：实时监控界面、灵活的传感器告警策略、Web SOL等，显著提升了管理效率和可操作性。在版本迭代过程中，我们持续跟踪开源社区的更新，并结合内部需求进行功能优化。发布流程严格遵循"先内测、再公开测试、最后正式发布"的步骤，确保每个版本在功能完善的同时，具备良好的稳定性和可用性。
发行厂商：南京百敖软件有限公司
发行时间：2025/9/30
更多信息
- ### 昆仑太科openUBMC商业发行版
- 昆仑太科openUBMC商业发行版（简称"昆仑BMC-U"），基于openUBMC社区25.09版本深度开发，在社区原生能力基础上，从功能增强、外设兼容、产品定制、文档完善四大核心维度进行系统性迭代优化。通过底层性能调优与上层能力拓展，昆仑BMC-U显著提升鲲鹏平台BMC产品的功能完整性与运维易用性，可为生态伙伴提供高可靠性、高效率的企业级BMC固件解决方案，充分彰显昆仑太科再BMC固件领域的技术沉淀与持续创新能力。
- 昆仑BMC-U将持续同步openUBMC社区版本节奏迭代升级，不断完善产品能力矩阵，持续保持在企业级BMC解决方案领域的核心竞争力，助力生态伙伴加速产品落地与价值提升。
发行厂商：昆仑太科（北京）技术股份有限公司
发行时间：2025年10月
更多信息
---
https://www.openubmc.cn/zh/download/community/all/
---
# 下载中心
一站式资源获取
社区发行版
由社区驱动、为社区服务的openUBMC发行版
商业发行版
基于openUBMC发布的商业发行版
下载中心社区发行版
## 社区发行版
openUBMC社区发行页面，提供最新稳定版本、历史版本下载及版本发布说明，方便开发者快速集成和定制。
...
版本类型
全部
长期支持版本（LTS）
创新版本
| 软件包类型 | 发行时间 | 维护截止时间 | 下载地址 |
| --- | --- | --- | --- |
| openUBMC 26.09 | 2026/09 | 2026/12 | 前往下载 |
| openUBMC 25.12 LTS SP3 | 2026/08 | 2026/12 | 前往下载 |
| openUBMC 26.06 | 2026/06 | 2026/07 | 前往下载 |
| openUBMC 25.12 LTS SP2 | 2026/05 | 2026/12 | 前往下载 |
| openUBMC 26.03 | 2026/03 | 2026/06 | 前往下载 |
| openUBMC 25.12 LTS SP1 | 2026/02 | 2026/12 | 前往下载 |
| openUBMC 25.12 LTS | 2025/12 | 2026/12 | 前往下载 |
| openUBMC 25.09 | 2025/09 | 2025/12 | 前往下载 |
| openUBMC 25.06 | 2025/07 | 2025/09 | 前往下载 |
| openUBMC 25.03 | 2025/04 | 2025/06 | 前往下载 |
## 获取相关资源
(应用市场)[/zh/marketplace]
(社区文档)[/zh/docs]
## 支持与服务
(常见FAQ)[/docs/zh/development/faq/general.html]
(社区论坛)[https://discuss.openubmc.cn/]
---
https://www.openubmc.cn/zh/download/community/detail/openUBMC 25.12 LTS/
---
版本列表
重置
确定
下载
所有版本
openUBMC 25.12 LTS
版本列表
openUBMC 26.09
openUBMC 25.12 LTS SP3
openUBMC 26.06
openUBMC 25.12 LTS SP2
openUBMC 26.03
openUBMC 25.12 LTS SP1
openUBMC 25.12 LTS
openUBMC 25.09
openUBMC 25.06
openUBMC 25.03
openUBMC 25.12 LTS
长期支持版
维护截止时间：2026/12/31
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 | 71.15 MB | 2025/12/31 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.00.01.zip | 25.12 | 77.58 MB | 2025/12/31 | SHA256 | 立即下载 |
---
https://www.openubmc.cn/zh/download/community/detail/openUBMC 25.12 LTS SP1/
---
版本列表
重置
确定
下载
所有版本
openUBMC 25.12 LTS SP1
版本列表
openUBMC 26.09
openUBMC 25.12 LTS SP3
openUBMC 26.06
openUBMC 25.12 LTS SP2
openUBMC 26.03
openUBMC 25.12 LTS SP1
openUBMC 25.12 LTS
openUBMC 25.09
openUBMC 25.06
openUBMC 25.03
openUBMC 25.12 LTS SP1
长期支持版
维护截止时间：2026/12/31
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP1 | 75.33 MB | 2026/02/14 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.01.01.zip | 25.12 SP1 | 66.08 MB | 2026/06/29 | SHA256 | 立即下载 |
---
https://www.openubmc.cn/zh/download/community/detail/openUBMC 25.12 LTS SP2/
---
版本列表
重置
确定
下载
所有版本
openUBMC 25.12 LTS SP2
版本列表
openUBMC 26.09
openUBMC 25.12 LTS SP3
openUBMC 26.06
openUBMC 25.12 LTS SP2
openUBMC 26.03
openUBMC 25.12 LTS SP1
openUBMC 25.12 LTS
openUBMC 25.09
openUBMC 25.06
openUBMC 25.03
openUBMC 25.12 LTS SP2
长期支持版
维护截止时间：2026/12/31
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP2 | 84.93 MB | 2026/06/03 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.01.01.zip | 25.12 SP2 | 66.46 MB | 2026/06/29 | SHA256 | 立即下载 |
---
https://www.openubmc.cn/zh/download/community/detail/openUBMC 25.12 LTS SP3/
---
版本列表
重置
确定
下载
所有版本
openUBMC 25.12 LTS SP3
版本列表
openUBMC 26.09
openUBMC 25.12 LTS SP3
openUBMC 26.06
openUBMC 25.12 LTS SP2
openUBMC 26.03
openUBMC 25.12 LTS SP1
openUBMC 25.12 LTS
openUBMC 25.09
openUBMC 25.06
openUBMC 25.03
openUBMC 25.12 LTS SP3
长期支持版
维护截止时间：2026/12/31
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP3 | 280.1 MB | 2026/09/09 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.03.01.zip | 25.12 SP3 | 74.58 MB | 2026/08/31 | SHA256 | 立即下载 |
---
https://www.openubmc.cn/zh/download/community/latest/
---
# 下载中心
一站式资源获取
社区发行版
由社区驱动、为社区服务的openUBMC发行版
商业发行版
基于openUBMC发布的商业发行版
下载中心社区发行版
## 社区发行版
openUBMC社区发行页面，提供最新稳定版本、历史版本下载及版本发布说明，方便开发者快速集成和定制。
...
openUBMC 26.09
最新版本
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 26.09 | 656.74 MB | 2026/09/29 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_26.09.00.01.zip | 26.09 | 83.85 MB | 2026/09/29 | SHA256 | 立即下载 |
| openUBMC-CMT_unsigned_26.09.00.01.zip | 26.09 | 83.84 MB | 2026/09/29 | SHA256 | 立即下载 |
openUBMC 25.12 LTS SP3
长期支持版
维护截止时间：2026/12/31
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 25.12 SP3 | 280.1 MB | 2026/09/09 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_25.12.03.01.zip | 25.12 SP3 | 74.58 MB | 2026/08/31 | SHA256 | 立即下载 |
openUBMC 26.06
版本说明
技术白皮书
生命周期
### 源码
openUBMC社区发行版全量源码包，适合需要进行二次开发的开发者。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| repositories.zip | 26.06 | 293.75 MB | 2026/07/06 | SHA256 | 立即下载 |
### 固件
openUBMC社区发行版固件包，可直接在使用openUBMC社区发行版的服务器上进行更新。
| 软件包名称 | 版本 | 软件包大小 | 发行时间 | 完整性校验 | 下载地址 |
| --- | --- | --- | --- | --- | --- |
| openUBMC-CMT_26.06.00.01.zip | 26.06 | 77.27 MB | 2026/06/30 | SHA256 | 立即下载 |
## 获取相关资源
(应用市场)[/zh/marketplace]
(社区文档)[/zh/docs]
## 支持与服务
(常见FAQ)[/docs/zh/development/faq/general.html]
(社区论坛)[https://discuss.openubmc.cn/]
---
https://www.openubmc.cn/zh/download/lifecycle/
---
社区发行版
生命周期
# 生命周期
社区版本按照交付年份和月份进行版本号命名。例如，openUBMC 25.09 于 2025 年 09 月发布。
社区版本分为长期支持版本和创新版本。
• 长期支持版本：发布间隔周期定为 1 年，提供 12 个月的社区支持。社区首个 LTS 版本 25.12 计划于 25 年 12 月发布。
• 社区创新版本：openUBMC 每隔 3 个月会发布一个社区创新版本，提供 3 个月社区支持。首个创新版本已于 25 年 3 月份发布。
Maintenance Support：CVE、Bugfix，新硬件支持和少量新特性（保证 LTS 内前向兼容的情况）
---
https://www.openubmc.cn/zh/events/
---
# 活动
了解openUBMC社区全年活动
活动概览
活动列表
活动活动概览
## 2026年度规划
JAN
FEB
MAR
Apr
May
JUN
Jul
Aug
Sep
Oct
Nov
Dec
国际开源会议
中国，深圳
华为中国合作伙伴大会2026
中国，北京
开放原子开源生态大会2026
中国，上海
华为全联接大会2026
TBD
KubeCON + CloudNativeC on China
TBD
open Source Summit Europe 2026
TBD
2025全球计算大会
TBD
操作系统大会 & openEuler Summit 2026
TBD
开放原子开源开发者大会
生态技术会议
中国，南京
2026 鲲鹏KPN 伙伴大会
中国，北京
2026 Open AI Infra Summit
中国，北京
鲲鹏昇腾开发者大会 KADC 2026
中国，北京
2026开放计算技术大会
TBD
2026上海海思创新大会
中国，深圳
GOSIM China 2026
TBD
固件联盟大会
开发者活动
Online
openUBMC 25.12 LTS版本解读直播
中国，武汉
openUBMC Meetup 武汉站
Online
1小时教你上手openUBMC开发直播
中国，长沙
高校行-国防科技大学站
中国，长沙
高校行-湖南师范大学站
中国，长沙
高校行-长沙理工大学站
中国，长沙
高校行-湖南大学站
高校 & 比赛
全年 开源实习
3月-11月 CCF开源创新大赛
8月-12月 第六届开源之夏
## 活动申请
无论是企业、SIG 组、科研院所或其他组织，我们都欢迎与 openUBMC 社区一起组织开发这活动，共同探讨前沿技术和开源发展趋势，分享创新成果和实践经验，与 openUBMC 社区共同成长！
1
1
如何申请
申报材料
2
2
申办审核
3
3
我们可以获得哪些赋能支持？
社区部分活动资金支持
品牌物料包
（易拉宝/海报/KV等设计源文件）
社媒矩阵传播
（官网/公众号/B站/社群同步宣传）
直播资源
（可选openUBMC官方直播间资源）
社区限定周边
（按实际参与人数配发，上限100份）
4
4
活动举办
5
5
活动成果反馈
---
https://www.openubmc.cn/zh/events/detail/1hours-buildUBMC/
---
活动列表
1hours BuildUBMC
# 直播预告 | 1小时教你上手openUBMC开发已结束
本课程将带你快速认识openUBMC的项目背景与核心价值，深度解析其核心架构设计，并通过多系统环境搭建实操与OpenUBMC Studio工具上手，助你启高效开发之旅。
2026年4月15日
线上
## 直播预告 | 1小时教你上手openUBMC开发
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/20251107shenzhen/
---
活动列表
20251107shenzhen
# 20251107shenzhen已结束
前沿技术深度解析 实战场景高效赋能，openUBMC 深圳站来啦！
2025年11月07日 9:00-16:30
南山区海天一路软件产业基地4栋B座1楼 禾木HOMEY SPACE（雅禾厅）
## 活动议程
前沿技术深度解析 实战场景高效赋能，openUBMC 深圳站来啦！
- 🕒 2025年11月7日（周五） 9:00–16:30
- 📍 南山区海天一路软件产业基地4栋B座1楼 禾木HOMEY SPACE（雅禾厅）
- 我要报名
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/20260814chengdu-meetup/
---
活动列表
openUBMC Meetup 成都站
# openUBMC Meetup 成都站已结束
openUBMC 社区联合华鲲振宇打造成都专场技术 Meetup，集结社区核心专家与产业一线实战工程师，全栈输出安全体系、硬件适配、场景管理核心技术方案。
2026年8月14日（周五） 9:30-16:00
丽柏酒店（成都四河地铁站新川店）-锦绣厅
## 活动议程
# openUBMC Meetup 成都站
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/20260922hefei-meetup/
---
活动列表
活动议程
# 欢迎报名｜openUBMC 合肥 Meetup 虚位以待，邀您共探 BMC 开源新实践已结束
本次活动由 openUBMC社区牵头，联合社区成员单位百信共同主办，是面向全体BMC技术伙伴的深度技术交流盛会。
2026年9月22日 9:30-16:00
合肥乐富强铂悦酒店三楼嘉悦厅
## 欢迎报名｜openUBMC 合肥 Meetup 虚位以待，邀您共探 BMC 开源新实践
# 活动议程
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/2026chengdu-meetup/
---
活动列表
开源聚力蓉城，技术筑牢底座
# 议题征集 | openUBMC × 华鲲振宇 Meetup 成都站，邀您开讲！已结束
本次活动由openUBMC社区联合华鲲振宇共同主办，聚焦 BMC 技术创新、产业落地与开源生态共建，打造全产业链开发者技术交流盛会。
申报截止至 7 月 31 日 23:59
成都
## 议题征集 | openUBMC × 华鲲振宇 Meetup 成都站，邀您开讲！
# 开源聚力蓉城，技术筑牢底座
openUBMC 2026 线下 Meetup 成都站将于8 月 14 日启幕，由openUBMC社区联合华鲲振宇共同主办，聚焦 BMC 技术创新、产业落地与开源生态共建，打造全产业链开发者技术交流盛会。
现面向全体开发者开放议题征集，覆盖 BMC 开发、硬件适配、运维实战、行业落地等全方向，入选嘉宾可获社区限定纪念礼品与官方宣传曝光支持。申报截止至 7 月 31 日 23:59，详情见下方海报，扫码即可申报。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/2026hefei-meetup/
---
活动列表
openUBMC Meetup 合肥站
# 议题征集｜openUBMC Meetup 合肥站邀您分享实战经验，共建 BMC 开源生态已结束
本次活动由 openUBMC社区牵头联合社区成员单位百信共同主办，面向BMC技术伙伴打造深度技术交流盛会。
申请截止至 9 月 13 日 23:59
合肥
## 议题征集｜openUBMC Meetup 合肥站邀您分享实战经验，共建 BMC 开源生态
# openUBMC Meetup 合肥站
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/2026shenzhen-meetup/
---
活动列表
openUBMC Meetup 深圳站
# 议题征集｜openUBMC Meetup 深圳站邀您分享实战经验，共建 BMC 开源生态进行中
本次活动由 openUBMC 社区主办，旨在为 BMC 技术伙伴搭建深度技术交流平台。
申请截止至 10 月 18 日 23:59
深圳
报名
## 议题征集｜openUBMC Meetup 深圳站邀您分享实战经验，共建 BMC 开源生态
# openUBMC Meetup 深圳站
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/Upcoming Live Stream0806/
---
未找到相关内容
---
https://www.openubmc.cn/zh/events/detail/Upcoming Live Stream0828/
---
未找到相关内容
---
https://www.openubmc.cn/zh/events/detail/Upcoming-Live-Stream0806/
---
活动列表
Upcoming Live Stream0806
# 直播预告｜openUBMC南向硬件管理技术规范、实践及生态建设分享Concluded
本课程通过实践验证提升兼容性与稳定性，并推动上下游厂商共建开放生态，实现各类硬件高效接入，通过社区协同促进产业链分工协作。
2026年8月6日
线上
## 直播预告｜openUBMC南向硬件管理技术规范、实践及生态建设分享
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/events/detail/Upcoming-Live-Stream0828/
---
活动列表
Upcoming Live Stream0828
# 直播预告｜openUBMC 架构概念设计介绍Concluded
本课程面向希望系统理解服务器管理软件的开发者，围绕 openUBMC 架构的概念设计展开。从硬件、接口与产品定制等高频变化出发，帮助你建立全局架构视图，为组件开发、接口扩展和产品定制打下基础。
2026年8月28日
线上
## 直播预告｜openUBMC 架构概念设计介绍
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/events/detail/WuhanMeetup-yicheng/
---
活动列表
议题征集！openUBMC Meetup 武汉站，与你共写新的开源记忆
# 议程公布已结束
openUBMC社区携手社区成员单位长江计算、神州鲲泰，诚邀您相聚武汉，共赴一场服务器管理技术的盛宴!全天10个精彩议题，涵盖高密存储产品化、AI服务器PCle Switch创新、x86平台适配、大模型赋能社区机器人，以及全新openUBMC Studio亮相。在这里，您将与行业专家深度交流，见证开源力量如何重塑BMC生态。相约樱花季，共探无限可能!
2026年3月20日
武汉鑫阿丹园光谷国际酒店二楼A区宴会厅
活动回顾
## 议程公布
# 议题征集！openUBMC Meetup 武汉站，与你共写新的开源记忆
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/ccf/
---
活动列表
Ccf
# 第八届CCF开源创新大赛 | openUBMC 开源项目贡献赛重磅启幕已结束
立足数字经济深度发展与国家开源战略布局，面向人工智能、泛在操作系统领域的技术创新、成果转化与专业人才供给需求，第八届CCF开源创新大赛由中国计算机学会(CCF)主办，CCF开源发展技术委员会承办。大赛以赋能开源生态高质量发展为核心导向，通过体系化赛道设置、精准化资源对接、全流程专业化运营、打造集开源成果展示、技术交流碰撞、产学研用协同于一体的权威赛事平台。
2026年4月2日～2026年8月16日
重庆
## 第八届CCF开源创新大赛 | openUBMC 开源项目贡献赛重磅启幕
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/chengdu-meetup/
---
活动列表
活动报名｜openUBMC Meetup 成都站
# 活动报名｜openUBMC Meetup 成都站已结束
10月31日，openUBMC社区Meetup将来到成都，诚邀广大开发者线下相聚，共同探索技术落地新路径。
2025年10月31日（周五） 9:30-16:35
成都新希望武侯智选假日酒店4F一号会议室
## 活动议程
# 活动报名｜openUBMC Meetup 成都站
从理论洞察到实战演练，本次活动将为开发者提供深度的技术体验。我们将在Meetup中展示可观测技术、部件驱动、社区版本测试策略的最新进展，分享BMC构建流水线搭建实践、AI赋能测试、调速策略配置、基于组件的自定义文件定制方法等关键议题，并开展Workshop，助力开发者将技术理念转化为落地解决方案。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/gosim-hangzhou-2025/
---
活动列表
openUBMC社区即将亮相GOSIM HANGZHOU 2025 大会，分享AI基础设施智能管理前沿实践！
# openUBMC社区即将亮相GOSIM HANGZHOU 2025 大会，分享AI基础设施智能管理前沿实践！
本次议题将分享如何利用openUBMC实现AI基础设施设备管理、智能化的故障预测与自愈，从而打造高性能、高可靠的AI基础设施管理平台，推动开源技术在企业级场景的深度落地。
2025年9月13日~9月14日
杭州白金汉爵酒店
## 活动议程
# openUBMC社区即将亮相GOSIM HANGZHOU 2025 大会，分享AI基础设施智能管理前沿实践！
## GOSIM HANGZHOU 2025
9 月 13–14 日，GOSIM HANGZHOU 2025 大会将在杭州隆重启幕。GOSIM作为一个开源社区平台，致力于为全球开源开发者提供一个协作和交流的空间。此次大会不仅是开源界的一次盛会，更是探讨未来技术趋势、共建智能基础设施的关键平台。届时，openUBMC将与全球开发者、企业代表以及技术领袖一起，深入探索开源技术在AI时代的新可能。
## openUBMC精彩议题抢先看
随着人工智能算力需求的爆发式增长，传统设备管理方式已难以应对大规模、高复杂度的AI基础设施。openUBMC致力于通过开源开放的模式，打造下一代智能设备管理标准，提升系统的可靠性、可维护性和自动化水平。本次分享将为开发者、企业技术决策者以及AI基础设施构建者提供重要参考和实践指南。
## 来现场，与openUBMC互动
除了精彩议题，openUBMC还将在大会展区设置展位，展示最新技术成果与实践。欢迎各位与会者前来交流，与技术团队面对面沟通，深入了解如何参与社区贡献、应用openUBMC提升自身业务系统的管理能力。
### 大会信息
- 会议名称：GOSIM HANGZHOU 2025
- 会议时间：2025年9月13日~9月14日
- 会议地点：中国·杭州白金汉爵酒店
- 会议官网：https://hangzhou2025.gosim.org/zh/
openUBMC社区期待在GOSIM 2025与您相遇，共同推动智能设备管理技术的创新与突破！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/hangzhou-meetup/
---
活动列表
openUBMC Hangzhou Meetup 2025
# openUBMC Hangzhou Meetup 2025
我们诚挚邀请您参与openUBMC首届线下Meetup！本次活动围绕openUBMC核心技术体系展开深度探讨，携手构建算力设备管理的开源社区。
2025年05月26日 9:00-17:00
杭州市滨江区Pagoda君亭设计酒店四楼嘉禾厅
活动回顾
## 活动议程
# openUBMC Hangzhou Meetup 2025
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/live stream preview0717/
---
未找到相关内容
---
https://www.openubmc.cn/zh/events/detail/live-stream-preview0717/
---
活动列表
Live Stream Preview0717
# 直播预告｜openUBMC 社区工程实践分享：从设计方法到产品落地Concluded
本直播系列课程聚焦 openUBMC 设计方法论，系统讲解如何基于 openUBMC 构建管理方案，帮助开发者把握设计核心要点与工程实践路径。
2026年7月17日
线上
## 直播预告｜openUBMC 社区工程实践分享：从设计方法到产品落地
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/events/detail/openUBMC-LTS-live/
---
活动列表
直播预告｜openUBMC 25.12 LTS版本解读直播专场
# 直播介绍
openUBMC 25.12 LTS 正式发布！这一里程碑式的长期支持版本，将重构企业级服务器管理的智能边界。在本次直播中，我们将完整介绍 openUBMC 平台的关键特性，并深度解读 25.12 版本在部件兼容适配、运维灵活定制等方面的核心突破，揭秘如何通过开源力量，驱动数据中心迈向更高效、更稳定、更安全的未来。
2026年2月3日
线上直播
## 直播介绍
# 直播预告｜openUBMC 25.12 LTS版本解读直播专场
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/openUBMC-Open-Source-Internship/
---
活动列表
OpenUBMC Open Source Internship
# openUBMC 开源实习火热招募：实习证明&薪资等你来拿！进行中
远程参与开源项目实践，提升个人技术，有机会获得企业关注！
2026年5月9日
线上
## openUBMC 开源实习火热招募：实习证明&薪资等你来拿！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/openatom-devloper-openubmc/
---
活动列表
Openatom Devloper Openubmc
# Openatom Devloper Openubmc已结束
开源算力设备管理软件分论坛即将启幕 | 2025 开放原子开发者大会，马上报名。
2025年11月21日 15:00-17:145
北京北人亦创国际会展中心(D+E厅)
## 活动议程
openUBMC社区联手固件产业技术创新联盟和全球计算联盟诚邀您参加2025开放原子开发者大会【开源算力设备管理软件分论坛】！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/detail/xian-meetup/
---
活动列表
openUBMC X 昆仑太科 Meetup 西安站
# openUBMC X 昆仑太科 Meetup 西安站
8月18日，openUBMC Meetup 将来到西安，诚挚地邀请广大开发者线下相聚，用技术燃动夏日！
2025年08月18日 13:00-17:30
西安市雁塔区团结南路智选假日酒店五楼多功能会议厅
活动回顾
## 活动议程
# openUBMC X 昆仑太科 Meetup 西安站
本次活动聚焦社区 25.06 版本的新特性，致力于帮助西北地域的开发者快速上手，让大家在技术的浪潮中紧跟步伐。我们将在Meetup中展示BMC Studio 新功能、开发板体验、可观测技术应用实践、社区软件工程能力建设等关键议题，同时针对开发者关注的领域开展对应的 Workshop。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/events/list/
---
# 活动
了解openUBMC社区全年活动
活动概览
活动列表
活动活动列表
## 活动列表
活动状态
全部
进行中
已结束
进行中
议题征集｜openUBMC Meetup 深圳站邀您分享实战经验，共建 BMC 开源生态
2026/10/30
深圳
已结束
openUBMC Meetup 合肥站
2026/09/22
合肥
已结束
议题征集｜openUBMC Meetup 合肥站邀您分享实战经验，共建 BMC 开源生态
2026/09/22
合肥
已结束
直播预告｜openUBMC 架构概念设计介绍
2026/08/28
线上
已结束
第八届CCF开源创新大赛 | openUBMC 开源项目贡献赛重磅启幕
2026/08/16
重庆
已结束
openUBMC Meetup 成都站
2026/08/14
成都
已结束
议题征集 | openUBMC × 华鲲振宇 Meetup 成都站，邀您开讲！
2026/08/14
成都
已结束
直播预告｜openUBMC南向硬件管理技术规范、实践及生态建设分享
2026/08/06
线上
已结束
直播预告｜openUBMC 社区工程实践分享：从设计方法到产品落地
2026/07/17
线上
已结束
openUBMC 开源实习火热招募：实习证明&薪资等你来拿！
2026/05/09
线上
已结束
直播预告 | 1小时教你上手openUBMC开发
2026/04/15
线上
已结束
10大硬核议题+Studio首秀！与您共赴樱花季技术盛宴
2026/03/20
武汉
共 19 条
1
2
前往
---
https://www.openubmc.cn/zh/internship/
---
# 开源实习
openUBMC 开源实习面向高校学生开放，聚焦算力设备开源管理软件开发，提供真实项目实战、资深导师专业指导与官方实习认证，全面提升开发能力与求职竞争力。
## 实习介绍
开源实习是openUBMC携手openEuler、MindSpore等多个社区共同发起的线上实习项目，旨在鼓励在校大学生深度参与开源实践，依托真实的开源项目场景，提升自身技术实操能力、问题解决能力与开源协作素养。由openUBMC社区提供实习任务，并提供导师辅导，学生通过实习申请后，可领取任务，每完成一个任务可获得相应积分，积分累计达规定量后，可获得实习证明和实习工资。
- 本实习项目将在社区长期进行。
- 学生实习合同期限一次为6个月，合同期限结束后仍可以继续在社区领取处理任务，但无法再领取实习工资，不可重复入职实习。
盛情邀请社区各位资深开发者成为开源实习活动导师，请发送报名至活动邮箱contact@openubmc.cn
01 申请实习
02 领取任务
03 提交成果
04 工资与证书发放
## 申请实习
01、阅读并签署活动声明。(见实习申请材料模板里)
02、完成实习测试任务
并截图至报名资料表内。
03、填写报名资料表。
在《实习申请材料模板》里仔细阅读实习报名流程，在线表单填写完毕后等待审核，组织方将以邮件反馈审核结果。组织方会根据所提交的资料对报名学生进行一定的审核筛选。审核通过后，将分配账号开始实习。
注意:
openUBMC开源实习offer发放时间为：实习积分满10分后。
实习申请材料模板
## 实习任务
- ### Interface SIG组
负责openUBMC社区接口的开发与维护
查看实习任务
- ### Hardware SIG组
负责openUBMC社区硬件的开发与维护
查看实习任务
- ### CICD SIG组
负责openUBMC社区软件工程相关的开发与维护
查看实习任务
查看全部实习任务
## 实习薪资与证明
- ### 实习工资
- 实习有效期6个月内满10分以上，可获得不同级别的实习工资。
- 具体见以上“申请步骤4”里的工资说明。
- ### 实习证明
- 实习有效期6个月内积分满60分
- 至少找一位导师写实习评语
- 提交实习报告
满足以上3条，实习评语与实习报告经评审合格后发放实习证明。具体见以上“申请步骤4“里的证明申请说明。
- ### 优秀实习生证书
- 申请本年度内积分达到150分
- 至少找一位导师写优秀推荐评语。
满足以上条件，可向社区发邮件申请发放优秀实习生证书。联系邮箱： contact@openubmc.cn
## 实习规则FAQ
1、哪些人可以报名？
开源实习面向全国范围内年满18周岁的在校大学生招募，无专业年级限制，欢迎感兴趣的同学踊跃报名。
2、实习有效期6个月是如何计算的？
在申请实习时需签署实习劳务合同，实习有效期即劳务合同上填写的实习有效期，为6个月期限，6个月期限内未满60积分则不能获得实习证明。线上实习时间管理相对自由，可根据自身情况安排时间，可提前结束实习。
3、超过了6个月或者完成了100积分还能继续在社区做任务吗？
可以，但积分将不再用于申领证明与奖金，欢迎大家持续参与openUBMC社区贡献，共同助力开源项目建设。
---
https://www.openubmc.cn/zh/maillist/
---
# Mailing Lists
Mailing lists are the core, efficient channel for all openUBMC community SIGs.
Engage directly in technical reviews, shape proposals, and drive project direction with real-time updates.
Subscribe to a SIG
选择订阅的SIG组
查看感兴趣的SIG组，点击"前往订阅"
填写信息
在订阅邮件页面内，填写相关个人信息，点击确认订阅
确认订阅邮件
您的邮箱将收到一封来自该SIG组的电子邮件，要求您确认订阅了邮件列表，点击确认链接完成订阅
成功订阅
当收到一封欢迎邮件，即成功订阅该SIG组邮件列表
SIG Mailing Lists
| SIG Name | Description | Mailing Lists | Archive | Subscribe |
| --- | --- | --- | --- | --- |
暂无数据
---
https://www.openubmc.cn/zh/news/
---
# 新闻资讯
新闻资讯是一个集行业新闻动态、社区资讯于一体的平台，旨在为用户提供最新的行业动态。
(议程公布 | 2026全球计算大会——openUBMC技术生态论坛议程全览)[/zh/news/CGC-2026-program]
(CGC 2026 | openUBMC 分论坛：从标准共建到技术落地，解锁在超节点与AI新形势下 BMC 演进方向)[/zh/news/CGC-2026-teaser]
(一图读懂9月社区文档更新清单)[/zh/news/202609-docs-update]
(华为全联接大会 2026｜openUBMC 精彩亮相，以开源底座使能产业差异化创新)[/zh/news/HUAWEI-CONNECT-2026]
(openUBMC 社区 2026 年 9 月运作报告)[/zh/news/community-operation-report9]
(openUBMC Meetup 合肥站圆满举办｜百信联合主办，共探 BMC 开源生态实践)[/zh/news/2026hefei-meetup-review]
(openUBMC 26.09 版本正式发布)[/zh/news/2609-release]
(openUBMC 社区 2026 年 8 月运作报告)[/zh/news/community-operation-report8]
(一图读懂8月社区文档更新清单)[/zh/news/202608-docs-update]
共 50 条
1
2
3
4
5
6
前往
---
https://www.openubmc.cn/zh/news/20250724/
---
新闻资讯
汇聚众智，共启新程，openUBMC开源发展委员会首次会议成功召开
# 汇聚众智，共启新程，openUBMC开源发展委员会首次会议成功召开
2025/07/24
# 汇聚众智，共启新程，openUBMC开源发展委员会首次会议成功召开
2025年7月18日，openUBMC开源发展委员会试运行正式启动并在深圳召开首次线下会议。本次会议汇聚了来自互联网、运营商、整机商、IBV、部件商、标准组织等领域30余家企业的领导和技术专家，共同见证openUBMC社区发展的里程碑时刻。
会议围绕技术创新、生态共建、社区治理等核心议题展开深入探讨，为openUBMC的下一阶段的发展指明了目标和方向。
openUBMC社区开源发展委员会主席马银川先生出席会议并致辞，对openUBMC开源以来所取得的进展做出了总结，并对各成员单位的贡献表示感谢，同时欢迎各位委员就社区下一步工作献计献策，凝聚共识，共同推动社区发展。
随后，openUBMC社区技术委员会主席宋铜铃为开源发展委员会汇报最新发布的25.06版本重点技术特性与H2技术规划解读：
- **25.06版本重大升级**
openUBMC 25.06社区发行版作为25年第二个版本，在标准化接口完善、硬件兼容性扩展、运维能力增强及开发者体验优化方面实现突破性进展。
- **2025H2技术路线图**
openUBMC社区2025年H2将进一步聚焦BMC运维特性、开发者易用性、社区基础设施等维度进行进一步优化和升级，打造具备好用易用的BMC软件和社区。同时社区技术委员会会在H2持续开展社区技术相关工作，确保社区版本和技术具备持续发展的可能性。
生态的持续繁荣，对开源社区尤为重要，生态发展组为开源发展委员会带来openUBMC社区生态发展最新进展：
- **产业生态丰富度持续提升：** openUBMC社区已初步形成的全产业链生态，面向未来将进一步丰富软、硬件支持类型，适配更多场景。
- **标准与认证体系稳步推进：** openUBMC部件驱动SIG将启动《BMC南向驱动接口规范》相关建设活动，联合社区各单位与标准组织一起共同建立部件驱动标准和认证体系。
- **商业落地初具规模：** 多个社区成员单位已基于openUBMC社区发行版已交付近20个商业版本，覆盖云服务、金融、国际民生等重点行业。
- **组织运作健康高效：** openUBMC已围绕北向接口管理、南向部件管理、BMC运维特性、部件驱动等技术方向成立9个技术SIG，汇聚超过200名社区开发者，初步形成了高效协作机制。
在开放讨论环节，openUBMC开发发展委员会围绕版本发布与上下游协作、南向部件驱动标准建设、生态联合拓展与影响力构建，社区治理和运作等核心维度开展深入讨论并达成诸多共识。
最后，openUBMC社区秘书长王瑞锋对会议进行总结。他指出，本次大会的成功召开是openUBMC社区发展的重要里程碑，为社区的长期健康发展打下了坚实的基础，未来社区将以本次会议为起点，秉承共建、共享、共治的开放原则，共同推动社区长期健康发展。
### 加入我们
社区官网：https://www.openubmc.cn
代码仓：https://gitcode.com/openUBMC
企业合作：contact@openubmc.cn
公众号：搜索"openUBMC"获取白皮书
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202510-docs-update/
---
新闻资讯
一图读懂10月社区文档更新清单
# 一图读懂10月社区文档更新清单
2025/11/07
# 一图读懂10月社区文档更新清单
你的专属知识库又双叒叕更新了！快来看看哪些宝藏内容被点亮？
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202511-docs-update/
---
新闻资讯
一图读懂11月社区文档更新清单
# 一图读懂11月社区文档更新清单
2025/12/04
# 一图读懂11月社区文档更新清单
快来看看文档中心11月又做了哪些更新吧！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202512-docs-update/
---
新闻资讯
一图读懂12月社区文档更新清单
# 一图读懂12月社区文档更新清单
2026/01/08
# 一图读懂12月社区文档更新清单
快来看看文档中心12月又做了哪些更新吧！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202601-docs-update/
---
新闻资讯
一图读懂1月社区文档更新清单
# 一图读懂1月社区文档更新清单
2026/02/04
# 一图读懂1月社区文档更新清单
快来看看文档中心1月又做了哪些更新吧！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202602-docs-update/
---
新闻资讯
一图读懂2月社区文档更新清单
# 一图读懂2月社区文档更新清单
2026/03/05
# 一图读懂2月社区文档更新清单
快来看看文档中心2月又做了哪些更新吧！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202603-docs-update/
---
新闻资讯
一图读懂3月社区文档更新清单
# 一图读懂3月社区文档更新清单
2026/04/03
# 一图读懂3月社区文档更新清单
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202604-docs-update/
---
新闻资讯
一图读懂4月社区文档更新清单
# 一图读懂4月社区文档更新清单
2026/05/11
# 一图读懂4月社区文档更新清单
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202605-docs-update/
---
新闻资讯
一图读懂5月社区文档更新清单
# 一图读懂5月社区文档更新清单
2026/06/02
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202606-docs-update/
---
新闻资讯
一图读懂6月社区文档更新清单
# 一图读懂6月社区文档更新清单
2026/07/06
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202607-docs-update/
---
新闻资讯
一图读懂7月社区文档更新清单
# 一图读懂7月社区文档更新清单
2026/08/06
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202608-docs-update/
---
新闻资讯
一图读懂8月社区文档更新清单
# 一图读懂8月社区文档更新清单
2026/09/10
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/20260807news-announcement/
---
新闻资讯
公告 | openUBMC 社区正式发布《生成式AI工具使用与开源贡献策略》
# 公告 | openUBMC 社区正式发布《生成式AI工具使用与开源贡献策略》
2026/08/07
# 公告 | openUBMC 社区正式发布《生成式AI工具使用与开源贡献策略》
* * *
- 立即“阅读原文”：https://www.openubmc.cn/zh/ai-coding-assistants
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/202609-docs-update/
---
新闻资讯
一图读懂9月社区文档更新清单
# 一图读懂9月社区文档更新清单
2026/10/12
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2026528-openUBMCnews/
---
新闻资讯
KADC 2026现场直击：openUBMC展区全景回顾
# KADC 2026现场直击：openUBMC展区全景回顾
2026/06/01
在KADC 2026大会现场，openUBMC设置的技术展区、动手体验区（Hands-on）和海报展示区（Poster）人气高涨，通过“展示+体验+共创”的丰富形式，全方位呈现了开源算力设备管理平台的技术活力与生态进展。
* * *
## 01 技术展区：核心能力全景呈现，生态联创成果亮眼
技术展区是本次展示的核心区域，集中展示南北向开放能力与多元业务创新成果。
openUBMC依托南向自适配能力，实现硬件Day级快速适配，可兼容xPU、网卡、硬盘、单板等各类部件，大幅降低硬件集成难度；凭借北向自接入特性，支持开发者自定义 Agent 开发，可灵活搭建专属算力设备管理体系。
基于完善的南北向一体化开发能力，openUBMC 有效支撑异构协同、智能运维、智能功耗调控、固件安全升级等各类业务创新，为算力设备全生命周期高效管理提供坚实技术支撑。
展台现场展出海思 Hi3095 UBMC 开发板，打造面向服务器管理、工业、电力、能源、IoT 等多领域的专用芯片能力。Hi3095 UBMC 开发板原生适配 openUBMC，凭借扎实的硬件基础，可充分支撑各类场景下的技术开发与应用创新。
展台还集中展示了光润通、昆仑太科、南京百敖、联瑞、沐创集成电路等生态伙伴的商业实践成果，直观彰显 openUBMC 强大的硬件兼容能力与产业协同共建价值，充分体现开源生态的蓬勃生命力。
参会开发者与展区技术专家围绕落地应用场景展开深入交流：
**某硬件厂商技术人员：** “希望平台进一步扩大硬件定制与兼容范围，把整机运行效果优化得更好，固件安全防护也做得更扎实。” **某软件研发工程师：** “期待平台能更好适配各类特殊部署场景，同时优化版本管理和编译环节，让使用体验更佳。”
社区持续迭代南北向开发架构与运行体系，各项优化工作始终稳步推进，本次收集的建议也将融入后续规划持续精进。
openUBMC 坚持以创新夯实技术底座，不断提升平台可靠性，全面保障各类业务平稳落地。
* * *
## 02 Hands-on实操区：沉浸式实战演练，降低开源开发门槛
实操体验区吸引众多开发者上手演练，开发者们基于 openUBMC Studio 一站式开发平台，完整体验环境部署、工程构建、硬件适配等全流程。
平台采用可视化、轻量化设计，搭配容器化部署模式，摒弃复杂操作，有效降低了 BMC 开发门槛，收获现场参与者一致认可。
现场多位开发者结合实操体验分享了感受，对产品功能、使用体验及社区服务给予高度肯定：
**某企业开发者：** “openUBMC Studio 的 AI 功能十分实用，真切帮我们解放双手、提升效率。我们团队已有同事在个人 PC 上完成 openUBMC 部署，依托配套文档顺利完成全部操作，成功编译出 UBMC 固件，整体体验很不错。”
“以往使用 openUBMC Studio 需依托 Linux 环境，如今适配 Windows 系统，对不熟悉 Linux 的使用者而言友好了许多。另外社区开设的 Grow Up 系列培训质量很高，希望后续可以提供培训录屏，方便大家回看学习。”
**某高校开发者：** “平台新增 AI 功能是一大亮点，让开发工作更聚焦、更高效。同时也希望在学习使用的过程中，能增加阶梯式引导流程，参考游戏‘升级闯关’的模式，让上手路径更清晰。”
社区始终聚焦开发者需求，不断优化工具功能与文档内容。结合开发者们针对性的意见与建议，也为社区体验细节优化提供更多参考方向。
* * *
## 03 海报展示区：创新成果精彩纷呈，拓展多元应用思路
海报展示区集中展出 **openUBMC × 第八届 CCF 开源创新大赛** 优秀参赛作品。顺应 BMC 开放化、智能化发展趋势，openUBMC 赛道聚焦智能运维、嵌入式 AI 两大方向，吸引超过30+团队参与。
其中百信、宝德、聿宁科技 & 浙江工业大学等企业与高校开发者依托 openUBMC 的插件化架构及北向自接入能力，在本次KADC展示了创新多元思路：既有 PVE 虚拟化轻管理、SNMP 智能运维等实用成果，也有基于 Hi3095 开发板打造的轻量化 LLM、BMC 大模型智能体、端侧边缘智能系统等多种北向自定义应用，为算力设备管理的定制化与场景化创新提供了更多可能。
* * *
本次KADC大会，openUBMC以多元展区形态、实战化体验、前沿创新成果，生动诠释了“开源共建、突破边界”的平台价值。面向未来，openUBMC将继续携手开发者与产业伙伴，共同推动算力基础设施管理走向更开放、更易用、更智能的新阶段。
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://gitcode.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2026KADC-techforum/
---
新闻资讯
KADC 2026 openUBMC 技术分论坛圆满举办 ┃ 打破业务边界，构筑接入新范式
# KADC 2026 openUBMC 技术分论坛圆满举办 ┃ 打破业务边界，构筑接入新范式
2026/05/26
2026 年 5 月 23 日，鲲鹏昇腾开发者大会 2026（KADC 2026）openUBMC 技术分论坛在北京顺利举办。本次论坛以“打破业务边界，构筑接入新范式”为主题，汇聚产业从业者、生态合作伙伴与社区技术骨干，集中展示多场景创新应用成果，深度研讨算力基础设施管理前沿技术与行业发展方向。
* * *
## 开场致辞：梳理阶段成果，共绘发展蓝图
华为计算产品线云与计算硬件部部长任超为本次论坛进行开场致辞。
开源一年多以来，openUBMC 依托跨平台、跨领域的全产业链协同模式稳步发展。目前社区汇集 **600 余名开发者**、**36 家成员单位**，代码量突破 **300 万行**，累计发布 **7 个版本**，孵化 **90 余个商业发行版**，超百个商业项目落地智算、IDC、边缘计算等多个场景。
借助南向部件驱动规范，多家厂商自主完成驱动开发，实现 **50 余款硬件部件**标准化接入，20 余家产业链企业共同参与标准制定，产业协作体系逐步完善。任超表示，未来社区将持续联动产业链上下游深化协同共创，不断拓宽 BMC 创新应用边界，更好支撑多样化算力业务发展。
华为计算产品线云与计算硬件部部长 任超
* * *
## 技术演讲：南北能力齐落地，实战成果集中亮相
本场论坛邀请多位产业技术专家依次分享技术创新与商用实践，全方位展现 openUBMC 南北向技术成果。
openUBMC 技术委员会主席宋铜铃发表《openUBMC：打破业务边界，构筑接入新范式》主题演讲。
他谈到，随着硬件架构与算力应用持续迭代演进，传统 BMC 管理模式正面临全新应用挑战。openUBMC 积极突破固有业务边界，为此，社区在2025年推出南向部件驱动规范的基础上，正式启动北向自接入统一规范编制工作（预计2026年底发布），将从设备接入、特性定制到多领域协同，打造一套南北贯通的自接入创新方式。
借助南北标准化能力，openUBMC将拓展至算力加速、性能优化、可靠性升级、AI 应用等业务领域，适配各类定制化场景，助力行业搭建高效开放的算力设备管理体系。
openUBMC 技术委员会主席 宋铜铃
* * *
南方电网电算工程有限公司数据中心事业部经理刘运分享了《南网妙算系列高能效服务器技术创新实践》。
南网基于openUBMC 开源生态探索绿色算力建设路径，搭载智能温控调控策略优化设备散热管理，显著提升整机运行能效。通过自研智能调速算法接入openUBMC，搭建硬件层级能效管控体系，实现能耗精准监测与动态调度，切实解决数据中心能耗管控难题，助力南网高效落实节能降碳目标，为行业绿色算力规模化应用提供成熟实践范例。
南方电网电算工程有限公司数据中心事业部经理 刘运
* * *
宝德BMC研发主管邱豪分享了《Hi171X AI部署调优与openUBMC AI组件设计实践》，系统介绍了基于BMC创新AI组件的设计思路，以及在硬件算力限制下的模型优化经验。
团队依托openUBMC开源生态，已实现嵌入式领域LLM与AI Agent的初步落地，后续将持续探索与新业务场景的深度融合，为行业算力设备管理提供全新思路。
宝德 BMC 研发主管 邱豪
* * *
openUBMC TC委员、河南昆仑 BMC 架构师王钦东结合实战运维场景，分享《基于 openUBMC 插件机制扩展多样化硬件固件升级设计实践》。
针对计算场景硬件多样化带来的的固件升级性能等运维难题，团队依托 openUBMC 轻量化插件技术，实现硬件总线资源高效利用与动态调度，私有协议快速适配，有效解决固件升级耗时过长等行业痛点，为多样化硬件固件高效迭代、规模化运维创新提供有力支撑。
openUBMC TC 委员、河南昆仑 BMC 架构师 王钦东
* * *
openUBMC TC委员、河南昆仑 BMC 架构师王钦东结合实战运维场景，分享《基于 openUBMC 插件机制扩展多样化硬件固件升级设计实践》。
针对计算场景硬件多样化带来的的固件升级性能等运维难题，团队依托 openUBMC 轻量化插件技术，实现硬件总线资源高效利用与动态调度，私有协议快速适配，有效解决固件升级耗时过长等行业痛点，为多样化硬件固件高效迭代、规模化运维创新提供有力支撑。
openUBMC TC 委员、昆仑太科 BMC 业务主管 王亚洲
* * *
openUBMC TC委员、昆仑太科BMC业务主管王亚洲分享《基于 openUBMC 的鲲鹏模组商业实践》。
针对模组商用落地技术难点，团队围绕定制化硬件适配、FRU 数据管理展开技术解读，并分享了基于北向自接入的落地案例。昆仑太科依托openUBMC北向自接入能力实现 UDP 对外通讯功能，为鲲鹏模组规模化商用、定制化运维软件自主接入积淀实践经验。
沐创固件专家 陈奎真
* * *
## 圆桌会议：南北协同，共筑算力设备智能管理新范式
分论坛最后进入圆桌研讨环节，与会嘉宾围绕“北向开放能力支撑全场景智能运维”与“南向标准化驱动异构部件协同创新”两大话题展开深入讨论。结合各自业务视角，与会嘉宾们分享了实践经验与前瞻思考，为 openUBMC 在开放架构深化、南北向生态协同及行业场景落地等方向上明确了演进共识。
随着南向驱动标准发布和北向自接入规范正式启动，openUBMC 南北向能力布局已全面铺开。
面向未来，openUBMC 的定位不再局限于传统服务器运维，而是通过持续的多维技术创新，服务于更复杂、多元的算力设备业务场景。社区将持续深化开源协作，携手产业伙伴共同构筑算力设备智能管理的新范式。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2026Wuhan-meetup-review/
---
新闻资讯
openUBMC Meetup 武汉站顺利举办｜长江计算 x 神州鲲泰首次联合主办，共促 BMC 开源生态
# openUBMC Meetup 武汉站顺利举办｜长江计算 x 神州鲲泰首次联合主办，共促 BMC 开源生态
2026/03/25
# 活动回顾｜openUBMC Meetup 武汉站
2026年3月20日，由 openUBMC 开源社区牵头，联合社区成员单位 **长江计算**、**神州鲲泰** 共同举办的 openUBMC Meetup 武汉站圆满落幕。本次活动汇聚了社区核心伙伴，全天呈现 **10+ 精彩议题**，从社区动态到商业实践，从前沿 AI 探索到全新开发平台解读，为现场开发者带来了一场关于 BMC 技术创新的深度交流。
## 社区动态：openUBMC 稳步前行
活动伊始，**openUBMC TC 委员程子明**带来社区季度进展分享。openUBMC社区持续活跃，目前已发布25.12 LTS版本，26.05 LTS SP2计划于5月30日推出。技术规划方面，多算力平台管理组件已启动开发，将支持x86、RISC-V等不同架构的统一管理；HAL层设计已完成，可屏蔽不同BMC芯片的驱动差异。此外，社区正式成立AI SIG，旨在通过引入AI技术降低开发门槛，探索大语言模型在带外管理系统中的创新应用。
## 商业实践：从高密存储到 AI 服务器的落地答卷
### 高密存储服务器产品化实践
**长江计算BMC系统工程师华从辉**分享了高密存储机型的产品化实践。该机型支持70盘带外管理，支持双RAID卡与双型号风扇分区调速。重点介绍了三个层面的实践案例
- **存储特性层面**：面对70盘场景下硬盘信息刷新长达20+分钟的挑战，团队通过任务分离、任务分级、无效冗余优化将刷新时间压缩至8分钟；
- **硬件适配层面**：针对四块15盘背板跨槽位即插即用的需求，运用openUBMC的SR公式实现了自适应盘符机制，零C零Lua开发；
- **部署层面**：通过openUBMC Studio构建CSR ALL包，将多次升级、多次重启优化为一次升级、一次重启，大幅提升部署效率。
### CPLD 升级挂死案例分析
**长江计算BMC开发工程师赵维松**深入剖析了I2C升级CPLD过程中概率性挂死的根因。在R420K项目中，由于JTAG信号线路过长只能采用I2C升级，压测时出现每4-6小时挂死一次的现象。通过分析发现，挂死源于写入失败后未擦除Flash即重试写入，违背了CPLD Flash“先擦后写”的物理特性。团队优化了异常处理机制，写入失败后全量擦除Flash并从头全量写入，重试3次，优化后连续升级测试3天以上未再出现挂死。
### 互联网客户快速交付实践
**长江计算BMC系统工程师李小灿**分享了应对互联网客户差异化需求的交付经验。面对客户需求差异大、版本迭代紧凑、问题响应紧急三大挑战，团队形成了可复用的解决方案：
- **机型配置**：利用openUBMC的CSR+硬件自发现机制，通过oem\_product组件融合多机型配置，2个HPM镜像即可支撑13个机型。
- **功能定制**：通过客户组件实现功能隔离，不同客户的定制需求独立维护，互不干扰。
- **版本管理**：采用单一主干原则+版本火车进行分支管理，重新定义版本配套性，同步社区版本迭代节奏。
- **问题定位**：依托本地化开发模式，结合代码逻辑与日志联合分析，利用社区AI助手提升问题定位效率。
### AI 服务器 PCIe Switch 多 GPU 自发现
**神州鲲泰BMC软件高级工程师刘杰**分享了在KunTai R624 K2 4U8卡AI服务器中引入PCIe Switch板的实践。在4U8卡服务器项目中，通过PCIe Switch芯片将有限的CPU PCIe通道高效扩展为多个下行端口，实现多GPU挂载。
- **两大核心功能**： **GPU 设备自发现**：
在PCIe Switch扩展拓扑下，通过在bmc与bios的交互中新增SwitchPort字段，实现槽位号与BDF号的精准关联，自动识别并枚举所连接的GPU设备。 **线缆状态管理**：
基于openUBMC原生功能扩展，新增Switch板线缆检测模块，集成线缆连接检测与状态上报机制，实现对下行物理链路的可靠监控。 通过引入PCIe Switch，主板走线设计大幅简化，GPU卡间P2P通信延迟降低20%，千亿参数级AI模型训练迭代速度提升25%，收敛精度提升1.5%。
## 技术创新：社区生态拓展与 AI 赋能
### M.2 RAID 卡带外管理创新
**分百信BMC高级工程师罗昊**分享了基于Marvell芯片的M.2硬RAID卡带外管理实践。该卡采用“盘卡一体”设计，无硬盘背板，专为系统盘设计，默认RAID1。
- **次实践实现两大突破**：
- 将openUBMC存储框架扩展至Marvell体系，通过推动SML开源，完成了SDK适配与存储管理库开发。
- 新增“盘卡一体”架构支持，通过灵活处理Drive与PD映射关系、虚拟RAID阵列，兼容原有层级设计。 开发周期约4个月，涉及5个组件、5种编程语言、约5000行代码，体现了openUBMC框架的可拓展性与低耦合性。
### x86 功能适配
**百敖BMC主管 & openUBMC TC委员汪涛**介绍了Intel/AMD平台特性向openUBMC迁移的工作。重点包括：
- **Intel CPU 功能适配**（远程调试）、ACD（故障诊断）、Node Manager（功率封顶）、RAS Offload（错误处理）、Seamless Update（BIOS热升级）等。
- **VGA 共享内存**:利用BMC VGA接口未使用内存空间，实现BIOS与BMC间大文件高效传输，支持系统资产信息（约10KB）与BIOS Setting（约2MB）的快速交换。
- **MMBI（内存映射 BMC 接口）**:基于eSPI总线外设通道，实现内存映射访问，带宽可达23MB/s，相对KCS的33KB/s提升两个数量级。
### 基于 RAG + 知识图谱的社区机器人
**华为BMC研发工程师李兆天**分享了社区AI机器人的技术方案。针对社区论坛存在的人工解答效率低、信息检索难、知识治理难三大痛点，团队构建了基于大模型+知识图谱+向量数据库融合架构的知识基座和社区AI机器人：
- **向量 + 图双引擎检索**：通过向量索引实现文档分片检索，通过知识图谱挖掘语义关联，实现精准召回。
- **多智能体安全审查**：对输入输出和检索内容相关性进行检查校验，保障回答可靠性。
- **数据飞轮机制**：基于用户点赞/点踩反馈，持续优化知识质量与问答效果。 未来计划引入代码上下文管理，构建代码图谱和代码索引，实现代码检索并支持复杂问题故障定位。
## 生态工具：全新 openUBMC Studio
**华为BMC研发工程师李睿宸**带来openUBMC Studio深度解读。2026年BMC Studio品牌升级为openUBMC Studio，同时带来四大升级：
- **一键安装，快速开箱**：openUBMC Studio大幅简化安装步骤，提供Windows、Ubuntu的一键安装包，内置引导式配置，预装核心功能插件，10分钟完成环境初始化。
- **模型驱动开发**：规则集通过社区基础设施分发，编码阶段实时校验CSR属性类型、引用正确性，支持表达式调试与SMC命令字计算。
- **可视化 + IDE 无缝切换**：在可视化配置能力基础上新增完整IDE能力，保留社区开发者操作习惯，支持代码与可视化页面双向同步，与命令行工具共同构建完整开发流程。
- **社区基础设施高度集成**：支持一键登录社区账号，联动社区制品仓等基础设施能力，未来将继续集成社区文档、论坛等功能，实现一站式社区开发。 openUBMC Studio 集成了code-OSS内核，全面兼容vscode插件生态，包括openVSX等主流插件市场，与Claude code、Cline等主流AI插件无缝对接，后续将继续探索AI赋能openUBMC社区的更多可能。
## 第八届 CCF 开源创新大赛：BMC 的 AI 时代机遇
**openUBMC TC委员张雨博**在本次Meetup发布了第八届CCF开源创新大赛openUBMC赛道。本赛道涵盖“AI时代智能运维创新平台”与“嵌入式芯片LLM挑战”两大方向，总奖金10万元，无论你是想探索BMC的创新边界，还是希望在嵌入式AI领域一展身手，这里都有你的舞台。欢迎扫码进群，组队参赛，赢取丰厚奖金与开源社区影响力！
## 结语
江城之约，因开源而相聚，因技术而共鸣。从社区动态到商业实践，从AI探索到工具革新，每一位分享者的真知灼见，每一位参与者的专注倾听，都让这场Meetup超越了议程本身的意义。我们相信，当来自不同厂商、不同背景的开发者坐在一起，分享踩过的坑、探索新的路，openUBMC的生态便有了生长的土壤。 下一站，我们期待在更多城市与你相遇——共同打造属于开发者的开源BMC社区，让技术的力量，因开放而更强大。
> **直播回顾链接**：https://www.chaspark.com/#/live/1249884591673499648
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2026ccf-competition-recap/
---
新闻资讯
圆满收官｜第八届 CCF 开源创新大赛 openUBMC 赛道结出创新硕果
# 圆满收官｜第八届 CCF 开源创新大赛 openUBMC 赛道结出创新硕果
2026/08/29
# 圆满收官｜第八届 CCF 开源创新大赛 openUBMC 赛道结出创新硕果
近日，第八届 CCF 开源创新大赛 openUBMC 赛道圆满落幕！
本次赛道聚焦 BMC 运维管理创新、大模型轻量化部署两大核心方向，紧扣 AI 算力基础设施智能化运维痛点，为广大青年开发者与产业技术团队搭建了高水平的开源创新实践平台。赛事热度高涨、覆盖面广泛，赛事共吸引 **41 所高校**、**120 支战队**、**154 人次** 踊跃参赛，学生参与占比达 **92.2%**，青年学子成为赛道创新主力军，产学研融合成效突出。赛事期间涌现出一大批创新性强、贴合产业需求、具备落地价值的优质作品，持续为算力基础设施开源生态注入鲜活的青春力量。
本次赛事不仅汇聚海量高校青年人才，更获得了算力产业链企业的深度加持。百信、宝德、华瑞数鑫等行业头部企业积极组队参赛，以真实产业场景、落地技术需求赋能开源创新，充分印证了产业端对 openUBMC 开源生态的高度认可与深耕布局。
* * *
## 获奖名单
* * *
## 佳作云集！多维度解锁运维创新新范式
> ### 赛题一：重塑 BMC：AI 时代智能运维创新平台
#### 一等奖：BMC PVE 虚拟化运维轻管理平台
作品针对虚拟化环境下 BMC 运维痛点，打造轻量化管理平台，提升资源管理效率与运维便捷性。应用场景明确，功能设计贴近实际需求，具备较好的实用价值和落地前景。
- _扫码查阅作品_
#### 二等奖
**1\. AegisBMC**
聚焦 BMC 设备全生命周期运维，围绕设备可靠性保障、安全风险管控、自动化运维升级三大方向创新突破，有效解决设备运维碎片化、人工干预多等问题，筑牢算力设备稳定运行根基。
- _扫码查阅作品_
**2\. AI Cluster Guard 智能运维方案**
基于 openUBMC 原生生态搭建一体化智能运维体系，实现硬件状态多维监测、故障智能预警、集群协同管控，全方位提升算力集群运维的智能化、精细化水平。
- _扫码查阅作品_
> ### 赛题二：嵌入式芯片的 LLM 挑战
#### 一等奖：bmc-llm-嵌入式 BMC 平台轻量化 LLM 部署
**作品亮点**：立足边缘智能运维发展趋势，创新探索轻量化大模型与嵌入式 BMC 硬件的融合落地路径，成功将 AI 智能分析、自主决策能力融入设备底层运维场景，实现传统硬件运维向智能化、智慧化运维升级，技术理念前瞻，行业借鉴意义极高。
- _扫码查阅作品_
#### 二等奖
**1\. openUBMC 本地智能运维助手**
**作品亮点**：深耕本地运维场景，集成智能数据分析、设备状态研判、异常故障辅助定位等核心能力，简化运维操作流程，降低运维门槛，助力基层运维高效落地。
- _扫码查阅作品_
**2\. 基于 openUBMC 的 AI Agent 管理组件**
**作品亮点**：创新性引入 AI Agent 智能编排能力，实现运维任务智能拆解、自动调度、自主执行，构建自动化、智能化的运维新模式，全面升级数据中心运维效能。
- _扫码查阅作品_
* * *
## 以赛促创，赋能开源生态长效迭代
第八届 CCF 开源创新大赛-openUBMC 赛道赛事，有效推动了 BMC 故障管控、设备可靠性优化、能效提升、智能运维等关键技术的迭代升级，为大规模、异构化、智能化数据中心的高质量发展提供了丰富的创新方案与实践案例。
未来，openUBMC 社区将持续深化校企联创发展模式，依托开源实习、开源之夏等优质开源平台，持续吸纳赛事优秀青年人才入驻社区、深耕贡献，打造「赛事创新 - 人才培育 - 成果转化 - 生态迭代」的完整闭环，持续壮大开源开发者队伍，完善算力基础设施开源生态体系。逐光开源，筑梦创新！
感谢每一支参赛战队、每一位开发者的深耕与付出。期待下一届赛事，更多青年创新力量扎根 openUBMC，持续解锁智能算力运维新可能，共筑开源算力新生态！
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://gitcode.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2026chengdu-meetup-review/
---
新闻资讯
openUBMC Meetup 成都站圆满举办｜华鲲振宇联合主办，共促 BMC 开源生态
# openUBMC Meetup 成都站圆满举办｜华鲲振宇联合主办，共促 BMC 开源生态
2026/08/24
# openUBMC Meetup 成都站圆满举办｜华鲲振宇联合主办，共促 BMC 开源生态
openUBMC Meetup 成都站活动现场嘉宾合影
8 月 14 日，由 openUBMC 社区与四川华鲲振宇智能科技有限责任公司联合主办、四川鲲鹏生态创新中心协办的 openUBMC Meetup 成都站圆满举办。
活动当天，openUBMC 社区多位 TC 委员、Maintainer，华为、华鲲振宇及多家社区成员单位的技术专家齐聚成都，聚焦 openUBMC 技术分享和产业实践，围绕产业落地痛点与实际研发过程中遇到的问题，重点介绍了可信计算架构方案、板卡管理常见问题定位、RAID 卡与电源适配实践，以及基于 Agent 的智能化调试流程，活动吸引线上/线下众多开发者参与深度交流。
* * *
## 十场分享，读懂 openUBMC 的技术底色
### 01 openUBMC Community Updates
openUBMC TC 委员、华鲲振宇 BMC 架构师 刘松
**亮点**：重点工作全面铺开，关键技术完成突破；“主线创新+LTS稳定”双轨并行，版本机制走向成熟；社区高速发展，成员单位、开发者数量、代码贡献量持续增长——向上生长的 openUBMC 社区，背后离不开每一位开发者的努力。
开场环节，openUBMC TC 委员、华鲲振宇 BMC 架构师刘松同步了社区的最新进展：
- **社区重点工作**：运维竞争力持续提升，已完成 CPLD 无感升级技术、硬盘/网卡等关键部件带外升级、算法自接入框架等能力构建；多算力与多芯片领域实现突破，AST2600、LS1020 等 BMC 芯片及 Intel 最新代次 Birch Stream CPU 等基础能力已完成接入与交付；南向驱动规范端到端测评和认证体系搭建完成；BMC 领域 LLM、MCP、故障模式库等 AI 体系建设亦取得阶段性成果。
- **版本发布**：自 25.03 首个社区版本发布以来，社区已按季度稳定发布 25.06 版本、25.09 版本、26.03 版本、26.06 版本；LTS（长期支持）累计发布 25.12 LTS 版本、25.12 LTS SP1 版本、25.12 LTS SP2 版本三个版本，25.12 LTS SP3 版本计划于 8 月 31 日发布。
- **社区生态**：自开源以来，openUBMC 已汇聚 **35 家** 成员单位、**791 位** 开发者，社区版本下载量达 **167,171** 次，论坛累计访问量 **1.597 亿** 次，社区组建 **13 个** SIG，累计召开 **525 场** SIG 例会，Issue 与 PR 闭环率分别达到 **80.6%** 和 **96.3%**，代码贡献累计突破 **783 万行**。这些数字背后，展示的是一个持续向上生长的开源社区。
* * *
### 02 构建可信计算安全体系的设计和测试能力
华为 BMC 安全技术专家 李小川
**亮点**：将可信计算做到国际顶级认证水平，BMC 不只是「能用」，更是应对 AI 安全威胁的防护体系，具备产业出海、进入高合规门槛市场的「可信」底座。
华为 BMC 安全技术专家李小川分享了当前 AI 带来的安全威胁与挑战，他指出 AI 已渗透进攻击的全链条，使攻击效率提升 10 倍以上，漏洞挖掘和利用从数天降至数十分钟，攻击门槛降至初学者水平。而可信计算技术，可有效防范 AI 安全威胁，当前正推进“基于 BMC 可信根的 TPCM”的可信计算 3.0 方案，依托可信根硬件安全“三防”（防侧信道、故障注入、物理攻击），建立芯片级信任锚点，将信任逐级传递到整个系统，通过 BMC 启动度量，消除了业务上电过程中的不可信窗口，一套架构同时兼容 TCM/TPM/TPCM。目前鲲鹏等关键固件均通过CC EAL4+等高等级安全认证，整机通过可信计算 3.0 增强级安全认证。他还结合即将生效的 CRA《网络弹性法案》的合规要求，从可信体系和安全测试体系维度分享了 BMC 的安全实践，建议社区构建端到端的软件供应链安全保障能力，提升产业安全能力。
* * *
### 03 超节点管理设计方案探索指导
openUBMC Hardware SIG Maintainer 常德兴
**亮点**：把一线工程师踩过的坑沉淀成标准化问题排查指导方法，是社区「授人以渔」式赋能的典型体现——大幅降低开发者新板卡接入的学习成本。
openUBMC Hardware SIG Maintainer 常德兴结合 CSR 加载、PCIe 拓扑、MCTP 链路等实际场景，围绕日志信息、设备拓扑、协议通信和根因定位，系统梳理了从拓扑建立、MCTP 通道建立、设备 BDF 上报到 CSR 加载的完整排查路径，并用真实案例讲解了如何通过日志关键字快速定位 PCIe 板卡不加载、多组件对象处理时序异常、RAID 卡传感器获取异常等典型问题。他还特别提到，社区近期已尝试将 AI 辅助能力引入问题定位流程，通过让 AI 分析多源日志、给出定位结论乃至修复代码，提升了排障效率。
* * *
### 04 基于 openUBMC 的集群管理设计
华鲲振宇 BMC 高级工程师 谢海军
**亮点**：从管理一台服务器到管理整个超节点，体现的是 openUBMC 架构本身的延展性——同一套技术底座，随算力形态演进而演进。
华鲲振宇 BMC 高级工程师谢海军的分享覆盖传统集群管理方案、后冯·诺依曼架构下 BMC 体系的机遇与实践、端侧 AI 跨界多算力芯片管理三个层次。他指出，当前超节点管理本质是在单节点 BMC 基础上增加机柜、网络协同的管理方案，对 BMC 在故障、运维、能效调控等方面的能力提出了更高的要求。而后冯·诺依曼架构无中心计算的设计思路，带外管理随算力形态也会逐步向分布式部署演进。大量的对等 xPU 单元给 BMC 管理带来巨大挑战，针对这些问题，提出一个探索方向：参考「车载安全岛」的设计，通过分布式安全岛部署、Mesh 高速互联网络、逻辑节点抽象等分布式协同的方案，解决超节点/集群的状态一致性、异步体系故障判断和溯源、多 BMC 网元互联导致攻击面扩大等问题。
* * *
### 05 openUBMC 多芯片适配与组件迁移指导
百敖 BMC 研发经理 周江坤
**亮点**：新增芯片不需要「重新造轮子」，体现的是 openUBMC 作为中立开放架构的价值：帮助伙伴复用已有 BMC 资产，摆脱对单一芯片厂商技术栈的路径依赖，掌握供应链自主权。
当前芯片存在供应连续性风险，而大部分 CPU 厂商能力与特定 BMC 技术栈深度绑定，BMC 软件资产复用迁移成本高、周期长——这是许多 BMC 生态伙伴共同面对的痛点。百敖 BMC 研发经理周江坤围绕 openUBMC 多芯片适配与组件迁移展开分享，以英特尔 X86 平台组件的迁移实践为例，系统介绍了源码梳理、开源化改造、驱动适配、QEMU 仿真验证到上板验证的标准迁移流程，并提炼出「组件源码不变、新增芯片仅适配驱动层、先在 QEMU 环境验证降低试错成本、流程可复用形成模板」四大迁移原则。他透露，团队已完成英特尔平台五大核心功能包向 openUBMC 的迁移并通过 QEMU 仿真验证，下一步将开展上板联调、完善标准化驱动接口，并逐步支持更多 BMC 芯片型号，最终纳入商用版本。
* * *
### 06 openUBMC Agent：从缺陷定位到升级验证的全链路工作流实践
软通华方 BMC 研发工程师 李庆华
**亮点**：AI Agent 不再只是聊天辅助，而是真正嵌入了从问题定位到升级验证的完整工程闭环。这标志着「openUBMC + AI」从概念走向了可复现的生产力。
软通华方 BMC 研发工程师李庆华结合真实缺陷处理场景，展示了 Agent 从问题发现、现场取证、源码分析、代码修改，到构建升级和效果验证的完整工作流程，并提炼为 Case（问题受理）、Debug（取证定位）、Developer（代码修改）、Delivery（构建部署）、Fresh Verify（重新取证复验）、Closeout（闭环输出）六个阶段，由 Context Runtime 驱动任务状态流转、Target Runtime 提供设备连接能力、openubmc-kb 知识库 MCP 提供候选方案检索。以 RAID 环境资源归属丢失问题为例，Agent 创建「Case」任务档案记录环境与验收标准后，自主完成定位、改代码、构建签名与升级验证，最终实现问题闭环——BMC 重启后资源归属重新建立，全部硬盘恢复健康。他特别提到，把每一步中间状态结构化写入 Case、而非把全部会话上下文重复带入模型，这套机制在保证可追溯性的同时，显著降低了 Token 消耗。
* * *
### 07 基于南向驱动规范的 RAID 卡适配实践
华瑞数鑫高级开发工程师 王伟
**亮点**：任何一家硬件伙伴都能照着南向驱动规范把自家部件「接入」进 openUBMC，体现的正是标准化生态的开放程度和复用效率。
华瑞数鑫高级开发工程师王伟以 B261s Boot RAID 卡的适配为案例，分享了基于南向驱动规范进行硬件适配、问题定位和功能验证的实践经验。他谈到，服务器领域 RAID 卡厂商众多、通信协议与功能特性各异，若没有统一框架，每新增一款 RAID 卡都需要改动大量模块，维护成本高昂；openUBMC 的解法是通过「硬件自发现 + SML 存储管理库 + 南向驱动规范」构成的三层协作模型实现标准化适配——新硬件只需按规范开发存储管理库、注册通信回调，即可复用北向接口层与拓扑管理框架，而无需改动整体架构。
* * *
### 08 基于 openUBMC 的开发工具提升效率实践
华鲲振宇 BMC 研发工程师 曹鹭洋
**亮点**：与「减少一次不必要的重启」较真，体现的是社区对一线运维体验的持续打磨——社区重视开发者真实日常体验。
华鲲振宇 BMC 研发工程师曹鹭洋聚焦 openUBMC 开发工具和热更新能力，探讨如何通过更加灵活的更新和调试机制，减少不必要的整包升级和 BMC 重启——当前 openUBMC 已支持配置维度的热加载，但是紧急修复漏洞或调优功能时仍需刷新整包固件。他分享的探索思路是：openUBMC 的微组件架构天然支持组件独立开发、测试与发布，配合 Systemd 对组件生命周期的管理，理论上可以把升级对象从「整个 BMC」缩小到「单个组件」；团队已围绕热更新包操作资源协作接口、以及在不重启任何组件的前提下通过 hpm 包动态加载新服务等场景展开验证，探索缩短研发验证链路、减少重复操作的路径。
* * *
### 09 CRPS 电源 3+N 冗余管理在 openUBMC 落地实践
软通华方 BMC 研发工程师 任平
**亮点**：面对多样电源设计、多种协议的真实复杂硬件场景，依然能用同一套分层框架标准化纳管，是对 openUBMC 南向驱动规范工程严谨度的又一次实测。
软通华方 BMC 研发工程师任平从真实电源硬件场景出发，围绕 CRPS 电源 3+N 冗余架构，分享了从硬件拓扑识别、协议通信到 openUBMC 适配和验证的完整实践。面对 6 路 CRPS 电源、2 块电源板带来的地址冲突问题，团队通过 PCA9545 通道隔离实现同组地址复用；在协议层，基于 PMBus 1.3+ 标准并配合 CRC8 校验、失败重试机制保障通信可靠性，同时实现电源工作模式的冷冗余切换控制。他特别强调了「CSR 负责描述硬件是什么、Protocol 负责怎么读写、Monitor 负责何时采集、北向负责怎么呈现」的分层解耦原则，使新增电源型号无需侵入现有通用电源路径，并具备完善的异常自动回退能力，避免设备停留在异常状态。
* * *
### 10 openUBMC Studio AI Agent 自主 BMC 调试工作流介绍和实践分享
openUBMC AI SIG Maintainer 范信鑫
**亮点**：22 个 MCP 工具、多类专用 Agent、一键日志分析——openUBMC 把 AI 原生的开发者体验做成了可现场上手的产品。
openUBMC AI SIG Maintainer 范信鑫围绕 openUBMC Studio 与 AI Agent 的结合，介绍了如何通过 MCP（Model Context Protocol）机制，将真实 BMC、调试工具、知识库和专家能力连接起来，让 OpenCode、Codex 等主流 Coding Agent 工具具备理解 openUBMC 组件关系、MDB 领域术语的能力。目前 openUBMC Studio 已提供 22 个 BMC 远程管理 MCP 工具（覆盖连接配置、分组管理、连通检测、命令执行、文件传输、命令宏、固件升级 7 类场景）与 5 个专用调试 MCP 工具（MDB 对象查询、D-Bus 服务查询、Systemd 状态查询、日志检索、路径权限校验），并内置代码巡检、故障诊断、PR 评审三类 Agent，使通用 Agent 从简单的代码辅助进一步进入问题定位、代码分析、调试和验证等真实 BMC 研发环节。演示环节还展示了一键日志采集与可视化解析工具，能把原本分散在多组件、多协议层的原始日志转化为可交互查询的结构化视图，为后续接入 AI 智能诊断打下基础。
开发者现场体验 openUBMC Studio AI Agent 调试工作流
现场实践环节，开发者对照四项实操任务动手体验——完成一次 BMC 一键日志分析并浏览告警与板卡信息、配置 BMC 环境完成一次 HPM 包一键升级、安装 openUBMC Skills 并借助 Fault Diagnosis Agent 进行环境问题诊断、通过社区工作台启动一次 PR 的 AI 检视，对 Agent 在真实 BMC 调试场景中的实用价值表现出较高关注，并提出了进一步优化建议。
* * *
## 从技术分享走向现场交流，让真实需求持续推动社区演进
从基础能力建设，到真实场景落地，再到 AI 赋能研发，本次 Meetup 不仅展示了 openUBMC 当前的技术能力，也为企业伙伴、社区专家与开发者搭建了面对面交流的平台。而这也是 openUBMC 一直以来努力的方向——以积极开放的方式，持续将社区能力转化为可产品化的技术，将真实场景中的经验沉淀为开发者可复用能力，帮助成员单位与开发者降低开发门槛、提升交付效率，推动产品适配与业务场景加速落地。
未来，openUBMC 将携手更多成员单位、产业伙伴与开发者，持续深化技术交流、共建产业生态。
**下一站 Meetup，期待与更多开发者相聚。**
* * *
- 点击 _“链接”_ 即可查看直播回放：https://www.chaspark.com/#/live/1303506534771056640
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://gitcode.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2026hefei-meetup-review/
---
新闻资讯
openUBMC Meetup 合肥站圆满举办｜百信联合主办，共探 BMC 开源生态实践
# openUBMC Meetup 合肥站圆满举办｜百信联合主办，共探 BMC 开源生态实践
2026/10/08
# openUBMC Meetup 合肥站圆满举办｜百信联合主办，共探 BMC 开源生态实践
openUBMC Meetup 合肥站活动现场嘉宾合影
2026 年 9 月 22 日，由 openUBMC 社区与百信信息技术有限公司联合主办的 openUBMC Meetup 合肥站圆满举办。
openUBMC 开源发展委员会委员、百信研发总经理鞠荣荣，开源发展委员会秘书长王瑞锋出席本次活动。同时，openUBMC 社区多位 TC 委员、Maintainer，以及来自百信、华瑞数鑫、华为、沐创等社区伙伴的技术专家齐聚合肥，围绕社区最新进展、北向架构设计、产品集成测试、南向部件标准与适配、板卡问题定位、硬件调试工具及 AI Agent 智能调试等议题展开深度分享，共同探讨 BMC 技术落地的关键问题与解决思路，活动吸引线上线下众多开发者参与深度交流。
* * *
## 10 场分享，直击 openUBMC 工程内核
### 01 openUBMC Community Updates
openUBMC 技术委员会委员 于飞
**亮点**：主线创新与 LTS 长期维护并行推进，算力生态、融合运维、南向规范与 AI 研发能力持续落地，社区技术与生态建设同步提速。
开场环节，openUBMC TC 委员于飞同步了社区最新进展。openUBMC 社区围绕多算力、多芯片场景，持续推进新一代 X86 平台机型及多 BMC 芯片等能力建设。易运维技术，完成网卡、RAID、NVMe 等部件的带外升级能力建设，并持续推进 CPLD 无感升级、并行升级、能效优化、安全签名，以及 event、sensor 高性能组件等重点技术方向。
26.09 版本继续在 hardware、interface、component-drivers、ai、CICD 等 SIG 推进关键能力交付；其中，ai SIG 已有 75 款 Skill 上线，并完成 MCP Server 与 LLM 技术探索验证。版本运作上，社区已形成主线版本与 LTS 长期维护版本并行的机制。
截至目前，社区已汇聚 40+ 家企业、1000+ 位开发者、成立 14 个 SIG，已召开 557 场 SIG 例会，累计 10,502 个 Issue、15,798 个 PR，Issue 闭环率达 86.95%、PR 闭环率达 95.6%；下载量 179,791 次，论坛访问量 1.842 亿次。openUBMC 已形成企业、开发者与 SIG 多方共建、高效协作、持续增长的活跃社区生态，社区规模、贡献产出与行业影响力稳步提升。
* * *
### 02 北向接口架构设计和实现方案介绍
openUBMC 技术委员会委员、interface SIG Maintainer 黄晗
**亮点**：聚焦 BMC 北向接口特点，系统讲解 openUBMC 北向架构总体设计，并深入分享以 DSL 为核心的 Redfish、WebREST、CLI、SNMP、IPMI 接口开发范式，具备灵活扩展、按需裁剪与定制能力。
本次技术分享聚焦 openUBMC 北向接口技术实践，围绕行业标准持续演进、产品形态多元、客户定制需求差异化的行业现状，系统呈现了 openUBMC 北向接口的整体设计思路与阶段成果。
项目以 “分层 + 偏序依赖”“两树分三层” 构建统一架构底座；接口映射 DSL 沉淀 60 + 关键字、12 类语句、7 类校验规则，实现主流接口全覆盖；映射引擎升级至 2.0 提效，支持灵活定制适配差异化场景。
未来团队将持续推动北向标准化建设，重点开展组件低成本适配迁移与互操作性 Profile 落地，逐步完善 OCP HW-Mgmt、DPU/NPU 管理接口、灵衢总线与硬件遥测等技术能力。
* * *
### 03 openUBMC产品化集成测试流程和常见问题分享
openUBMC QA SIG Committer 杨威
**亮点**：三重防护网、五层问题拦截，将质量保障从“版本发布前验证”前移到需求、设计、开发和集成全过程。
本议题围绕 openUBMC 产品化集成测试流程展开，从测试分析、测试设计、测试执行到测试评估，梳理了需求决策、特性开发、版本构建、集成验证与版本发布各阶段的质量活动，以及 QA、docs、release-management 等 SIG 的协同方式。
在系统设计验证环节，以 MCX4121A-ACAT 网卡兼容需求为例，从功能、性能、可靠性、兼容性等维度拆解需求并形成可执行测试点；在 SIT 环节，则覆盖性能、可服务、规格、兼容性、可靠性、安全六类系统级测试。
社区同时建设流水线工具、模块级、版本级三重防护网，通过五层拦截尽可能将问题前移，并持续向伙伴开放测试架构、策略模板、用例规范、自动化框架、QEMU 仿真、版本冒烟等测试能力，相关资产统一沉淀在 openUBMC/QA项目仓。
* * *
### 04 AI Agent 驱动的 openUBMC开发板调试：从远程上电到 RAMFS 验证
百信BMC研发工程师、 openUBMC ai SIG Maintainer 沈威
**亮点**：三个 rootfs 均损坏后，Agent 依托 13 项阶段化 Skills 和远程电源、串口等能力，完成从启动失败到 Web 重新登录的故障恢复闭环，全流程用时 1 小时 00 分 37 秒。
本议题聚焦真机调试中“Agent 能分析，但现场操作仍绕不过去”的现实问题：BMC 挂死后 SSH/Web 入口可能失效，启动阶段日志依赖串口，镜像加载需要网络与 TFTP 环境，软件重启无效时还需要重新上下电。
为此，实践提出“Skills 保存判断与方法，脚本执行动作”的思路，由 Agent 先识别当前处于串口登录、U-Boot 还是 Linux 阶段，再选择下一步 Skill，并带着执行结果继续判断。基于社区已有远程桌面能力，本次进一步沉淀 13 项 bring-up 专项 Skills（PR #141–#153），覆盖串口接入、U-Boot 临时引导、RAMFS、GPP 恢复、管理网络恢复、Redfish 就绪诊断等阶段。
实机案例完整演示“三槽 rootfs 损坏→普通启动失败→RAMFS 装载→重新部署→eMMC 冷启动→Web 登录成功”的恢复与验收过程，并将可复用的方法继续贡献回社区。
* * *
### 05 基于CSR2.0的自发现机制技术分享
openUBMC 技术委员会委员 于飞
**亮点**：为“管理面驱动”建立统一标准，推动部件差异在驱动层完成收敛与消化，让上层 BMC 应用免于反复侵入式改造。
本议题从部件“业务系统侧驱动”已经形成成熟标准，而带外“管理面驱动”长期缺少统一规范的行业现状出发，介绍 openUBMC 南向部件标准化思路。
通过统一部件抽象接口屏蔽硬件差异，采用必选/可选接口分层兼顾标准能力与差异化竞争力，并结合 CSR 自描述、自发现等机制完成部件识别、加载与管理，目标是实现标准部件接入时 BMC 应用层免修改。社区已围绕网卡、xPU、硬盘、RAID 卡等重点部件建立测评与认证体系，形成 L1-L4 分级认证，并持续完善测试工具、用例、兼容性清单与认证流程。
component-drivers SIG 汇聚整机厂商、部件厂商及相关技术伙伴，围绕驱动规范、开发框架、认证体系和生态扩展持续演进，推动南向部件驱动从单点适配走向可复用的标准化能力。
* * *
### 06 板卡管理常见问题定位指导
openUBMC hardware SIG Maintainer 黄雷生
**亮点**：从 CSR 加载到 MCTP 建链，再到北向显示、RAID 卡降速和 NCSI 网卡联动复位，将复杂板卡问题拆解成可复用的分层排查路径。
本议题以“板卡管理常见问题定位”为主线，围绕“拓扑建立→丝印文件生成→带内 BIOS 上报 BDF→读取四元组→匹配并加载 CSR”梳理关键排查点，并通过“环境缺少 PSR，导致拓扑建立失败、丝印文件无法生成”的案例说明PCIe建链问题定位方法。
MCTP 部分介绍 Prepare for Endpoint Discovery、Endpoint Discovery、EID 分配、路由注册等建链阶段，以及从路由、Endpoint、链路报文逐层排查的思路。
随后又结合 Redfish 查询字段概率性为空的时序问题、RAID 卡速率概率跳变、KVM强制下电触发NCSI网卡联动复位等案例，展示如何结合资源协作接口、日志、CSR配置与代码逐层收敛问题，并给出 PCIe 拓扑、MCTP、CSR 配置以及 DMTF 协议等资料入口。
* * *
### 07 基于服务器南向标准的网卡部件驱动自接入实践
沐创固件专家 陈奎真
**亮点**：从 CSR 配置到 NCSI over MCTP 调试，完整走通网卡部件基于 openUBMC 南向标准自接入的工程路径。
本议题介绍了沐创网卡接入 openUBMC 的实践背景，并总结部件厂商在固件开发中面临的共性挑战：不同整机 BMC 软件栈存在差异、管理协议要求不统一、全量学习成本高，以及缺少自主调试手段等。
以实际网卡为例，按照“CSR 准备→服务器硬件拓扑与 SMBus 参数配置→私有协议命令实现→NCSI over MCTP 命令实现→编译集成→协议调试”的路径完成驱动接入，并结合 BMC 侧与网卡固件侧日志定位 MCTP/NCSI 通信问题。
实践体现了南向驱动规范的价值：通过统一接口要求、独立代码模块和社区化发布机制，部件厂商可以更早参与开发、验证和问题定位，降低对具体整机软件栈的依赖，并推动更多硬件厂商参与 component-drivers SIG 共建。
* * *
### 08 openUBMC I2C与Hisport总线调试工具的设计与应用
百信 BMC 高级工程师 、openUBMC ai SIG Committer 罗昊
**亮点**：把设备探测和读写验证前置，用一套工具先确认“总线在哪里、设备在不在、链路通不通”，再进入 CSR 与正式代码开发。
本议题针对 openUBMC 硬件调试中往往需要先配置 CSR、编写调用代码并完成构建部署，才能验证设备在位与读写的痛点，介绍了 bus\_tools 总线调试工具集。
工具覆盖 I2C 与 Hisport 两类总线，提供 i2cdetect、hisportdetect、busdetect 以及 i2ctransfer、hisporttransfer、bustransfer 六个命令，可完成总线枚举、地址扫描、多级 mux 探测、设备读写和组合事务验证。六个命令共享一套公共内核，并通过 lease、共享锁、重试机制、mux 初值保存与恢复等设计保证使用过程的可靠性。
现场案例包括通过插卡前后拓扑差异定位 PCIe 插卡归属设备、读取 RAID 卡 DDR 温度、获取 GPU 功耗等。工具的定位十分明确：提供正式开发前的快速调试与验证入口，而最终产品能力仍由 CSR 和正式代码交付。
* * *
### 09 基于南向驱动规范开发实践的技术分享
华瑞数鑫高级开发工程师 郭晟果
**亮点**：“一套框架，多厂商扩展”，以四款国产 RAID 卡真实适配为样本，沉淀从硬件识别、厂商库接入到系统验证的标准化方法。
本议题以 D3100s、D4100t、H3130s、B261s 四款 RAID 卡接入 openUBMC 为背景，系统拆解南向三层协作模型：VPD 负责硬件拓扑描述，PCIe Device 负责 BDF 与设备识别，Storage 负责控制器、物理盘和逻辑盘管理，形成“VPD 找得到→PCIe Device 认得出→Storage 管得了”的验证逻辑。
实战中，B261s 通过新增厂商自研 SML 库路径完成接入，其他卡型则基于既有框架复用和扩展；针对无背板 Boot RAID 场景，还设计了软件虚拟盘位点灯，并通过独立 I2C 读接口、厂商通道隔离和传感器告警配置化等方式处理差异化能力。
最终将实践归纳为硬件信息收集、VPD 拓扑配置、PCIe 设备识别验证、SML 厂商库开发、适配层集成、业务策略适配与测试六步标准化流程。
* * *
### 10 openUBMC Studio AI Agent 自主BMC调试工作流介绍和实践分享
openUBMC ai SIG Maintainer 李兆天
**亮点**：openUBMC Studio 将领域知识、真实 BMC 环境与专业调试MCP工具统一纳入 Agent Harness，让 AI 从“能执行命令”进一步走向安全、可追溯、可复用的 BMC 自主调试闭环。
本议题分享围绕通用 Agent 在 openUBMC 调试中存在领域上下文不足、环境连接反复、专用工具与知识缺失、定位过程难以稳定收敛等问题，介绍了基于 openUBMC Studio 构建的 AI Agent 自主 BMC 调试工作流：通过 MCP 统一连接和管理真实 BMC 环境，提供 SSH/Telnet、MDB、D-Bus、Systemd、日志查询及固件升级等场景化能力，并结合 RAG 知识库与 Skills 沉淀 openUBMC 专家知识经验；在实际故障案例中，Agent 从问题描述出发，自主完成在线观测、证据收集和根因定位，并进一步衔接修复方案、整包构建、固件升级与测试验证，在受控只读和关键操作审批机制下实现从问题定位到修复验证的完整闭环。
现场实践环节，开发者围绕四项实操任务动手体验：一是完成 BMC 一键日志分析，查看告警与板卡信息；二是使用 BMC 环境管理，配置 BMC 环境及常用命令；三是完成 HPM 包一键升级，安装 openUBMC Skills，并借助 Fault Diagnosis Agent 诊断环境问题；四是使用社区工作台，启动一个 PR 的 AI 检视。开发者对 Agent 在真实 BMC 调试场景中的实用价值给予高度关注，并提出了进一步优化建议。
开发者现场体验 openUBMC Studio AI Agent 调试工作流
* * *
## 从技术分享到深度共创 ——openUBMC Meetup 覆盖工程全周期落地
从北向架构标准化体系建设，到产品测试验证与南向部件生态共建，再到板卡故障定位、硬件调试工具体系与 AI 原生研发实践，本次 Meetup 完整串联起 openUBMC 从「架构与标准」到「开发、适配、测试、排障、运维」的全周期工程链路，为整机厂商、部件厂商、社区技术专家与广大开发者搭建了面对面交流的深度协作平台。这也正是 openUBMC 社区持续深耕的方向：以开放协作模式推动社区技术能力向产品化落地转化，将真实工程经验沉淀为全行业开发者可复用的公共技术资产。
未来，openUBMC 将携手更多成员单位、产业伙伴与开发者，持续完善架构、标准、测试与工具体系，推动更多部件、产品和真实业务场景在社区中完成共建与验证，共同建设开放、协同、可持续演进的 BMC 开源生态。
下一站 Meetup，期待与更多开发者相聚。
* * *
**活动相关直播回放将陆续同步至 openUBMC 视频号，欢迎持续关注。**
扫码关注openUBMC视频号
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://atomgit.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2503-release/
---
新闻资讯
openUBMC 25.03 版本发布：开启开源新旅程
# openUBMC 25.03 版本发布：开启开源新旅程
2025/05/08
# openUBMC 25.03 版本发布：开启开源新旅程
在开源的浪潮中，openUBMC 项目一直致力于为用户提供更优质、更灵活的 BMC（基板管理控制器）解决方案。openUBMC 25.03 版本正式上线啦！作为今年的首个版本，它带着诸多亮点与创新，为openUBMC 领域注入了新的活力。
## 版本概览：开源与自由
openUBMC 25.03 采用木兰宽松许可证 2.0，用户可自由复制、使用、修改和分发，无论是个人开发者还是企业用户，都能在合法合规的前提下，根据自身需求进行定制和优化。
## 版本特性：全面升级
### 北向接口生态
- 安全升级：安全框架升级，支持密码策略定制化配置，实现用户名规则自定义，新增证书管理基础模块。
- 运维优化：配置导入/导出标准化，出厂重置保留用户数据，重构 MCU/VRD 升级架构，支持 hpm 标准化升级包格式。
### 南向部件扩展
- 管理增强：增强管理能力，支持调速策略，可加载多 SML 库。
- 部件适配：新增支持 SP322D/SP323D 网卡，支持 NVMe-MI v7 协议 linkspeed 查询。
### 开发体验优化
- 工具增强：bingo 支持本地调试和模型检查，BMC Studio 发布至社区。
- 功能拓展：支持 CSR 配置检查和全模型检查。
## 下载体验
下载链接：https://openubmc.cn/zh/download
详细版本发布说明，请阅： https://openubmc.cn/zh/version/25.03
## 源代码发布：共享与协作
25.03 版本源代码已发布至社区网站，开源的力量在于共享与协作，我们期待更多开发者加入，共同推动 openUBMC 的发展。
仓库链接：https://gitcode.com/openUBMC
## 致谢
感谢所有参与 openUBMC 项目的社区开发者，是你们的智慧和努力，让这个版本得以顺利发布。希望未来有更多伙伴加入我们，共创开源美好未来！
开源之路，我们一起前行！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2506-release/
---
新闻资讯
openUBMC 25.06 版本发布
# openUBMC 25.06 版本发布
2025/07/07
# openUBMC 25.06 版本发布
🥳感谢所有参与25.06版本贡献的开发者，openUBMC 25.06如期而至！
✅ Issue解决 1272
✅ PR合入 1582
✅ 新增代码行 334K
✅ 由来自多家组织的179名贡献者共同完成
## openUBMC 25.06版本关键特性
### Hardware SIG
🔥 网卡NCSI边带管理功能补齐
🔥 NVME-MI协议命令字实现增强
🔥 硬盘SMART信息获取能力增强
🔥 Raid卡管理支持多协议库并行加载
🔥 风扇手动/自动模式切换和持久化设置切换
🆕 提供电源效率曲线接口，可用于动态切换电源模式
🆕 支持多类型部件并行升级能力
🆕 支持BF2、BF3网卡、9540-8i、9560-8i、9440-8i、SP686C-M 16i 4G raid卡等部件管理能力
### Interface SIG
🔥 部分Redfish 1.20标准接口补齐
🆕 新增Observability组件，用于观测BMC运行数据，提升问题调试和定位效率
🆕 新增libirc组件，提供远程客户端通讯库，便于二次开发远程客户端
🐞 webui部分bug修复，kvm能力增强
### bmc\_core SIG
🔥 部分IPMI Sensor规范补齐
🔥 加强电子标签、上下电策略定制能力
🐞 sensor组件bug修复，可定位性增强
### CICD SIG
🔥 优化BMC Studio硬件适配界面，提供更直观的配置界面
🔥 BMC Studio CSR检查能力增强
🆕 Qemu支持天池组件仿真能力
🐞 修复bingo构建若干问题，并支持apt、pip安装
🆕 bingo支持对hpm包进行cms签名能力
### 资源获取
DownLoad：https://www.openubmc.cn/zh/download
版本说明：https://www.openubmc.cn/zh/version/latest
应用市场：https://www.openubmc.cn/zh/marketplace
安装文档：https://www.openubmc.cn/zh/docs
感谢每一位开发者的付出！正是你们的贡献，让 openUBMC 不断进步。欢迎持续关注我们，更期待您的加入，一起推动社区繁荣！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2509-release/
---
新闻资讯
openUBMC 25.09 版本发布
# openUBMC 25.09 版本发布
2025/09/30
🥳感谢所有参与25.09版本贡献的开发者，openUBMC 25.09如期而至！
✅ Issue解决 1313
✅ PR合入 1923
✅ 新增代码行 565K
✅ 由来自17家组织的开发者共同完成
## openUBMC 25.09版本特性
### Security SIG
🆕 支持禁用历史密码、失败锁定次数配置、登录失败锁定时间配置、超长密码支持等策略配置
🆕 支持WEB SSO单点登录、IPMI通道权限配置、前端敏感信息加密
### Interface SIG
🆕 支持Zabbix、Ansible、Cmdlets、Nagios网管openUBMC插件
🚀 Redfish Manager、Processor、SEL、NTP、时区等资源管理接口补齐
🆕 新增支持User access/Password、User Name、DCMI Power等标准命令
🚀 支持单HPM包多个固件场景升级、BMC升级异常时自恢复
🚀 支持VRM和NPU升级过程中禁止主机上电
### Hardware SIG
🆕 支持I3C/CAN-FD能力、Ncsi Over Mctp over I2C/SMBUS协议获取网卡信息
🆕 支持Emulex的pldm OEM协议
🆕 新增标卡和OCP网卡，包括E810XXVDA2G1P5、E810CQDA2G2P5、MCX755106AS-HEAT等支持
🆕 新增RAID卡（SP686C-M系列）、硬盘、NVMe盘（SamSung PM9D3A、Memblaze PBlaze7、Solidigm D7-PS1010等）支持
🆕 新增GPU（A6000）、NPU模组等部件支持
🆕 新增TPSU/PSU管理能力，包括TPSU模块信息查询、 Turbo电容管理、双CAN电源线路主备切换、功耗封顶、功率监控、输出限功率点配置
🚀 支持VRM/电源等关键部件临终遗言持久化
🚀 支持BIOS固件导出、关键部件固件升级
🚀 支持网卡Flash recovery故障检测、光模块关键信息记录和闪断检测
🚀 支持高速链路检测、CPU与外围器件链路异常告警
### Component Driver SIG
🆕 新增设备驱动管理框架，支持部件适配驱动化管理
🚀 支持AWM M11P、SP670、RP1000P2SFP-A03部件驱动化
### CICD SIG
🚀 增强QEMU仿真能力，支持SMBus、MCTP等复杂协议仿真、MCU、PCIe、IMU等器件仿真
🚀 QEMU冒烟测试性能优化、支持依赖驱动同步OS版本更新
🆕 完成Conan2.0中心仓能力构建、支持Profile配置和并行构建
🚀 Bingo支持基于gtest的开发者测试、DT测试质量加固、门禁模型检查能力增强
🆕 新增I2C扫描和读写工具、支持度量采集和可观测跟踪可配置
### Docs SIG
🆕 新增SNMP接口映射器、TRAP告警、装备定制、CLI映射器等配置指导文档
🚀 更新BMC Studio用户指南、联机帮助页面扩展
### Infra SIG
🆕 新增社区贡献看板，支持查询个人贡献、签署CLA公司贡献、SIG贡献排行等统计信息
🆕 社区支持周期性会议创建，会议录制能力增强，支持语音转文字、录屏等功能
### 资源获取
DownLoad：https://www.openubmc.cn/zh/download
版本说明：https://www.openubmc.cn/zh/version/latest
应用市场：https://www.openubmc.cn/zh/marketplace
安装文档：https://www.openubmc.cn/zh/docs
感谢每一位开发者的付出！正是你们的贡献，让 openUBMC 不断进步。欢迎持续关注我们，更期待您的加入，一起推动社区繁荣！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2512-SP3-release/
---
新闻资讯
openUBMC 25.12 LTS SP3 版本正式发布
# openUBMC 25.12 LTS SP3 版本正式发布
2026/09/03
## openUBMC 25.12 LTS SP3 版本正式发布
🥳 感谢所有为25.12 LTS SP3 版本做出贡献的开发者！
✅ Issue修复 68 个
✅ PR合入 90 条
## openUBMC 25.12 LTS SP3版本特性交付范围包括：
- ### component-drivers SIG
🆕 新增182X新代次SP566(2\*200G)网卡兼容性
🆕 新增MCX653105A-HDAT/MCX755106AS-HEAT网卡兼容性
🆕 新增沐创N10G-X2-DC/N20G-R2F-25G网卡兼容性
🆕 新增光润通F1002T-V3.0网卡兼容性
🆕 新增Intel X550网卡兼容性
🆕 新增博通BCM957416A4160C网卡兼容性
🆕 新增星云智联S1055AS-A00CHT(2\*25G)网卡兼容性
🚀 优化SP686C RAID卡固件日志收集机制和日志可读性
- ### hardware SIG
🆕 新增HKEP810401T9000N/HKEP820501T9000N/HKEP910401T6000N/HKEP920501T6000N、德明利TS3160、紫光闪芯、佰维、英韧、长江存储等10+款硬盘兼容性
🆕 新增900W电源、EXP 12盘背板部件兼容性
🚀 优化扩展板CPLD localbus链路异常检测机制
🚀 优化BIOS固件和TEE固件生效机制
- ### 缺陷修复
🆕 修复SP686C RAID设置启动盘及适配SATA SSD显示、RAID卡通信失败、日志冗余记录等60+问题
## 资源获取
DownLoad：https://www.openubmc.cn/zh/download
版本说明：https://www.openubmc.cn/zh/version/25-12-LTS-SP3
应用市场：https://www.openubmc.cn/zh/marketplace
技术白皮书：https://www.openubmc.cn/zh/whitepaper
## 欢迎关注openUBMC
❤️ 从开发体验优化到稳定性深度加固，每一次都凝聚着社区的力量。是你们的持续投入，让开源力量在算力基础设施领域走得更稳、更远。
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://gitcode.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2512-release/
---
新闻资讯
openUBMC 25.12 LTS 版本发布
# openUBMC 25.12 LTS 版本发布
2025/12/31
🥳感谢所有参与25.12 LTS版本贡献的开发者，openUBMC 25.12 LTS如期而至！
✅ Issue解决 1586
✅ PR合入 1984
✅ 新增代码行 1327K
✅ 由来自19家组织的开发者共同完成
## openUBMC 25.12版本特性
### Security SIG
🆕 新增用户锁定事件上报功能
🚀 用户删除功能优化，登录用户和最后一个用户不可删除
🆕 新增SPDM认证原子能力，支持可信部件的接入与度量
🚀 会话和认证能力增强，支持差异化定制和修改
🚀 安全管理模块遥测能力增强
### Interface SIG
🆕 新增PowerEquipment、Pumps、Circuit、StorageController、Transceivers等标准接口能力
🚀 PCIeDevice、PCIeFunction、StorageController、StorageControllerMetrics、NetworkAdapter等资源管理接口更新
🆕 新增DCMI的GetDcmiCapabilitiesInfo、GetAssetTag、SetAssetTag、GetThermalLimit等标准命令
🚀 AccountService、CertificateService、Chassis等北向接口DT能力增强
### Hardware SIG
🆕 新增标卡和OCP网卡，包括FF5025、LRES3023PT、LRES3012PFP、BCM957608-P2200GQF00 、MCX623436AN-CDAB等兼容性
🚀 新增硬盘（DAPUSTOR R6301、R6101；SE005-1920GB-H、PETAIO P6118Z252153、LONGSYS RSYE3836N-480G等）兼容性
🆕 新增GPU（MXC500）等部件兼容性
🚀 TPSU/PSU管理能力增强：TPSU黑匣子收集方案优化；TPSU电容寿命预测和预警；TPSU电容信息记录；PSU故障检测能力增强
🚀 RAID卡定制能力增强：多RAID场景I2C链路性能优化；RAID卡协议扩展能力增强
🆕 新增电源，包括PSIP双子星、EB1000电源等兼容性；模组VRM管理
### bmc-core SIG
🚀 完善上电锁/下电锁机制
🆕 传感器、FRU等基础代码生成能力增强
### Component Driver SIG
🆕 支持L40、L20、MTT S4000、瀚博DC1000、TESLA T4等部件驱动化
🚀 规范网卡南向驱动接口，提升扩展性
### CICD SIG
🚀 QEMU仿真能力增强，支持网卡、RAID卡、硬盘、GPU等70+部件仿真
🚀 构建能力优化，构建归一化: 实现了组件、产品及自定义命令的构建流程统一；新增hpm\_signer签名工具及签名中心基础能力，支持发布包在线签名等
🚀 构建依赖与环境治理，发布集成开发环境 Docker 镜像；优化Manifest结构，支持组件版本重定义及产品级配置（如 NTP、BIOS 默认项）的灵活定制
🆕 新增hisport扫描工具
### Docs SIG
🆕 新增RAID卡解耦、在线调试、182x 管理等核心特性的设计说明书
🚀 温度曲线、健康状态等新特性的用户使用资料更新
🚀 发布Qemu、Bingo、BMC Studio 等工具的常见FAQ
🚀 更新Docker开箱即用指南与签名包制作指导
### Infra SIG
🚀 CI/CD 流水线优化，落地PR门禁自动识别与拦截机制；支持基于资源协作接口的组件打桩测试集成
🆕 优化客户体验，支持Excel文件在openUBMC社区直接展示；完善社区需求评审与管控流程
🆕 提供整包构建task.log的归档下载，便利问题排查
### QA SIG
🆕 建立组件IT测试门禁（以 network\_adapter 为试点）
🆕 设计并落地固件联盟认证测试用例
🆕 提升devmon/libmcpp 等核心组件的自动化测试覆盖率
### 资源获取
DownLoad：https://www.openubmc.cn/zh/download
版本说明：https://www.openubmc.cn/zh/version/latest
应用市场：https://www.openubmc.cn/zh/marketplace
安装文档：https://www.openubmc.cn/zh/docs
感谢每一位开发者的付出！正是你们的贡献，让 openUBMC 不断进步。欢迎持续关注我们，更期待您的加入，一起推动社区繁荣！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2603-release/
---
新闻资讯
openUBMC 26.03 版本发布
# openUBMC 26.03 版本发布
2026/04/02
# openUBMC 26.03版本特性
## Hardware SIG
🆕 新增920L模组、182X新代次标卡和OCP网卡及光模块、MCX75310AAS-NEAT网卡、网讯FF5025网卡、9500-16i/8i等兼容性
🆕 新增RS485获取温度和湿度
🆕 新增硬盘、风扇、扩展板、硬盘背板和基础板更换记录信息
🚀 NVMe硬盘故障预测特性增强
🚀 光模块故障检测能力增强，包含标卡和昇腾卡故障采集能力增强
🚀 Bluefield DPU功能优化
🆕 新增BOX管理功能：Retimer、故障检测
🆕 支持SP686C-M-16i/40i、持SP686C-MH-32i等RAID卡固件及其管理硬盘带外升级
🆕 能效管理配置能力增强：分区调速、精细化配置、PID参数等
## Component Driver SIG
🆕 新增182X新代次标卡和OCP网卡及光模块、光润通(GRT)驱动开发
🚀 驱动框架优化：支持DBUS和共享内存调用、组件schema加载和管理、自描述记录解析和处理、复杂属性语法等
🆕 新增南向网卡兼容性工具
## Interface SIG
🆕 支持根据机型WEB接口灵活组合
🚀 光模块性能数据采集接口优化
🚀 基于Validator扫描通用问题标准化
🚀 ComputerSystem、PCIeSlots、Memory等北向接口标准接口能力增强
🆕 新增特性北向接口能力：RAID卡慢盘、固件升级暂存、dump BIOS Flash、DICE、大包升级、多系统等
## CICD SIG
🆕 openUBMC Studio全新升级，新增IDE能力，CSR辅助开发功能等
🚀 QEMU仿真能力增强：博通RAID卡
🚀 新增基于lockfile的产品级构建
🆕 新增子系统切面配置汇总机制
🚀 QEMU版本升级到8.2.10
## Docs SIG
🆕 新增compute、libsoc\_adapter、ipmi\_core、bmc\_network等组件接口文档
🆕 新增风扇板和风扇适配指导文档
## bmc-core SIG
🆕 新增FRU电子标签加工时间扩展
🆕 新增传感器事件多主机场景能力
🆕 新增IPMI硬盘信息获取功能
## Infra SIG
🆕 社区基础设施软件开发生命周期治理与安全规范V1.0发布
🆕 新增LTS版本每日构建功能
🆕 新增社区包签名基础能力
## Security SIG
🆕 支持板间通信会话管理
🆕 支持基于基于SessionID会话固定超时时间检测
## QA SIG
🚀 测试平台集成QEMU版本升级到8.2.10
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2606-release/
---
新闻资讯
openUBMC 26.06 版本正式发布
# openUBMC 26.06 版本正式发布
2026/07/02
## openUBMC 26.06版本如期而至
🥳 感谢所有为26.06 版本做出贡献的开发者！
✅ Issue解决 2137 个
✅ PR合入 3397 条
✅ 新增代码行 1849k
✅ 由来自 22 家组织 104 位开发者共同完成
## openUBMC 26.06版本特性
### CICD SIG
🆕 Studio支持社区RAG集成，为主流Coding Agent提供MCP能力
🆕 Studio集成社区多款开发插件，支持一键日志可视化，社区skills部署，社区工作台等功能
🆕 Studio支持金样CSR、部件驱动模板一键生成，快速完成定制化诉求
🆕 大模型接入社区，新增AI代码检视和接口规范自动检查等能力，提升社区交付效率
🆕 OEE工具链能力增强，支持多厂商BMC芯片接入社区完成整包构建
🆕 SignServer签名接入，社区发布固件安全性增强
🚀 GCC升级到14.3版本，提升构建在安全、性能、效率等方面能力
🚀 bingo整包构建能力：海思Hi3093/3095 DT包、社区导入DT平台包
### hardware SIG
🚀 运维能力再升级：新增NVMe盘带外升级和并行升级能力；硬盘多启动盘配置
🚀 介质可靠性增强：支持硬盘故障自愈能力，提升整机可靠性
🆕 新增CPLD无感升级功能、并行升级等运维特性，提升整机运维效率
🆕 新增佰维SS821、PetalIO P8118Z3、YMTC PE511等20+款硬盘兼容性
🆕 构建UB相关带外管理能力：光模块故障告警、信息采集、光链路等DFX能力
🆕 KP920双路模组支持：CPU/内存侦测、CPLD/BIOS升级、PCIe Switch等特性落地
### interface SIG
🚀 200+DMTF标准接口：Processor/Memory/PCIeDevice/ComputerSystem/Manager等资源属性全面升级
🆕 OCP规范全量适配：EthernetInterface/NetworkDeviceFunction/ManagerNetworkProtocol等
🚀 Web Options灵活裁剪，支持整机厂商按需组合
🆕 NPU Redfish接口能力增强，包含NPU Board资源、GPU/NPU最大个数查询、功耗查询、计算能力等
🆕 Web UI增强：固件拖拽上传、VNC双鼠标、离散传感器搜索、BMC配置包导入导出
🚀 事件订阅能力增强：EventFormatType信息、veth通道端口精细化控制
### component-drivers SIG
🆕 新增沐创N10、网迅25GE、Intel X550、N20等10+款网卡
🆕 新增英伟达5090、Tesla P4/P40/V100/A100等5+款GPU兼容性
🆕 构建RAID卡/NVMe盘/风扇/电源等部件南向驱动规范体系定义和建设
🚀 新增华为182X系列网卡光模块LOL/LOS/SNR/脏污检测等故障检测能力
🚀 设备管理双框架使能：CSR1.0的8种总线，20+器件驱动能力完成构建，满足社区多元场景演进诉求
🆕 自发现能力下沉，支持非天池硬件自接入
### bmc-core SIG
🆕 构筑高性能event和sensor组件能力，业务性能提升30%
🚀 故障采集智能限流，故障诊断从小时到分钟
🚀 主备管理增强：硬件信号获取主备状态、数据同步策略
### ai SIG
🆕 发布skills-marketplace的studio插件，支持社区skills一键安装和更新
🆕 发布mcp host的studio插件，支持studio能力与主流Coding Agent对接
### QA SIG
🆕 测试代码与itestsmart解耦，支持工具和自动化测试用例独立演进
🆕 完成网卡、xPU、硬盘、RAID卡测评和认证流程构建，完成网卡全自动化流程测评端到端验证
🆕《服务器基板管理控制器（BMC）技术要求》新增190+自动化用例，支撑《服务器基板管理控制器（BMC） 测试方法》95%通过自动化完成
### infra SIG
🆕 openUBMC社区RAG服务，提供社区问答机器人相关的知识库查询能力
🆕 官网上线硬件兼容性列表，支持兼容性沙盘在线查询
🚀 PR门禁进行并发和统一资源池优化，优化PR排队效率，提高并发能力
### security SIG
🆕 新增基于接口的分权分域的用户管理定制能力
🆕 新增ASPEED芯片+OEE的用户管理和认证能力
### docs SIG
🆕 200故障模式知识库：覆盖属性同步失败、传感器异常、升级失败等典型故障
🚀 API文档自动化生成：自动生成可用于商用发布的Redfish接口文档
## 资源获取
DownLoad：https://www.openubmc.cn/zh/download
版本说明：https://www.openubmc.cn/zh/version/26.06
应用市场：https://www.openubmc.cn/zh/marketplace
技术白皮书：https://www.openubmc.cn/zh/whitepaper
感谢每一位开发者的付出！正是你们的贡献，让 openUBMC 不断进步。欢迎持续关注我们，更期待您的加入，一起推动社区繁荣！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/2609-release/
---
新闻资讯
openUBMC 26.09 版本正式发布
# openUBMC 26.09 版本正式发布
2026/10/08
## openUBMC 26.09版本如期而至
🥳 感谢所有为26.09 版本做出贡献的开发者！
✅ Issue解决 2693 个
✅ PR合入 4795 条
✅ 新增代码行 3742k
## openUBMC 26.09版本特性
### CICD SIG
🆕 新增openEuler+Kunpeng构建能力，支持X86+ARM双CPU架构交叉编译
🆕 新增40+款兼容性板 QEMU仿真模型，扫清硬件验证门槛
🆕 引入ASan 内存扫描、clang-tidy 静态检查、AI 辅助日志与安全规范扫描，质量门禁矩阵全面升级
🚀 支持OEE+Hi3095、OEE+AST2600等多BMC芯片平台构建能力，筑牢多算力和多场景基础
### hardware SIG
🚀 增强UB链路故障、PCIe建链失败和BBU过温等告警能力，故障不沉默
🚀 CPLD/VRD/硬盘/网卡/RAID卡等固件在备件更换时自动升级，更换零门槛
🚀 硬盘/网卡/DPU等部件配置更换后自动恢复，真正做到部件即插即用
🆕 新增沐创、梧桐树、华为182X系列、Mellanox和博通等厂商10+网卡兼容性
🆕 新增DDP、得瑞领新、德明利、紫光闪芯和英韧等厂家15+款硬盘兼容性
🆕 新增华瑞数鑫、博通等5+款RAID卡兼容性
🆕 新增PECI/H2B/KCS/SGPIO等X86算力驱动能力，多算力多场景能力全面进阶
### component-drivers SIG
🆕 部件驱动规范测评和认证体系能力发布，驱动适配结果可度量，测试效率提升50%+
🚀 完成libmcpp/devmon适配Zephyr，构建轻量化部署能力
🆕 部件驱动框架完成自发现、热插拔管理、统一总线驱动等62项能力构建，硬件适配效率倍增
🆕 新增跟踪、度量、日志、消息通讯、防抖能力等19项可观测框架，开箱即用，南向开发体验全面升级
🆕 SSU模组管理模型、BIOS 带外升级、启动参数设置查询、部件自描述加载，管理能力一步到位
### interface SIG
🆕 新增自动分页、权限管理、子任务、上下文管理等12项映射库能力，筑牢北向高效开发底座
🚀 近端运维、机框管理、资产管理等17项特性灵活裁剪，实现Redfish/CLI/SNMP/WEB全覆盖
🚀 实现event事件汉化，遥测指标紧跟DMTF规范，推动标准持续迭代演进
### bmc-core SIG
🆕 聚焦算网融合机型，重构上下电逻辑，适配多场景业务流程
🆕 新增全量数据同步能力，多节点BMC通信原子能力全开放
🚀 深度优化最大session场景性能，带内IPMI命令实现秒级极速响应
### infrastructure SIG
🚀 推进 61 个代码仓接入编码规范治理，流水线强力赋能 AI 智能检视能力
🆕 openUBMC Studio 工具链全面升级：打通 Workbench、扩展模块构建发布流水线，上线 DSL 检查数据发布流水线
🚀 流水线状态按仓精准可查，开放 RAG 对外查询接口，推进 issue/MR 提交规范化，社区运营深度升级
### ai SIG
🚀 70+ skills 上线 Skills Marketplace，覆盖开发、测试、构建、发布全流程，开发无忧
🚀 检视技能全面优化，覆盖魔鬼数字、度量单位、异常堆栈、定位信息等场景，一键检视
🆕 IPMI/Redfish 代码文档同步检查上库，实现文档与代码同步更新
### docs SIG
🚀 从快速上手到设计、开发、适配，一站式贯通开发者全流程，部件驱动 2.0 全套指南上线
🆕 组件文档全面升级，CSR/MDS/资源协作接口配置语法齐套交付，入门、构建与故障定位教程同步上新
🚀 部件数据资产化管理落地，一键完成数据导出、统计概览、搜索过滤与分类导航核心能力
🆕 SNMP/CLI接口文档自动生成，原生确保接口文档与代码同源，实现文档与代码同步更新
### security SIG
🚀 SPDM 可信根互联落地，异构算力信任根建立，安全底座坚实
### QA SIG
🚀 社区用例全面接入每日构建，覆盖硬件管理、能效管理、基础服务及用户和安全等领域，实现用例资产随版本持续沉淀
🆕 南向驱动规范测试用具正式落地，全面支持 GPU 接口卡、硬盘、网卡及 RAID 卡
🆕 冒烟测试深度对接每日构建，社区众测正式落地，质量防护网持续增强
## 资源获取
DownLoad：https://www.openubmc.cn/zh/download
版本说明：https://www.openubmc.cn/zh/version/26.09
应用市场：https://www.openubmc.cn/zh/marketplace
技术白皮书：https://www.openubmc.cn/zh/whitepaper
感谢每一位开发者的付出！正是你们的贡献，让 openUBMC 不断进步。欢迎持续关注我们，更期待您的加入，一起推动社区繁荣！
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://atomgit.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/CGC 2026-program/
---
未找到相关内容
---
https://www.openubmc.cn/zh/news/CGC 2026-teaser/
---
未找到相关内容
---
https://www.openubmc.cn/zh/news/CGC-2026-program/
---
新闻资讯
议程公布 | 2026全球计算大会——openUBMC技术生态论坛议程全览
# 议程公布 | 2026全球计算大会——openUBMC技术生态论坛议程全览
2026/10/16
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://atomgit.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/CGC-2026-teaser/
---
新闻资讯
CGC 2026 | openUBMC 分论坛：从标准共建到技术落地，解锁在超节点与AI新形势下 BMC 演进方向
# CGC 2026 | openUBMC 分论坛：从标准共建到技术落地，解锁在超节点与AI新形势下 BMC 演进方向
2026/10/16
当 AI 大模型从技术探索迈向产业深耕，算力基础设施形态正在加速重构。超节点、XPU模组等新架构与部件形态不断涌现，集群规模从千卡走向万卡，异构算力成为常态。BMC 作为算力设备的管理中枢，正迎来开放化、智能化的全新拐点。
在此，我们诚挚邀请您相聚 CGC 2026 openUBMC 技术生态分论坛。本次论坛以“打破边界，AI 提智——定义超节点与AI时代的管理新范式”为主题，汇聚产业领军力量与资深技术专家，共同探讨超节点与AI新形势下，下一代BMC技术演进方向，现场还将发布管理规范与开源成果，凝聚产业共识，助力企业把握开放、智能、自治的算力管理新范式。
* * *
## 01 算力变革时代，BMC 管理技术如何持续演进？
AI 算力集群加速落地，管理复杂度正在指数级攀升。从产业视角来看，有三个方向值得关注：
**从碎片化适配，走向硬件标准化统一管理：** GPU、DPU 等新型算力部件加速迭代，传统“一部件一适配”的模式已难以跟上节奏。产业需要统一的部件管理接口规范，让硬件厂商基于标准自主开发，实现“一次开发、全链复用”，降低产业链协同成本。
**运维能力下沉边缘，构建带外自主处置能力：** AI 训练对实时性和稳定性要求极高，单次故障可能造成巨大的算力浪费。将运维能力下沉至离硬件更近的 BMC 侧，实现端侧自治与快速响应，正在成为提升算力集群可靠性的重要方向。
**从被动应答模式，迈向节点自治运维升级：** AI Agent、MCP 等技术的成熟，为基础设施管理打开了新的想象空间。BMC 作为服务器带外管理的核心入口，正在从传统的“被管理对象”演变为“自治运维节点”，推动算力管理向智能化持续演进。
* * *
## 02 论坛重磅看点抢先看
### 看点一｜重磅标准首发，解锁异构算力管理原生开源方案
本次论坛将重磅发布由GCC -BMC技术课题专项组牵头、openUBMC社区、云厂商、XPU厂商等产业链头部伙伴联合共建的 XPU 模组管理规范。规范同步配套开源代码资产对外开放，聚焦异构 XPU 硬件统一管理场景，补齐多类算力部件适配不统一、固件定制成本高的产业短板，为异构算力基础设施规模化、标准化落地提供权威体系支撑与可落地的开源实现方案。
### 看点二｜前沿技术全景拆解，洞悉下一代 BMC 演进方向
论坛将围绕下一代 BMC 技术演进路径展开深度解析，拆解北向自接入、南向标准化、AI Agent 给算力管理底层逻辑带来的技术变革，探讨异构算力统一管理的设计思路。现场将分享北向自接入创新实践，以及 Agent Harness 相关的工程探索，解读大模型能力嵌入 BMC构建基础设施自主管理能力的技术实现思路，探讨开源模式如何支撑下一代算力管理体系的创新。
### 看点三｜全场景产业落地，解锁算力能效与可靠性实战方案
论坛集结云厂商、整机厂商、固件厂商等一线实战团队，带来服务器智能管理领域多项产业落地实践。聚焦大规模异构算力的能耗优化、故障管理、可靠性增强等产业痛点。依托商用真实业务场景，分享 BMC 能效调优、超节点带外管理创新、多元异构硬件部署实践，提炼可复用工程方案，支撑下一代算力基础设施规模化商用。
万卡异构浪潮之下，底层硬件管理能力是 AI 集群规模化落地的关键。本次论坛汇集算力全产业链同仁，是把握 BMC 技术演进方向、链接产业生态的重要窗口，助力从业者前瞻布局新型算力基础设施。
openUBMC 期待携手产业链上下游领域伙伴，从标准共建走向产业落地，共同探索开放、智能、自治的算力基础设施管理新未来。
### **CGC 2026 openUBMC 分论坛，期待与您共同见证。**
- 📅 **时间：** 2026年10月21日 14:00-17:00
- 📍 **地点：** 深圳会展中心（福田）5F玫瑰厅-1
- 🔗 **报名方式：** 关注 openUBMC 社区官网及公众号，扫描下方二维码，获取最新报名信息
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://atomgit.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/HUAWEI CONNECT 2026/
---
未找到相关内容
---
https://www.openubmc.cn/zh/news/HUAWEI-CONNECT-2026/
---
新闻资讯
华为全联接大会 2026｜openUBMC 精彩亮相，以开源底座使能产业差异化创新
# 华为全联接大会 2026｜openUBMC 精彩亮相，以开源底座使能产业差异化创新
2026/10/12
作为面向算力设备管理的开源底座，openUBMC 深度参与大会展览展示与技术分享环节，在计算展区全景呈现"南向自适配、北向自接入"的双向架构体系，并同步开放 Codelab 现场动手体验区，集中呈现社区开源以来的技术演进、开发者体验升级与产业链共建成果。依托开源的算力设备管理平台，openUBMC 持续使能整机、部件、芯片等产业链伙伴，面向 Agentic AI 时代的多样算力架构进行差异化创新，推动算力设备管理向开放化、平台化、智能化持续演进。
* * *
## 算力变革，重塑带外管理新范式
Agentic AI 时代，算力架构走向通算与智算协同，算力节点的规模、密度与异构程度同步抬升，南向硬件兼容、北向自运维正成为算力基础设施管理的关键变量。
然而，传统BMC管理能力多以整机为单位随固件交付，产业链伙伴想加入差异化功能，往往需要深入底层代码改动，研发投入难以沉淀复用。打造开放、可组装的硬件管理底座，成为产业更具工程落地性的方案。
* * *
## 开源底座筑基，助力服务器差异化创新
本届峰会上，华为ICT战略与业务发展部总裁彭红华、华为鲲鹏计算产品线总裁李义携手12家整机伙伴代表，基于鲲鹏920新型号与鲲鹏950，联合发布覆盖高密、均衡、高性能、存储等全形态服务器新品，全系新品均基于openUBMC构建带外管理体系。
openUBMC此前已支撑鲲鹏13家OEM伙伴推出300余款服务器产品，本次发布进一步拓展openUBMC的部署版图。依托这套可裁剪的管理底层，不同厂商、不同形态、面向不同客户的机型可灵活完成南向适配、固件管理与北向运维对接，使能伙伴差异化创新，引领产业走向开放、智能、自治的新阶段。
* * *
## 计算展区：全景展示 openUBMC 双向开放体系与产业实践
HC 大会同期， openUBMC 设置专属展区，以技术解读、联创实践、实操体验相结合的方式，集中呈现 openUBMC 南北向开放架构：北向自接入按需赋能运维创新、南向自适配全域降低硬件接入门槛，让到场行业客户、硬件伙伴、开发者直观理解openUBMC对算力基础设施升级、服务器差异化创新、运维效率提升的核心价值。
北向自接入创新支持上层运维能力按需集成、灵活编排，让管理更贴近算力。区别于传统 BMC固化的运维接口模式，openUBMC 通过组件化、可扩展的北向架构，支持各类 AIOps 等智能化管理能力按需接入、自由组合。平台集成 AI 智能运维、无感批量升级、端侧运维下沉等能力，助力企业数据中心实现极简、高效、零中断运维，同时支持伙伴基于开放底座自定义运维体系、沉淀行业专属运维能力，大幅降低算力集群运维成本，全方位提升商用算力运维效率与智能化水平。
南向方面，openUBMC 打破传统驱动适配体系，以标准化驱动的方式解决产业痛点。目前社区已完成 300+ 款硬件部件适配，依托行业 20 + 头部厂商共建的标准化接口规范，通过可视化配置能力，减少硬件适配的重复底层编码，实现硬件部件标准化、快速化接入。伴随服务器南向部件管理接口标准推进，将进一步降低硬件厂商接入生态门槛。
* * *
## Codelab ：零门槛实操，沉浸感受openUBMC 开发乐趣
除产业成果展示外，大会 CodeLab 开发者区同步开放实操体验，直观展示 openUBMC 在硬件适配、算力运维、AI辅助开发领域的范式革新，让开发者沉浸式感受开源轻量化、高效率的开发优势。现场收获大量开发者正向评价：“BMC开发比想象中简单很多，AI辅助和可视化配置大大降低了门槛。”“openUBMC Studio与AI集成后，技术知识检索、概念理解、问题自查效率都提升了很多，很多时候自己问AI也能理解一些设计和概念了。”同时，现场也收集到开发者对硬件兼容与适配、安全与能效联合创新、文档与社区体验优化等方面的多项建设性建议。
后续社区将针对性迭代升级，持续丰富硬件适配类目、深化生态联创与伙伴赋能，优化社区活动运营机制，同时完善官网文档体系、统一版本开发指引、显性化项目差异化介绍，持续优化开发者体验，赋能更多伙伴与开发者高效创新，共建开放生态。
* * *
## 结语
随着算力基础设施向异构化、集群化持续演进，算力设备管理能力正在被重新定义。openUBMC通过南北向开放架构，为产业链伙伴提供了从硬件适配到业务创新的完整支撑。
未来，openUBMC 将持续迭代核心技术、完善硬件认证体系、壮大开源生态，以开源力量使能计算产业开放创新，携手全产业链伙伴共建高效、开放、创新的下一代算力设备管理体系。
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://atomgit.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/Star-Open-Source-Community/
---
新闻资讯
openUBMC社区荣获2025年软件和信息技术服务业明星开源社区奖项
# openUBMC社区荣获2025年软件和信息技术服务业明星开源社区奖项
技术干货
2026/05/09
openUBMC小助手
### 01 开源生态获认可，引领算力管理新范式
**2026年4月**在以“人工智能与软件变革——AI融合与数智出海新机遇”为主题的第五届中国国际软件发展大会上，openUBMIT社区凭借其在算力设备管理领域的创新实践与生态贡献，荣获“**2025年软件和信息技术服务业明星开源社区**”称号。
这一荣誉标志着openUBMC社区在推动国产开源算力设备管理软件发展方面取得的成就获得业界高度认可。
* * *
### 02 深耕开源沃土，赋能产业创新
openUBMC于2024年正式开源，旨在打造开放、易用的算力设备管理软件开发平台，为全场景、全连接、全智能时代提供架构领先、开发友好、遵循开放标准的开源BMC软件。
社区保持高频迭代，截止目前：
- **代码规模**：累计代码量突破 300万行
- **开发者生态**：汇聚 500+ 核心开发者参与贡献
- **版本迭代**：推出 5个 创新版本 + 1个 长期支持版本（LTS）
- **生态兼容**：支持 200+ 款主流部件即插即用
* * *
### 03 首创南向标准，引领行业变革
在传统的服务器带外管理开发中，BMC 南向部件接口碎片化一直是困扰开发者的核心难题。部件与整机深度绑定，导致每适配一款新硬件，都需要投入大量重复的驱动开发工作。
openUBMC 从架构层面直击这一痛点：
- **首创南向部件驱动规范**：实现了硬件能力定义与底层实现的彻底解耦；
- **打破绑定模式**：推动交付模式从传统的“整机集成商单点对接”向“多产业协同”变革，联合20余家产业链单位完成标准立项后，目前已有10余家头部部件商基于社区完成适配；
- **0 Day级适配效率**：新增硬件的接入效率达到 0 Day级，极大释放了研发生产力，为服务器行业带来开放高效的协同新范式。
* * *
### 04 持续创新，筑牢数字基础设施底座
面向AI基础设施急剧增长带来的大规模算力部署与运维挑战，openUBMC持续深耕智能运维、安全可信等核心能力，为行业提供更智能、更高效的管理底座。
未来，openUBMC社区将继续以“标准+开源”双轮驱动，携手生态伙伴共驱产业智能化升级。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
## 关于作者
- openUBMC小助手
openUBMC小助手是openUBMC社区的活跃推手，专注于为开发者提供前沿技术动态、深度文章解析以及丰富的社区互动内容，致力于打造一个开放、互助、充满活力的技术社区，助力每一位成员在技术探索中不断进步。
---
https://www.openubmc.cn/zh/news/Wuhan-meetup/
---
新闻资讯
议题征集！openUBMC Meetup 武汉站，与你共写新的开源记忆
# 议题征集已结束
openUBMC社区2026年首场线下Meetup将于3月20日在武汉与大家见面!本次 Meetup 由 openUBMc社区牵头，联合社区成员单位长江计算、神州鲲泰共同主办。现诚邀openUBMC社区全体开发者参与议题征集，欢迎积极分享您在openUBMC领域的实践实操、技术创新、工具开发、落地案例及优化建议，与产业上下游开发者深度探讨，凝聚社区合力，推动BMC技术迭代升级与生态高速发展，实现开发者个人成长与生态共建的双向共赢！
2026年3月20日
武汉
## 议题征集
# 议题征集！openUBMC Meetup 武汉站，与你共写新的开源记忆
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/chengdu-meetup-review/
---
新闻资讯
openUBMC Meetup成都站成功举办，聚焦开源BMC技术创新与社区共建
# openUBMC Meetup成都站成功举办，聚焦开源BMC技术创新与社区共建
2025/11/03
# openUBMC Meetup成都站成功举办，聚焦开源BMC技术创新与社区共建
2025年10月31日，openUBMC Meetup在成都成功举办。本次活动吸引了近50位开发者及技术专家齐聚一堂，围绕openUBMC社区最新进展、可观测技术、部件驱动、测试策略、CI/CD实践、AI赋能测试等核心议题展开深度分享与交流。
### 社区蓬勃发展，25.09版本成果显著
openUBMC技术委员会委员张雨博分享了社区最新进展：25.09版本在代码贡献、硬件兼容性与开发者体验上取得突破性进展；社区首个LTS版本——25.12的规划也已启动，将重点增强接口规范与部件驱动框架等能力。与此同时，社区运营持续活跃，继西安、杭州之后，本次成都Meetup和即将举办的深圳站活动将进一步连接广大开发者，共建开放协作的技术生态。议题的最后，张雨博表示，2026年技术规划已开启，现公开征集技术需求与创新建议，诚邀全球开发者共同参与，推动openUBMC生态持续演进。
### 可观测技术：从“黑盒”到“透明系统”
openUBMC Interface SlG Maintainer李四光分享了openUBMC在可观测性方面的技术实践。通过引入Trace（追踪）、Metric（指标）、Log（日志）三大信号，结合OpenTelemetry Collector与Prometheus、Jaeger、Zipkin等后端系统，实现了BMC系统运行状态的实时监控与问题定位。通过实际案例，演示了如何在BMC界面配置可观测服务，并通过Grafana实现数据可视化分析。
### 部件驱动规范：推动硬件管理标准化
openUBMC Component Drivers SIG Maintainer 刘兴森介绍了社区在南向部件驱动规范方面的突破。通过定义统一的部件接口模型，实现了硬件管理与BMC软件层的解耦，支持“必选+可选”接口组合，兼顾基础功能与差异化能力。目前，已有部分网卡、GPU已在社区落地，Q4会继续发布更多的部件。同时，《服务器南向接口要求》已完成标准立项，正面向社会公开征集意见中。
### 测试与自动化：构建高质量交付体系
openUBMC QA SIG Maintainer刘宇杰分享了openUBMC的分层测试策略与自动化防护网，涵盖组件IT测试、版本冒烟、每日构建与全量验证。社区完善了测试贡献流程，鼓励开发者共同完善测试用例与自动化脚本。
### CI/CD与AI赋能：提升开发与测试效率
软通动力软件工程师文成龙与顾晓东分别分享了在CI/CD流水线建设与RAG技术在测试中的应用。
- CI/CD实践：通过自定义镜像、静态检查、依赖扫描等环节，提升代码合入效率与质量；
- RAG智能助手：基于历史用例、脚本与日志构建知识库，实现用例智能检索、脚本复用与失败根因分析，显著提升测试资产复用率与问题定位效率。
### openUBMC实战分享：调速策略与组件定制
华鲲振宇BMC研发工程师何伟与厉兆伦分别就调速策略配置与组件级文件定制方法进行了实战分享：
- 调速策略：详细讲解了目标调速、线性调速、分区调速等场景的配置模型与注意事项；
- CSR定制与函数重定义：提出基于组件级的CSR合并与Lua函数重写机制，支持非侵入式硬件适配与功能扩展。
### Workshop实战环节：动手体验核心技术
在下午的Workshop实战环节中，开发者们展现出极高的参与热情，围绕部件驱动开发、可观测技术集成与测试策略三大主题展开了深度实践。在专家的指导下，现场参会开发者通过“手把手”实践促进技术理解，现场互动频繁，交流热烈，有效推动了技术经验的流动与社区协作共识的形成。
## 总结
本次Meetup在热烈的技术交流与实战研讨中圆满落幕，充分展现了openUBMC社区在开源BMC技术领域的创新活力与实践成果。社区将持续为开发者搭建开放、协作的技术平台，推动设备管理软件技术的标准化与普惠化，诚邀更多开发者加入，共同构建智能、开放的设备管理未来。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/community-operation report5/
---
未找到相关内容
---
https://www.openubmc.cn/zh/news/community-operation report6/
---
未找到相关内容
---
https://www.openubmc.cn/zh/news/community-operation report7/
---
未找到相关内容
---
https://www.openubmc.cn/zh/news/community-operation report8/
---
未找到相关内容
---
https://www.openubmc.cn/zh/news/community-operation report9/
---
未找到相关内容
---
https://www.openubmc.cn/zh/news/community-operation-report1-3/
---
新闻资讯
openUBMC 社区 2026 年 1-3 月运作报告
# openUBMC 社区 2026 年 1-3 月运作报告
2026/04/08
## 概述
2026年第一季度，openUBMC社区在技术迭代与生态建设上取得扎实进展。技术方面，openUBMC 26.03版本正式发布，围绕硬件适配、核心管理、驱动优化、接口定制与安全防护五大维度全面升级；openUBMC Studio同步进化为一体化IDE开发平台，原生集成智能开发能力，显著降低开发门槛、提升贡献效率。
生态方面，社区规模持续扩大：累计下载量突破11万+，活跃开发者超500人，成员单位达21家。成功举办25.12 LTS版本解读直播及武汉Meetup（联合长江计算、神州鲲泰），并启动第八届CCF开源创新大赛openUBMC赛道，加速培养算力基础设施人才。社区深度参与2026华为中国合作伙伴大会与鲲鹏KPN伙伴大会，推进“开源UBMC + 开放BIOS”双轮驱动战略。
品牌与基础设施同步升级：上线活动与品牌专区，统一视觉规范与使用指南，强化专业形象，支撑Studio推广与用户转化。安全治理持续夯实：Q1发布2份安全公告，修复21个漏洞，包括高危的protobuf组件漏洞（CVE-2022-1941），巩固LTS版本安全基线，保障产业级部署可信可靠。
> **阅读提示**：本月报阅读时长约10分钟
### 社区规模
## 截至2026年3月31日，openUBMC社区用户累计下载量12万+，超过500名开发者在社区持续贡献，累计产生7.5k个PRs、5.3k条Issues、36.2k条comments，11个SIG组。目前，已有26家成员单位加入openUBMC社区。
### 社区事件
➣ **openUBMC 2025社区年报发布**
2025 年是 openUBMC 社区迈向规模化发展的关键之年。openUBMC致力于通过开源模式，打造开放、易用的管理软件开发平台，推动算力设备管理产业的繁荣与创新。社区聚焦于软件管理领域，在面向全场景、全连接、全智能的时代需求下，为开发者提供一款架构领先、开发友好、遵循开放标准的算力设备开源管理软件。自2025.03.30 推出首个开源版本，到年底的 25.12 LTS 长期稳定版本发布，一年四轮迭代。482 位开发者已在此汇聚，与 openUBMC 并肩前行。
**原文阅读**：LINK
➣ **openUBMC 12.5 LTS版本解读直播**
2026年2月3日，openUBMC 成功举办 25.12 LTS 版本解读直播，吸引超600位开发者关注。该版本作为社区协同创新的里程碑，采用开放式微组件架构，在北向生态、运维能力及南向适配三大维度实现重磅升级。北向支持 Redfish 标准及 3D 服务器视图，南向新增 160+ 款硬件即插即用，运维方面通过并行升级技术将业务中断时间大幅降低。目前社区Issue 闭环率达97.32%，四层防护网全面建成，标志着 openUBMC 向着更开放、高效、可靠的BMC新生态迈进。
**原文阅读**：LINK
➣ **openUBMC 2026年首场Meetup在武汉举办**
2026年3月20日，由openUBMC开源社区牵头，联合社区成员单位长江计算、神州鲲泰共同举办的openUBMC Meetup武汉站圆满落幕。本次活动汇聚了社区核心伙伴，全天呈现10+精彩议题，从社区动态到商业实践，从前沿AI探索到全新开发平台解读，为现场开发者带来了一场关于BMC技术创新的深度交流。
**原文阅读**：LINK
➣ **第八届CCF开源创新大赛openUBMC赛道启幕**
本届赛事中，openUBMC社区发布赛道 —— openUBMC开源项目贡献赛，旨在发掘和培育精通 AI 时代 BMC 智能运维、嵌入式轻量化大模型部署的算力基础设施开源创新人才，助力现代化数据中心管理技术创新与产业升级。本次大赛共分两个赛题，赛题一：重塑BMC·AI时代智能运维创新平台、赛题二：嵌入式芯片的LLM挑战。
**赛事连接**：LINK
➣ **openUBMC 亮相 2026 华为中国合作伙伴大会**
2026 华为中国合作伙伴大会上，openUBMC 在鲲鹏计算展区独立展屏精彩亮相，全面展示开源智能管理软件的核心能力与生态价值。openUBMC 依托南北向丰富的生态能力，打造自主创新、安全可信的算力管理底座，同时展现开放活跃的开源生态，强化与鲲鹏深度协同，充分体现软硬件解耦、生态开放、高效易用的核心优势，面向全行业伙伴展示生态价值，共筑鲲鹏算力竞争力。
➣ **openUBMC 亮相 2026 鲲鹏 KPN 伙伴大会 赋能伙伴高效创新**
2026 鲲鹏 KPN 伙伴大会在南京隆重举行，吸引数百位鲲鹏生态伙伴及行业专家参与，华为鲲鹏计算业务副总裁刘云强在主题演讲中表示：“华为以openUBMC 开源 + BIOS 开放” 双轮驱动模式，为伙伴提供低门槛、低成本开发底座。当前已有多家 KPN 伙伴基于 openUBMC 在多行业场景落地自研发行版，显著提升开发效率。期待更多生态伙伴积极参与、深度协同，携手共建开放共赢的鲲鹏算力生态。
➣ **委员会议**
2026 年 3 月 27 日上午，openUBMC 开源社区发展委员会 2026 年度首次会议顺利召开。本次会议共设五个环节，依次为开场致辞、遗留问题同步、委员工作交流、专题研讨及会议总结。与会委员围绕相关议题展开充分交流研讨并提出建设性意见，针对社区共性问题，各工作组在研讨环节中进行了详细回应与解答，相关议题均取得良好研讨成效。
* * *
### 技术进展
➣ **openUBMC 26.03 正式发布**
- **硬件适配升级**：兼容 920L模组、182X标卡、OCP 网卡，支持温湿度采集，故障预判更精准
- **核心能力增强**：FRU 标签扩展、多主机传感器管理、硬盘信息远程获取，管理更精细
- **驱动能力优化**：新增182X/OCP/光润通多款硬件专属驱动，搭配兼容工具，适配更简单
- **接口灵活适配**：WEB 接口可按机型定制，标准对接顺畅，高阶能力全覆盖
- **安全防护升级**：强化会话安全管理，发布社区安全规范 V1.0，系统更可信
- **开发体验优化**：QEMU 仿真升级，文档及适配指南进一步完善，上手更快
**了解更多版本信息与下载**：LINK
➣ **openUBMC Studio全新升级**
定义开发流程，一个窗口解决openUBMC开发：BMC Studio 品牌全新升级为 openUBMC Studio。该平台原生基于 openUBMC 社区规范和基础设施构建开发流程。让您在一个窗口即可完成 openUBMC 开发。我们引入了完整的IDE功能，在几乎不改变您开发习惯的同时，提供深度对接社区、全面覆盖openUBMC开发的辅助支持。
**下载体验**：LINK
➣ **Hardware SIG**
1至3月完成社区26.03版本更新，完成硬件兼容性扩展，新增920L模组、182X新代次标卡、OCP网卡及光模块、MCX75310AAS-NEAT网卡、网讯FF5025网卡、9500-16i/8i等支持，新增RS485温湿度采集及硬盘/风扇/扩展板/硬盘背板/基础板更换记录功能，增强NVMe硬盘故障预测及光模块（含标卡与昇腾卡）故障检测能力，优化Bluefield DPU功能并新增BOX管理（Retimer及故障检测），支持SP686C-M-16i/40i及SP686C-MH-32i等RAID卡固件及其管理硬盘带外升级，同时增强能效管理配置能力，包括分区调速、精细化配置及PID参数等。
➣ **Component Driver SIG**
1至3月更新涵盖新增182X新代次标卡、OCP网卡及光模块与光润通(GRT)驱动开发，同时优化驱动框架以支持DBUS和共享内存调用、组件schema加载与管理、自描述记录解析处理及复杂属性语法，并新增南向网卡兼容性工具。
➣ **Interface SIG**
1至3月更新包括支持根据机型WEB接口灵活组合、优化光模块性能数据采集接口、基于Validator扫描通用问题标准化、增强ComputerSystem/PCIeSlots/Memory等北向接口标准能力，并新增RAID卡慢盘、固件升级暂存、dump BIOS Flash、DICE、大包升级及多系统等特性北向接口能力。
➣ **CICD SIG**
1至3月更新包括openUBMC Studio全新升级并新增IDE能力及CSR辅助开发功能，增强QEMU对博通RAID卡的仿真能力，新增基于lockfile的产品级构建与子系统切面配置汇总机制，并将QEMU版本升级至8.2.10。
➣ **Docs SIG**
openUBMC 社区 1-3 月新增 25 篇技术文档，包含compute、libsoc\_adapter、ipmi\_core、bmc\_network等组件接口文档与风扇板和风扇适配指导文档，文档覆盖底层硬件配置、故障定位及网络管理等核心场景，显著夯实社区知识底座。
➣ **bmc-core SIG**
1至3月更新包括新增FRU电子标签加工时间扩展、传感器事件多主机场景能力，同时新增IPMI硬盘信息获取功能。
➣ **Infra SIG**
1至3月更新包括发布社区基础设施软件开发生命周期治理与安全规范V1.0，新增LTS版本每日构建功能，以及新增社区包签名基础能力。
➣ **Security SIG**
- 支持框内节点间通信的安全控制能力，实现内部通信全安全策略可覆盖；
- 支持CPLD固件PFR能力，实现全固件可信覆盖；
- 支持组件级安全切面配置，集中可定制的安全风险控制。
➣ **QA SIG**
测试平台集成QEMU版本升级到8.2.10。
➣ **AI SIG**
社区新成立了AI SIG，聚焦社区AI辅助研发效率提升，以及AI与BMC智能运维的结合运用。
➣ **open UBMC 优质技术文章精选**
- 从开源社区到产业标准：openUBMC携手UBIOS引领服务器管理新纪元：LINK
- 让AI真正“防宕机”：openUBMC 故障预测系统的指标误区澄清与无感运维应用：LINK
- 基于BMC的AI故障预测系统构建及应用：LINK
- 昆仑太科基于openUBMC的POST Code功能实现从开源社区到产业标准：LINK
- openUBMC：超节点时代的 BMC 新范式：LINK
* * *
### 基础设施升级
➣ **每日构建与签名**
新增LTS版本每日构建功能，确保版本稳定性；新增社区包签名基础能力，保障软件供应链安全。
➣ **社区平台优化**
- 上线活动专区，展示全年活动规划并明确申请要求和相关流程；
- 优化下载中心，新增“全部版本”模块，按照LTS版和创新版对社区发行版进行了系统归档，帮助用户更清晰、高效地选择和获取所需版本；
- 为openUBMC Studio工具上线提供配套的工具包，提升工具的曝光度，助力工具推广和使用转化；
- 更新TC组织架构图与成员名单，确保社区治理结构的准确性和时效性；
- 上线品牌专区页面，提供社区标志视觉识别规范、品牌使用说明、logo不同格式下载及社区PPT模板，统一了社区品牌对外输出标准，方便开发者规范使用社区品牌资产。
➣ **社区流程优化**
openUBMC 社区在管理版本的需求/缺陷上，为了提高质量，需要在流程进行把控。社区基础设施在社区机器人上线对Issue的工作状态进行管控新功能，并包含权限配置和校验。同时给社区用户提供使用说明：LINK
* * *
### 软硬件兼容性测评
截至2026年3月31日，2026年1-3月新增19个，其中北向（ISV）新增7个，南向（IHV）新增12个。
➣ **南向兼容性列表**：SP675、SP681、SP235、SP235-O、SP233、SP232、SP236、SP566、UBEXP、紫金DPU-4口-25G、MCX75310AAS-NEAT、MCX623106AN-CDAT ➣ **技术测评列表**：已完成测评规范初稿制定，明确了评分机制和接口权重计算方案；完成部件驱动自动化测试平台搭建，并完成网卡部件驱动测试用例的建设，实现了测试流程标准化，提升了测试效率和覆盖度，为后续其他部件管理能力量化提供了依据。 ➣ **北向兼容性列表**：Assembly、Chassis DigitalWarranty、Graphics-Controllers、Processors Metrics、UpdateServiceCapabilities、CpuFPC、NpuFPC
* * *
### 安全公告
2026年1 -3月，社区共发布安全公告2个，修复漏洞21个。
**重点漏洞提醒**
**漏洞基本信息**
| 项目 | 内容 |
| --- | --- |
| 公告编号 | openUBMC-SA-2026-1002 |
| 涉及组件 | protobuf |
| 关联 CVE | CVE-2022-1941 |
| 严重等级 | High (高) |
**漏洞描述**：Oracle MySQL Connectors（数据库软件）存在一个被归类为 Critical 的漏洞。该程序在资源被重新利用之前未释放或错误地释放了资源（CWE-404），影响了系统的可用性。
**影响版本**
| 影响版本号 | 修复版本号 | 修复状态 |
| --- | --- | --- |
| openUBMC 25.12 | openUBMC 26.03 | Fixed |
**公告连接**：LINK
* * *
### 致谢
感谢以下 SIG 组及个人的贡献：
| Hardware SIG | Component Driver SIG | Interface SIG |
| --- | --- | --- |
| Docs SIG | Bmc-Core SIG | Infra SIG |
| QA SIG | AI SIG | release-management SIG |
| CICD SIG | Security SIG | LIU Yi |
| Huang Qiuxia | Ye Dailin | Wu Jiacong |
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/community-operation-report8/
---
新闻资讯
openUBMC 社区 2026 年 8 月运作报告
# openUBMC 社区 2026 年 8 月运作报告
2026/09/14
## 概述
2026年8月，openUBMC社区在技术迭代与生态建设上持续攀升，社区规模不断壮大：截至8月31日，累计下载量已突破17万，活跃开发者超830人，贡献单位增至36家。
生态建设上，openUBMC Meetup成都站圆满举办，聚焦技术赋能与产业落地，汇聚技术专家与开发者面对面交流；CCF开源创新大赛openUBMC赛道决赛于重庆大学收官，吸引41所高校、154人次参赛。影响力方面，openUBMC社区开展了2场技术直播，并首次在openUBMC视频号开播；开源实习30项任务截至8月底已全线认领完毕，多项成果合入社区代码库。
技术方面，openUBMC 25.12 LTS SP3版本正式发布，接入7款网卡、10+款硬盘的兼容性，60+缺陷修复提升版本稳定性；硬件适配与故障自愈能力增强，部件驱动2.0体系化文档发布、CSR2.0驱动落地，驱动开发有规范可依；研发诊断Agent打通Studio、MCP与真实BMC环境，形成初步闭环；社区文档新增29篇，开发者文档与参考指南持续完善。
从技术深耕到生态活跃，openUBMC以开放架构、生态协同、智能运维与高效开发为牵引，持续释放开发者活力与产业创新效能，推动产学研协同共建，加速构建安全、可信、繁荣的算力设备管理开源生态，夯实下一代数据中心基础设施底座。
> _（本月报阅读时长预计10分钟）_
* * *
## 社区规模
截至2026年8月31日，openUBMC社区用户累计下载量 **17万+** ，超过 **830** 名开发者在社区持续贡献，累计产生 **13k+** 个PRs、 **9k+** 条Issues、 **97k+** 条Comments， **13** 个sig组。目前，已有 **36** 家单位参与社区贡献。
* * *
## 社区事件
### ➣ 社区活动
#### ➣➣ openUBMC Meetup 成都站圆满举办，合肥站即将开启
8月14日，由openUBMC社区与华鲲振宇联合主办的openUBMC Meetup成都站圆满举办。本次活动聚焦技术赋能与产业落地核心主题，openUBMC社区多位TC委员、Maintainer及社区成员单位的技术专家齐聚成都，围绕可信计算安全体系设计、超节点管理方案探索、RAID卡与电源适配实践、基于Agent的智能化调试流程等主题展开10场技术分享，吸引了线上/线下众多开发者参与深度交流。
继成都站顺利落幕后，openUBMC Meetup 活动将于 9 月落地合肥，更多技术分享与生态碰撞敬请期待！
活动详情：https://www.openubmc.cn/zh/news/2026chengdu-meetup-review
#### ➣➣ 第八届CCF开源创新大赛openUBMC赛道圆满收官
8月14日，第八届 CCF 开源创新大赛 openUBMC 赛道决赛于重庆大学圆满收官。赛事聚焦 BMC 运维创新、大模型轻量化部署两大方向，共吸引 41 所高校、120 支战队、154人次参赛，学生参与占比达92.2%，百信、宝德、华瑞数鑫等产业链头部企业积极参与，产学研深度融合，以真实产业场景赋能开源创新，产出了一批优质落地作品，为算力开源生态注入新动能。
活动详情：https://www.openubmc.cn/zh/news/2026ccf-competition-recap
#### ➣➣ openUBMC社区技术直播持续开展
8月，openUBMC社区开展2场技术直播分享，分别由openUBMC社区技术委员会委员刘兴森、张超作为主讲嘉宾，围绕“openUBMC南向硬件管理技术规范、实践及生态建设分享”与“openUBMC架构概念设计介绍”两大主题，深入讲解统一高性能驱动框架与部件驱动管理规范、MDS微组件描述与MDB协作资源树等四大模型及南北向解耦设计等内容。
8月，openUBMC视频号也同步作为直播渠道开播，后续直播也将持续在视频号开展。**搜索关注【 openUBMC 】** 视频号账号，获取相关直播详情。
> - _扫码关注openUBMC视频号_
#### ➣➣ openUBMC开源实习继续火热推进
openUBMC 开源实习继续火热推进，截至8月31日，30项社区实习任务已全线认领完毕，多项成果已成功合入社区代码库，高校开发者踊跃参与社区共建，开源社区活力持续攀升。
开源实习详情：https://www.openubmc.cn/zh/internship
招募推文：https://www.openubmc.cn/zh/events/detail/openUBMC-Open-Source-Internship
* * *
## 技术进展
### ➣ 版本进展
**8月openUBMC 25.12 LTS SP3版本正式发布：**
- **硬件兼容版图持续扩大：** 新增182X新代次、MCX系列、沐创、光润通、Intel、博通、星云智联等7款网卡兼容性；新增HKEP系列、德明利、紫光闪芯、佰维、英韧、长江存储等10+款硬盘兼容性；新增900W电源、EXP 12盘背板等部件兼容性。
- **可靠性与稳定性增强：** 优化SP686C RAID卡固件日志收集机制和日志可读性、扩展板CPLD localbus链路异常检测机制，以及BIOS固件和TEE固件生效机制，版本可靠性持续提升。
- **缺陷修复：** 修复SP686C RAID设置启动盘及适配SATA SSD显示、RAID卡通信失败、日志冗余记录等60+问题，版本稳定性与用户体验进一步改善。
本版本共计修复Issue 68 个，合入PR 90 条。
了解更多版本信息：https://www.openubmc.cn/zh/news/2512-SP3-release
下载链接：https://www.openubmc.cn/zh/download
### ➣ SIG组月度动态
本月新增PR 1525 个，各sig组共召开公开例会 27 次，sig组活跃地图分布情况如下：
#### ➣➣ sig-hardware
8月，sig-hardware 在电源管理、故障自愈、硬件适配及可运维性等方面取得实质性进展，硬件可靠性与兼容性持续增强。
- **电源管理：** 支持 EB300 电源砖管理、BMC 主从电源带外管理、电源芯片厂商和型号查询，以及电源升级时UID灯控制，电源管理覆盖范围进一步扩大。
- **故障自愈与巡检：** 支持风扇故障自愈；VRD升级后备份固件包并支持VRD自愈；天池单板JTAG扫链巡检，可主动排查链路连通性异常，硬件可靠性进一步提升。
- **硬件适配：** 新增华瑞数鑫 B261 Boot RAID 控制器适配，以及紫光闪芯、英韧等硬盘兼容性适配，社区硬件兼容生态持续丰富。
- **可运维性：** 支持数码管显示框号、NPU模组电源黑匣子日志收集，以及通过IPMI命令记录BIOS维护日志；BIOS PFR可定位性增强；新增PCIe标卡在位建链失败告警，运维排障手段更加完善。
- **南向驱动升级：** 支持南向部件驱动 CSR 和 SO 的独立升级，驱动升级方式更加灵活。
#### ➣➣ sig-component-drivers
8月，sig-component-drivers 持续推进驱动2.0体系化与CSR2.0驱动落地，并在设备监控、devmon及libmcpp方面持续完善，驱动开发规范与框架能力同步提升。
- **部件驱动2.0体系化：** 发布部件驱动2.0体系化文档、南向API参考及网卡/GPU适配指南，统一DMC契约，驱动开发有规范可依。
- **CSR2.0 驱动：** 落地 LocalBus / I2cOverLocalBus / CpldRegister 等 CSR2.0 驱动，完善光模块与出框电链路扩展信息，驱动开发框架进一步完善。
- **设备监控与管理：** 支持DPU/ASU带外与SSU GE切换；EEPROM预加载改为header比对；加固Scanner调度死锁与误告警，设备监控更加稳定高效。
- **devmon：** 补齐设备/应用层插件设计文档；支持defer\_registration取消自动上树与定制化删除硬件自描述对象；修复position卸载残留与拓扑发现误跳过问题，设备自发现与管理能力进一步完善。
- **libmcpp：** 推出度量/telemetry与Lua/C++ Trace混用；优化旧SHM RPC与对象树内存，完善异步调度与旧框架兼容；补齐属性精确订阅、HTTP与D-Bus覆盖率，修复并发缓存与日志归属问题，框架库能力持续增强。
#### ➣➣ sig-docs
8月新增文档29篇，覆盖驱动开发、硬件适配、编码规范、安全基线等多个方向，重点包括：
- 《部件驱动2.0适配方案》：介绍部件驱动2.0适配方案的架构、核心价值与应用场景
- 《设备驱动开发指南》：提供从设计到实现的设备驱动完整开发流程
- 《整机类适配快速上手》：手把手完成新整机/新板卡的硬件接入
- 《openUBMC安全配置基线》：固件配套运行时的安全配置基线指导
此外，部件驱动接口模型设计、南向硬盘驱动适配指南、IPMI接口定制指南等文档也同步上线，社区知识底座持续夯实。
#### ➣➣ sig-ai
8月，sig-ai 在研发诊断Agent方面形成初步闭环，知识中台完成新一轮能力升级，问题诊断与全链路追溯能力初步形成。
- **研发诊断 Agent 初步闭环：** 已打通 Studio 连接管理、MCPHost、Coding Agent 与真实 BMC 环境，可调用 SSH/Telnet、BMT/MDB、知识检索等工具，结合问题描述、源码和真实环境开展问题诊断，并进一步衔接修复、升级和测试验证。后续将进一步区分研发诊断与运维日志分析的产品边界，重点服务研发阶段问题定位与修复，补齐离线诊断能力，优先覆盖高频、标准化问题。
- **知识中台能力升级：** 知识中台原型开发完成新一轮能力升级，新增精确查询、Issue/PR/Commit/论坛等显式关联、Fact/Event时序账本、版本归属与严格版本过滤等能力，可追踪需求、代码变更和版本演进全过程。下一步尽快上线测试环境，接入Interface SIG等真实研发用户，通过实际使用和过程数据进一步验证、优化技术能力及使用入口。
### ➣ openUBMC 优质文章精选：
从故障诊断到 RAS Offload：百敖 openUBMC 的 Intel 平台适配实践
一图读懂｜openUBMC 7月社区文档更新清单
* * *
## 致谢
亲爱的社区开发者：
过去一个月，是你们的热情与奉献，让 openUBMC 社区持续迸发活力！
每一行代码的提交、每一次技术的探讨、每一份经验的分享，都在为社区注入前行的力量。正是每一位开发者的持续参与，让openUBMC的基础更加坚实、生态更加繁荣。
若您在阅读月报时发现遗漏了您的精彩贡献或重要进展，请随时联系我们补充。
开源之路，感恩同行！让我们携手打造更繁荣的算力设备管理开源生态。
在此，谨向为本期月报提供资料支持的各 sig 团队及广大开发者致以诚挚的感谢与敬意：
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://gitcode.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/community-operation-report9/
---
新闻资讯
openUBMC 社区 2026 年 9 月运作报告
# openUBMC 社区 2026 年 9 月运作报告
2026/10/12
## 概述
2026年9月，openUBMC社区在技术迭代与生态建设上持续跃升，社区规模不断壮大：截至9月30日，累计下载量已突破18万，开发者超1000人，加入社区单位超40家。
生态建设上，openUBMC Meetup合肥站圆满举办，聚焦工程实践与AI调试创新，共建BMC开源生态；openUBMC开源发展委员会2026年第三季度会议召开，总结第三季度社区治理成效，开发者生态持续壮大、多方协同共建能力持续增强，生态治理与社区规模迈上新台阶。影响力方面，openUBMC亮相上海海思创新大会，Hi3095硬件能力正式向社区开放；openUBMC还亮相华为全联接大会2026，开源开放理念持续强化行业影响力。
技术方面，openUBMC 26.09版本正式发布，Studio能力增强、构建工具链升级，硬件生态与平台能力拓展；bmc\_network等核心组件实现社区贡献，华为贡献libiam、iam等安全能力组件落地；Agentic BMC完成小模型上板可行性验证。
从能力跃升到生态聚力，openUBMC以开放架构、生态协同、智能运维与高效开发为牵引，持续释放开发者活力与产业创新效能，深化社区治理与产业协同，加速构建安全、可信、繁荣的算力设备管理开源生态，夯实下一代数据中心基础设施底座。
> _（本月报阅读时长预计10分钟）_
* * *
## 社区规模
截至2026年9月30日，openUBMC社区用户累计下载量 **18万+** ，开发者超 **1000** 名，累计产生 **15 k+** 个PRs、 **10k+** 条Issues、 **123 k+** 条Comments， **15** 个sig组。目前，已有 **40+** 家单位加入社区。
* * *
## 社区事件
### ➣ 开源发展委员会会议
9月29日，openUBMC开源发展委员会2026年第三季度会议召开。第三季度以来，社区各项工作稳步推进，开发者生态持续壮大，代码规模和贡献量进一步提升。各成员单位在文档编写、特性开发与测试用例补充等方面持续投入，让社区的技术交流与协作更加活跃。
### ➣ 社区活动
#### ➣➣ openUBMC Meetup 合肥站圆满举办，深圳站即将开启
9月22日，由openUBMC社区与百信信息技术有限公司联合主办的openUBMC Meetup合肥站圆满举办。本次活动聚焦openUBMC工程实践与AI调试创新，汇聚线上线下开发者，围绕北向架构、南向适配、板卡排障等议题深度研讨，联动社区与产业伙伴，共建BMC开源生态。
继合肥站顺利落幕后，openUBMC Meetup活动将于10月落地深圳，更多技术分享与生态碰撞敬请期待！
活动详情：https://www.openubmc.cn/zh/news/2026hefei-meetup-review
更多Meetup 活动相关直播回放，将陆续同步至 **openUBMC 视频号** ，欢迎持续关注。
> _扫码关注openUBMC视频号_
#### ➣➣ openUBMC 亮相华为全联接大会 2026
9月，openUBMC亮相华为全联接大会2026，在高层演讲中被重点提及。作为面向硬件设备管理赛道的开源BMC项目，openUBMC秉持开源开放理念，以标准化、开放化的管理平台破除厂商锁定，赋能硬件厂商与服务器客户自主定制、快速集成。现场开设openUBMC主题展区与CodeLab实操体验，直观呈现北向自接入、南向自适配等核心技术方案，与开发者、产业链伙伴深度交流，持续夯实openUBMC在服务器硬件管理开源领域的核心影响力。
#### ➣➣ openUBMC 亮相上海海思创新大会
9月，openUBMC亮相上海海思创新大会，海思MCU产品领域总经理陈桂培在主题演讲中宣布，Hi3095硬件能力正式向openUBMC社区开放，双方合作由技术协同升级至市场联合共建。依托本次大会，openUBMC持续扩大在硬件设备管理领域的行业影响力，凝聚上下游伙伴力量，共同参与开源生态共建。
* * *
## 技术进展
### ➣ 版本进展
**9月openUBMC 26.09版本正式发布**
- **开发体验与工具链全面升级：** BMC Studio打通Workbench与模块构建发布流水线；bingo新增openEuler+Kunpeng，实现双架构交叉编译与多BMC芯片平台构建；新增40+款QEMU仿真模型，引入ASan、clang-tidy与AI辅助安全扫描；70+ skills上线Skills Marketplace，覆盖开发全流程。
- **硬件生态与平台能力持续拓展：** 新增10+款网卡、15+款硬盘、5+款RAID卡兼容性，部件更换后自动固件升级与配置恢复，实现即插即用；部件驱动框架新增62项能力并落地19项可观测框架；bmc-core重构算网融合上下电逻辑，带内IPMI实现秒级响应。
- **规范落地与质量保障体系完善：** Redfish/CLI/SNMP/WEB四协议全覆盖，17项特性灵活裁剪；SPDM可信根互联落地；社区用例接入每日构建，南向驱动规范测试用具落地，社区众测正式开启；部件驱动2.0全套指南与CSR/MDS配置语法齐套交付，SNMP/CLI接口文档自动生成。
本版本共计解决Issue 2693个、合入PR 4795条、新增代码行3742K。
了解更多版本信息：https://www.openubmc.cn/zh/news/2609-release
下载链接：https://www.openubmc.cn/zh/download
### ➣ SIG组月度动态
本月新增PR 1790 个，各sig组共召开公开例会 24 次，sig组活跃地图分布情况如下：
#### ➣➣ sig-hardware
9月，sig-hardware在部件适配、运维保障与电源管理等方面持续推进，硬件兼容版图与可运维性进一步提升。
- **存储与硬盘适配：** 新增德明利TS3160 SATA SSD适配，新增备件更换场景下硬盘/RAID配置的自动备份和恢复，运维切换更可靠。
- **电源与供电管理：** 新增支持PM3000W DC电源管理、900W电源适配，支持thermal\_mgmt组件风扇管理功能灵活裁剪，供电与散热管理能力持续完善。
- **硬件升级与信息获取：** 新增182x系列带外命令获取卡信息、通过SFC方式对FPGA固件升级，硬件可管理性进一步增强。
#### ➣➣ sig-component-drivers
9月，sig-component-drivers在部件驱动、设备监控及框架库方面持续演进，驱动体系与自发现能力进一步完善。
- **component\_drivers：** CSR1汇聚读支持按位合并，连接器可按硬件热插拔能力加载卸载；落地RS485风扇管理与BMC主从DPU带外管理，补齐SSU的Bios/BootOptions契约，驱动管理粒度更细。
- **devmon：** 器件合并覆盖跨槽位共享总线；未由插件接管的芯片可直接访问驱动，降低CPU占用；支持按热插拔能力加载卸载、从升级分区加载驱动，并发布硬件加载完成状态，设备发现与加载流程更透明。
- **libmcpp：** sensor与event支持函数表达式；提供最小系统模式下的服务启动管理，同步属性跟踪可随一键收集导出；补充本地持久化的写入量与写入频次统计，可观测数据更完整。
- **vpd：** 补齐博通BCM957608-P1400G的产品关键数据（VPD）并更新同系列P2200G能力；网迅FF5025同步到CSR 2.0；合入宝德PR2715B的OCP与Riser配置，硬件识别与兼容持续扩展。
#### ➣➣ sig-bmc-core
9月，sig-bmc-core持续推进核心组件开源与文档沉淀：bmc\_network、firmware\_mgmt、bmc\_upgrade组件实现社区开源，并新增文档《固件管理设计思想》，核心组件开放与知识积累同步并进。
#### ➣➣ sig-security
9月，sig-security新增华为公司贡献的安全管理特性组件libiam、iam、capability\_proxy、certificate，身份认证与能力代理等安全管理能力进一步丰富。
#### ➣➣ sig-docs
9月新增文档33篇，覆盖组件说明、驱动适配、CSR配置、接口参考、构建指导等多个方向，重点包括：
- **《部件类适配快速上手》：** 部件适配的最短可操作路径，手把手完成接入与验证
- **《南向网卡驱动适配指南》：** 从设计到实现的网卡适配完整开发流程
- **《Redfish资源索引集合》：** 新增Redfish资源接口参考文档
- **《Hi1712芯片构建指导》：** 涵盖环境准备、配置说明、构建流程与产物验证
此外，21篇组件说明文档及CSR配置字典、驱动规范、全局属性配置指导等也同步上线，社区知识底座持续夯实。
#### ➣➣ sig-ai
9月，sig-ai召开组会并总体确认openUBMC AI已由单点能力建设进入工程化和效果验证阶段，AI基础设施与场景化落地双线推进。
- **研发侧能力升级：** 持续升级RAG知识中台、MCP、Skills和Agent基础设施，后续将通过构建Benchmark验证知识中台相较裸Agent在准确率、任务完成率及Token和时延上的实际增益。
- **AI门禁架构演进：** 不再采用“大Skill+一次性Prompt”实现方式，向多专项Agent、并行执行、状态复用和Runtime/Harness化演进，门禁精准度与执行效率同步提升。
- **日志智能分析：** 进一步区分运维态与开发态——运维侧聚焦故障处置，开发侧结合日志、代码、历史变更和知识体系进行Agent化根因定位，问题定位链路更清晰。
- **Agentic BMC：** 已完成小模型上板可行性验证，后续重点从“能运行”转向真实平台性能与用户体验探索验证。
### ➣ openUBMC 优质文章精选：
基于 openUBMC 构建 Agent 驱动的 BMC 研发工作流
一图读懂｜openUBMC 8月社区文档更新清单
* * *
## 基础设施升级
### ➣ 社区文档场景化架构升级
匹配开发者真实开发流程，围绕“入门与准备—核心开发场景—测试集成—交流贡献—工具与参考”五大任务全面升级文档架构，为不同类型、不同水平的开发者提供更清晰的学习路径，让文档更易获取。
### ➣ 社区搜索能力优化提升
社区搜索范围已覆盖GitCode的PR/Issue；支持搜索结果版本切换，默认展示全部版本；同时新增搜索纠错、相关搜索和搜索反馈功能，检索体验更加智能便捷。
* * *
## 安全公告
9月，社区持续开展版本安全跟踪，对发现的安全问题及时评估、修复并发布公告，截至9月底共发布安全公告18个，CVE 76个，切实保障版本安全。
相关内容请关注官网安全公告：https://www.openubmc.cn/zh/security-advisories
* * *
## 致谢
亲爱的社区开发者：
过去一个月，是你们的热情与奉献，让 openUBMC 社区持续迸发活力！
每一行代码的提交、每一次技术的探讨、每一份经验的分享，都在为社区注入前行的力量。正是每一位开发者的持续参与，让openUBMC的基础更加坚实、生态更加繁荣。
若您在阅读月报时发现遗漏了您的精彩贡献或重要进展，请随时联系我们补充。
开源之路，感恩同行！让我们携手打造更繁荣的算力设备管理开源生态。
在此，谨向为本期月报提供资料支持的各 sig 团队及广大开发者致以诚挚的感谢与敬意：
* * *
## 欢迎关注openUBMC
- 社区官网：https://www.openubmc.cn
- 代码仓地址：https://atomgit.com/openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/community-opration-report4/
---
新闻资讯
openUBMC 社区 2026 年 4 月运作报告
# openUBMC 社区 2026 年 4 月运作报告
2026/05/11
## 概述
2026年4月，openUBMC社区技术革新与生态发展同步迈入新阶段。生态方面，社区规模持续扩大：累计下载量突破13.5万+，活跃开发者超600人，成员单位27家；高校行活动走进长沙四所高校，开源实习项目正式启动，南方电网基于openUBMC的能效优化实践落地，社区更荣获“2025年明星开源社区”称号，产学研用协同效应显著增强。
技术方面，Hardware SIG持续推进RAID南向部件驱动与CPLD无感升级特性开发，CICD SIG完成白牌包定制构建能力集成并发布openUBMC Studio 2.0版本，Docs SIG新增多份CSR配置指导书与开发文档，AI SIG重点建设Skills Marketplace生态并上线AI接口规范检视功能，官网同步完成“快捷访达”导航与内容展示板块升级，进一步优化开发者体验。
从技术输出到生态协同，openUBMC以开放架构、智能运维、全栈兼容与高效开发为战略支点，全面构建安全繁荣的算力设备管理开源新生态，推动下一代数据中心基础设施迈向更高阶。
> **阅读提示**：本月报阅读时长约10分钟
* * *
## 社区规模
截至2026年4月30日，openUBMC社区用户累计下载量**13.5万+**，超过**600**名开发者在社区持续贡献，累计产生**8k**个PRs、**5.9k**条Issues、**38.9k**条comments。目前，已有**27家**成员单位加入openUBMC社区。
* * *
## 社区事件
### ➣ openUBMC社区长沙高校行
2026年4月下旬，openUBMC社区联合CCF开展开源高校行活动，走进国防科技大学、湖南大学等四所长沙高校。活动以“开源技术赋能AI算力”为核心，通过技术分享、赛事宣讲深化产学研合作。社区专家围绕BMC智能算力管理、开源操作系统等前沿技术授课，并重点发布开源创新大赛赛题，聚焦“AI智能运维平台”与“嵌入式LLM应用”领域，鼓励学生基于openUBMC平台创新实践。活动期间，社区与高校达成多项合作意向，推动开源人才培育政策落地。本次行动有效提升了openUBMC技术影响力，为AI基础设施生态建设储备青年力量，助力社区开源使命与产业需求深度融合。
> **原文阅读**：LINK
### ➣ openUBMC 开源实习火热招募中！
openUBMC社区本月重磅推出开源实习项目，面向在校大学生开放线上实践机会。项目依托社区真实项目场景，设置安全构建方案设计、Qemu能力研究、事件管理系统等多元技术任务，覆盖系统开发、硬件适配等领域。学生通过官网报名审核后即可认领任务，完成任务可累计积分兑换薪资（最高8000元），达标还可获得中国科学院软件研究所官方实习证明。社区为实习生配备资深导师全程辅导，表现优异者更有机会获得企业青睐。目前实习项目已开放报名，扫码即可加入交流群获取一手资讯，开启开源实战之旅！
> **实习详情**：LINK
### ➣ openUBMC在Open AI Infra Summit分享超节点管理最新实践
2026年4月9日至10日，Open AI Infra Summit在北京成功举办。期间，openUBMC社区技术委员会委员黄晗在超节点生态分论坛上发表了题为《基于 openUBMC 打造超节点硬件智能管理平台》的主题演讲。此次分享深入剖析了智算集群规模化发展下的运维痛点，并系统性地提出了openUBMC的解决方案。演讲重点阐述了如何通过架构创新，构建超节点多BMC协同底座，实现CDI资源的透明管理；同时，强调了社区通过共建北向统一标准与标准化遥测接口，赋能AI智能运维闭环的核心价值。此次宣讲不仅展示了openUBMC在超节点管理和AI运维领域的技术前瞻性，也进一步巩固了社区在智算基础设施领域的影响力。
> **原文阅读**：LINK
### ➣ 荣誉：荣获“2025年明星开源社区”称号
2026年4月21-22日，在以“人工智能与软件变革——AI融合与数智出海新机遇”为主题的第五届中国国际软件发展大会上，openUBMC社区凭借其在算力设备管理领域的创新实践与生态贡献，荣获“2025年软件和信息技术服务业明星开源社区”称号。这一荣誉标志着openUBMC社区在推动国产开源算力设备管理软件发展方面取得的成就获得业界高度认可。
> **原文阅读**：LINK
### ➣ 实践创新：openUBMC在电力行业的典型应用落地
2026年4月29日，第九届数字中国建设峰会期间，华为计算产业峰会顺利举办。会上，南方电网带来了《南网妙算系列高能效服务器技术创新实践》主题分享，南网基于openUBMC实现模型预测控制算法落地，通过对服务器关键部件温度变化精准预测，实时测算整机最优功耗阈值，动态调节风扇转速，保障服务器整机始终处于最佳能效运行状态，助力数据中心绿色低碳、高效稳定运行。
本次实践是 openUBMC 在电力行业算力基础设施的典型落地应用，以开源硬件管理能力赋能行业算力能效升级，为智算中心绿色化转型提供了可借鉴的实践方案。
* * *
## 技术进展
### ➣ 版本进展
openUBMC社区故障上报和工程能力增强，新增**五个代码仓**(sensor, event, ipmi等)，分拆1个代码仓(component\_drivers)，持续提升传感器、精细化告警、部件驱动和门禁规则等组件能力；
经技术委员会讨论和表决，确定openUBMC社区LTS版本的发行节奏，按照5/8/11/2季度火车发车，25.12 LTS配套及收编，onetrack运作；
> **了解更多**：版本信息与下载
### ➣ SIG组月度动态
本月新增PR数507个，各SIG组共召开公开例会27次。
**特别兴趣小组活跃度全景图**
### ➣ Hardware SIG
- **RAID南向部件驱动特性**：旨在将RAID卡管理能力从应用层下沉至标准化的南向部件驱动框架，通过南向接口规范实现RAID卡、BBU、逻辑盘、物理盘、Expander等存储组件的统一管理；相关详细设计和代码开发进行中预计630发布。
- **CPLD无感升级特性**：旨在实现固件升级过程中业务不中断，实现CPLD无感升级能力构建；相关详细设计和代码开发进行中预计630发布。
### ➣ CICD SIG
- **白牌包定制构建**：首次在bingo中集成了白牌包定制能力，用户可自定义执行脚本和内容进行白牌hpm包构建。
- **openUBMC Studio发布**：在社区发布openUBMC Studio可视化BMC开发工具 2.0 版本，提供模型配置与检查、CSR可视化配置、一键出包、CSR出包等开发功能。
- **Robot Framework**：伙伴向社区贡献了基于Robot Framework开源测试框架实现的冒烟测试方案。
### ➣ Docs SIG
4月新增文档上新：bitstring接口说明、基础板CSR配置指导书、风扇板CSR配置指导书、扩展板CSR配置指导书、IEU CSR配置指导书、整机PSR配置指导书，更新Docker开发环境搭建、持久化机制介绍、key\_mgmt密钥管理组件FAQ、BMC Studio用户指南、Docker开发环境搭建、KVM常见问题定位指南、网络管理常见问题指南。
### ➣ AI SIG
4月份，AI SIG重点推进了Skills Marketplace生态建设，包括openUBMC Studio插件上线、技能扩展、数据飞轮的方案评审，完成了AI接口规范检视功能上线，并吸纳了新的Maintainer与Committer。
### ➣ open UBMC 优质技术文章精选
- 一图读懂｜openUBMC 3月社区文档更新清单
- 效率提升150%！基于openUBMC的高密存储服务器产品化实践
* * *
## 基础设施升级
### ➣ 官网与信息架构全面升级优化
对社区官网的整体内容进行了全面补充升级，新增了openUBMC整体特性介绍、社区贡献、社区伙伴单位等内容，丰富了官网信息维度。同时对导航架构及信息层级进行全面优化，提升了内容查找效率与浏览体验，优化社区资源获取路径。
### ➣ 组织架构成员新增补充
根据社区治理发展需要，对开源发展委员会和技术委员会（TC）的成员名单进行了新增和补充，确保社区组织信息的动态更新与治理角色的完整性。
* * *
## 致谢
亲爱的社区开发者：
过去一个月，是你们的热情与奉献，让 openUBMC 社区持续迸发活力！
无论是代码仓库中的匠心雕琢，还是技术论坛的思想交锋；无论是文档的精心编撰，还是活动的全力支持——每个“你”的参与，都是社区生态茁壮成长的养分。
若您在阅读月报时发现遗漏了您的精彩贡献或重要进展，请随时联系我们补充。
开源之路，感恩同行！让我们携手打造更繁荣的算力设备管理开源生态。
在此，谨向为本期月报提供资料支持的各 SIG 团队及广大开发者致以诚挚的感谢与敬意：
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/hangzhou-meetup-review/
---
新闻资讯
共筑算力管理新未来|openUBMC Meetup回顾
# 共筑算力管理新未来|openUBMC Meetup回顾
2025/05/30
# 共筑算力管理新未来|openUBMC Meetup回顾
2025年5月26日，由openUBMC开源社区主办的首届Meetup在杭州成功举办。本次活动吸引了来自整机、互联网、IBV、部件、芯片等行业上下游的社区Maintainer、社区开发者等60余位行业精英，围绕openUBMC社区展开交流，共同探讨了openUBMC的技术演进路径与产业实践经验。
本次Meetup由上午的议题分享和下午的Workshop组成。现在，让我们回顾一下本次活动吧。
## 议题分享
上午的分享由技术议题组成，来自5家企业的社区开发者分享了各自的技术议题。
### 开场介绍
张雨博代表openUBMC社区技术委员会介绍了本次Meetup的具体议程，并分享了当前openUBMC社区更新，包括社区25.03版本的新特性、25.06版本展望、社区运营数据分享、BMC Studio特性快照，和社区门户网站的下一步规划。
### DT在北向接口中的优秀实践
黄晗代表Interface SIG介绍了如何利用UT能力对北向映射配置进行单元测试，大幅度缩短开发调试周期的同时提高了社区代码质量看护能力。他呼吁社区开发者后续在北向接口中持续开展UT测试的建设，共同提高openUBMC北向接口稳定性。
### 南向部件驱动规范
刘兴森代表Hardware SIG介绍了如何通过规范化的部件兼容方式解决不同硬件差异性适配的问题，同时通过开放式架构支持部件厂商自行在社区上开发BMC部件驱动。他呼吁社区更多的志同道合之士共同加入规范建设讨论中。
### 开发者构建与流水线构建实践
来自武汉长江计算科技有限公司的易重辉介绍了长江计算如何基于openUBMC社区Conan仓搭建了自己的构建流水线体系，他还结合实际案例，分享了在搭建过程中遇到的各类技术挑战及应对经验，为开发者们提供了极具实践价值的参考。
### 智能网卡适配经验分享
来自河南昆仑技术有限公司的包敏敏结合河南昆仑在openUBMC智能网卡项目交付中的实战经历，深入剖析了项目实施过程中遇到的各类技术难题，并分享了团队在攻克这些难题时积累的宝贵经验与心得。
### 开发实践问题案例分享
同样来自河南昆仑技术有限公司的熊子锐作为新接触BMC领域的开发者，将上手openUBMC中遇到的问题总结成经验心得，让更多的新开发者快速上手openUBMC。
### 智能串口屏自研组件方案介绍
来自宝德计算机系统有限公司的邱豪深入剖析了宝德如何在openUBMC平台上，凭借自研组件成功实现串口屏功能的创新突破。他详细解读了技术细节与实现路径。同样来自宝德的朱俊杰先生，则聚焦于新增组件的全流程管理，总结并分享了其中的关键步骤与宝贵经验，为开发者们提供了极具参考价值的实践指南。
### 北向接口适配分享
四川华鲲振宇智能科技有限公司的张强详细介绍了如何巧妙运用北向映射机制，将原本需要1.5人月的接口适配工作量，高效压缩至仅需3人天即可完成。这一创新方法不仅大幅提升了工作效率，更为企业节约了宝贵的时间与资源，引发了现场开发者的广泛关注与热烈讨论。
## 实战Workshop
下午的实战Workshop由openUBMC社区技术委员会发起的，聚焦社区核心技术与热门话题，通过沉浸式开发场景赋能开发者成长。活动设置代码实战、分组攻坚、开放讨论等多元环节，参与者通过手写关键模块、协同调试代码、即时方案论证，零距离体验开源协作的创造力与凝聚力。现场开发者反馈："学习和交流了很多问题，遇到的问题都得到了很好的解答。"本次Workshop通过「以战代练」的创新模式，助力开发者深化技术理解，推动社区生态共建。
## 总结
本次Meetup通过不同企业的技术经验分享，展现了openUBMC社区开发者对技术的热爱和钻研精神，为BMC开发者提供了一个开放的、技术为导向的交流平台。后续openUBMC社区会持续举办线下技术活动，欢迎更多的开发者参与！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/kadc-2025/
---
新闻资讯
KADC 2025 | openUBMC技术分论坛圆满举办：共筑智能化算力的管理底座
# KADC 2025 | openUBMC技术分论坛圆满举办：共筑智能化算力的管理底座
2025/05/27
# KADC 2025 | openUBMC技术分论坛圆满举办：共筑智能化算力的管理底座
2025年5月24日，鲲鹏昇腾开发者大会（KADC）在北京中关村国际创新中心盛大召开。作为大会重要组成部分，以“openUBMC：共筑智能化算力的管理底座”为主题的技术分论坛吸引了来自互联网云厂商、整机商、部件商、标准组织、高校等领域的开发者，与会者共同探讨开源设备管理软件的未来发展。
## 开场致辞：开源共建，引领产业未来
华为计算产品线云与计算硬件部部长任超为分论坛致辞。他回顾了华为自2003年投入服务器研发以来在BMC领域的深厚积累，强调华为BMC以“极致安全”为根基，为全球算力设备提供智能化管理能力。任超表示：“计算产业是生态型产业，BMC作为关键一环，唯有通过开源才能凝聚产业上下游智慧，共建算力管理生态。”华为作为openUBMC社区发起者，将开源二十余年的技术沉淀，并持续投入社区治理、技术创新和生态建设，推动形成“开放、协作、透明、共建、共享、共治”的开源社区。他呼吁开发者共同参与，将openUBMC打造为全球领先的数字基础设施管理软件。
华为计算产品线 云与计算硬件部部长 任超
## 主题演讲：开源实践与生态共赢
分论坛演讲围绕openUBMC的技术创新与行业实践展开六场重磅分享：
### 共建openUBMC社区，共筑智能化算力管理底座
openUBMC社区秘书长王瑞锋深入剖析了AI时代下多元算力所面临的管理挑战与机遇。他明确提出了社区的使命：致力于提供开源且标准化的数字基础设施设备管理软件，汇聚全球开发者的智慧，在跨平台、跨领域以及全产业链上持续创新。在演讲中，他详细介绍了社区的架构设计、工具链功能以及创新实例化路径，并正式发布了openUBMC 25.03社区发行版。最后，他向广大开发者发出呼吁，倡导“同源共振”，携手推动版本的持续迭代与创新。
openUBMC社区秘书长 王瑞锋
### 开放式架构构筑管理软件平台新形态
openUBMC技术委员会委员宋铜铃在演讲中，从算力行业对设备管理的诉求演进进行分析，提出了微组件架构的设计原则，以解决产业从单机到集群的管理难题。强调通过标准化接口和统一组件框架，实现南北向管理的开放性与适配性，并通过“一站式开发平台”，助力开发者在社区持续创新。
openUBMC技术委员会委员 孙铜铃
### 基于openUBMC构建&自动化测试经验分享
来自四川华鲲振宇智能科技有限责任公司的刘松在分享中深入介绍了基于openUBMC的构建与自动化测试实践。他详细阐述了华鲲振宇如何通过组件化设计显著提升集成效率，有效缩短版本发布周期，并保障项目的高效与高质量交付。
四川华鲲振宇智能科技有限责任公司 刘松
### 基于openUBMC端到端交付实践与案例解析
在演讲中，来自河南昆仑技术有限公司的王钦东详细介绍了河南昆仑的openUBMC一体化解决方案。他通过展示鲲鹏/昇腾机型商用发行版的端到端交付案例，深入阐述了如何借助社区力量实现商用化落地，为行业提供了宝贵的经验和思路。
河南昆仑技术有限公司 王钦东
### 基于openUBMC的BMC Studio工具链的应用实践
来自昆仑太科（北京）技术股份有限公司的王亚洲在演示中展示了BMC Studio工具链的强大功能，特别是在开发环境搭建和部件定制方面的高效应用。充分凸显了openUBMC的易用性与易扩展性，为开发者提供了极具价值的参考和启示。
昆仑太科（北京）技术股份有限公司 王亚洲
### 基于openUBMC的conan组件构建与管理实践
来自南京百敖软件有限公司的汪涛在分享中详细介绍了Conan组件的构建实践，以及百敖在相关构建场景下的丰富经验积累。他指出，通过社区的集中化依赖管理，能够显著提升对客户需求的响应效率，为企业的技术发展和客户服务提供了有力支持。
南京百敖软件有限公司 汪涛
本次分论坛通过不同企业的技术分享与案例实践，展现了openUBMC社区在推动算力管理底座智能化中的多元化价值和作用，为产业提供了更开放、更高效的开源设备管理软件。
## 加入我们
openUBMC社区将持续汇聚全球开发者力量，共同打造数字基础设施管理的开源标杆。扫描下方二维码关注社区动态，携手共建算力管理生态！
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/meetup-callfor/
---
新闻资讯
议题征集｜openUBMC Meetup成都站、深圳站，诚邀您提交议题
# 议题征集｜openUBMC Meetup成都站、深圳站，诚邀您提交议题
金秋时节，openUBMC开源社区将在10月31日来到成都，在11月7日来到深圳，举办两场线下Meetup技术交流活动。在此，我们面向全体开发者公开征集Meetup议题，期待在活动现场听到你的声音！
2025年10月31日、 2025年11月07日
成都、深圳
## 活动议程
# 议题征集｜openUBMC Meetup成都站、深圳站，诚邀您提交议题
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/openAI-infra-summit/
---
新闻资讯
开源筑基，智算同行！锁定4月10日Open AI Infra Summit，openUBMC与你共探超节点智能管理新未来
# 开源筑基，智算同行！锁定4月10日Open AI Infra Summit，openUBMC与你共探超节点智能管理新未来
2026/04/08
## 概述
智算时代加速演进，超节点架构与开源协同正成为算力基础设施升级的关键方向。作为算力设备管理开放生态的核心力量，openUBMC持续以开放架构破解行业痛点，推动硬件管理标准化、智能化与生态化发展。
2026年4月10日，Open AI Infra Summit超节点生态分论坛即将开启，openUBMC将带来重磅主题演讲，分享基于开源体系构建超节点硬件智能管理平台的最新实践。
## 本次演讲亮点抢先看：
- **1.聚焦超节点Scale-Up架构趋势，直击AI算力硬件管理核心痛点；**
- **2.深度解读openUBMC如何构建统一、可复用、高可靠的智能管理引擎；**
- **3.分享开放生态协同方案，助力伙伴快速落地超节点硬件智能化能力；**
- **4.前瞻产业标准与技术路线，共筑智算基础设施开源新生态。**
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/openUBMC-annual-report-2025/
---
新闻资讯
openUBMC开源社区2025年度报告
# openUBMC开源社区2025年度报告
2026/01/16
# openUBMC开源社区2025年度报告
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/shenzhen-meetup-review/
---
新闻资讯
openUBMC Meetup 深圳站成功举办，共探开源BMC技术与生态新进展
# openUBMC Meetup 深圳站成功举办，共探开源BMC技术与生态新进展
2025/11/10
# openUBMC Meetup 深圳站成功举办，共探开源BMC技术与生态新进展
2025年11月7日，openUBMC Meetup深圳站成功举办。本次活动汇聚了来自硬件厂商、开发者、企业用户等多方代表，围绕openUBMC社区最新进展、南向部件驱动、可观测技术、多机型构建、AI测试融合等热点议题展开深度分享与研讨。
## 社区进展与版本发布
**openUBMC技术委员会委员张雨博**分享了社区最新进展：25.09版本在代码贡献、硬件兼容性与开发者体验上取得突破性进展；社区首个LTS版本——25.12的规划也已启动，将重点增强接口规范与部件驱动框架等能力。与此同时，社区运营持续活跃，通过在西安、成都、深圳等各地举办活动，进一步连接广大开发者，共建开放协作的技术生态。议题的最后，张雨博表示，2026年技术规划已开启，现公开征集技术需求与创新建议，诚邀全球开发者共同参与，推动openUBMC生态持续演进。
## 关键技术议题深度解析
### 南向部件驱动框架：标准化管理，生态共建
**openUBMC Component Drivers SlG Maintainer 刘兴森**系统介绍了openUBMC南向部件驱动规范的逻辑架构与实现路径。该框架通过统一接口标准，实现硬件适配与BMC应用层解耦，支持部件即插即用，显著降低开发与定制成本。目前，已有部分网卡、GPU已在社区落地，Q4会继续发布更多的部件。同时，《服务器南向接口要求》已完成标准立项，正面向社会公开征集意见中。
### 可观测技术：从数据到洞察，提升运维效率
**openUBMC Interface SlG Maintainer 李四光**深入讲解了openUBMC在Trace、Metric、Logs三大信号维度的能力建设。通过集成OpenTelemetry标准、Grafana可视化与Prometheus监控等系统，实现了系统状态的全链路可观测，助力故障定位与性能优化。
### 开发者说：openUBMC实战案例分享
- **3D Web服务器交互系统创新实践**
**宝德计算BMC研发主管邱豪**分享了基于Vue+Three.js构建的沉浸式3D管理界面，通过硬件故障可视化定位与远程运维支持，展现了openUBMC在现代运维体验方面的创新突破。
- **PCIe Switch在鲲鹏平台的深度适配**
**同泰怡软件工程师彭爽**揭秘了在鲲鹏平台上实现PCIe Switch设备识别、槽位管理与BMC界面集成的全流程适配方法，展现了openUBMC在复杂硬件环境中的强大兼容性。
- **NVMe逆序编排与故障灯反转实战**
**openUBMC TC委员&河南昆仑BMC架构师王钦东**分享了通过定制化CSR配置与CPLD协同，实现客户对NVMe盘符逆序编排与故障指示灯行为灵活定制的完整方案，体现了openUBMC在客户定制化需求方面的卓越能力。
- **多机型自动化构建流水线实践**
**河南昆仑BMC研发工程师黄奥**展示了基于Docker与Bingo工具链的多分支、多机型自动化构建与归档方案，显著提升了版本交付效率，为社区开发者提供了可靠的构建实践参考。
- **自动化测试与质量保障体系**
**河南昆仑BMC研发工程师钱强**介绍了Redfish标准化测试工具与iTestSmart自动化测试平台的深度应用，在831条用例中实现93%通过率，为社区提供了可靠的质量保障方案。
- **1GE网卡南向适配完整流程**
**网迅!科技固件工程师余天文**演示了网迅如何在openUBMC平台上完成网迅网卡的自适配流程，通过CSR配置、NCSI协议测试与驱动集成快速将网迅网卡适配至openUBMC社区，为广大部件开发者提供了全新的思路。
- **多节点服务器散热管理挑战与突破**
**恒扬数据软件工程师李天亮**深入探讨了多节点服务器场景下BMC间协同调速、数据同步与异常容错等架构挑战，为社区在多节点管理能力建设方面提供了重要思路。
## Workshop：动手实践，深度互动
在Workshop环节，社区为与会开发者准备了南向部件驱动与可观测技术两大专题的动手实践。现场开发者们踊跃参与，在社区专家的指导下，体验了从理论到实践的完整过程。
本次Meetup不仅是技术成果的集中展示，更是社区协作与生态共建的生动体现。随着25.12 LTS版本的筹备与2026年技术规划的启动，openUBMC社区将继续携手开发者与企业伙伴，推动开源BMC技术在架构领先、标准开放、安全可信的方向上持续演进。
## 🚩 期待下一期 openUBMC Meetup!
技术的交流与探索永无止境，openUBMC 社区的脚步不会停歇。未来，openUBMC Meetup 将走进更多城市，把前沿的技术分享、实用的实操体验带到各地开发者的身边。openUBMC 将持续深耕社区建设，汇聚更多技术力量，丰富社区生态，让每一位开发者都能在社区中收获成长与价值。
### 您可以查阅我们的官方网站、论坛，了解 openUBMC更多信息⬇️
- openUBMC 官方网站 https://www.openubmc.cn/zh
- openUBMC 论坛 https://discuss.openubmc.cn/
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/ubmc-studio/
---
新闻资讯
openUBMC Studio 正式发布
# openUBMC Studio 正式发布
2026/03/31
### 资源获取：
openUBMC Studio下载链接：https://www.openubmc.cn/zh/marketplace/openUBMC Studio
openUBMC Studio使用手册：https://www.openubmc.cn/docs/zh/development/tool\_guide/bmc\_studio\_tool.html
### 资源获取：
openUBMC Studio下载链接：https://www.openubmc.cn/zh/marketplace/openUBMC Studio
openUBMC Studio使用手册：https://www.openubmc.cn/docs/zh/development/tool\_guide/bmc\_studio\_tool.html
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/ubmc-studio-2.0.3/
---
新闻资讯
openUBMC Studio 2.0.3 发布
# openUBMC Studio 2.0.3 发布
2026/07/13
### 资源获取：
openUBMC Studio下载链接：https://www.openubmc.cn/zh/marketplace/openUBMC Studio
openUBMC Studio使用手册：https://www.openubmc.cn/docs/zh/development/tool\_guide/bmc\_studio\_tool.html
### 资源获取：
openUBMC Studio下载链接：https://www.openubmc.cn/zh/marketplace/openUBMC Studio
openUBMC Studio使用手册：https://www.openubmc.cn/docs/zh/development/tool\_guide/bmc\_studio\_tool.html
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/news/xian-meetup-review/
---
新闻资讯
活动回顾｜openUBMC Meetup 西安站
# 活动回顾｜openUBMC Meetup 西安站
2025/08/22
# 活动回顾｜openUBMC Meetup 西安站
8月18日下午，openUBMC X 昆仑太科 Meetup西安站圆满举办。现场近30位企业开发者线下参与。本次 Meetup 聚焦社区 25.06 版本的新特性，以Workshop形式开展，**围绕可观测技术运用、社区测试能力提升和软件能力提升**三大核心主题展开实操体验。开发者在动手实践中增强了对技术的理解，加强了对社区发展的认识，并进一步激发了参与社区建设的热情。
## Topic：openUBMC Community Updates
**openUBMC 社区技术委员会委员张雨博介绍了活动流程及社区最新进展，涵盖 25.06 版本特性、25.09 版本规划以及社区组织与运作机制，帮助开发者全面了解社区在技术迭代和生态建设方面的成果**。25.06 版本在可定位性和工具易用性方面引起广泛关注，25.09 的版本规划也让开发者对社区未来充满期待。社区组织与运作机制的透明介绍，为开发者更深入参与社区工作提供了清晰路径。
## 可定位性Workshop：可观测技术运用
**openUBMC 社区 Interface SIG 的李四光深入介绍了可观测特性**，从技术原理到应用场景系统讲解，帮助开发者掌握从数据采集、指标监控到日志分析的全流程方法，深化对 BMC 软件系统性观测的理解。
## 社区测试能力提升Workshop：社区冒烟测试运用和实践
**张雨博和林万敏代表 CICD SIG，分享了 25.06 版本中基于 Robot Framework + Qemu 实现的冒烟测试体系**。林万敏通过实际案例演示了如何利用 Robot Framework 开发 BMC 北向接口测试用例，使开发者直观体验到自动化测试的高效与便捷。
## 软件能力提升Workshop：大模型辅助编码运用和实践
**张雨博与李兆天围绕设计、编码和测试三大维度，结合 openUBMC 实际案例，解析了社区特性设计方法、代码编写策略及测试用例设计流程**。李兆天展示了如何借助 AI 大模型工具链实现设计文档自动生成、测试用例自动编写与 DT 代码自动生成，为开发者提升效率提供新思路，并鼓励大家积极探索 AI 辅助编码的潜力，贡献创新方案。
## 🚩 期待下一期 openUBMC Meetup!
技术的交流与探索永无止境，openUBMC 社区的脚步不会停歇。未来，openUBMC Meetup 将走进更多城市，把前沿的技术分享、实用的实操体验带到各地开发者的身边。openUBMC 将持续深耕社区建设，汇聚更多技术力量，丰富社区生态，让每一位开发者都能在社区中收获成长与价值。
### 您可以查阅我们的官方网站、论坛，了解 openUBMC更多信息⬇️
- openUBMC 官方网站 https://www.openubmc.cn/zh
- openUBMC 论坛 https://discuss.openubmc.cn/
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/operations-rules/
---
# 技术委员会运作规则
# 政策规则
了解openUBMC社区的运作规则、行为准则、AI贡献策略等相关内容
技术委员会运作规则社区行为准则AI贡献策略
openUBMC社区技术委员会运作规则
## 总则
openUBMC开源社区技术委员会（Technical Committee, 简称TC）是 openUBMC 社区项目的技术管理机构，提供技术指导、决策和监督。
## 主要职责
技术委员会是社区的技术领导机构，其主要职权是：
1. 技术委员会拥有技术决策的最终裁决权。
2. 决策社区技术的发展愿景和方向。
3. 决策社区 SIG 的成立、撤销、合并等事务。解决 SIG 组之间的协作冲突，辅导、审视和监督 SIG 组的日常运作。
4. 落实社区日常开发工作，保证 openUBMC 社区发行版高质量发布。
5. 引导社区建立原创性开源项目，持续构建社区技术影响力。
## 构成
技术委员会设主席 1 名，主席的职权是：
1. 召集和主持技术委员会会议，并保证参会人员有充分表达技术意见的权利。
2. 在各类会议、活动中代表社区进行宣传。
3. 主席同时是技术委员会委员，拥有和其他委员相同的投票权利。
openUBMC 开源社区TC主席及成员，由 openUBMC 社区任命，包含对 openUBMC 社区做出重大贡献并愿意持续投入的人员。
## 会议召开与决策机制
技术委员会每月召开技术委员会例会，或二分之一以上委员提议召开临时会议。
1. 技术委员会会议由主席在会议召开前 5 个自然日通过邮件在邮件列表通知全体委员，会议通知应当包括召开的地点、日期、时间、方式和会议议题以及可用的参考来源，以便委员对会议内容获取相关信息进行准备。会议为公开会议，任何社区成员都可以参加会议，表达技术观点但无投票权利。
2. 技术委员会会议须有三分之二以上（含）的委员出席为有效会议。
3. 所有决议均需要在有效的例会进行投票表决，投票为公开记名投票。投票分为赞同票、反对票和弃权票，只有三分之二以上（含）的与会委员且超过全体委员会的二分之一投赞同票，决议才能通过，未到场委员不能委托其他人代替投票。
## 联系方式
邮件列表：tc@public.openubmc.cn
线上会议：请前往SIG中心参与
# 社区行为准则
# AI贡献策略
---
https://www.openubmc.cn/zh/organizations/
---
# Organizational Structure
The openUBMC community is governed by an elected TC and operates with full transparency to ensure an impartial and forward-looking technical roadmap.
We champion the principle: Contribution Earns Influence. Advance your role to a project maintainer or TC member, and collectively define openUBMC's future.
更多
## Vision & Mission
The openUBMC community offers open source and standardized software for managing digital infrastructure. By harnessing the collective expertise of developers, it drives continuous innovation across all platforms, domains, and the entire industry value chain.
## Organizational Structure
The openUBMC community's governance is defined by the Open Source Development Committee. The Secretariat, led by the Secretary-General, oversees routine operations, while the Technical Committee (TC) sets the technical direction.
## Open Source Development Committee
马银川
主席
华为技术有限公司
Email
王瑞锋
秘书长
华为技术有限公司
Email
卞兴中
委员
深圳云芯智联信息技术有限公司
Email
蔡积淼
委员
北京软通华方计算机有限公司
Email
陈刚
委员
河南昆仑技术有限公司
Email
陈林
委员
四川云海芯科微电子科技有限公司
Email
陈小春
委员
昆仑太科（北京）技术股份有限公司
Email
丁雁林
委员
北京兴汉网际股份有限公司
Email
高贤虎
委员
海思技术有限公司
Email
高兴华
委员
北京网迅科技有限公司
Email
高瞻
委员
南京百敖软件有限公司
Email
洪坤贤
委员
中科驭数（北京）科技有限公司
Email
鞠荣荣
委员
百信信息技术有限公司
Email
李浩杰
委员
深圳市恒扬数据股份有限公司
Email
李雪莲
委员
中国电子技术标准化研究院
Email
李志高
委员
腾讯云计算（北京）有限责任公司
Email
林国辉
委员
无锡沐创集成电路设计有限公司
Email
刘敬轩
委员
中移（苏州）软件技术有限公司
Email
刘胜
委员
浙江力积存储科技股份有限公司
Email
刘玉伟
委员
北京光润通科技发展有限公司
Email
苗福友
委员
全球计算联盟
Email
庞玮
委员
天翼云科技有限公司
Email
彭小南
委员
神州鲲泰（厦门）信息技术有限公司
Email
盛永
委员
百度在线网络技术（北京）有限公司
Email
View All
## Technical Committee (TC)
宋铜铃
主席
Email
陈莹亮
委员
Email
陈士豪
委员
Email
程子明
委员
Email
黄晗
委员
Email
黄嘉庆
委员
Email
刘松
委员
Email
刘兴森
委员
Email
刘宇杰
委员
Email
司昌谅
委员
Email
王钦东
委员
Email
汪涛
委员
Email
王亚洲
委员
Email
许晓菡
委员
Email
于飞
委员
Email
张超
委员
Email
章建平
委员
Email
张雨博
委员
Email
赵锐
委员
Email
钟君
委员
Email
## Secretariat
王瑞锋
秘书长
Email
陈莹亮
执行秘书&生态组长
Email
何芦微
执行秘书&运营组长
Email
刘怿
执行秘书&营销组长
Email
---
https://www.openubmc.cn/zh/roadmaps/
---
文档中心
体验地图
社区体验地图
01
## 认识openUBMC
什么是openUBMC
openUBMC定义了一款开源BMC软件栈，基于灵活可伸缩的架构、敏捷易用的开发工具、丰富的生态资源，支持广大开发者打造差异化BMC功能，自由定制竞争力特性
文档中心开发工具社区支持openUBMC提供哪些服务
02
## 文档中心
开发指南
丰富文档助力开发者快速上手openUBMC，灵活定制专属的BMC软件
快速入门
03
## 开发工具
BMC Studio
直观的拖拽式可视化开发工具与一步到位的构建工具，打造开发者友好的开发工具库
BMC Studio
在线会议
社区论坛
04
## 社区支持
论坛 SIG组会
供开发者自由交流的社区论坛、工作组会议线上直播，共建开发者深度参与的社区
05
## 与openUBMC共同成长
创建组织 组织介绍 组织管理
SIG管理与开发者团队建设
---
https://www.openubmc.cn/zh/sig/
---
# SIG Center
Special interest groups (SIGs) are the foundational units of the openUBMC community. These open groups are organized around specific technical domains to streamline management and improve workflows. Join a SIG to collaborate on projects, share knowledge, and co-create with fellow developers.
Join Our SIGs
了解SIG运转
SIG是openUBMC社区管理运营的最小单位，由社区开发者组成并独立运作。每个SIG围绕一个或多个技术主题成立，负责管理相关代码仓库，并通过参与社区项目推动技术落地和持续创新。
进行SIG交流
您可以在SIG中心页面内查阅SIG信息、SIG中的Repository列表与联系方式等内容。或前往openUBMC community仓库对应的SIG目录下查阅README.md文件。欢迎您通过邮件列表和公开例会的方式参与SIG的交流与讨论。
使用openUBMC会议创建功能需要SIG组Maintainer或Committer身份权限。创建会议
参与SIG贡献
openUBMC社区诚邀开发者、技术爱好者及行业专家加入协作生态。您可通过代码提交、文档完善、功能测试等多种形式参与社区建设。
社区为贡献者提供清晰指引，具体详情请查看 SIG贡献指南
About SIGs
SIG角色说明
了解openUBMC社区贡献者的角色及其职责。
SIG会议指南
openUBMC SIG会议是SIG的核心活动之一，通过定期地召开会议，SIG成员可进行技术方案审议、开发进度对齐、技术问题答疑及未来路线规划等，从而推动SIG组的持续创新。
### SIG申请流程
当你和你的朋友有了非常好的技术idea，并且希望更多的人参与到你们的探索中，那么你就可以申请成立一个新的SIG了。查看具体申请流程
创建
填写信息
配置
提交PR
发送申请
改进
### SIG订阅指南
您可以通过订阅感兴趣的SIG组的邮箱来获取最新相关信息，包括SIG组的会议邀请、线上讨论等。查看具体订阅流程
选择订阅的SIG组
填写信息
确认订阅邮件
成功订阅
openUBMC SIGs
暂无数据
---
https://www.openubmc.cn/zh/sig/TC/
---
SIG中心
TC
TC
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
TC个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/apply/
---
SIG Center
SIG Application Process
# 申请流程
## 总则
申请创建SIG之前，请查阅现存的SIG列表并确认是否某个SIG已满足您的述求。正式申请创建SIG之前，建议在OpenUBMC论坛或公共邮箱发起讨论，这样可以为新SIG获得更多的关注度与反馈，有助于确认SIG的使命与范围并吸纳更多的SIG成员。
正式创建SIG需要参照SIG管理指南在community仓库创建Pull Request，并向社区技术委员会发邮件申请。技术委员会会定期组织评审决定是否通过申请。
## 角色说明
| 角色 | 主要职责范围 | 操作 |
| --- | --- | --- |
| Contributor | 项目贡献者，认领Isssue 和 PR 并在 PR 提交前完成测试 | AtomGit注册成员 |
| Committer | 项目代码审核者，分配Issue与PR，并审核代码的质量和正确性 | SIG 的积极贡献者，经验丰富，愿意投入精力参与到审核工作 |
| Maintainer | 项目Owner，确定SIG所负责项目的技术路线并制定项目的发布计划 | 经验丰富，富有责任心、出色的技术能力和管理能力 |
## 申请步骤
### 步骤一：使用SIG模板创建自己的新SIG
- 将 atomgit.com/openubmc/community Fork到你的AtomGit下，利用SIG申请模板在sig目录创建你的sig文件夹，以及把SIG申请模板拷贝到该文件夹下。
`git clone https://atomgit.com/${YOURGITCODE}/community cd ./community/sig cp -r sig-template sig-${YOURSIGNAME} cd sig-${YOURSIGNAME}`
### 步骤二：完成新SIG README内容的填写
- 打开新创建sig目录下的README.md文件，按照推荐完成必选内容的填写
`vi README.md`
### 步骤三：完成新SIG成员与SIG仓库的配置
- 请在sig-info.yaml文件中完成对SIG成员的配置
`vi sig-info.yaml`
### 步骤四：提交PR
- 将以上修改提交到AtomGit上，并在AtomGit上创建一个Pull Request。
### 步骤五：向TC发送邮件申请
- 给技术委员会发邮件（邮箱tc@public.openubmc.cn），并在正文中包含主题“新SIG提案”和PR的链接
### 步骤六：TC评审并反馈意见
- 技术委员会将通过合并Pull Request的方式来批准您的申请。合入后社区基础设施团队会负责配置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);}
---
https://www.openubmc.cn/zh/sig/infrastructure/
---
SIG中心
infrastructure
infrastructure
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
infrastructure个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/role-description/
---
# 角色说明
在openUBMC社区，开发者主要通过参与SIG（Special Interest Group）来贡献自己的力量。无论Contributor、Committer、Maintainer，都是社区重要的贡献者角色，他们的主要区别在于参与的SIG治理范围不同。
SIG中心
角色说明
贡献者
职责：通过代码开发、问题修复和文档完善等方式推动社区发展。
要求：理解社区技术，遵守社区规范，积极参与社区贡献。
查看详情
审核者
职责：通过细致的代码评审帮助提升社区代码质量，同时以自身贡献带动社区共同进步。
要求：具备丰富项目经验，熟悉代码规范，能够提供建设性意见并乐于分享经验。
查看详情
维护者
职责：把握技术方向并推动关键决策，通过关键领域的贡献领导社区的长期发展。
要求：深入理解项目架构，善于协作沟通，认同开源精神并长期引领社区成长。
查看详情
新的贡献者
欢迎新成员加入社区。我们有关于如何开始贡献的指导文档请参考openUBMC 贡献者指南
既有社区成员
既有的社区成员应认可社区导向，遵守openUBMC 社区的行为守则，熟悉社区运作机制和技术能力。
社区非活跃成员退出标准和流程请参考非活跃成员退出标准和流程
## 贡献者Contributor
贡献者是openUBMC社区的核心力量，他们通过代码开发、文档完善、问题修复、社区运营等多种方式积极参与，共同推动项目的创新与发展。
### 加入要求
- AtomGit 上的注册会员
- 为 SIG 或社区做出多方面贡献，包括不限于：在 AtomGit 上提交或审核PR；在 AtomGit 上对问题进行归档或评论；参与 SIG 或社区讨论
- 已阅读 贡献者指南
- 积极参与 1 个或多个 SIG
### 责任与权益
- 响应被分配的问题和PR
- 对贡献的代码负责，保证贡献的代码：经过良好的测试；能够让测试用例始终通过，并保证DT覆盖率满足社区要求；解决后继发生的错误或问题
- 负责具体实现设计，并通过 SIG 评审
- 获得成为 SIG 审核者 Committer 的权利。
贡献代码的同时积极参与代码审查、设计评审等活动，即可以成为 SIG 的审核者 Committer
## 审核者Committer
审核者是代码仓库的核心维护者，拥有代码合入权限。他们凭借丰富的技术经验，通过代码评审、开发者测试和规范检查等方式保障代码质量，并推动组件的技术演进与长期健康发展。
### 加入要求
- 作为贡献者至少 3 个月
- 作为主要审阅者至少参与了 6 次 PR 的审阅
- 审阅或合并至少 20 个基本 PR 到代码库
- 熟悉代码库
- 可以自我提名，或由该 SIG 的审核者 Committer 或维护者 Maintainer 提名，并在SIG会议通过
- 或者一次性贡献具备完整特性的组件，也可直接成为Committer
### 责任与权益
- 评审 PR：对 Contributor 提交的 PR 完成评审，基于代码的设计、实现、安全性、可扩展性、兼容性等为度给出公正客观的评价
- 熟知社区开发流程，并指导 Contributor 按照社区开发流程完成代码贡献，保障社区开发流程正确的应用
- 针对接口变更，指导 Contributor 参与社区接口变更评审会议，充分地预审，确保组件接口的设计合理性、兼容性、必要性、易读性、易用性
- 看护组件的软件工程能力，在SIG组中建立良好的软件工程文化
- 看护组件的代码实现设计，确保特性设计的合理性
- 更新和维护组件的版本，与社区项目版本保持一致
- 获得成为 SIG 维护者 Maintainer 的权利。
成为 SIG 内多个代码仓的审查者，积极参与 SIG 技术规划和架构演进，即可以成为 SIG 的维护者 Maintainer
## 维护者Maintainer
维护者是SIG组的核心领导者，负责技术方向规划、社区协作和长期发展。他们不仅具备审核者的所有职责，还主导组件的架构演进、质量保障和生态适配，并通过协调社区内外资源推动SIG目标的实现。
### 加入要求
- 作为审核者至少 3 个月
- 作为主要审阅者至少参与了 12 次 PR 的审阅
- 审阅或合并至少 30 个基本 PR 到代码库
- 熟悉 SIG 超过一半的代码库
- 可以自我提名，也可以由本 SIG 维护者 Maintainer 提名，并且没有其他 维护者 Maintainer 的反对，并在TC会议通过
### 责任与权益
- 确定 SIG 所负责项目的技术路线：包括规划和决策 SIG 技术方向、路标规划、架构演进
- 看护SIG组的技术设计方案，在SIG组内营造良好的技术氛围
- 制定 SIG 所负责项目的发布计划：确定 SIG 的关键需求和发布计划；参与社区的 PM 活动，并协调 SIG 计划和社区版本的里程碑时间表匹配
- 参与社区协调活动：作为 SIG 的代表参与 openUBMC 组织的活动和特定会议等
- 召集 SIG 会议：定期召集 SIG 会议，决策 SIG 内上升的争议
- 代表 SIG 参加技术委员会，汇报 SIG 工作和进展
- 获得可参与技术委员会委员选举的权利。
积极提升 SIG 影响力，与其他 SIG 共同协作，即有机会参与技术委员会委员选举
---
https://www.openubmc.cn/zh/sig/sig-CICD/
---
SIG中心
CICD
CICD
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
CICD个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-Linkedsemi/
---
SIG中心
Linkedsemi
Linkedsemi
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
Linkedsemi个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-QA/
---
SIG中心
QA
QA
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
QA个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-ai/
---
SIG中心
ai
ai
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
ai个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-application-process/
---
SIG中心
application-process
application-process
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
application-process个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-bmc-core/
---
SIG中心
bmc-core
bmc-core
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
bmc-core个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-component-drivers/
---
SIG中心
component-drivers
component-drivers
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
component-drivers个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-docs/
---
SIG中心
docs
docs
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
docs个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-framework/
---
SIG中心
framework
framework
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
framework个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-hardware/
---
SIG中心
hardware
hardware
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
hardware个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-hisilicon/
---
SIG中心
hisilicon
hisilicon
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
hisilicon个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-interface/
---
SIG中心
interface
interface
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
interface个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-om/
---
SIG中心
om
om
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
om个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-release-management/
---
SIG中心
release-management
release-management
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
release-management个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/sig-security/
---
SIG中心
security
security
在AtomGit上查看更多内容
核心成员（0）
会议与活动
工作会议
邮件列表
## 仓库列表（0）
| 仓库名称 | Committer |
| --- | --- |
| |
暂无数据
贡献展示
security个人会员贡献
度量指标
合并请求 PR
需求&问题 Issue
评审 Comment
统计周期
\-
Maintainer
Committer
Contributor
| 序号 | GitCode ID | PR |
| --- | --- | --- |
| |
暂无数据
---
https://www.openubmc.cn/zh/sig/subscribe-guide/
---
SIG中心
订阅指南
# 订阅指南
01
## 选择订阅的SIG组
查看感兴趣的SIG组，点击"前往订阅"
02
## 填写信息
在订阅邮件页面内，填写相关个人信息，点击确认订阅
03
## 确认订阅邮件
您的邮箱将收到一封来自该SIG组的电子邮件，要求您确认订阅了邮件列表，点击确认链接完成订阅
04
## 成功订阅
当收到一封欢迎邮件，即成功订阅该SIG组邮件列表
---
https://www.openubmc.cn/zh/usercase/
---
# 用户案例
了解openUBMC在各行业的最佳案例
(软通华方)[/zh/usercase/building-agent-driven-bmc-rd-workflow]
(昆仑太科)[/zh/usercase/implementing-blade-chassis-integrated-management-via-northbound-self-onboarding]
(神州鲲泰)[/zh/usercase/implementing-pice-switch-with-multi-gpu-self-discovery]
(长江计算)[/zh/usercase/building-sourthbound-hardware-compatible-ecosystem]
---
https://www.openubmc.cn/zh/usercase/building-agent-driven-bmc-rd-workflow/
---
用户案例
基于 openUBMC 构建 Agent 驱动的 BMC 研发工作流
# 基于 openUBMC 构建 Agent 驱动的 BMC 研发工作流
2026/10/09
### 一、应用背景
BMC 固件研发涵盖源码开发、构建部署、设备验证全链路，任务进度与验证证据分散零散、缺乏统一追溯机制。引入智能 Agent 虽可推进编码与工具调用，但任务跨阶段、会话中断仍需人工重复梳理衔接；同时 BMC 故障属于典型跨层问题，依赖多维度交叉核验，零散的工具调用无法形成可信闭环。因此，亟需一套支持断点续跑、操作可对账、以设备真实状态为验收标准的标准化研发工作流。
### 二、解决方案
软通华方依托 openUBMC 资源模型、组件化开发与设备管理能力，构建了 openUBMC Agent Workflow。该工作流由四层协同：
- 宿主 Agent 负责规划与工程判断；
- 领域工作流通过 Skill 选择诊断、开发、构建、部署或验证路线；
- Target Runtime 基于 MCP 管理任务进度、目标连接、资源调度、变更记录与验收结果；
- 工程环境提供源码/构建能力与真实设备现场。
工程师定义目标与验收条件后，各层协同自主推进分析、修复、构建、升级与实机验证。
图 1：openUBMC Agent Workflow 全链路执行与职责分工
**核心能力一：工程对象贯通**：基于 MDS 模型、MDB/D-Bus 资源对象与北向接口映射，结合源码依赖与构建工具链，保证源码改动、固件制品与设备业务结果三者可追溯。
**核心能力二：长流程断点续跑与多任务并发**：编译、重启等耗时环节后台运行，中断后可续接；同一任务内无依赖动作并行执行，多任务错峰开展，系统按依赖与资源统一调度。
**核心能力三：可信执行闭环**：任务档案（Case）保存目标与阶段结果；变更日志（Mutation Journal）记录写操作并核验设备真实状态，避免超时误判；证据账本（Evidence Ledger）管理变更前后证据；任务验收（Closeout）以设备实测结果为准，达标才算闭环。
### 三、典型场景示例：RAID 控制器信息缺失修复
某项目 RAID 卡可识别但控制器信息不显示，日志显示 libsml\_lsi.so 加载失败、错误码 4357，定位为适配库缺失。基于 openUBMC Agent Workflow 自动完成依赖修正、测试构建、固件升级及设备恢复，并校验适配库加载与接口状态，研发人员仅需处理核心决策与复杂异常，大幅削减机械值守与重复操作，显著提升故障修复与版本交付效率。
图 2：人工组织与 Workflow 自主推进对比
### 四、客户价值
- **高效跨层研判**：统一任务目标串联领域知识、源码、接口与设备证据，并行分析快速收敛故障范围。
- **释放人力成本**：构建、升级、重连、核验等重复动作自动化，工程师专注高价值研发。
- **多任务并行调度**：利用编译、重启等待窗口并行推进其他任务，提升单位时间交付量。
- **沉淀工程资产**：排查逻辑、构建流程、验收规范固化为领域 Skill，同类任务直接复用，持续优化流程。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/usercase/building-sourthbound-hardware-compatible-ecosystem/
---
用户案例
基于 openUBMC 南向部件规范共建硬件兼容生态
# 基于 openUBMC 南向部件规范共建硬件兼容生态
2026/05/28
# 长江计算 & 沐创集成电路基于 openUBMC 南向部件规范共建硬件兼容生态
### 背景
随着数字经济与算力基础设施快速发展，金融、政务、运营商等行业对服务器的兼容性、稳定性、交付效率提出更高要求；鲲鹏新型号的规模化落地，也推动整机产品向多样化、场景化升级，客户对多品牌硬件部件的快速适配、稳定兼容需求日益迫切。
传统服务器部件适配模式高度依赖整机厂商定制开发，周期长、耦合度高、复用性差，难以快速响应客户业务迭代与硬件更新需求，也制约了算力基础设施生态的完善与规模化推广。在此背景下，整机与部件厂商基于开源开放架构实现协同联创、快速适配，成为行业提升交付能力、满足客户高质量需求的关键路径。
### 解决方案
长江计算联合沐创，依托 openUBMC 南向部件规范及驱动框架，充分发挥其标准化接口、模块化驱动的核心优势，打造标准化、模块化的硬件部件兼容适配方案，构建高效协同的产业联创模式。
#### 南向部件适配框架
- **接口标准化**
基于 openUBMC 南向部件规范，统一服务器部件驱动接口、部件模型与描述信息，通过 CSR 完成标准化承载，部件厂商可依据统一规范独立开发驱动，无需依赖整机厂商 BMC 软件栈，大幅降低适配门槛，实现部件快速接入适配。
- **开发模块化**
基于 openUBMC 南向部件驱动框架的模块化设计，按网卡、xPU、RAID 等类型构建标准化管理接口模型，将驱动代码独立封装，部件厂商无需掌握 BMC 全量技术，聚焦自身部件即可完成开发，提升适配效率与代码复用性。
- **生态联创交付**
依托 openUBMC 社区完善的基础设施与南向部件规范体系，建立整机厂商 + 部件厂商 + 开源社区三方协同模式，分工清晰、高效协作，实现需求快速响应、高质量交付，践行社区 “共建共享、生态共赢” 的理念。
### 价值
- **适配交付更高效**
打破传统定制开发壁垒，基于 openUBMC 南向部件规范实现需求快速落地，大幅缩短部件适配周期，高效支撑客户服务器迭代升级与业务平稳过渡。
- **产品兼容更稳定**
通过统一的 openUBMC 南向部件规范与模块化设计，降低软硬件耦合风险，提升服务器硬件兼容性与运行可靠性，保障客户业务连续稳定。
- **生态成本更优化**
构建开放共赢的产业链协同
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/usercase/implementing-blade-chassis-integrated-management-via-northbound-self-onboarding/
---
用户案例
基于 openUBMC 北向自接入实现刀片机箱节点一体化健康管理
# 基于 openUBMC 北向自接入实现刀片机箱节点一体化健康管理
2026/07/30
### 一、应用背景
当前，AI 算力数据中心广泛采用高密度刀片机箱，单机箱内置多片独立刀片，每片刀片搭载专属 BMC 管理芯片。传统 BMC 仅支持单节点本地管控，彼此隔离形成管理孤岛，存在以下运维痛点：
- sensor、fru\_ctrl 等基础组件仅管理本机资源，缺少跨板通信接口；
- 缺乏统一的数据聚合上报通道，网管系统只能逐一轮询各刀片 BMC；
- 交换刀片 Web 界面缺少整机视角，无法集中查看整机刀片健康状态并远程控制；
多重限制叠加，进一步造成 IPMB 总线拥堵、页面卡顿、多终端数据不一致、故障发现滞后等问题，大幅降低集群运维效率。
### 二、解决方案
昆仑太科基于 openUBMC 开源架构自研 health\_manager 专用管理组件，部署于交换刀片 BMC，充分利用社区北向自接入能力，将 UDP 上报、Web 展示、MDB 接口扩展等北向功能以独立组件形式接入框架，使团队得以聚焦于跨刀片管理核心逻辑的实现。
health\_manager 通过 IPMB 总线统一采集框内所有刀片数据，经 blade\_cache 缓存后，同步供给 Web 展示与网管系统，构建底层采集、上层可视化上报双业务闭环。
关键技术创新包括：
- **采集-缓存-服务三层分离**：引入 blade\_cache 中枢后，Web 详情响应从 600ms 降至 5ms 以内，IPMB 总线负载恒定，多用户并发无阻塞；
- **MDB 与 RPC 混合数据模型**：MDB 仅维护每刀片 1 个聚合对象，详情页通过 RPC 直接读取缓存原子快照，大幅降低 D-Bus 信号开销；
- **双通道统一数据源**：Web REST 与 UDP 上报共享同一份 blade\_cache 数据，彻底消除多通道数据不一致；
- **自适应降级采集**：默认 3s 轮询，刀片失联自动降频至 10s/30s 并标记离线；刀片采集时间错峰偏移 100ms，规避总线瞬时抢占；
- **数据面异步、控制面同步**：采集与页面刷新异步进行保证总线平稳，上下电控制同步穿透，指令延迟 ≤200ms
| 指标 | 传统穿透模式 | 本方案缓存模式 |
| --- | --- | --- |
| Web 详情响应 | 12×50ms = 600ms | < 5ms |
| IPMB 峰值负载 | 随 Web 并发线性增长 | 恒定 |
| 多用户并发 | 总线拥塞互相阻塞 | 无影响 |
_新旧方案核心性能对比_
此外，方案构建了通信层（超时自动重试、降频等）、服务层（Skynet 心跳监控、systemd 自动拉起等）、安全层（IPMB 通道隔离、UDP 白名单校验、Web 权限管控等）三层防护体系，保障机房 7×24 小时稳定运行。
### 三、客户价值
- **管理效率大幅提升**：Web 详情响应从 600ms 降至 5ms 以内，运维人员可在秒级内感知整机箱健康状态，端到端上报延迟 ≤4s，无需逐个访问刀片 BMC，故障快速定位。
- **运维准确性显著增强**：Web 与网管系统共享同一数据源，彻底消除多通道数据不一致导致的误判。
- **系统稳定性充分保障**：自适应降级采集避免单刀片故障拖垮整机采集链路；三层防护体系确保通信异常、进程崩溃等场景下服务持续可用。
- **架构开放，可快速扩展**：基于 openUBMC 北向自接入能力，核心采集链路与北向功能完全解耦，后续对接新网管协议或扩展新可视化维度均可独立迭代，无需改动底层采集链路，方案演进的技术风险与回归验证成本大幅降低。
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。
---
https://www.openubmc.cn/zh/usercase/implementing-pice-switch-with-multi-gpu-self-discovery/
---
用户案例
基于 openUBMC 实现 PCIe Switch 多 GPU 自发现
# 基于 openUBMC 实现 PCIe Switch 多 GPU 自发现
2026/05/29
### 应用背景
随着大模型训练场景规模化落地，行业对单机高密度算力、低延迟互联、高稳定部署的需求持续提升。传统 CPU 直出架构受原生 PCIe 通道物理限制，难以满足海量 GPU 挂载、高效算力互联的业务需求，存在带宽瓶颈、通信延迟高、组网灵活性不足、硬件设计成本高、故障易扩散等痛点，无法适配 AI 训练场景对服务器高性能、高可靠、高灵活的严苛要求。
\*该图仅用来解释switch的作用，并非实际拓扑
### 解决方案
神州鲲泰基于openUBMC 开源开放架构，依托其完善的硬件适配能力与标准化扩展框架，完成 PCIe Switch 板深度适配，实现 AI 服务器多 GPU 智能自发现、统一管控与全链路硬件监控，打造适配高密度算力场景的 AI 服务器硬件管理方案。
| 关键特性 | 规格描述 |
| --- | --- |
| 产品形态 | 机架式服务器 |
| 处理器 | 2*鲲鹏920新型号 （48/64/核，最高主频2.9GHz） |
| AI加速卡 | 最多支持10张全高全长双宽AI加速卡 |
| 内存 | 最多支持32*DDR5 4800MT/s 及以上内存，支持ECC、热备、镜像等多种保护模式 |
| 存储控制器 | 支持大容量缓存及超级电容。提供RAID级别迁移、磁盘漫游、自诊断、Web远程设置等功能，支持直通、RAID0、1、5、6、10、50、60等多种存储方案，支持RAID卡安全启动 |
| 本地存储 | 前置：支持123.5"盘位，其中8SAS / SATA+4*NVMe，支持热插拔 |
| 灵活插卡 | 支持1OCP3.0标准网卡（4GE电口 / 2*25GE光口） |
| PCle槽位 | 支持12*PCIe 5.0 x16扩展槽位 |
| 接口 | 4USB 3.0接口，2VGA接口，2UID按键&指示灯，1串口、1*RJ45管理网口 |
| 电源模块 | 4热插拔CRPS 2600W电源，支持2+2冗余 / 4热插拔CRPS 2000W电源，支持3+1冗余 |
| 风扇模块 | 配置12*颗热插拔风扇，支持单风扇失效状态下稳定工作 |
| 工作温度 | 5℃~35℃ |
| 尺寸 | 高176.8mm宽447.4mm深871.4mm |
### 客户价值
1. **突破硬件瓶颈，支撑高密度算力部署**
突破 CPU 原生 PCIe 通道物理上限，通过 PCIe Switch 实现通道高效拓展，满足单机海量高性能 GPU 挂载需求，完美支撑大模型训练的算力规模要求。
2. **优化算力互联，大幅提升训练效率**
实现 GPU 点对点低延迟直连通信，减少 CPU 中转带来的带宽损耗与数据延迟。相较传统 CPU 中转模式，带宽从 25GB/s 提升至 42GB/s，提升幅度约 70%，有效增强多卡算力协同效率，全面优化 AI 模型训练效果。
3. **架构灵活可靠，适配多元业务需求**
支持基于 PCIe Switch 的硬件拓扑灵活定制，可根据客户算力规模、业务场景、成本预算等差异，快速调整链路分配与总线规划，高效匹配多样化部署诉求。
4. **简化硬件设计，降本增效**
简化服务器主板 PCIe 高速走线设计，降低信号干扰与硬件故障风险，减少整机研发与生产成本，提升服务器规模化交付能力。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/1.0.0/
---
文档中心
版本说明
版本选择
# openUBMC 1.0.0 社区首版本正式上线！
2024/12/31
# openUBMC 1.0.0 社区首版本正式上线！
## 版本概览
openUBMC 是一款架构领先、开发友好、开放标准的开源 BMC。采用协议“木兰宽松许可证”（Mulan PSL V2），用户可以自由复制、使用、修改、分发，不论修改与否。 openUBMC 版本号采用点分位命名规则（X.Y.Z）模式，其中 X 表示每年发布版本，Y 表示每半年发布版本，Z 表示补丁版本。正常每半年会发布一个 Y 版本，每年发布两个版本。 openUBMC 生命周期初步规划为 0.5 年。
## 版本特性
- 支持微组件架构，组件通过总线互联，具备组件、插件、配置多重扩展能力。
- 提供标准化的 SDK 套件供社区使用并兼容 D-Bus 总线协议，支持组件快速开发并接入系统。
- 支持南向硬件定制通过生成配置数据方式接入，实现低代码开发。
- 支持北向接口映射配置，实现"0"代码简化增量开发。
## 源代码
开源软件代码仓：https://atomgit.com/openubmc
## 致谢
我们衷心地感谢参与和协助 openUBMC 项目的所有成员，是你们的辛勤付出使得版本顺利发布！ openUBMC 在不断的发展中，未来还会有更多好用的特性发布，这里也非常欢迎大家下载并体验，并参与到openUBMC 开源社区建设中来，也期待聆听每一位用户的反馈意见！ 社区邮件列表：community@openubmc.org
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/25-12-LTS-SP2/
---
文档中心
版本说明
版本选择
# openUBMC 25.12 LTS SP2 版本发布说明
2026/05/31
# openUBMC 25.12 LTS SP2 版本发布说明
* * *
## 版本概览
该版本是基于25.12 LTS SP1发布的补丁版本，openUBMC 25.12 LTS SP2采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
25.12 LTS SP2版本在25.12 LTS SP1版本基础上进行开发，特性交付范围包括：
### 北向接口生态
#### 1\. 运维与管理功能
- 新增 VNC 最大会话数定制功能。
### 丰富度：硬件接入与功能增强
#### 1\. 网卡与硬盘接入能力扩展
- 新增 182X 新代次标卡、DC1000C GPU卡、9款 SATA SSD 和11款 NVMe SSD 等兼容性。
#### 2\. 故障诊断增强
- 增强 CSR 异常检测能力。
- 增强 IERR 故障上报能力。
## 源代码
25.12 LTS SP2版本源代码已发布至社区网站：https://openubmc.cn/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 25.12 LTS SP2 | 25.12 LTS SP1 | 5.12.0 | 5.11.0 | 5.10.0 | 5.9.0 |
| --- | --- | --- | --- | --- | --- | --- |
| 25.12 LTS SP2 | Y | Y | Y | N | N | N |
| 25.12 LTS SP1 | N | Y | Y | Y | N | N |
| 25.12 | N | N | Y | Y | N | N |
| 25.09 | N | N | N | Y | N | N |
| 25.06 | N | N | N | N | Y | N |
| 25.03 | N | N | N | N | N | Y |
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3690536 | 带内os热升级SATA SSD盘固件版本，BMC上显示的硬盘固件版本不更新 | storage |
| 3644159 | 电源通讯异常，通过北向接口查询电源功率、电压、温度、电流等动态信息显示为0 | power_mgmt |
* * *
## 已修复问题
本修复问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3873976 | 修复开箱检测日志刷屏 | chassis |
| 4035170 | 硬盘日志自动收集任务阻塞其他业务对总线的访问 | storage |
| 3878904 | nvme热插拔遍历，NVMe硬盘调速策略未加载 | storage |
| 3834737 | 线缆信息无法获取时，日志刷屏 | pcie_device |
| 3867075 | 存储管理页面直通盘不显示接口类型 | storage |
| 3720145 | raid卡通讯丢失上报告警 slot与实际slot不符 | vpd |
| 4030661 | 修复/redfish/v1/Systems/1/VirtualMedia/CD接口设置Password报错时响应体中的Password敏感词未加密的问题 | rackmount |
| 4035589 | redfish接口查询到的传感器数量和ipmi命令查询到的不一致 | sensor |
* * *
## CVE 漏洞
暂无
* * *
## OPEN SOURCE SOFTWARE NOTICE
Open Source Software Notice
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/25-12-LTS-SP3/
---
文档中心
版本说明
版本选择
# openUBMC 25.12 LTS SP3 版本发布说明
2026/08/31
# openUBMC 25.12 LTS SP3 版本发布说明
* * *
## 版本概览
openUBMC 25.12 LTS SP3 版本是基于 25.12 LTS SP2 发布的补丁版本，该版本采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
25.12 LTS SP3 版本在 25.12 LTS SP2 版本基础上进行开发，特性交付范围包括：
### 丰富度：硬件接入与功能增强
#### 1.硬件接入能力扩展
- 新增182X新代次SP566标卡、MCX653105A-HDAT/MCX755106AS-HEAT网卡等兼容性
- 新增沐创N10G-X2-DC/N20G-R2F-25G网卡、光润通F1002T-V3.0 intelX550网卡、博通BCM957416A4160C万兆双电口网卡、博通BCM957416A4160C万兆双电口网卡、星云智联S1055AS-A00CHT(2\*25G)网卡等兼容性
- 新增HK EP810/EP820/EP910/EP92、德明利TS3160、紫光闪芯、佰维、英韧、长江存储等硬盘兼容性
- 新增900W电源、EXP 12盘背板等兼容性
#### 2.故障诊断增强
- 优化扩展板CPLD localbus链路异常检测机制
#### 3.运维能力提升
- 优化BIOS固件和TEE固件同时生效机制。
- 优化SP686C Raid卡固件日志收集机制和日志可读性。
## 源代码
25.12 LTS SP3版本源代码已发布至社区网站：https://openubmc.cn/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 5.12.0.35 | 5.12.0.17 | 5.12.0.5 | 5.12.0.1 | 5.11.0 | 5.10.0 | 5.9.0 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 25.12 LTS SP3 | Y | Y | Y | Y | N | N | N |
| 25.12 LTS SP2 | N | Y | Y | Y | N | N | N |
| 25.12 LTS SP1 | N | N | Y | Y | Y | N | N |
| 25.12 | N | N | N | Y | Y | N | N |
| 25.09 | N | N | N | N | Y | N | N |
| 25.06 | N | N | N | N | N | Y | N |
| 25.03 | N | N | N | N | N | N | Y |
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 4290337 | 缺陷: 在kunlun2280V2机型，模拟"OCP网卡温度获取失败"、”OCP卡温度过高告警“、”OCP卡降速告警“，产生的告警码与《2280V2告警参考手册》中的预期告警码不符。 | vpd |
* * *
## 已修复问题
本版本已修复问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 4131933 | 缺陷: 升级 retimer后提示下电生效 | webui |
| 4115989 | 缺陷: 新适配的SATA SSD适配后搭配1880raid卡厂商信息仍显示ATA问题 | storage |
| 4111714 | 缺陷: SensorName属性取消const描述 | sensor |
| 4125875 | 缺陷: 1880卡支持多个启动设备 | webui |
| 4239258 | 缺陷: 监听ReadyToEnumerate增加属性判空 | bios |
| 4153771 | 缺陷: 下载一键收集日志的操作日志内容需优化 | webui |
| 4126377 | 缺陷: 部分GPU部件编码、异常功率读值和芯片型号显示异常 | vpd |
| 4166445 | 缺陷: 告警问题需修改配置修复 | vpd |
| 4157064 | 缺陷: 同时导入csr失败时打印操作日志 | general_hardware |
| 4165576 | 缺陷: 新建用户被误删 | account |
| 4132154 | 缺陷: 修改NVME硬盘组RAID场景下Revision信息获取的方式 | storage |
| 4131977 | 缺陷: SNMP新增0x2D000031、0x280003D告警修复redfish/v1//System/1/Processors/Gpu1查询GPU温度 创建VNC会话，redfish查询当前会话数为0，预期应该与web查询一致 修复网络适配下部件编码显示为N/A 修复ipmcset -t maintenance -d importcsr -v回显不完整 | rackmount |
| 4127088 | 缺陷: main分支反合至lts分支 | power_mgmt |
| 4157051 | 缺陷: 需要支持从BMA解析网卡永久MAC地址 | network_adapter |
| 4156083 | 缺陷: 修复DC1000异常温度读值为0和厂商与CSR不一致的问题 | general_hardware |
| 4128485 | 缺陷: 调制日志级别，避免日志刷屏 | general_hardware |
| 4154306 | 缺陷: fru信息更新时出现非utf-8数据导致北向接口查询报错 | frudata |
| 4172231 | 缺陷: web点击下电实际无法正常下电 | fructrl |
| 4156376 | 缺陷: 调整ATA硬盘通过ManufacturerOUI获取厂商名的逻辑，并修复控制器下硬盘列表未更新到资源树的问题。 | storage |
| 4156371 | 缺陷: 修复网卡SupportedLLDP配置和光模块默认值误告警，支持设置RAID卡bootdevice | vpd |
| 4166720 | 缺陷: Power接口设置时大概率返回412错误 | rackmount |
| 4160707 | 缺陷: PowerSupplyStatus添加默认值 & 修复由于防互升标志被误清导致BIOS升级失败的问题 | bios |
| 4156275 | 缺陷: 修复下电场景下磐石DPU卡powerstate未及时刷新的问题 | general_hardware |
| 4164482 | 缺陷: 网卡概率性温度获取失败告警 | network_adapter |
| 4156262 | 缺陷:修复partnumber修改失败问题 | network_adapter |
| 4172459 | 缺陷: 下电后风扇pwm不显示为0 | thermal_mgmt |
| 4128587 | 缺陷: 1880 RAID卡不显示SN | storage |
| 4166827 | 缺陷: redfish资源查询PowerHistoryData、 Measurement接口时返回404 | rackmount |
| 4156535 | 缺陷: 删除磐石DPU上下电时冗余操作日志记录 | pcie_device |
| 4156597 | 缺陷修复/redfish/v1/Chassis/:chassisid/PCIeDevice/:id接口修改属性回显异常问题 | rackmount |
| 4160712 | 缺陷: 修改0xA000061告警snmp trap oid | rackmount |
| 4251117 | 缺陷: SP625D 增加FRU写保护 | vpd |
| 4250350 | 缺陷: 在自协商无法获取的情况下，FC卡的自协商字段在BMC上显示值为默认值“已关闭”，显示不合理 | network_adapter |
| 4275168 | 缺陷:WEB设置raid卡启动项后，提示操作成功，实际没有切换启动项 | webui |
| 4265965 | 缺陷: 网卡的温度告警门限、温度传感器状态取值、厂商名称、是否支持MCTP需调整 | vpd |
| 4266420 | 缺陷: 适配非2口卡光模块温度问题 | mdb_interface |
| 4111639 | 缺陷: 新增告警码0x000000F3和0x000000F5 | vpd |
| 4111678 | 缺陷: sensorname属性取消const描述 | mdb_interface |
| 4111661 | 缺陷: 记录pll热切换日志 | general_hardware |
| 4129157 | 缺陷: 调整固件升级上传固件大小上限为110M | webui |
| 4183089 | 缺陷: 修复EEPROM读写测试项失败问题 | frudata |
| 4266731 | 缺陷: os上下电和bmc复位场景会误报BBU在位/不在位事件 | storage |
| 4267537 | 缺陷: os上下电和bmc复位场景会误报BBU在位/不在位事件 | vpd |
| 4268976 | 缺陷: EepromV2类型FRU 反写头的内容错误 | frudata |
| 4268417 | 缺陷: 支持北向接口获取和设置RAID卡的多个启动盘 | storage |
| 4267021 | 缺陷: 支持北向接口获取和设置RAID卡的多个启动盘 | rackmount |
| 4267743 | 缺陷: BMC上报CPLD信息异常 | general_hardware |
| 4265849 | 缺陷: SDI卡 VLAN 未就绪时 IPv4 配置持续失败 | general_hardware |
| 4265834 | 缺陷: 修正安全模块Protocol默认值 | vpd |
| 4251788 | 缺陷: /redfish/v1/Chassis/1/Power接口设置ExpectedRedundancy请求体缺失，回显信息里Message显示不全 | rackmount |
| 4087078 | 缺陷: 增加Drvwritedelay属性配置 | component_drivers |
| 4154006 | 缺陷: 环境上安装两张沐创网卡时，只有一张正常显示通过oem_smbus获取到的信息 | network_adapter |
| 4273297 | 缺陷: 补充manager_account_backup_db_obj对象的create_mdb_object函数实现 | account |
| 4057042 | 缺陷: ipmi命令进行dpu上下电，判别参数的逻辑有误 | general_hardware |
| 4266569 | 缺陷: 电源升级过程中被升级的电源输入功率要变成0 | power_mgmt |
| 4260286 | 缺陷: cpu阈值接口问题 | rackmount |
| 4241585 | 缺陷: 0x2C000007告警描述未更新 | vpd |
| 4260706 | 缺陷: AirCofig/CoolingPolicy获取不到 | thermal_mgmt |
| 4245107 | 缺陷: 电子标签写入队列加固 | frudata |
| 4228834 | 缺陷: MCU Flash日志收集逻辑修改为只向BCU的MCU发送 | general_hardware |
| 4277517 | 缺陷:修复异常显示VRD待升级状态的问题 | general_hardware |
| 4261055 | 缺陷:web 服务器上下电界面设置下电时限10秒，web界面点下电整机无法正常下电成功 | manifest |
| 4200367 | 缺陷: 模拟光模块温度获取失败，但是环境没有产生光模块获取失败告警 | network_adapter |
| 4263802 | 缺陷: BMCSet_DrivesLogAutoCollectEnable 定制失败 | storage |
| 4238909 | 缺陷 双SP686C RAID卡MCTP通信失败：worker线程与smld线程跨lua_State竞态 | storage |
| 4229670 | 缺陷: 修复导入证书时，日志有多余的warning打印 | rackmount |
| 4269286 | 缺陷: 修复用于二级缓存cli查询的单词拼写错误 | rackmount |
| 4266686 | 缺陷: 修复命令行导入用户公钥的示例不正确问题 | rackmount |
* * *
## bmc\_sdk(5.12.0.35)已修复问题
已修复问题清单：
| | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 1 | 修复删除资源对象时未清理对象error信息的问题 | hwproxy |
| 2 | 修复IPMI修改备份IP报错问题 | bmc_network |
| 3 | 修复概率性产生bmc_core、libmcc组件异常退出问题 | libsoc_adapter |
| 4 | 修复未收集SATA硬盘smart信息的问题 | libmgmt_protocol |
| 5 | 修复使用IPMI备用端口连接SOL报错问题 | rmcpd |
| 6 | 优化内存占用率 | libmc4lua |
| 7 | 修复CPLD升级失败问题 | firmware_mgmt |
| 8 | 修复Redfish接口Accept请求头不支持大写字母问题 | redfish |
| 9 | 修复删除过期CA证书后仍有CA证书过期告警问题 | certificate |
| 10 | 修补开源软件漏洞 | sqlite3 nginx libssh2 curl |
| 11 | 修复获取硬盘厂商错误问题 | libmgmt_protocol |
| 12 | 修复VNC输入异常问题 | remote_console |
| 13 | 修复资源树和协议栈mac不一致导致BMC网络不通问题 | bmc_network |
| 14 | 修复设置启动设备未生效问题 | libmgmt_protocol |
| 15 | 优化网络转发规则 | bmc_network |
| 16 | 修复失效license在AC掉电后信息丢失 | license |
| 17 | 修复key_mgmt组件概率启动失败问题 | key_mgmt |
| 18 | 修复bmc_network、power_strategy组件异常记录日志 | power_strategy |
* * *
## CVE 漏洞
暂无
* * *
## 接口变更
无
* * *
## OPEN SOURCE SOFTWARE NOTICE
Open Source Software Notice
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/25.03/
---
文档中心
版本说明
版本选择
# openUBMC 25.03 版本发布说明
2025/03/31
# openUBMC 25.03 版本发布说明
* * *
## 版本概览
作为25年首版本，openUBMC 25.03 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发，不论修改与否。
* * *
## 版本特性
25.03版本在1.0.0版本基础上进行开发，特性交付范围包括：
### 北向接口生态
1. 安全框架升级
- 支持密码策略定制化配置
- 实现用户名规则自定义功能
- 新增证书管理基础模块
2. 运维功能优化
- 配置导入/导出标准化
- 出厂重置保留用户数据
- 重构MCU/VRD升级架构（解耦式设计）
- 支持hpm标准化升级包格式
### 南向部件扩展
1. 管理能力增强
- 调速策略能力支持
- 多SML库加载
2. 部件适配
- 支持SP322D/SP323D网卡
- 支持NVMe-MI v7协议linkspeed查询
### 开发体验优化
1. 开发工具增强
- bingo支持本地调试
- bingo支持模型检查功能
2. BMC Studio发布至社区
- 支持CSR配置检查
- 支持全模型检查
* * *
## 源代码
25.03版本源代码已发布至社区网站：https://www.openubmc.cn/zh/download
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3026302 | 产品调速策略未适配所有机型，社区提供调速策略定制能力，需要开发者基于整机产品自行定制 | thermal_mgmt |
* * *
## 已修复问题
暂无
* * *
## CVE 漏洞
暂无
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/25.06/
---
文档中心
版本说明
版本选择
# openUBMC 25.06 版本发布说明
2025/06/30
# openUBMC 25.06 版本发布说明
* * *
## 版本概览
作为25年第二个创新版本，openUBMC 25.06 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
25.06版本在25.03版本基础上进行开发，特性交付范围包括：
### 北向接口生态
1. 可观测性服务：覆盖日志、独立、跟踪等数据的采集和存储能力；
2. 升级方案优化：支持固件并行升级与统一生效；
3. 接口功能优化：支持针对不同客户提供接口灵活扩展和定制能力；
4. 接口升级：IPMI和Redfish标准接口升级，主要包含Power、Drive和Thermal等；
5. 独立KVM开发套件：支持独立KVM客户端通过websocket链接到BMC，实现VMM功能，电源控制功能，系统启动项管理功能；
6. 新增规范：支持资源树协作接口关键字规范；
### 南向部件扩展
1. 板卡接入丰富度：新增网卡(标卡和OCP)、RAID卡、硬盘、NVMe盘、TPM卡、DPU、SDI、GPU、NPU等部件接入，详细接入清单参照vpd代码仓；
2. 南向协议能力：支持NVMe-mi over mctp的协议解析；支持使用pldm协议获取网卡部分信息；支持NCSI边带管理功能；支持PMBus1.2/CANBUS协议；
3. 能效管理能力：支持功率、电源固件升级、电源告警功能、供电信息、供电模式、时钟同步等管理能力;
4. DFX能力：支持电源砖精细化管理能力，支持动态组合获取硬盘的SMART信息，支持硬盘(SSD)寿命管理;
### 开发体验优化
1. BMC STUDIO: 支持可视化图形开发和自动化检测功能，完成CSR开发和语法合法性检查；提供VSCode插件一键完成QEMU安装、配置、启动和调试；
2. QEMU仿真功能: 支持仿真镜像的构建与发布；支持Qemu工具的构建与发布；支持仿真数据的发布。当前已支持EEPROM,HisPort，BMC芯片等数据插件；
3. 自动化防护：支持kptest测试框架基础能力建设和自动化用例；
4. 工程能力: 支持工具生成产品、客户层级的全量接口配置；支持组件工具依赖自管理；支持编译构建及ut/it的门禁检查；支持组件的全量二进制构建；支持组件转维发布能力；支持社区开发者签名出包等；提供调试工具能力；
* * *
## 源代码
25.06版本源代码已发布至社区网站：https://openubmc.cn/zh/download
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| https://atomgit.com/openUBMC/mdb_interface/issues/135 | 资源协作接口属性和方法Description字段修改 | mdb_interface |
| https://atomgit.com/openUBMC/fructrl/issues/15 | 老版本导入新版本上电延迟值可能被改变 | fructrl |
* * *
## 已修复问题
历史版本已发现在当前版本解决的缺陷：暂无
* * *
## CVE 漏洞
暂无
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/25.09/
---
文档中心
版本说明
版本选择
# openUBMC 25.09 版本发布说明
2025/09/30
# openUBMC 25.09 版本发布说明
* * *
## 版本概览
作为25年第三个创新版本，openUBMC 25.09 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
25.09版本在25.06版本基础上进行开发，特性交付范围包括：
### 北向接口生态
#### 1\. 基础安全能力
- **密码安全策略**：支持禁用历史密码、失败锁定次数配置、登录失败锁定时间配置、超长密码支持
- **认证与授权**：支持WEB SSO单点登录、IPMI通道权限配置、前端敏感信息加密
- **安全审计**：支持动态插桩拦截风险接口调用日志、Cleancode排查整改
#### 2\. 管理软件生态
- **网管系统对接**：支持Zabbix、Ansible、Cmdlets、Nagios插件，实现与openUBMC的完整对接
- **开发指导文档**：提供SNMP接口映射器、TRAP告警、装备定制、CLI映射器等配置指导文档
#### 3\. 接口升级与扩展
- **Redfish接口增强**：主要包含Manager、Processor、SEL、NTP、时区等资源管理
- **IPMI标准命令**：支持User access/Password、User Name、DCMI Power等标准命令
#### 4\. 融合运维能力
- **固件升级管理**：支持一个hpm包多个固件场景升级、BMC升级异常时自恢复
- **安全升级控制**：支持VRD和NPU升级过程中禁止主机上电
- **任务管理**：支持任务资源标准规范和定制能力
### 南向部件扩展
#### 1\. 南向驱动框架
- **驱动规范**：完成南向驱动框架和规范发布，基于规范完成网卡和GPU兼容性适配
- **协议支持**：支持I3C/CAN-FD能力、Ncsi Over Mctp/I2C/SMBUS协议获取网卡信息
- **私有协议**：支持Emulex的pldm私有协议
#### 2\. 板卡接入丰富度
- **网卡支持**：新增标卡和OCP网卡，包括E810XXVDA2G1P5、E810CQDA2G2P5、MCX755106AS-HEAT等
- **存储设备**：支持RAID卡（SP686C-M系列）、硬盘、NVMe盘（SamSung PM9D3A、Memblaze PBlaze7、Solidigm D7-PS1010等）
- **计算加速**：支持GPU（A6000）、NPU模组等部件接入
#### 3\. TPSU/PSU管理
- **基本信息管理**：支持TPSU模块信息查询、电源额定功率变化记录
- **Turbo功能**：支持Turbo电容管理、充放电控制、使能控制
- **主备切换**：支持双CAN电源线路主备切换、供电模式切换
- **功率管理**：支持功耗封顶、功率监控、输出限功率点配置
#### 4\. DFX能力增强
- **临终遗言**：支持VRM/电源等关键部件临终遗言持久化
- **固件管理**：支持BIOS固件导出、关键部件固件升级
- **故障检测**：支持网卡Flash recovery故障检测、光模块关键信息记录和闪断检测
- **链路检测**：支持高速链路检测、CPU与外围器件链路异常告警
### 开发体验优化
#### 1\. QEMU仿真能力
- **总线仿真**：支持SMBus、MCTP等复杂协议仿真
- **部件仿真**：支持MCU、PCIe、IMU等器件仿真
- **性能优化**：QEMU冒烟测试性能优化、支持依赖驱动更新
#### 2\. 指导文档完善
- **接口文档**：完成SNMP接口映射器、TRAP告警、装备定制、CLI映射器等指导文档
- **开发指南**：提供映射器接口设计说明书、配置指导、定位指导
- **用户手册**：更新BMC Studio用户指南、联机帮助页面扩展
#### 3\. 构建优化
- **Conan2.0升级**：完成conan2.0中心仓能力构建、支持Profile配置和并行构建
- **Bingo工具增强**：支持基于gtest的开发者测试、DT测试质量加固、门禁模型检查能力增强
- **构建脚本**：支持社区组件构建脚本适配Conan2.0、非root运行
#### 4\. 开发体验提升
- **测试能力**：bingo支持基于gtest的开发者测试、DT测试能力增强
- **代码质量**：门禁模型检查能力增强、支持代码开源合规检查
- **工具支持**：新增I2C扫描和读写工具、支持度量采集和可观测跟踪可配置
* * *
## 源代码
25.09版本源代码已发布至社区网站：https://openubmc.cn/zh/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 5.11.0 | 5.10.0 | 5.9.0 |
| --- | --- | --- | --- |
| 25.09 | Y | N | N |
| 25.06 | N | Y | N |
| 25.03 | N | N | Y |
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3187698 | 资源协作接口属性和方法Description字段修改 | mdb_interface |
| 3190225 | 老版本导入新版本上电延迟值可能被改变 | fructrl |
* * *
## 已修复问题
历史版本已发现在当前版本解决的缺陷：暂无
* * *
## CVE 漏洞
暂无
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/25.12/
---
文档中心
版本说明
版本选择
# openUBMC 25.12 LTS 版本发布说明
2025/12/31
# openUBMC 25.12 LTS 版本发布说明
* * *
## 版本概览
作为25年第1个长期支持版本，openUBMC 25.12 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
25.12版本在25.09版本基础上进行开发，特性交付范围包括：
### 北向接口生态
#### 1\. 接口标准化与扩展
**Redfish 资源升级**：包含对ProcessorMetrics、PCIeDevice、PCIeFunction、MemoryMetrics、StorageController、VirtualMedia等28个关键资源升级。
**IPMI**：支持Chassis与DCMI相关IPMI标准命令。
#### 2\. 安全与可靠性
**账户管理**：支持登录用户和最后一个用户不可删除。
#### 3\. 运维与管理功能
**固件与配置管理**：支持双主机BIOS固件管理、BMC恢复出厂设置后保留BIOS属性。
**监控**：支持查询历史功率资源信息。
### 南向部件扩展
#### 1\. 硬件生态接入扩展
**网卡**：支持网卡的LLDP、电源故障告警、管理属性加固；支持OCP网卡Multihost场景；UB/UBoE网口及光模块的适配与管理。
**存储**：支持多款NVMe硬盘（如DAPUSTOR R6301/R6101）。
**电源与散热**：支持EB1000、3kw电源、PSIP双子星等新型电源管理；增强对TPSU电容寿命预测、风扇转速告警阈值设置、液冷系统（如Pumps资源、LeakDetection）的监控。
#### 2\. 驱动与协议框架深化
**驱动框架**：网卡/GPU/硬盘南向驱动适配特性增强，并开始适配南向部件驱动新规范接口，为统一驱动模型打下基础。
**新协议支持**：引入并支持标准SPDM协议，提供相关资源协作接口与原子能力。
### 开发体验优化
#### 1\. 构建与部署工具链
**Bingo构建系统增强**：支持组件构建、产品构建、自定义命令的归一处理；支持Manifest对bingo工具的版本约束和自动升级；适配Conan 2.0，支持产品仓裁剪、包构建时打包MDS信息。
**Docker与CI/CD**：支持基于Dockerfile的镜像构建与发布、一体化集成开发环境Docker镜像构建；优化QEMU仿真镜像流水线。
#### 2\. 测试与质量保障
**测试覆盖强化**：实现libmcpp、devmon等模块测试覆盖率提升，强化component\_drivers组件驱动模块测试。
**门禁与流水线**：支持社区PR门禁自动识别和拦截、门禁检查并发控制。
**社区质量**：新增需求需要经过RM Sig评审的管控措施，以提升需求质量。
#### 3\. 仿真、调试与文档
**QEMU仿真优化**：Qemu维护与部署优化，创建qemu\_mockup新仓专门管理仿真数据和驱动，提升仿真便利性。
**在线调试与诊断**：提供在线调试特性设计说明书。
**文档体系完善**：补充和更新开发指南与常见问题，包括硬盘背板、网络管理、固件升级、BIOS实现、北向接口适配、持久化机制等数十个主题的指导文档，并支持docs仓库的CI门禁识别失效链接。
## 源代码
25.12版本源代码已发布至社区网站：https://openubmc.cn/zh/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 5.12.0 | 5.11.0 | 5.10.0 | 5.9.0 |
| --- | --- | --- | --- | --- |
| 25.12 | Y | N | N | N |
| 25.09 | N | Y | N | N |
| 25.06 | N | N | Y | N |
| 25.03 | N | N | N | Y |
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3690536 | 带内os热升级SATA SSD盘固件版本，BMC上显示的硬盘固件版本不更新 | storage |
| 3644159 | 电源通讯异常，通过北向接口查询电源功率、电压、温度、电流等动态信息显示为0 | power_mgmt |
* * *
## 已修复问题
本修复问题清单：
| 问题描述 |
| --- |
| 修复了 告警码处理意见存在主板的英文单词，单板只有基础板，没有主板 的错误告警。 |
| 修复了 告警码0x0100003B在槽位11模拟不上报告警 的问题。 |
| 修复了 cli查询ip信息，网口组1和网口组2的Ip Mode信息显示不统一 的问题。 |
* * *
## CVE 漏洞
| 漏洞编号 | 漏洞描述 |
| --- | --- |
| CVE-2020-14354 | A possible use-after-free and double-free in c-ares lib version 1.16.0 if ares_destroy() is called prior to ares_getaddrinfo() completing. This flaw possibly allows an attacker to crash the service that uses c-ares lib. The highest threat from this vulnerability is to this service availability. |
| CVE-2025-62408 | c-ares is an asynchronous resolver library. Versions 1.32.3 through 1.34.5 terminate a query after maximum attempts when using read_answer() and process_answer(), which can cause a Denial of Service. Use after free will lead to crash / Denial of Service. This issue is fixed in version 1.34.6. |
| CVE-2025-57665 | Element Plus Link component (el-link) through 2.10.6 implements insufficient input validation for the href attribute, creating a security abstraction gap that obscures URL-based attack vectors. The component passes user-controlled href values directly to underlying anchor elements without protocol validation, URL sanitization, or security headers. This allows attackers to inject malicious URLs using dangerous protocols (_, data:, file:) or redirect users to external malicious sites. While native HTML anchor elements present similar risks, UI component libraries bear additional responsibility for implementing security safeguards and providing clear risk documentation. The vulnerability enables XSS attacks, phishing campaigns, and open redirect exploits affecting applications that use Element Plus Link components with user-controlled or untrusted URL inputs. |
* * *
## OPEN SOURCE SOFTWARE NOTICE
Open Source Software Notice
## 接口 API 变更
### 资源协作接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| 资源协作接口方法 FirmwareMatchRules 权限和签名变更 | >> 变更详细说明 |
| 资源协作接口方法 GetPolicyGuidances 响应签名变更 | >> 变更详细说明 |
| 资源协作接口方法 SetNpuPowerCap 权限变更 | >> 变更详细说明 |
### 北向接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| 【Redfish】SimpleUpdate POST请求不保留配置升级权限变更 | >> 变更详细说明 |
| 【IPMI】SetUserAccess 带内设置用户通道权限变更 | >> 变更详细说明 |
| 【Redfish】LimitException 功耗封顶失败后的策略取值和行为变更【IPMI OEM】SetPowerCappingConfiguration 功耗封顶失败后的策略取值和行为变更【IPMI DCMI】SetPowerLimit 功耗封顶失败后的策略取值和行为变更【WEB】功耗封顶失败后的策略取值和行为变更【SNMP】功耗封顶失败后的策略取值和行为变更 | >> 变更详细说明 |
| 【IPMI】GetUserAccess 请求体通道号无效时返回值变更 | >> 变更详细说明 |
* * *
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/26.03/
---
文档中心
版本说明
版本选择
# openUBMC 26.03 版本发布说明
2026/03/31
# openUBMC 26.03 版本发布说明
* * *
## 版本概览
作为26年第1个创新版本，openUBMC 26.03 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
26.03版本在25.12版本基础上进行开发，特性交付范围包括：
### 易用性：工具链与开发体验提升
#### BMC Studio 与可视化配置
1. 支持BMC Studio IDE独立发布和升级。
2. 支持CSR编码辅助：语法高亮、引用跳转、基础语法检查、表达式计算
3. 支持lockfile提交记录可视化查看
#### 版本构建与工具链
1. 支持1712芯片构建
2. 支持 基于lockfile的产品级构建，解决版本冲突问题
3. conan并行化构建，优化构建效率
4. qemu升级到8.2.10版本
5. 社区基础设施支持签名能力
#### 开发、测试与调试体验提升
新增 社区技术文档、FAQ、接口文档、适配指南，降低新开发者上手成本
### 丰富度：硬件接入与功能增强
#### 网卡接入能力扩展
1. 新增对 182x系列网卡（高低档位） 的全面支持，包括标卡、OCP卡、大板网卡等形态，支持光模块信息采集、告警增强、私有NCSI/SMBUS协议支持
2. 支持 Mellanox ConnectX-7网卡的适配
#### 硬盘与存储管理增强
1. 支持1880 RAID卡的升级和慢盘检测开关使能，支持1880 RAID管理的SAS/SATA硬盘的固件升级和版本信息展示
2. 支持硬盘槽位号动态更新、硬盘插入/拔出日志记录SN/PN
#### 异构与PCIe设备管理
1. 支持JBOG管理，包括设备信息查看与状态监测，固件升级。
2. 支持 PCIe拓扑高速线缆交叉插法、PCIe卡插入/拔出日志记录SN/PN
#### 带外管理能力提升
1. 支持 CPLD/BIOS/VRD/MCU/NPU 等多种固件的整包升级
2. 支持 固件升级暂存机制（仅适用于下电生效的固件）
3. 支持管理板和节点间的板间通信
4. ipmb/bt性能优化
### 标准：规范建设与质量保障
#### 驱动与硬件接入规范
1. 推动 驱动认证规范，完成南向网卡兼容认证工具开发，明确准入用例标准
#### 接口与协议标准化
1. 支持 Redfish标准资源PCIeSlots、Assembly、Memory、Chassis 新增新属性
2. 完善 Schema管理机制：支持xml/json schema独立加载、版本升级
3. 支持 Redfish-Protocol/Interop/Service Validator 工具集成
* * *
## 源代码
26.03版本源代码已发布至社区网站：https://openubmc.cn/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 5.13.0 | 5.12.0 | 5.11.0 | 5.10.0 | 5.9.0 |
| --- | --- | --- | --- | --- | --- |
| 26.03 | Y | Y | N | N | N |
| 25.12 | N | Y | N | N | N |
| 25.09 | N | N | Y | N | N |
| 25.06 | N | N | N | Y | N |
| 25.03 | N | N | N | N | Y |
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3813122 | 进行硬盘暴力热插拔时，系统事件出现错误的硬盘SN信息 | frudata |
| 3812472 | 串口环境下passwd 命令修改用户密码失败, cli命令修改用户报权限不足 | account |
| 3644159 | 电源通讯异常，通过北向接口查询电源功率、电压、温度、电流等动态信息显示为0 | power_mgmt |
* * *
## 已修复问题
本修复问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3783134 | 修复vrd下电升级失败和暂存失败的问题 | general_hardware |
| 3777594 | 修复schemasotre/en接口查询时，响应体中，自定义oem部分无法查询问题 | rackmount |
| 3789480 | 升级CPLD过程中，解除smc告警屏蔽的流程放在内层函数，防止因为fork执行导致时序异常 | general_hardware |
* * *
## CVE 漏洞
| 漏洞编号 | 漏洞描述 |
| --- | --- |
| CVE-2022-1941 | A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input. We recommend upgrading to versions 3.18.3, 3.19.5, 3.20.2, 3.21.6 for protobuf-cpp and 3.18.3, 3.19.5, 3.20.2, 4.21.6 for protobuf-python. Versions for 3.16 and 3.17 are no longer updated. |
| CVE-2024-2410 | The JsonToBinaryStream() function is part of the protocol buffers C++ implementation and is used to parse JSON from a stream. If the input is broken up into separate chunks in a certain way, the parser will attempt to read bytes from a chunk that has already been freed. |
| CVE-2025-55131 | c-ares is an asynchronous resolver library. Versions 1.32.3 through 1.34.5 terminate a query after maximum attempts when using read_answer() and process_answer(), which can cause a Denial of Service. Use after free will lead to crash / Denial of Service. This issue is fixed in version 1.34.6. |
| CVE-2022-1941 | A vulnerability, which was classified as critical, has been found in Oracle MySQL Connectors up to 8.0.31 (Database Software).Using CWE to declare the problem leads to CWE-404. The program does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.A possible mitigation has been published immediately after the disclosure of the vulnerability. |
| CVE-2025-4565 | Any project that uses Protobuf Pure-Python backend to parse untrusted Protocol Buffers data containing an arbitrary number of recursive groups, recursive messages or a series of SGROUP tags can be corrupted by exceeding the Python recursion limit. This can result in a Denial of service by crashing the application with a RecursionError. |
| CVE-2025-53605 | The protobuf crate before version 3.7.2 for Rust contains uncontrolled recursion vulnerability in protobuf::coded_input_stream::CodedInputStream::skip_group when parsing unknown fields in untrusted input. |
| CVE-2024-7254 | Any project that parses untrusted Protocol Buffers data containing an arbitrary number of nested groups / series of SGROUP tags can corrupted by exceeding the stack limit i.e. StackOverflow. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. |
| CVE-2023-30608 | sqlparse is a non-validating SQL parser module for Python. In affected versions the SQL parser contains a regular expression that is vulnerable to ReDoS (Regular Expression Denial of Service). This issue was introduced by commit e75e358. The vulnerability may lead to Denial of Service (DoS). This issues has been fixed in sqlparse 0.4.4 by commit c457abd5f. |
* * *
## OPEN SOURCE SOFTWARE NOTICE
Open Source Software Notice
## 接口 API 变更
### 资源协作接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| 资源协作接口方法 bmc.kepler.AccountService 下属性 EmergencyLoginAccountId 权限变更 | >> 变更详细说明 |
### 北向接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| 【WebRest】AdvancedSecurity GET请求获取EmergencyLoginUser权限变更 | >> 变更详细说明 |
| 【Redfish】AccountService GET请求获取EmergencyLoginUser权限变更 | >> 变更详细说明 |
| 【Redfish】AccountService/PrivilegeMap 中Oem//EmergencyLoginUser的GET权限变更 | >> 变更详细说明 |
| 【Redfish】PerformanceCollection资源的光模块URI变更 | >> 变更详细说明 |
| 【Redfish】光模块脏污检测资源的Start请求体以及GetResult响应体变更 | >> 变更详细说明 |
| 【Redfish】GPU处理器资源的PCI Ids属性类型变更 | >> 变更详细说明 |
| 【Redfish】Bios资源的GET操作响应体变更 | >> 变更详细说明 |
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/26.06/
---
文档中心
版本说明
版本选择
# openUBMC 26.06 版本发布说明
2026/06/30
# openUBMC 26.06 版本发布说明
* * *
## 版本概览
作为26年第2个创新版本，openUBMC 26.06 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
26.06版本在26.03版本基础上进行开发，特性交付范围包括：
### 易用性：工具链、开发体验与可视化配置全面升级
#### BMC Studio IDE 能力增强
- CSR编码辅助：基于模型的属性与对象配置联想、掩码类型属性可视化、CSR复杂规则实时检查，支持用户扩展。
- 可视化配置能力：风冷调速策略可视化配置，支持基于模版创建部件驱动框架代码。
#### 文档与知识体系建设
- IPMI文档结构化：补充IPMI文档结构化信息，支持通过脚本自动生成IPMI接口文档。
- 接口审核自动化：支持版本接口变更文档自动生成、sig-interface评审帖自动预审、社区接口变更PR自动检视。
- 技术知识沉淀：新增PMBus、NCSI、CANBus、M.2、NVMe、CPLD升级等系列技术介绍文档；新增storage、pcie\_device等18个核心组件设计说明；建设200故障案例知识库。
#### 工程与门禁能力
- 构建与出包：bingo支持白牌包出包、基于OEE工具链的整包构建/集成、ccache构建优化及PR页面Conan版本回显。
- 编译器适配：适配GCC 14.3编译器。
- 代码仓治理：component\_drives代码仓体积及构建时间优化。
- 组件性能优化：支持组件启动性能优化、传感器对象接入性能提升30%。
### 丰富度：硬件生态、部件管理与平台能力拓展
### 网卡与网络适配
- 新网卡适配：新增沐创N10、网迅25GE、Mellanox MCX653106A、光润通F1002T-V3.0、N20 40G/100G等多款网卡。
- 182x系列能力增强：支持高低档182x系列的DFX、调速策略、告警补齐、光模块信息快速记录、SMBUS获取功率及自定义SMBUS固件升级。
- UB管理：光模块告警/信息采集、光链路定界、网口与光模块动态映射及web信息查询，提升UB设备带外可管理性。
#### 硬盘与存储管理
- 新硬件适配：适配佰维SS821、PetaIO P8118Z3、YMTC PE511、芯展速/芯盛SSD等硬盘；支持9580-8i8e。
- RAID管理增强：支持多启动盘配置（Web/Redfish/CLI）、并行升级、硬盘故障自愈、日志收集及启动盘信息显示。
- NVMe能力：支持NVMe盘固件升级，并行升级。
#### 异构计算与PCIe管理
- GPU/AI芯片适配：适配英伟达5090 和 Tesla P4/P40/V100/A100多款GPU。
- PCIe管理：支持基于rootBDF加载设备、UBC线缆检测增加整机白名单配置、SKU/RevisionId/Status属性查询。
#### 运维管理
- CPLD无感升级：支持无感升级全流程（前置处理、寄存器保存恢复、BMC与模块交互、数据持久化）。
- 暂存升级：支持固件的暂存和待生效固件的版本号展示。
- 用户管理：支持分权分域、LDAP登入可定位。
### 标准：规范落地
#### 接口协议标准化
- Redfish资源补齐：新增Chassis、Fan、Drive、Port、PortMetrics、NetworkAdapter、NetworkDeviceFunction、EthernetInterface、EnvironmentMetrics等OCP规范资源属性。
- 固件升级标准化：UpdateService支持MultipartHttpPushUri和Targets参数。
#### 安全与签名规范
- 签名完整性：支持SignServer对接HPM外层签名、流水线固件完整性保护签名。
#### 南向驱动规范与部件认证
- 南向驱动规范接入：风扇/电源/NVMe/RAID卡。
- 南向认证测评：网卡、GPU、硬盘、Raid。
- 固件联盟认证：支持固件联盟190+认证用例。
* * *
## 源代码
26.06版本源代码已发布至社区网站：https://openubmc.cn/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 5.14.0 | 5.13.0 | 5.12.0 | 5.11.0 | 5.10.0 |
| --- | --- | --- | --- | --- | --- |
| 26.06 | Y | Y | N | N | N |
| 26.03 | Y | Y | Y | N | N |
| 25.12 | N | N | Y | Y | N |
| 25.09 | N | N | N | Y | N |
| 25.06 | N | N | N | N | Y |
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 4104349 | 使用Redfish接口修改自定义用户OEM权限，偶现PATCH接口返回500错误。 | account |
| 4106323 | Redfish访问Systems资源下级Storages资源跳转链接未切换为标准Storage。 | rackmount |
| 4106703 | SSH登录后执行ipmcget -d version查询版本信息超过性能基线2s。 | rackmount |
| 4106819 | 通知式热拔出网卡后重新插入实体网卡，切换管理网口到NCSI口后网络不通。 | rackmount |
| 3912021 | 博通RAID卡作为PCIe卡未配置BoardPCIeCard对象，导致/redfish/v1/Chassis/1/Boards/下查询不到。 | vpd |
* * *
## 已修复问题
本版本已修复问题清单（部分）：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 3825410 | Vue的parseHTML函数正则表达式可导致ReDoS漏洞。 | webui |
| 3825420 | Vue原型污染可导致XSS攻击，攻击者可修改Object.prototype属性执行任意JS代码。 | webui |
| 3825424 | @intlify/shared的lib.deepCopy函数存在原型污染漏洞。 | webui |
| 3825413 | Vue I18n的handleFlatJson函数存在原型污染漏洞。 | webui |
| 3825414 | intlify vue-i18n组件存在XSS漏洞(CWE-79)。 | webui |
| 4072295 | 单板生产时间超过2027-11-25后，Redfish查询显示为1996年。 | frudata |
| 4035445 | BMC加载电子标签未实际成功仍上报pass，可能导致异常单板流入现网。 | frudata |
| 4077108 | 账户信息缓存同步存在时间窗口，新增账户的缓存信息可能被误删。 | account |
| 3880710 | 环境持久化存在不支持的账户策略数据时，重启后AccountPolicy读取异常。 | account |
| 4076853 | 部分组件不支持GCC 14.3编译器编译。 | spdm |
| 3878363 | bingo build/test依赖组件默认仅使用@openubmc结尾conan包，导致依赖解析错误。 | bingo |
| 4082796 | bingo build未正确使用本地conan缓存，导致重复下载已存在的组件包。 | bingo |
| 4077222 | 社区固件完整性保护签名缺少uboot部分签名，签名链路不完整。 | bingo |
| 3878995 | 传感器线性模式下事件构造至上限时，转储操作性能消耗过高。 | sensor |
| 4084448 | BMC上unions温度显示与实际不符。 | sensor_mgmt |
| 4091329 | service工具扫描EnvironmentMetrics接口存在兼容性问题。 | rackmount |
| 3834751 | 未配置精细化告警时，普通线缆告警也无法正常触发。 | pcie_device |
| 3912553 | thermal_mgmt组件启动时cooling_pumps文件产生无效日志刷屏。 | thermal_mgmt |
| 3856614 | HBM动态巡检参数配置功能接口定义调整。 | mdb_interface |
| 3720145 | RAID卡通讯丢失上报告警slot与实际物理槽位不一致。 | vpd |
| 4035170 | NVMe盘频繁热插拔时偶现调速策略未正确加载。 | storage |
| 3690536 | Lua语法and/or误当三目运算符使用，导致属性赋值全为true。 | storage |
| 4072112 | BMA开启后不支持南向驱动的网卡导致port_mgmt.lua日志刷屏。 | network_adapter |
| 3783134 | BMC配置独立VRD时，上传固件包执行暂存操作失败。 | general_hardware |
| 4092237 | retimer芯片故障时定时任务持续失败产生日志刷屏。 | general_hardware |
| 3833460 | 修复0x2400001F告警显示信息与产品资料不一致的问题。 | vpd |
| 3868622 | 网卡升级active流程未判断firmware type，影响其他固件active信号。 | network_adapter |
| 4032010 | 故障/预故障硬盘在BMC复位后告警状态被错误恢复再产生。 | storage |
| 4048926 | VRD生效流程中生效失败仍返回成功，操作日志与实际状态不一致。 | general_hardware |
| 3644159 | 电源CommunicationStatus异常恢复后，额定功率仍为0。 | power_mgmt |
* * *
## CVE 漏洞
本版本已修复的CVE漏洞：
| 漏洞编号 | 漏洞描述 |
| --- | --- |
| CVE-2024-6783 | A vulnerability in Vue that allows an attacker to perform XSS via prototype pollution. The attacker could change the prototype chain of properties such as Object.prototype.staticClass or Object.prototype.staticStyle to execute arbitrary JavaScript code. |
| CVE-2024-9506 | An improper regular expression in Vue's parseHTML function leads to a potential regular expression denial of service vulnerability. |
| CVE-2024-52809 | A cross-site scripting (XSS) vulnerability in intlify vue-i18n up to 9.14.1/10.0.4. The manipulation of the argument createI18n/useI18n with unknown input leads to CWE-79. |
| CVE-2024-52810 | @intlify/shared (10.0.4) is vulnerable to Prototype Pollution through the entry function lib.deepCopy. An attacker can supply a payload with Object.prototype setter to introduce or modify properties within the global prototype chain, causing denial of service (DoS). |
| CVE-2025-27597 | Vue I18n @intlify/message-resolver and @intlify/vue-i18n-core are vulnerable to Prototype Pollution through the entry function handleFlatJson. An attacker can supply a payload with Object.prototype setter to introduce or modify properties within the global prototype chain. |
| CVE-2025-40908 | YAML-LibYAML prior to 0.903.0 for Perl uses 2-args open, allowing existing files to be modified. |
| CVE-2025-62718 | Axios prior to 1.15.0 and 0.31.0 does not correctly handle hostname normalization when checking NO_PROXY rules. Requests to loopback addresses like localhost. (with trailing dot) or ::1 (IPv6 literal) skip NO_PROXY matching and go through the configured proxy. |
| CVE-2026-40175 | Axios prior to 1.15.0 and 0.3.1 is vulnerable to a specific Gadget attack chain that allows Prototype Pollution in any third-party dependency to be escalated into Remote Code Execution (RCE) or Full Cloud Compromise. |
| CVE-2026-42033 | Axios prior to 1.15.1 and 0.31.1: when Object.prototype has been polluted by any co-dependency with keys that axios reads without a hasOwnProperty guard, an attacker can silently intercept and modify every JSON response before the application sees it, or fully hijack the underlying HTTP transport. |
| CVE-2026-42034 | Axios prior to 1.15.1 and 0.31.1: for stream request bodies, maxBodyLength is bypassed when maxRedirects is set to 0. Oversized streamed uploads are sent fully even when the caller sets strict body limits. |
| CVE-2026-42035 | Axios prior to 1.15.1 and 0.31.1: a prototype pollution gadget exists in the HTTP adapter that allows an attacker to inject arbitrary HTTP headers into outgoing requests. |
| CVE-2026-42036 | Axios prior to 1.15.1 and 0.31.1: when responseType: 'stream' is used, Axios returns the response stream without enforcing maxContentLength, bypassing configured response-size limits. |
| CVE-2026-42037 | Axios 1.0.0 to before 1.15.1: the FormDataPart constructor interpolates value.type directly into the Content-Type header without sanitizing CRLF sequences, allowing HTTP header injection. |
| CVE-2026-42038 | Axios prior to 1.15.1 and 0.31.1: incomplete fix for NO_PROXY hostname normalization bypass. When no_proxy=localhost is set, requests to 127.0.0.1 and ::1 still route through the proxy. |
| CVE-2026-42039 | Axios prior to 1.15.1 and 0.31.1: toFormData recursively walks nested objects with no depth limit, causing deeply nested request data to crash the Node.js process with a RangeError. |
| CVE-2026-42040 | Axios prior to 1.15.1 and 0.31.1: the encode() function contains a character mapping that reverses the safe percent-encoding of null bytes, converting %00 back to a raw null byte. |
| CVE-2026-42041 | Axios prior to 1.15.1 and 0.31.1: vulnerable to a Prototype Pollution Gadget attack that allows any Object.prototype pollution to silently suppress all HTTP error responses, bypassing application-level authentication and error handling. |
| CVE-2026-42042 | Axios prior to 1.15.1 and 0.31.1: XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for withXSRFToken, causing cross-site request forgery protection bypass. |
| CVE-2026-42043 | Axios prior to 1.15.1 and 0.31.1: an attacker who can influence the target URL can use any 127.0.0.0/8 address (other than 127.0.0.1) to completely bypass the NO_PROXY protection. Incomplete fix for CVE-2025-62718. |
| CVE-2026-42044 | Axios 1.0.0 to before 1.15.2: vulnerable to a Prototype Pollution Gadget attack that allows any Object.prototype pollution to be escalated into surgical, invisible modification of all JSON API responses, including privilege escalation and authorization bypass. |
| CVE-2026-42264 | Axios 1.0.0 to before 1.15.2: five config properties (auth, baseURL, socketPath, beforeRedirect, insecureHTTPParser) are read via direct property access without hasOwnProperty guards, making them exploitable as prototype pollution gadgets. |
| CVE-2026-46625 | js-cookie's internal assign() helper copies properties with for...in + plain assignment. When the source object is produced by JSON.parse, the proto member triggers a per-instance prototype hijack, allowing attacker-controlled keys to land in Set-Cookie headers. |
## OPEN SOURCE SOFTWARE NOTICE
Open Source Software Notice
## 接口 API 变更
### 资源协作接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| 资源协作接口 bmc.kepler.Systems.NetworkPort 部分属性类型变更 | >> 变更详细说明 |
### 北向接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| 【IPMI】IPMI接口Get/Set Rack Info机柜供电方式取值变更 | >> 变更详细说明 |
| 【Redfish】Redfish事件订阅请求参数EventTypes、Context由必选调整为可选 | >> 变更详细说明 |
| 【Redfish】Redfish网口资源部分属性在读取硬件数据失败时取值变更 | >> 变更详细说明 |
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/26.09/
---
文档中心
版本说明
版本选择
# openUBMC 26.09 版本发布说明
2026/09/30
# openUBMC 26.09 版本发布说明
* * *
## 版本概览
作为26年第3个创新版本，openUBMC 26.09 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
26.09版本在26.06版本基础上进行开发，特性交付范围包括：
### 易用性：工具链、开发体验与可视化配置全面升级
#### BMC Studio IDE 能力增强
- **代码仓类型识别**：支持自动识别manifest产品配置仓、mdb\_interface接口配置仓、rackmount北向接口配置仓及业务组件仓，并基于类型提供可执行操作。
- **出包配置可视化**：支持可视化编辑manifest.yaml，自动检测SDK版本及组件列表，提供组件依赖联想、特性开关可视化配置，出包时展示固件包信息概览（组件列表、版本、特性开关、SDK版本）。
- **hpm包一键升级**：支持在hpm文件上右键选择“升级到环境”，可一次升级到多个环境，后台执行并显示进度与结果。
- **BMC环境管理**：支持配置BMC环境（IP、用户名、密码加密存储），一键打开SSH/Telnet终端及网页，在线状态检测与变更提醒。
- **CSR门禁屏蔽**：支持通过注释方式屏蔽CSR门禁错误，并支持在错误问题上点击按钮一键屏蔽。
- **阈值传感器告警掩码校验**：当AssertMask、DeassertMask、ReadingMask配置与上下限规则不符时给出错误提示，并说明正确值及原因。
- **白牌定制配置可视化**：支持web\_custom.xml文件的可视化配置界面，图片内容可预览并显示说明信息。
- **智能问答**：集成社区知识库与故障案例库，实现问题快速定位定界与AI辅助BMC开发能力。
- **日志分析能力**：支持导入一键收集日志解析整机CSR拓扑及查看CSR文件内容；支持通过日志信息结合AI能力产出事件告警触发链条分析报告。
#### 构建工具链与工程能力
- **bingo支持OpenEuler+Kunpeng环境**：支持在OpenEuler+Kunpeng环境下安装、升级及编译bingo依赖的二进制文件。 #223
- **OEE+Hi3095构建支持**：bingo支持基于OEE+Hi3095的组件构建、升级包构建及SDK发布包产品构建，支持OEE+Aspeed烧片包构建。 #209 #210 #230 #231
- **产品构建组件替换**：支持产品构建时通过配置对平台组件进行覆写替换，并在替换时提供醒目提示。 #232
- **ASan扫描能力**：bingo test支持ASan扫描识别C/CPP代码内存问题，支持通过代码注释方式屏蔽扫描结果。 #211 #212
- **clang-tidy错误检查**：社区C/CPP组件支持基于clang-tidy的错误检查。 #225
#### 文档与知识体系建设
- **组件文档说明**：为bingo、manifest、mctpd、hwdiscovery、hwproxy、runtime\_accessor、liblogger、libsomp、libmc4lua、iam/libiam、account等组件/lib库建立完整文档体系，包括组件概述、API使用说明和示例、扩展案例、日志说明、问题定界指南及FAQ。 #215 #297 #795 #796 #829 #830 #831 #832 #846 #851 #853 #212 #214
- **开发指导文档**：新增Hi1712芯片构建指导、开发环境初始化配置文档、快速新增一个产品教程、拆包解析能力定制指导、IPMI通道（bt、ipmb）不通定位指导。 #793 #794 #799 #836 #837
- **AI辅助扫描流水线**：支持AI辅助日志规范扫描和安全规范扫描，支持组件级和版本级扫描，版本级扫描结果归档为html报告。 #299 #300
#### 社区治理与流程规范
- **Issue/PR提交规范校验**：需求issue必须包含简要说明、系统用户、前置条件、主成功场景、扩展场景、兼容性影响评估；缺陷issue必须包含预置条件、操作步骤、结果描述、预期结果、受影响版本、问题优先级；PR提交时自动检查模板合规性。 #185
- **Issue状态精简**：删除“转测中”状态，需求代码合入转测后直接从“开发中”走到“待验收”。 #194
- **编码风格可视化**：社区代码仓支持基于pre-commit机制的编码风格检查，C/CPP代码仓生效clang-format，Python代码仓生效Ruff，JS代码仓配置.prettierrc。 #296
- **RAG对外查询接口**：开放 RAG 相关接口，支持用户通过 MCP 访问 RAG 系统，获取 openUBMC 知识上下文。 #166
### 丰富度：硬件生态、部件管理与平台能力拓展
#### 异构计算与PCIe管理
- **PCIe设备RAS原子能力**：支持PCIe设备上报故障时识别设备BDF，已知BDF汇聚到PCIeCollector，未知BDF汇聚到UnknownPCIeCollector。 #385
- **DPU独立分类显示**：支持DPU在BMC WEB界面单独分类显示，不再混在PCIe设备界面。 #909 #414
- **NPU模组管理增强**：支持NPU模组电源告警精确解析和上报、HBM冗余资源实时监控和资源不足告警。 #359 #368
- **NPU参数面光模块控制**：支持通过Redfish接口实现NPU参数面光模块灭灯/恢复亮灯操作。 #399
#### 存储与硬盘管理
- **SMART信息获取增强**：支持NVMe盘组硬Raid后带外获取SMART信息、Redfish接口获取SATA盘SMART信息、Redfish接口获取NVMe盘标准SMART信息。 #414 #416 #937
- **SMART日志采集与导出**：支持自研RAID下SATA盘和直通NVMe盘的SMART日志定时采集、存储与导出，支持Web前端硬盘日志收集按钮。 #417 #428
- **硬盘时间同步**：支持自研RAID下SAS/SATA SSD盘时间同步功能，在盘第一次识别加载、盘更换、系统上下电时同步。 #422
#### 网卡与网络适配
- **光模块门限值采集**：光模块静态文件增加门限值，日志采集包含对应门限值。 #352
- **光模块告警实现优化**：支持网卡光模块各通道告警通过CSR配置实现，删除软件告警，提升扩展性。 #456
- **光模块指标定义**：redfish遥测支持光模块相关指标定义（MetricDefinition），包括RxInputPower和TxBiasCurrent。 #630
#### 固件升级与管理
- **Krun固件升级**：复用BIOS固件升级方式，支持通过SPI接口升级Krun固件。 #151
- **本地固件仓管理**：支持本地固件仓固件的添加、更新、删除与生效，支持本地固件仓容量查询，并支持检测本地固件仓版本与运行固件版本的一致性。 #908 #387#947 #404
- **VRD自愈能力**：VRD升级成功后备份升级包，检测到VRD异常时使用备份包重新升级尝试自愈。 #379
- **CPLD JTAG扫链巡检**：支持天池单板通过JTAG链路进行CPLD扫链巡检，验证CSR配置与实际硬件一致性。 #378
#### 平台基础能力
- **libmcpp框架能力**：支持基于lmc库提供服务管理、协程/任务管理、消息通讯功能，支持lua基础类型封装、lua Actor模型能力，提供服务管理接口测试能力。 #131 #132 #133 #134 #135 #136
- **C++映射器库能力**：支持集合资源自动分页控制、消息/错误处理、资源协作接口权限管理、子任务（SubTasks）机制、免鉴权认证、安全文件函数、IgnoreEtags定制、上下文管理、框架日志接口、首次登录修改密码、板间通信会话区分节点板、历史问题重构。 #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 #30 #31
- **IPMI SOL转发**：支持通过标准IPMI命令设置/查询SOL Payload端口，支持SOL Activate Payload命令返回用户配置的端口。 #388
- **组件循环依赖解决**：解决ipmi\_core组件与bmc\_network组件间循环依赖。 #408
- **主备状态上全局变量**：支持主备状态上全局变量。 #402
- **系统上下电状态上全局变量**：基础服务支持通用属性系统上下电状态上到全局变量。 #76
- **恢复初始IP原子能力**：资源协作接口提供恢复初始IP原子能力。 #405
- **国际证书管理**：支持国际证书资源协作接口管理，包括通信证书管理、导出CSR、导入证书能力。 #393
- **内存CE统计**：支持MemoryMetrics资源内存CE统计属性，满足IPMI、Redfish RAS相关规范。 #392 #936
- **数据采集导出接口**：新增导出数据采集信息的WebRest接口，触发BMC后端调用metric\_analyzer组件导出采集数据压缩包。 #999
#### 运维管理
- **错峰上电**：支持各节点之间按照槽位进行延时实现错峰上电，避免同时上电对电源的冲击。 #423
- **看门狗设置**：支持redfish设置看门狗使能状态和超时动作（FunctionEnabled、TimeoutAction）。 #928
- **中文event定义**：redfish接口支持中文event定义信息查询，Description、Message、Severity等字段展示为中文。 #929
- **传感器事件删除**：web界面支持删除传感器事件按钮。 #422
- **PSU与TPSU兼容**：支持canbus协议对TPSU和PSU电源板协议兼容性适配，支持电源信息获取、告警、黑匣子及电源升级。 #265
- **RAID卡告警增强**：支持自研RAID卡PCA9555访问失败告警和电源故障告警。 #631
- **BIOS日志与状态**：支持BIOS通过IPMI命令记录维护日志、SystemStartupState变化记录日志、增加全局变量表征BIOS启动状态、Bios PFR可定位性增强。 #162 #159 #163 #164
- **基础调速过程数据获取**：支持获取PID和异常转速计算后的数据，用于管理板汇总主/从控数据进行计算。 #191
### 标准：规范落地
#### 接口协议标准化
- **Redfish标准兼容**：指标定义、指标报告、指标报告上报内容兼容redfish标准内容，支持通过Oem属性切换到redfish标准形式。 #912
- **集合资源自动分页控制**：支持控制redfish集合资源自动分页能力，保持历史兼容性。 #913 #20
- **Port资源Oem补齐**：redfish接口Port资源补齐Oem相关实现，与NetworkPort资源已实现的Oem属性保持一致。 #938
- **Job支持OperationApplyTime**：创建和查询Job支持OperationApplyTime，支持对应调度。 #911
#### 测试与质量保障
- **测试资产整理**：完成社区开源测试用例整理、开发者贡献用例归档、QA仓库目录与文件整理。 #227 #233
- **冒烟测试流水线对接**：支持冒烟测试用例流水线对接社区每日构建流水线，自动完成冒烟测试并输出结果报告。 #243
- **IT测试资源树接口覆盖率提升**：补充开发者IT测试用例，增加资源树接口覆盖率。 #213
* * *
## 源代码
26.09版本源代码已发布至社区网站：https://openubmc.cn/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 5.15.0 | 5.14.0 | 5.13.0 | 5.12.0 | 5.11.0 |
| --- | --- | --- | --- | --- | --- |
| 26.09 | Y | N | N | N | N |
| 26.06 | Y | Y | Y | N | N |
| 26.03 | N | Y | Y | Y | N |
| 25.12 | N | N | N | Y | Y |
| 25.09 | N | N | N | N | Y |
备注：SDK中的部分二进制以源码形式开放到社区，`openUBMC 26.09` 与 `5.14.0 SDK` 配套时无法做到完全兼容。在该配套场景下，社区对 `libmgmt_protocol`、`compute` 组件的修改将无法生效。详见论坛 Topic 《openUBMC 26.09 与 SDK 配套兼容性说明》。
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 4104349 | 使用redfish接口设置自定义用户权限失败 | account |
* * *
## 已修复问题
本版本已修复问题清单（部分）：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 4381659 | 一键收集日志创建/var/log/netcard目录失败 | network_adapter |
| 4376537 | 先导入备用证书，再导入主证书，nginx启动失败 | nsm |
| 3859066 | OCP网卡Type属性配置错误 | vpd |
| 4032010 | 硬盘故障/预故障在BMC复位场景误恢复 | storage |
| 3820500 | 网卡卸载时，未在stop函数里停掉相关的timer任务 | component_drivers |
| 4089694 | 修复带内上报拓扑信息没有设置上限的问题 | pcie_device |
| 3878208 | 解决BMC启动时网页BBU状态跳变问题 | rackmonut |
| 4109892 | bmc启动时主动清除一次事件 | fructrl |
| 4101747 | EXU 12V — DescArg 显示原始 ADC（如 1823 V） | libmcpp |
| 4070324 | EthernetInterfaces资源Links下的Ports的@odata.id配置错误 | rackmount |
| 4087729 | BMA正常运行时，redfish查询GPU信息，"GPUUsagePercent"和"MemoryUsagePercent"值一直为0 | general_hardware |
| 4087729 | 修复空定制化且SystemProductName不为空时，SystemProductName变化 | frudata |
| 4099359 | 解决journal_export服务在退出时崩溃问题 | rootfs_user |
* * *
## CVE 漏洞
本版本已修复的CVE漏洞：
| 漏洞编号 | 漏洞描述 |
| --- | --- |
| CVE-2026-69186 | The DNS name decompression parser of c-ares does not limit the recursion/iteration depth when processing DNS responses containing compressed pointer chains. An attacker can trigger an unbounded loop by sending a malicious DNS response, causing a CPU exhaustion denial of service. |
| CVE-2026-69184 | The DNS name decompression parser of c-ares does not limit the recursion/iteration depth when processing DNS responses containing compressed pointer chains. An attacker can trigger an unbounded loop by sending a malicious DNS response, causing a CPU exhaustion denial of service. |
| CVE-2026-33630 | A vulnerability was found in c-ares related to a use-after-free condition in the ares_getaddrinfo function. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code, impacting availability. |
## OPEN SOURCE SOFTWARE NOTICE
Open Source Software Notice
## 接口 API 变更
### 资源协作接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| 资源协作接口 bmc.kepler.Managers.SOC温度属性签名变更 | >> 变更详细说明 |
### 北向接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| Redfish接口创建Volume请求体必选参数缺失时的响应变更 | >> 变更详细说明 |
| redfish接口Drive资源patch请求取值无效时的响应变更 | >> 变更详细说明 |
| redfish接口遥测资源查询响应及事件报文格式变更 | >> 变更详细说明 |
| redfish接口NetworkPort和Port资源关于FC网卡WWN顺序变更 | >> 变更详细说明 |
| DPU/SDI卡在WEB页面显示位置调整 | >> 变更详细说明 |
| 设置延迟上电IPMI命令的配置锁定策略变更 | >> 变更详细说明 |
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/version/latest/
---
文档中心
版本说明
版本选择
# openUBMC 26.09 版本发布说明
2026/09/30
# openUBMC 26.09 版本发布说明
* * *
## 版本概览
作为26年第3个创新版本，openUBMC 26.09 采用木兰宽松许可证 2.0（Mulan PSL v2），用户可以自由复制、使用、修改、分发。
* * *
## 版本特性
26.09版本在26.06版本基础上进行开发，特性交付范围包括：
### 易用性：工具链、开发体验与可视化配置全面升级
#### BMC Studio IDE 能力增强
- **代码仓类型识别**：支持自动识别manifest产品配置仓、mdb\_interface接口配置仓、rackmount北向接口配置仓及业务组件仓，并基于类型提供可执行操作。
- **出包配置可视化**：支持可视化编辑manifest.yaml，自动检测SDK版本及组件列表，提供组件依赖联想、特性开关可视化配置，出包时展示固件包信息概览（组件列表、版本、特性开关、SDK版本）。
- **hpm包一键升级**：支持在hpm文件上右键选择“升级到环境”，可一次升级到多个环境，后台执行并显示进度与结果。
- **BMC环境管理**：支持配置BMC环境（IP、用户名、密码加密存储），一键打开SSH/Telnet终端及网页，在线状态检测与变更提醒。
- **CSR门禁屏蔽**：支持通过注释方式屏蔽CSR门禁错误，并支持在错误问题上点击按钮一键屏蔽。
- **阈值传感器告警掩码校验**：当AssertMask、DeassertMask、ReadingMask配置与上下限规则不符时给出错误提示，并说明正确值及原因。
- **白牌定制配置可视化**：支持web\_custom.xml文件的可视化配置界面，图片内容可预览并显示说明信息。
- **智能问答**：集成社区知识库与故障案例库，实现问题快速定位定界与AI辅助BMC开发能力。
- **日志分析能力**：支持导入一键收集日志解析整机CSR拓扑及查看CSR文件内容；支持通过日志信息结合AI能力产出事件告警触发链条分析报告。
#### 构建工具链与工程能力
- **bingo支持OpenEuler+Kunpeng环境**：支持在OpenEuler+Kunpeng环境下安装、升级及编译bingo依赖的二进制文件。 #223
- **OEE+Hi3095构建支持**：bingo支持基于OEE+Hi3095的组件构建、升级包构建及SDK发布包产品构建，支持OEE+Aspeed烧片包构建。 #209 #210 #230 #231
- **产品构建组件替换**：支持产品构建时通过配置对平台组件进行覆写替换，并在替换时提供醒目提示。 #232
- **ASan扫描能力**：bingo test支持ASan扫描识别C/CPP代码内存问题，支持通过代码注释方式屏蔽扫描结果。 #211 #212
- **clang-tidy错误检查**：社区C/CPP组件支持基于clang-tidy的错误检查。 #225
#### 文档与知识体系建设
- **组件文档说明**：为bingo、manifest、mctpd、hwdiscovery、hwproxy、runtime\_accessor、liblogger、libsomp、libmc4lua、iam/libiam、account等组件/lib库建立完整文档体系，包括组件概述、API使用说明和示例、扩展案例、日志说明、问题定界指南及FAQ。 #215 #297 #795 #796 #829 #830 #831 #832 #846 #851 #853 #212 #214
- **开发指导文档**：新增Hi1712芯片构建指导、开发环境初始化配置文档、快速新增一个产品教程、拆包解析能力定制指导、IPMI通道（bt、ipmb）不通定位指导。 #793 #794 #799 #836 #837
- **AI辅助扫描流水线**：支持AI辅助日志规范扫描和安全规范扫描，支持组件级和版本级扫描，版本级扫描结果归档为html报告。 #299 #300
#### 社区治理与流程规范
- **Issue/PR提交规范校验**：需求issue必须包含简要说明、系统用户、前置条件、主成功场景、扩展场景、兼容性影响评估；缺陷issue必须包含预置条件、操作步骤、结果描述、预期结果、受影响版本、问题优先级；PR提交时自动检查模板合规性。 #185
- **Issue状态精简**：删除“转测中”状态，需求代码合入转测后直接从“开发中”走到“待验收”。 #194
- **编码风格可视化**：社区代码仓支持基于pre-commit机制的编码风格检查，C/CPP代码仓生效clang-format，Python代码仓生效Ruff，JS代码仓配置.prettierrc。 #296
- **RAG对外查询接口**：开放 RAG 相关接口，支持用户通过 MCP 访问 RAG 系统，获取 openUBMC 知识上下文。 #166
### 丰富度：硬件生态、部件管理与平台能力拓展
#### 异构计算与PCIe管理
- **PCIe设备RAS原子能力**：支持PCIe设备上报故障时识别设备BDF，已知BDF汇聚到PCIeCollector，未知BDF汇聚到UnknownPCIeCollector。 #385
- **DPU独立分类显示**：支持DPU在BMC WEB界面单独分类显示，不再混在PCIe设备界面。 #909 #414
- **NPU模组管理增强**：支持NPU模组电源告警精确解析和上报、HBM冗余资源实时监控和资源不足告警。 #359 #368
- **NPU参数面光模块控制**：支持通过Redfish接口实现NPU参数面光模块灭灯/恢复亮灯操作。 #399
#### 存储与硬盘管理
- **SMART信息获取增强**：支持NVMe盘组硬Raid后带外获取SMART信息、Redfish接口获取SATA盘SMART信息、Redfish接口获取NVMe盘标准SMART信息。 #414 #416 #937
- **SMART日志采集与导出**：支持自研RAID下SATA盘和直通NVMe盘的SMART日志定时采集、存储与导出，支持Web前端硬盘日志收集按钮。 #417 #428
- **硬盘时间同步**：支持自研RAID下SAS/SATA SSD盘时间同步功能，在盘第一次识别加载、盘更换、系统上下电时同步。 #422
#### 网卡与网络适配
- **光模块门限值采集**：光模块静态文件增加门限值，日志采集包含对应门限值。 #352
- **光模块告警实现优化**：支持网卡光模块各通道告警通过CSR配置实现，删除软件告警，提升扩展性。 #456
- **光模块指标定义**：redfish遥测支持光模块相关指标定义（MetricDefinition），包括RxInputPower和TxBiasCurrent。 #630
#### 固件升级与管理
- **Krun固件升级**：复用BIOS固件升级方式，支持通过SPI接口升级Krun固件。 #151
- **本地固件仓管理**：支持本地固件仓固件的添加、更新、删除与生效，支持本地固件仓容量查询，并支持检测本地固件仓版本与运行固件版本的一致性。 #908 #387#947 #404
- **VRD自愈能力**：VRD升级成功后备份升级包，检测到VRD异常时使用备份包重新升级尝试自愈。 #379
- **CPLD JTAG扫链巡检**：支持天池单板通过JTAG链路进行CPLD扫链巡检，验证CSR配置与实际硬件一致性。 #378
#### 平台基础能力
- **libmcpp框架能力**：支持基于lmc库提供服务管理、协程/任务管理、消息通讯功能，支持lua基础类型封装、lua Actor模型能力，提供服务管理接口测试能力。 #131 #132 #133 #134 #135 #136
- **C++映射器库能力**：支持集合资源自动分页控制、消息/错误处理、资源协作接口权限管理、子任务（SubTasks）机制、免鉴权认证、安全文件函数、IgnoreEtags定制、上下文管理、框架日志接口、首次登录修改密码、板间通信会话区分节点板、历史问题重构。 #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 #30 #31
- **IPMI SOL转发**：支持通过标准IPMI命令设置/查询SOL Payload端口，支持SOL Activate Payload命令返回用户配置的端口。 #388
- **组件循环依赖解决**：解决ipmi\_core组件与bmc\_network组件间循环依赖。 #408
- **主备状态上全局变量**：支持主备状态上全局变量。 #402
- **系统上下电状态上全局变量**：基础服务支持通用属性系统上下电状态上到全局变量。 #76
- **恢复初始IP原子能力**：资源协作接口提供恢复初始IP原子能力。 #405
- **国际证书管理**：支持国际证书资源协作接口管理，包括通信证书管理、导出CSR、导入证书能力。 #393
- **内存CE统计**：支持MemoryMetrics资源内存CE统计属性，满足IPMI、Redfish RAS相关规范。 #392 #936
- **数据采集导出接口**：新增导出数据采集信息的WebRest接口，触发BMC后端调用metric\_analyzer组件导出采集数据压缩包。 #999
#### 运维管理
- **错峰上电**：支持各节点之间按照槽位进行延时实现错峰上电，避免同时上电对电源的冲击。 #423
- **看门狗设置**：支持redfish设置看门狗使能状态和超时动作（FunctionEnabled、TimeoutAction）。 #928
- **中文event定义**：redfish接口支持中文event定义信息查询，Description、Message、Severity等字段展示为中文。 #929
- **传感器事件删除**：web界面支持删除传感器事件按钮。 #422
- **PSU与TPSU兼容**：支持canbus协议对TPSU和PSU电源板协议兼容性适配，支持电源信息获取、告警、黑匣子及电源升级。 #265
- **RAID卡告警增强**：支持自研RAID卡PCA9555访问失败告警和电源故障告警。 #631
- **BIOS日志与状态**：支持BIOS通过IPMI命令记录维护日志、SystemStartupState变化记录日志、增加全局变量表征BIOS启动状态、Bios PFR可定位性增强。 #162 #159 #163 #164
- **基础调速过程数据获取**：支持获取PID和异常转速计算后的数据，用于管理板汇总主/从控数据进行计算。 #191
### 标准：规范落地
#### 接口协议标准化
- **Redfish标准兼容**：指标定义、指标报告、指标报告上报内容兼容redfish标准内容，支持通过Oem属性切换到redfish标准形式。 #912
- **集合资源自动分页控制**：支持控制redfish集合资源自动分页能力，保持历史兼容性。 #913 #20
- **Port资源Oem补齐**：redfish接口Port资源补齐Oem相关实现，与NetworkPort资源已实现的Oem属性保持一致。 #938
- **Job支持OperationApplyTime**：创建和查询Job支持OperationApplyTime，支持对应调度。 #911
#### 测试与质量保障
- **测试资产整理**：完成社区开源测试用例整理、开发者贡献用例归档、QA仓库目录与文件整理。 #227 #233
- **冒烟测试流水线对接**：支持冒烟测试用例流水线对接社区每日构建流水线，自动完成冒烟测试并输出结果报告。 #243
- **IT测试资源树接口覆盖率提升**：补充开发者IT测试用例，增加资源树接口覆盖率。 #213
* * *
## 源代码
26.09版本源代码已发布至社区网站：https://openubmc.cn/download
* * *
## 版本兼容说明
| openUBMC/BMC_SDK | 5.15.0 | 5.14.0 | 5.13.0 | 5.12.0 | 5.11.0 |
| --- | --- | --- | --- | --- | --- |
| 26.09 | Y | N | N | N | N |
| 26.06 | Y | Y | Y | N | N |
| 26.03 | N | Y | Y | Y | N |
| 25.12 | N | N | N | Y | Y |
| 25.09 | N | N | N | N | Y |
备注：SDK中的部分二进制以源码形式开放到社区，`openUBMC 26.09` 与 `5.14.0 SDK` 配套时无法做到完全兼容。在该配套场景下，社区对 `libmgmt_protocol`、`compute` 组件的修改将无法生效。详见论坛 Topic 《openUBMC 26.09 与 SDK 配套兼容性说明》。
* * *
## 已知问题
本版本问题清单：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 4104349 | 使用redfish接口设置自定义用户权限失败 | account |
* * *
## 已修复问题
本版本已修复问题清单（部分）：
| ISSUE ID | 问题描述 | 关联仓库 |
| --- | --- | --- |
| 4381659 | 一键收集日志创建/var/log/netcard目录失败 | network_adapter |
| 4376537 | 先导入备用证书，再导入主证书，nginx启动失败 | nsm |
| 3859066 | OCP网卡Type属性配置错误 | vpd |
| 4032010 | 硬盘故障/预故障在BMC复位场景误恢复 | storage |
| 3820500 | 网卡卸载时，未在stop函数里停掉相关的timer任务 | component_drivers |
| 4089694 | 修复带内上报拓扑信息没有设置上限的问题 | pcie_device |
| 3878208 | 解决BMC启动时网页BBU状态跳变问题 | rackmonut |
| 4109892 | bmc启动时主动清除一次事件 | fructrl |
| 4101747 | EXU 12V — DescArg 显示原始 ADC（如 1823 V） | libmcpp |
| 4070324 | EthernetInterfaces资源Links下的Ports的@odata.id配置错误 | rackmount |
| 4087729 | BMA正常运行时，redfish查询GPU信息，"GPUUsagePercent"和"MemoryUsagePercent"值一直为0 | general_hardware |
| 4087729 | 修复空定制化且SystemProductName不为空时，SystemProductName变化 | frudata |
| 4099359 | 解决journal_export服务在退出时崩溃问题 | rootfs_user |
* * *
## CVE 漏洞
本版本已修复的CVE漏洞：
| 漏洞编号 | 漏洞描述 |
| --- | --- |
| CVE-2026-69186 | The DNS name decompression parser of c-ares does not limit the recursion/iteration depth when processing DNS responses containing compressed pointer chains. An attacker can trigger an unbounded loop by sending a malicious DNS response, causing a CPU exhaustion denial of service. |
| CVE-2026-69184 | The DNS name decompression parser of c-ares does not limit the recursion/iteration depth when processing DNS responses containing compressed pointer chains. An attacker can trigger an unbounded loop by sending a malicious DNS response, causing a CPU exhaustion denial of service. |
| CVE-2026-33630 | A vulnerability was found in c-ares related to a use-after-free condition in the ares_getaddrinfo function. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code, impacting availability. |
## OPEN SOURCE SOFTWARE NOTICE
Open Source Software Notice
## 接口 API 变更
### 资源协作接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| 资源协作接口 bmc.kepler.Managers.SOC温度属性签名变更 | >> 变更详细说明 |
### 北向接口变更
| 变更说明 | 变更详情 |
| --- | --- |
| Redfish接口创建Volume请求体必选参数缺失时的响应变更 | >> 变更详细说明 |
| redfish接口Drive资源patch请求取值无效时的响应变更 | >> 变更详细说明 |
| redfish接口遥测资源查询响应及事件报文格式变更 | >> 变更详细说明 |
| redfish接口NetworkPort和Port资源关于FC网卡WWN顺序变更 | >> 变更详细说明 |
| DPU/SDI卡在WEB页面显示位置调整 | >> 变更详细说明 |
| 设置延迟上电IPMI命令的配置锁定策略变更 | >> 变更详细说明 |
## 致谢
我们衷心感谢参与openUBMC项目的所有社区开发者，正是因为你们的参与才能使得此版本顺利发布，为openUBMC更好的发展迈出了第一步。
\[Copyright\] Copyright © 2026 openUBMC Community. This article was first published by the openUBMC Community. Reproduction is welcomed under CC-BY-SA 4.0. When reproducing, please prominently note the source in the text and retain the original article link and author information.
\[Disclaimer\] The views expressed in this article are solely those of the author and do not represent the stance of this website. This website remains neutral regarding the statements and opinions presented and provides no express or implied warranty as to the accuracy, reliability, or completeness of the content. This article is intended for reference only, and all legal responsibilities arising therefrom shall be borne by the reader.
---
https://www.openubmc.cn/zh/vulnerability-management/
---
Security Center
Vulnerability Management
# Vulnerability Management
2025/03/30
openUBMC
# 漏洞管理
## 1\. 漏洞响应
openUBMC 社区非常重视社区版本的安全性，openUBMC 社区安全小组（SIG Security）负责接收、调查和披露 openUBMC 社区相关的安全漏洞。我们鼓励漏洞研究人员和行业组织主动将 openUBMC 社区的疑似安全漏洞报告给 openUBMC 社区安全小组。我们会快速的响应、分析和解决上报的安全问题或安全漏洞。
## 2\. 支持版本
漏洞响应流程主要支持 openUBMC 社区的发行版。
## 3\. 漏洞处理流程
每一个安全漏洞都会有一个指定的人员进行跟踪和处理，协调员是 openUBMC 安全小组的成员，他将负责跟踪和推动漏洞的修复和披露。漏洞端到端的处理流程如下图。
在这里我们主要介绍流程中漏洞上报、漏洞评估和漏洞披露这三部分内容。
### 3.1 漏洞上报
如果您认为 openUBMC 产品存在一个疑似安全漏洞，我们希望您将漏洞上报给 openUBMC 社区，并与我们配合以负责任的方式修复和披露该问题。
#### 3.1.1 漏洞上报方式
您可以通过 email 将 openUBMC 产品的潜在安全漏洞发送到 openUBMC 安全小组邮箱（securities@public.openubmc.cn）。因为漏洞信息比较敏感，为确保机密性，建议您使用安全团队邮箱PGP 公钥对邮件信息进行加密。我们能够收到使用 OpenPGP 加密的电子邮件。安全小组成员信息如下：
- 张超\[@TacoJay\]，zhangchao60@huawei.com
- 鄢川杰\[@loopvoid\]，yanchuanjie@huawei.com
- 彭祥麟\[@Free\_Tomato\]，pengxianglin2@huawei.com
- 任山\[@Renyqing\]，renshan2@huawei.com
#### 3.1.2 漏洞上报内容
为了便于快速的确认和验证疑似漏洞，请在漏洞上报邮件中包含但不限于以下内容：
- 基本信息：包括漏洞影响的模块、漏洞的触发条件和成功利用后对系统的影响等。
- 技术细节：包括系统配置、定位方法、Exploit 的描述、POC、问题重现方法和步骤等。
- 修复方案建议。
- 上报者的组织和联系方式。
- 上报者可能的漏洞披露计划。
#### 3.1.3 邮件响应时间
我们将在 5 天内响应通过邮箱上报的疑似安全漏洞，并向上报者反馈漏洞处理的进展。
### 3.2 漏洞严重性评估
业界普遍使用 CVSS 标准评估漏洞的严重性，openUBMC 在使用 CVSSv3 进行漏洞评估时，需要设定漏洞攻击场景，基于在该攻击场景下的实际影响进行评估。漏洞严重等级评估是指针对漏洞利用难易程度，以及利用后对机密性、完整性、可用性的影响进行评估，并生成一个评分值。
#### 3.2.1 评估标准
openUBMC 社区采用 CVSS v3 对漏洞进行评估，CVSS V3 由通过对以下向量来评估一个漏洞的影响：
- 攻击向量（AV）-表示攻击的“远程性”以及如何利用此漏洞。
- 攻击复杂性（AC）-讲述攻击执行的难度以及成功进行攻击需要哪些因素。
- 用户交互（UI）-确定攻击是否需要用户参与。
- 所需的权限（PR）-记录成功进行攻击所需的用户身份验证级别。
- 范围（S）-确定攻击者是否可以影响具有不同权限级别的组件。
- 机密性（C）-衡量信息泄露给非授权方后导致的影响程度。
- 完整性（I）-衡量信息被篡改后导致的影响程度。
- 可用性（A）-衡量用户在需要访问数据或服务时受影响的程度。
#### 3.2.2 评估原则
- 评估漏洞的严重等级，不是评估风险。
- 评估时必须基于攻击场景，且保证在该场景下，攻击者成功攻击后能对系统造成机密性、完整性、可用性影响。
- 当安全漏洞有多个攻击场景时，应以造成最大的影响，即 CVSS 评分最高的攻击场景为依据。
- 被嵌入调用的库存在漏洞，要根据该库在产品中的使用方式，确定漏洞的攻击场景后进行评估。
- 安全缺陷不能被触发或不影响 CIA（机密性/完整性/可用性），CVSS 评分为 0 分。
#### 3.2.3 评估步骤
对漏洞进行评估时，可根据下述步骤进行操作：
- 设定可能的攻击场景，基于攻击场景评分。
- 确定漏洞组件（Vulnerable Component）和受影响组件（Impact Component）。
- 选择基础评估指标的值：通过对可利用指标（攻击向量/攻击复杂度/所需权限/用户交互/范围）和受影响指标（机密性/完整性/可用性）给出漏洞影响评估。
#### 3.2.4 严重等级划分
| 严重等级（Severity Rating） | CVSS评分（Score） |
| --- | --- |
| 致命（Critical） | 9.0 - 10.0 |
| 高（High） | 7.0 - 8.9 |
| 中（Medium） | 4.0 - 6.9 |
| 低（Low） | 0.1 - 3.9 |
| 无（None） | 0.0 |
### 3.3 漏洞披露
为了保护 openUBMC 用户的安全，在进行调查、修复和发布安全公告之前，openUBMC 社区会严格控制漏洞信息的范围，将之限制在仅处理漏洞的相关人员之间传递，不会公开披露、讨论或确认 openUBMC 产品的安全问题，同时也要求漏洞上报者对此漏洞进行保密，直到对外公开披露。安全漏洞修复后 openUBMC 社区会发布安全公告，安全公告内容包括该漏洞的技术细节、CVE 编号、CVSS 安全评分、严重性等级以及受到该漏洞影响的版本和修复版本等信息。安全公告提供邮件订阅功能，您可以通过“security”链接订阅 openUBMC 社区的安全公告。
Content on This Page
---
https://www.openubmc.cn/zh/whitepapers/
---
# 白皮书
了解openUBMC技术详情及行业生态现状、业务场景的应用
Coming soon
# openUBMC — Full Documentation
> openUBMC 是一款架构领先、开发友好、遵循开放标准的算力设备开源管理软件。
> openUBMC is an open-source BMC management software with leading architecture, developer-friendly design, and open standard compliance.
---
# 下层平台依赖管理方案
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/Lower_level_platform_management.html
> Language: zh
# 下层平台依赖管理方案
本文记录外部依赖管理的思路。
## 1. 问题
openUBMC的构建依赖各种外部制品，常见方式是CMC依赖下层平台制品和构建工具，在日常过程中会遇到下层平台版本号未变更但制品变更的场景。
外部制品不可控带来如下影响：
1. 下层平台不可控
2. 下层平台变更低感知
3. 版本处于一种不确定状态，可能影响重复构建
## 2. 思路
下层平台管理生成的制品需要有文件指纹校验，在构建系统中使用文件清单记录文件SHA256值，只有经过文件清单校验的外部制品才能进入构建系统，不能通过检查的将报告失败。
上述思路的好处在于外部的依赖在代码仓中可管控、能记录，降低外部变更的影响。
## 3. 实现方案
借助ArtGet定义的XML文件，将需要校验的文件SHA256值写入对应XML文件中。当通过XML文件下载依赖制品后，根据XML文件中的文件SHA256值与实际的文件SHA256值进行对比，当有文件SHA256值对比不一致时，报告失败并终止构建。
对于需要校验的制品，在XML的对应`copy`标签下新增`verifyFiles`标签，其中包含1~N个`file`标签，`file`标签内容包括文件名和SHA256值。
XML文件中hash值示例：
```xml
/foo/bar/file.zip
foo/bar/
file.zip
xxxxx
...
/foo
/
file.zip
xxxxx
file.tar.gz
xxxxx
```
## 4. 影响
1. 按上述思路整改后，引入新的平台版本时不仅是修改版本号，还需要申明或修改下载的文件SHA256值，如引入的平台制品变更将因文件校验失败而构建失败。
2. 当将XML文件归档到构建的制品包中时，需要先删除XML文件中的自定义`verifyFiles`标签。
---
# 构建制品定制化方案
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/build_customized_products.html
> Language: zh
构建采用 **组件自申明、集成时赋权** 策略管理组件生成的文件，该策略要求组件生成的文件都由一个permissions.ini文件申明需要的权限，由构建系统在组件集成环节解析permissions.ini文件完成文件赋权。
## 为什么要使用组件自申明、集成时赋权策略
一个产品往往包含开源、平台、芯片、自研软件等各种软件，实践表明产品权限管理存在漏赋权、重复赋权、管理困难等，为此产生了“赋权不一定要准确，可以忽略错误”的做法，最终导致很多漏到后端测试。
Openubmc所有权限由组件自主申明，赋权文件会强制检查所有赋权操作是否正确执行，按错误即失败原则处理，实现**左移**。
> [!WARNING]
> openubmc要求赋权100%准确，会检测每一条命令执行结果，如遇失败即报错退出。
> 有授权记录但无被授权文件的会报构建失败；对有文件但无授权记录的由测试团队的脚本检查并提单。
## 如何操作
组件的制品权限管理包含四种方式：
1. 静态配置权限：构建任意场景都会生成的文件由代码仓打包的permissions.ini文件描述。
2. 动态配置权限：构建时按特性选项生成的文件由conanfile.py动态生成permissions.ini文件。
3. 组件定制化配置权限：组件构建时不生成，产品集成时由组件定制化脚本生成的文件由定制化脚本赋权。
4. 产品定制化配置权限：产品对通用权限有不同要求的由产品定制化脚本赋权。
### 静态配置权限
组件源码目录存储一个静态permissions.ini文件，每一行记录一个文件/文件夹权限，格式要求为`name type mode uid gid`，支持对指定文件、指定目录、递归指定目录下的文件、递归指定目录下的目录赋权，下面是iam模块的示例。
```yaml
# syntax documentation
# format: name type mode uid gid
# name is the path to the file you want to create/modify
# type is the type of the file, being one of:
# f: a regular file
# d: a directory
# r: a directory recursively
# rd: a directory recursively, only subdirectory effectivity
# mode are the usual permissions settings (only numerical values are allowed)
# name is the path to the file you want to create/modify
opt/bmc/apps/iam rd 550 0 0
opt/bmc/apps/iam r 440 0 0
etc/systemd/system/iam.service f 640 0 0
etc/rc.d/rc.start/init_user.sh f 550 0 0
etc/weakdictionary f 640 0 0
```
> [!TIP]
> 组件构建时打包源码目录下的permissions.ini文件至打包目录。
### 动态配置权限
静态配置的permissions.ini文件只适配于必然会生成和打包的文件，实际应用中可能因为特性开关状态产生不同的文件，此时就需要动态生成permissions.ini文件。
conan的特性控制是由options完成，一个典型的应用示例是在组件的conanfile.py的build方法中判断是否使能或关闭某个特性并将动态赋权内容追加到permissions.ini文件。
以下示例演示了gcov选项未使能时向permissions.ini文件追加了`opt/bmc/apps/example/yy f 550 0 0`赋权内容。
```python
class IamConan(ConanBase):
def build(self):
super().build()
if not self.options.gcov:
with open("permissions.ini", "a+") as fp:
fp.write("\nopt/bmc/apps/example/yy f 550 0 0")
```
> [!TIP]
> 示例仅演进功能，赋权内容要跟构建制品逻辑100%匹配，请以实际特性状态和文件生成逻辑为准。
### 组件定制化配置
某些场景组件对其它组件/平台提供的文件有权限诉求的，如果这种诉求与组件存在100%关联，即组件存在，该文件必须存在且权限满足要求的，可以使用组件定制化配置权限。
该方式依赖组件定制化功能，该功能为组件提供了在特定阶段注入一段python代码的能力，其基础原理是由组件管理一个`build/customization.py`文件，构建时打包到include目录，产品构建时会搜索该文件并执行。
当前支持组件在三个阶段进行定制化，按照执行阶段顺序分为`post_image` -> `post_rootfs` -> `post_hpm`，组件按需配置各个阶段的定制化。
- `post_image` - 所有组件合并为组件镜像后执行，其中定制化脚本类`rootfs_path`参数为组件镜像目录。使用场景：对组件镜像的文件进行软链接、权限设置或其他定制化操作。
- `post_rootfs` - 组件镜像和rtos、sdk合并为rootfs镜像后执行，其中定制化脚本类`rootfs_path`参数为rootfs镜像目录。使用场景：对非组件的文件（rtos自带文件）进行定制化操作（软链接、权限设置、删除、更改内容等）。
- `post_hpm` - 制作hpm前执行，其中定制化脚本类`rootfs_path`参数为hpm包制作目录。一般组件不涉及，属于特殊场景。
以下示例用于演示了一种场景：某一组件要求/etc/passwd文件权限必须为600，该文件实际由rtos带入，为确保权限正确性，需要组件在post_rootfs(rootfs制作完成后)执行一段定制化脚本完成赋权。
```python
import subprocess
# 定制化脚本，由manifest构建时调用
class Customization(object):
def __init__(self, board_name, rootfs_path):
self.board_name = board_name
self.rootfs_path = rootfs_path
def post_rootfs(self):
subprocess.run(['/usr/bin/sudo', '/usr/bin/chmod', '600', '/etc/passwd'], check=True)
```
> [!attention]
>
> 1. 定制化配置请一定集成到版本构建中验证完成再上库。
> 2. 在`build/customization.py`脚本中不要import bmcgo相关代码，避免引起依赖。
### 产品定制化配置
如果组件提供的默认权限不符合极个别产品定制化要求，可以由产品定制化脚本自主完成权限控制。
该方式依赖产品manifest.yml文件记录的customization定制化脚本，该脚本会在多个阶段执行，一般权限定制放在rootfs_cust阶段即可，以下示例为产品定制化脚本动态创建`data/opt/bmc/web/custom`目录并赋权的示例：
```python
class Customization(BaseCustomization):
def rootfs_cust(self, rootfs_path):
self.work.run_command("mkdir -p data/opt/bmc/web/custom", sudo=True)
self.work.run_command("sudo chmod 750 data/opt/bmc/web/custom", sudo=True)
```
> [!attention]
定制化配置请一定验证存在性及权限正确后再上库
定制化验证步骤：
* 初步验证：构建`hpm`包完成后，在`temp`目录下，使用`find`命令去查找对应`build_type`和`stage`目录生成的文件或者修改权限的文件，如下：
```shell
[11:28:08 root(1110):/home/workspace/codehome/manifest]# find . -name custom | grep extern
./temp/build_Openubmc_debug_dev/tmp_root/opt/bmc/web/htdocs/extern/custom
./temp/build_Openubmc_debug_dev/buildimg/rtos_with_driver/rootfs/opt/bmc/web/htdocs/extern/custom
[11:28:12 root(1110):/home/workspace/codehome/manifest]# find . -name custom | grep extern | xargs ls -la
lrwxrwxrwx 1 root root 24 4月 1 10:47 ./temp/build_Openubmc_debug_dev/buildimg/rtos_with_driver/rootfs/opt/bmc/web/htdocs/extern/custom -> /data/opt/bmc/web/custom
lrwxrwxrwx 1 root root 24 4月 1 10:47 ./temp/build_Openubmc_debug_dev/tmp_root/opt/bmc/web/htdocs/extern/custom -> /data/opt/bmc/web/custom
[11:47:52 root(1110):/home/workspace/codehome/manifest]#
```
* 环境验证(开发者自行验证，不做示例)：在初步验证成功后，将`hpm`包升级到环境中，检查对应路径下的文件是否存在或符合预期权限要求
* 版本验证(开发者自行验证，不做示例)：需求完成后，上库并出版本以后，将版本包升级到环境，再次检查对应路径下文件是否存在或者符合预期权限要求
---
# 组件的构建与发布
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/build_process.html
> Language: zh
openUBMC采用`Conan`包管理器与`CMake`构建系统集成的方式，实现组件的独立构建和发布。`Conan`是一个`C`/`C++`构建框架，由命令、属性和方法构成，主要负责封装并对外提供一致的接口，并基于`Conan`仓库完成组件交付。`CMake`定义了如何从源代码生成可执行文件或库，主要任务是负责项目的构建过程。关于`CMake`的详细介绍请参考[Cmake官方文档](https://cmake.org/documentation/)；`Conan`的详细介绍请参考[Conan官方文档](https://docs.conan.io/en/1.6/introduction.html)。
openUBMC组件构建由`CMake`脚本`cmakelists.txt`和`Conan`脚本`conaninfo.py`、`conanfile.py`以及`conanbase.py`组成：
1. `cmakelists.txt`：`CMake`构建配置文件，用于定义项目的构建规则、依赖关系、编译选项等，简化项目的编译和构建过程。
2. `conaninfo.py`：定义了`Conan`基本信息，包括包名，版本号和git仓。
3. `conanbase.py`：定义了统一的`Conan`构建脚本。
4. `conanfile.py`：`Conan`脚本，继承自`conanbase.py`，可以重写`conanbase`的方法。
# CMake基本使用
`CMake`是一个开源的跨平台自动化建构系统，用来管理软件构建的程序，并不依赖于某特定编译器，并可支持多层目录、多个应用程序与多个函数库。
`CMake`的所有语句都写在一个`CMakeLists.txt`的文件中。`CMakeLists.txt`文件确定后，直接使用Cmake命令运行`CMakeLists.txt`所在的目录，CMake之后就会自动生成makefile文件，然后再直接make就可以编译出构建结果。
更简单的解释就是`CMake`是为了生成`Makefile`而存在，开发者不需要自己去写`Makefile`，只需要写简单的`CMakeLists.txt`即可。开发者可以在`CMakeLists.txt`中添加引用所需的`C`/`C++`库。
这里，以组件`new_app`的`CMakeLists.txt`为例，简单介绍openUBMC中用到的`CMake`指令：
```cmake
-- cmake最低版本需求
cmake_minimum_required(VERSION 3.14)
-- 设置项目名称，后面可添加支持的语言，默认是C和C++
project(new_app)
-- 查找PkgConfig模块，通过PkgConfig模块找到你想要找到的第三方库
find_package(PkgConfig REQUIRED)
-- 用于查找PkgConfig格式的库信息
pkg_search_module(GLIB REQUIRED glib-2.0)
...
-- 设置变量的值
set(TARGET_LIB ${PROJECT_NAME})
...
-- 指定安装时运行规则
install(DIRECTORY src/lualib DESTINATION ${APP_INSTALL_DIR} OPTIONAL)
...
```
若为定制组件，则在通用组件配置的基础上，新增定制组件构建项
```cmake
## customized resource deployment options
set(CUSTOMER new_app)
set(CUSTOM_INSTALL_DIR opt/bmc/extend/${CUSTOMER})
-- 定制仓所需的sr等文件/目录
install(DIRECTORY sr DESTINATION ${CUSTOM_INSTALL_DIR} OPTIONAL)
...
message(STATUS "new_app customized resource deployment is completed.")
```
# Conan基本介绍
`Conan`是一个开源的`C/C++`包管理器，用于下载、管理和构建项目所需的依赖库。简单来说，`Conan`可以作为包的使用者和包的创建者，它使用`conanfile.py`文件自动化实现构建出包。在openUBMC中，`Conan`与`CMake`构建工具集成实现项目的编译和构建。
`conanfile.py`文件需定义一个继承自`ConanFile`的类。这个类包括两个部分：属性和方法。属性用于设置一些只读信息而方法用于自动化打包的逻辑。在编写完`conanfile.py`文件之后，执行`Conan`工具的`conan create`命令会默认按照以下顺序自动执行conanfile类的方法：
```python
1. export()
2. export_sources()
3. config_options()
4. configure()
5. layout()
6. requirements()
7. package_id()
8. validate()
9. validate_build()
10. build_requirements()
11. build_id()
12. system_requirements()
13. source()
14. generate()
15. imports()
16. build()
17. package()
18. package_info()
```
这里简单介绍`conanbase`中定义的`export`、`generate`、`build`和`package`等方法。各方法的函数体功能简要介绍如下
```python
import os
import stat
import urllib3
from conans import ConanFile, CMake
from bingo.component.gen import GenComp
urllib3.disable_warnings()
class ConanBase(ConanFile):
name = "new_app" #定义包名
version = "0.0.1"
url = "https://www.huawei.com"
settings = "os", "compiler", "build_type", "arch" # 定义不同二进制包的配置。对操作系统、编译器、构建类型或架构定义的任何修改都将生成不同的二进制包。
generators = "cmake"
language = "lua"
_cmake = None
_codegen_version = 14
scm = {
"type": "git",
"url": "",
"revision": "auto"
}
options = { # 包特定的配置，可以在default_options中定义默认值
"asan": [True, False],
"gcov": [True, False],
"manufacture": [True, False],
}
default_options = {
"asan": False,
"gcov": False,
"manufacture": False,
}
def generate(self):
# 执行将创建一个映射Conan和CMake语法的conan_toolchain.cmake文件
...
# 构建时，此方法会自动生成export目录
def export(self):
# 此方法定义拷贝文件到export目录
...
def requirements(self):
# 引用组件的依赖包
...
# 构建时，此方法会自动生成build目录
def build(self):
# 主要调用了cmake下的build方法，相当于执行了cmake build命令，完成从预处理到链接的全部过程
...
cmake = self._configure_cmake()
cmake.build()
# 构建时，此方法会自动生成package目录
def package(self):
# 执行了cmake install命令，根据cmakelists.txt文件当中的install命令将编译生成后的文件移动到指定位置
cmake = self._configure_cmake()
cmake.install()
...
```
openUBMC的工程工具`bingo`在构建命令`bingo build`中集成了自动生成`conanbase.py`的功能。此文件定义了继承自`ConanFile`的类`conanbase`，并在此类中已实现基本的构建方法。因此，在各组件的conanfile.py文件中，只需定义继承自conanbase的类即可。若开发者需要自定义构建出包文件，可在`conanfile.py`文件定义的类中重写相关方法。
`conanfile.py`文件的`settings`字段定义了不同二进制包的配置。在此示例中，对操作系统、编译器、构建类型或架构定义的任何修改都将生成不同的二进制包。这些配置信息的值都统一存放于`profile`文件中。在执行构建时，`Conan`工具会根据设置的`–profile`参数获取配置文件中的所有信息，并应用于要构建或安装的软件包。如果没有指定该参数，相当于使用`–profile=default`进行调用。
在组件目录下执行命令构建包时，会生成以`<包名>/<版本>@<用户>/<渠道>`格式命名的`Conan`包。
可通过`conan cache path <组件名>`获取`Conan`生成的包所存在的具体目录，构建生成的每一个`Conan`包都会包含五个重要文件夹，每个文件夹都在`confile`类中有对应同名的方法。
- `e`: 用于存储包的文件夹，`export`方法的默认目标文件夹。
- `es`: 在`conanfile.py`文件定义的类中，使用`exports_sources`方法`copy`的文件默认存放于此文件夹中。
- `s`: 存储源码文件，`source`方法的默认目标文件夹。
- `b`: 完成实际源代码编译的文件夹，`build`方法的默认目标文件夹。
- `p`: 最终构建生成的包所在的文件夹，每个不同的二进制配置将有一个子文件夹。`package`方法的默认目标文件夹。
# 构建、发布
openUBMC的工程工具实现了`CMake`和`Conan`工具的相关文件自动生成。同时，支持CLI命令一键完成组件的构建，运行`bingo build`命令所执行的整个构建流程可以描述为：
1. 主动生成`conanbase.py`文件。组件的`conanfile.py`文件继承自`conanbase.py`定义的类`conanbase`。
2. 根据命令参数获取交叉编译所需的配置信息。
3. 清除组件锁文件，对于组件在`service.json`文件中未指明特定版本的依赖，使用最新版本的依赖包。
4. 执行`conan create`命令，依据`conanfile.py`文件实现构组件定制化构建出包。
`bingo build`命令的相关参数如下：
```shell
Build conan
optional arguments:
-h, --help show this help message and exit
-bt BUILD_TYPE, --build_type BUILD_TYPE
构建类型，可选：dt,debug,release
默认：debug
--stage STAGE 组件包发布阶段, 可选: dev(developer), pre, rc, stable
默认：dev
-r REMOTE, --remote REMOTE
conan仓别名，请检查conan remote list查看已配置的conan仓
默认: openUBMC_dev
-nc, --no_cache 不使用~/.conan/data目录下的缓存包(构建前删除缓存)
-o OPTIONS, --options OPTIONS
Define options values (host machine), e.g.: -o Pkg:with_qt=true
--user USER 指定conan包的user字段，尝试从/etc/bingo.conf文件读取conan.user字段，否则由程序管理
-as, --asan Enable address sanitizer
```
`bingo build`命令集成了`Conan`和`CMake`工具的使用，实现组件自动化编译出包。
开发者进行个人开发时，使用此命令生成的组件`Conan`包，将会发布并存放于本地的`root/.conan2/p`目录下。
---
# 构建工具管理
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/build_tools.html
> Language: zh
本文用于指导开发者管理组件特有的构建工具。
目前openubmc有特殊构建工具的组件主要是ai_engine（依赖flatbuffers）
## 说明
部分组件构建时需要使用特殊的构建工具，这些工具可能不在构建OS中并且一般针对专用场景，考虑到工具管理方式归一、持续演进（适配编译器、OS、芯片等），所有特有的构建工具请使用conan管理，原则上产品构工程和manifest仓将不再为特定app添加构建依赖。
## 基本逻辑
首先我们需要将工具conan化，在依赖工具的组件`conanfile.py`中添加`build_requirements`方法引入构建时的工具依赖。
ai_engine组件改造示例：
### STEP1: flatbuffers构建工具conan化
创建工具的conan包，这一步需要在`conan_index`仓中添加flatbuffers构建脚本，
工具一般需要对外呈现一个或一组命令，因此工具conan包最显著的特征是要在`package_info`方法中管理好自己的PATH环境变量，当构建依赖此工具的组件时（如ai_engine组件构建时）该变量会注入PATH环境变量以正确查找到需要的工具。
除此之外，工具包跟开源软件、平台软件等conan包没有区别，就是添加一个普通的conan组件，flatbuffers完整的conanfile.py示例。
```python
# Copyright © Huawei Technologies Co., Ltd. 2022-2025. All rights reserved.
from conans import ConanFile, tools, CMake
from conans.errors import ConanInvalidConfiguration
import os
required_conan_version = ">=1.42.0"
class FlatbuffersConan(ConanFile):
generators = "cmake"
homepage = "https://google.github.io/flatbuffers/"
description = "FlatBuffers is an efficient cross platform serialization library. "
chost = None
settings = "os", "compiler", "build_type", "arch"
exports_sources=["permissions.ini"]
_cmake = None
@property
def _source_subfolder(self):
return "source_subfolder"
def validate(self):
if self.settings.arch != "x86_64":
raise ConanInvalidConfiguration("Only x86_64 supported")
def source(self):
git = tools.Git(verify_ssl=False)
git.clone(**self.conan_data["sources"][self.version])
def _configure_cmake(self):
if self._cmake:
return self._cmake
self._cmake = CMake(self)
os.environ['CFLAGS'] = os.getenv('CFLAGS') + " -D_FORTIFY_SOURCE=2"
os.environ['CXXFLAGS'] = os.getenv('CXXFLAGS') + " -D_FORTIFY_SOURCE=2"
if self.settings.arch == "armv8" or self.settings.arch == "x86_64":
self._cmake.definitions["CMAKE_INSTALL_LIBDIR"] = "usr/lib64"
else:
self._cmake.definitions["CMAKE_INSTALL_LIBDIR"] = "usr/lib"
self._cmake.definitions["CMAKE_INSTALL_BINDIR"] = "usr/bin"
self._cmake.configure(args=["--no-warn-unused-cli"])
return self._cmake
def build(self):
cmake = self._configure_cmake()
cmake.build()
cmake.install()
def package_info(self):
self.env_info.PATH.append(os.path.join(self.package_folder, "usr", "bin"))
```
> [!NOTE]
> 上述示例最重要的是package_info方法将打包目录追加到PATH环境变量。
### STEP2：构建工具包
可以用`bmcgo build -t dependencies -cp flatbuffers/2.0.0 --verbose`命令构建出可用的版本。
正式发布需要使用CI工程
### STEP3：引入工具
conan提供了`build_requirements`方法管理构建依赖，我们只需要将需要的工具添加到依赖清单即可。
```python
import subprocess
class AppConan(ConanBase):
def build_requirements(self):
super(ConanBase, self).build()
# 由build_requires引入工具依赖
self.build_requires("flatbuffers/2.0.0@openubmc.dev/dev")
# 启动构建示例
def build(self):
# .... other 代码
# 调用flatc，此时会去flatbuffers设置的PATH环境变量中查找flatc可执行程序
subprocess.run(f"flatc -o {cml_save_path} -b {self.fbs_path}/CML.fbs {json_path}", shell=True)
```
### STEP4：构建
随后只需要构建出包（如ai_engine）即可，构建工具会自动下载，conan会自动设置工具带入的PATH环境变量。
---
# 调试工具管理
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/debug_tools.html
> Language: zh
在开发调试过程中预置一些调试功能和工具通常是有意义的，如预置telnet、gdb等，本文描述openubmc如何管理这些功能。
##
一个组件化的构建架构需要考虑扩展性，能够轻松适配不同OS、不同编译器甚至不同的芯片。采用二进制引入工具绝对不是一个明智的选择，所有非产品类的调试功能或工具建议按如下方式管理。
### 工具也是一个组件
调试工具应该以可源码构建的conan组件形式引入，支持可源码构建、支持交叉编译、自动依赖管理、构建工具（make/cmake/gcc等知名且通用的除外）自管理特性，这样做可以明显的好处包括：
1. 可追溯、可升级、支持交叉编译，为openubmc提供长期支持，广泛适用于各种场景，持续产生收益；
2. 维护openubmc组件化通用的和解耦的架构，维护扩展性和灵活性。
### 功能有开关
融入业务组件中的调试功能应该以特性形式控制可见范围，控制方式一般是构建类型(debug/release)，也可以根据需要扩展，不管如何都需要由conan包对外呈现特性开关，实现可控。
## 构建工程实现
构建工程已支持软件包（supportE发布包、toGDP生产装备包）级实现组件裁剪和特性裁剪。
同时，考虑调试功能、工具的可见范围需要基于 **某些条件**，只有满足特殊条件的软件包或特性才会引入工具或组件，构建工程为此需要扩展支持条件引入功能，并预置常用条件，如根据build_type要求控制引入条件，具体条件可以扩展。
以下是manifest.yml中编写条件引入 组件 和 特性 的示例：
```yaml
dependencies:
- conan: "ssdp"
condition:
build_type: release
- conan: "muparser"
options:
shared: true
condition:
build_type: debug
- conan: "muparser"
options:
shared: false
condition:
build_type: release
```
上述示例演示了：
1. ssdp组件只在release条件下引入
2. muparser组件在debug条件下使用shared动态库
3. muparser组件在release条件下使用静态库
## 责任与分工
调试功能和工具的引入涉及构建工程和业务述求方，相关责任与分工：
1. 构建工程提供扩展条件检查设计和实现，可为具体工具和功能编译构建提供指示。
2. 调试工具和调试功能引入按谁痛谁主动原则确定，一般为业务述求方，需要完成组件的源码引入和功能实现。
---
# Hi1712 芯片构建指导
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/hi1712_chip_build.html
> Language: zh
# 概述
本文档指导开发者完成 Hi1712 芯片的构建与整机集成，涵盖环境准备、配置说明、构建流程、整机集成、执行构建和产物验证。
# 第一步：环境准备
## 1.1 开发环境要求
开发环境准备请参考：[环境介绍](../../../getting_started/quick_start/env_introduction.md)
## 1.2 安装构建工具
```bash
# 克隆 manifest 仓库
git clone https://gitcode.com/openUBMC/manifest.git
cd manifest
# 执行环境初始化脚本
python3 init.py
```
初始化脚本参数说明：
| 参数 | 说明 |
|------|------|
| `-b BOARD_NAME` | 构建类型，支持 openUBMC 或 oee，默认为 openUBMC |
| `-user OPENUBMC_USER` | openUBMC 社区用户名 |
| `-psw OPENUBMC_PASSWORD` | openUBMC 社区密码，推荐使用交互式输入 |
| `--no_build` | 不进行 SDK 初始化 |
使用示例：
```bash
# 默认初始化（openUBMC）
python3 init.py
# 带全部选项初始化
python3 init.py -b openUBMC -user <用户名> -psw <密码>
```
初始化脚本会自动安装：
- bingo 构建工具
- Conan 2.x 包管理器
- Node.js 运行环境
- 其他依赖工具
## 1.3 配置 Conan 远程仓库
```bash
# 查看已配置的 remote
conan remote list
# 输出示例：
# openubmc_opensource: https://conan.openubmc.cn/openubmc_opensource [Verify SSL: False, Enabled: True]
```
默认存在 `openubmc_opensource` remote，用于开源组件发布的 conan 包。
如需添加其他 remote：
```bash
# 添加 Conan 远程仓库
conan remote add
# 认证（以 openubmc_opensource 为例）
conan remote login openubmc_opensource
```
## 1.4 bingo 安装
```bash
# 检查 bingo 版本
bingo -v
```
初始化脚本默认安装 bingo 工具。
也可以手动安装：
```bash
# 克隆 bingo 仓库
git clone https://gitcode.com/openUBMC/bingo.git
cd bingo
# 执行安装脚本
sh install_local.sh .
```
# 第二步：构建配置说明
Hi1712 已有默认产品配置 `openUBMC_1712`，可直接使用：
```bash
cd /path/to/manifest/build/product/BMC/openUBMC_1712
```
## 2.1 产品配置文件
查看产品配置：
```bash
# 查看 manifest.yml 配置
cat manifest.yml
# 查看辅助配置文件
ls -la
# 输出：
# -rw-r--r-- 1 root root 4871 Aug 11 20:00 manifest.yml
# -rw-r--r-- 1 root root 256 Aug 11 20:00 archive.ini
# -rw-r--r-- 1 root root 2100 Aug 11 20:00 version.xml
# -rw-r--r-- 1 root root 500 Aug 11 20:00 update_ext4.cfg
```
## 2.2 SDK 配置
```yaml
bmc_sdk_download:
url: https://repo.openubmc.cn/26.06/sdk/bmc_sdk_1712.tar.gz
sha256: c3f3b7c51ca503b40ac090b7e773aae2798f2652fc1f5f006c769d0c7bf5d8ea
```
**说明**：
- Hi1712 使用专用 SDK：`bmc_sdk_1712.tar.gz`
- SHA256 校验值确保下载完整性
- SDK 包含平台组件的 Conan 包，以及配套的 RTOS、SDK、编译器、构建工具
- 是整包构建方案的关键配置，简化依赖管理
## 2.3 平台配置
```yaml
platform:
conan: "ibmc_sdk/5.14.00.01.b001@openubmc/stable"
options:
rtos_version: rtos_v2_1712 # Hi1712 专用标识
enable_haf: false
package: community_unsign_webvnc_1712
```
**关键参数**（1712 平台组件专用 option）：
- `rtos_version: rtos_v2_1712`：Hi1712 专用 RTOS 版本标识（不能使用 rtos_v2）
- `enable_haf: false`：平台是否支持高可用特性
- `package: community_unsign_webvnc_1712`：默认使用的整包方案
## 2.4 签名配置
Hi1712 支持 RSA4096 和 SM2 国密双签名：
```yaml
base:
signature:
files:
- file: ${product}/ca/rootca.crl
dst: cms.crl
- file: ${product}/ca/rootca.der
dst: rootca.der
# RSA4096 签名
- file: ${product}/ca/rsa_rootca.crt
dst: rootca.crt
condition:
signature_type: rsa4096
# SM2 国密签名
- file: ${product}/ca/sm2_rootca.crt
dst: rootca.crt
condition:
signature_type: sm2
# RSA 签名密钥
rsa_sign_key: UBMCCMSEE
rsa_ts_key: UBMCTS
rsa_rootca_crl_download:
url: https://openubmc-certs.obs.cn-north-4.myhuaweicloud.com/bb7d00fb-5ca5-476b-bc1a-258105fa0b8f.crl
rsa_ica_crl_download:
url: https://openubmc-certs.obs.cn-north-4.myhuaweicloud.com/4277907e-3a28-41e9-b58d-8f54f741dedf.crl
rsa_ica_download:
url: https://openubmc-certs.obs.cn-north-4.myhuaweicloud.com/openUBMC-RSA-PSS-Integrity-CA-1_certificate.pem
# SM2 签名密钥
sm2_sign_key: testsm2ee
sm2_ts_key: testsm2tsa
sm2_crl_download:
url: https://cert-b07f.obs.cn-north-4.myhuaweicloud.com/sm2ca.crl
sm2_ica_download:
url: https://cert-b07f.obs.cn-north-4.myhuaweicloud.com/sm2ica.pem
```
**说明**：
- 支持 RSA4096 和 SM2 双签名
- 构建时通过 `--signature-type` 参数选择签名方式
- 需要配置对应的密钥标识和证书下载地址
## 2.5 Linx 配置
```yaml
skip_linx: true
linx:
files:
- file: ${product}/ca/rootca.der
dst: host_cms_root_cert_g2.bin
```
**说明**：
- `skip_linx: true`：跳过 Linx 构建（Hi1712 必配）
- `linx.files`：Linx 包文件列表
## 2.6 gpp 分区配置
```yaml
gpp:
files:
- file: ${work_out}/rootfs_BMC.img
- file: ${work_out}/rootfs_BMC.tar.gz
- file: ${work_out}/rootfs_BMC.img.cms
- file: ${board_path}/cms.crl
dst: cms.crl
- file: ${board_path}/rootca.der
dst: rootca.der
- file: ${sdk_path}/Hi1711_boot_4096_debug.bin
dst: Hi1711_boot_4096.bin
condition:
build_type: debug
- file: ${sdk_path}/Hi1711_boot_4096.bin
dst: Hi1711_boot_4096.bin
condition:
build_type: release
- file: ${linx_build_dir}/out/LiteOS_M.bin
dst: LiteOS_M.bin
# Hi1712 专用分区头部配置
pkg_headers:
gpp_header:
dst: emmc_header.config
file: /usr/share/bingo/emmc_uboot_header_1712.config
hpm_header:
dst: hpm_header.config
file: /usr/share/bingo/hpm_header_1712.config
uboot_header:
dst: emmc_uboot_header.config
file: /usr/share/bingo/emmc_uboot_header_1712.config
```
**说明**：
- `pkg_headers`：eMMC/HPM 分区头部配置（Hi1712 必配）
- 使用 `/usr/share/bingo/emmc_uboot_header_1712.config` 等专用配置文件
## 2.7 组件依赖
```yaml
dependencies:
- conan: iam
- conan: vpd
options:
board_name: openUBMC
- conan: hica
- conan: observability
- conan: fluent-bit
- conan: libyaml
- conan: opentelemetry
- conan: abseil
- conan: grpc
- conan: protobuf
- conan: re2
- conan: c_ares
- conan: opentelemetry-proto
- conan: webui
options:
energy_enabled: false
webvnc_enabled: true
- conan: help
options:
board_name: openUBMC
- conan: libspdm
- conan: spdm
- conan: dcmid
- conan: vnc_proxy
```
# 第三步：构建流程说明
执行 `bingo build` 后，bingo 会按依赖关系自动编排构建任务。完整的任务编排定义在 `bmcgo/target/personal.yml`（个人构建）和 `publish.yml`（发布构建）中，其中涉及 Hi1712 的 5 个关键任务以下文「3.1 ~ 3.5」详述（图中以 ★ 标注），其余为通用辅助任务（组件编译、WBD、元数据打包、HPM 打包签名、QEMU 仿真、接口配置生成等）。
下图依据 `personal.yml` 描述了 Hi1712 构建的核心流水线（箭头表示等待依赖，并行分支在同层展开）：
```python
prepare_env
│
▼
┌─ download_buildtools
download ──┤
└─ download_dependency ★ 3.1
│
┌───────────────┼───────────────┐
▼ ▼ ▼
oct_rtos ★ build_linxbin ★ build_conan(组件编译)
3.2 3.3 │
│ │ ┌──────┴──────┐
│ │ ▼ ▼
│ │ build_wbd_up package_metadata
│ │ └──────┬──────┘
└───────────────┼────────────────┘
▼
build_rootfs_img ★ 3.4
│
┌────────────┼─────────────┐
▼ ▼ ▼
buildgppbin ★ qemu_rootfs run_qemu_bmc
3.5(wait (可选,ignore_not_exist)
linxbin)
│
▼
buildhpm_ext4 ──► sign_and_pack_hpm
│
▼
create_interface_config
```
## 3.1 下载并解压 SDK 依赖（task_download_dependency）
对应源码：`bmcgo/tasks/task_download_dependency.py`，编排节点 `work.build.download`。
本步骤负责将整包 SDK 中的平台二进制文件安装到本地，是后续所有构建步骤的基础。
**主要动作**：
1. 从缓存目录（`~/sdk`）复制 SDK 到构建临时目录
2. 解压 `Hi1712_SDK*.tar.gz`，提取以下关键文件：
- `drivers/Module.symvers`：内核模块符号表
- `drivers/sdk_initrd.tar.gz`：initrd 根文件系统
- `drivers/sdk_rootfs.tar.gz`：rootfs 根文件系统
- `boot/packeted/hibmc_core_sec_boot*.bin`：安全启动镜像（按签名类型和构建类型选取）
3. 安装到 `/opt/hi1711sdk` 并建立软链接，记录 SHA256 用于增量判断
**Hi1712 特有逻辑**：
- 根据 `build_type`（debug/release）选择 `_debug` 后缀的 boot 镜像
- 根据 `signature_type`（sm2/rsa）选择对应签名的 boot 镜像
- 当 SDK SHA256 匹配时跳过安装，加速增量构建
## 3.2 裁剪 RTOS（task_oct_rtos）
对应源码：`bmcgo/tasks/task_oct_rtos.py`，编排节点 `work.oct_rtos`（等待 `work.build.download`）。
本步骤基于 OCT（Output Configuration Trim）策略裁剪 RTOS，生成精简的 `rtos_with_ko.tar.gz`，供后续构建 rootfs 使用。
**主要动作**：
1. 准备 RTOS 编译环境，加载 `dlsetenv.sh` 工具链环境变量
2. 若配置了 `base/rtos_oct`，下载并安装 `rtos_dist` 裁剪工具
3. 分别裁剪 initrd 和 rootfs：
- 依据 `policy.yml` 策略删除无用文件（`nouse_files`、`rm_exclude_files`）
- 清理 initrd 中非 busybox 相关文件以压缩体积
- 复制编译链的 `libstdc++.so`、`libgcc_s.so` 到镜像
- 对镜像执行 strip 精简
4. 生成 `initrd_boot.cpio.gz`（≤5MB）、`uImage` 和 `rtos_with_ko.tar.gz`
**Hi1712 特有逻辑**：
- initrd 镜像大小限制为 5MB，超出将报错
- 通过 SHA256 缓存机制判断是否需要重新裁剪
## 3.3 编译灵犀核固件（task_build_linxbin）
对应源码：`bmcgo/tasks/task_build_linxbin.py`，编排节点 `work.build.linxbin`（等待 `work.build.download`）。
本步骤构建并签名灵犀（Linx）协处理器固件 `LiteOS_M.bin`。该步骤仅对 `1712` 和 `oee_3095` 芯片执行，与裁剪 RTOS、组件编译**并行执行**。
**主要动作**：
1. 下载灵犀核源码（非伙伴模式）
2. 构建 `origin_LiteOS_M.bin` 固件
3. 对固件进行加密和 RSA 签名（执行 `01_prepare_build.sh` ~ `05_build_header.sh` 系列脚本）
4. 生成 `LiteOS_M.bin`（协处理器固件）和 `gpp4_top_hdr.bin`（分区头部）
**Hi1712 特有逻辑**：
- 当 `skip_linx: true` 时，跳过构建并生成空文件占位（兼容升级模块）
- 自签名模式仅支持 RSA 算法
- 产出的 `LiteOS_M.bin` 会在 3.5 中打包进 GPP 镜像的 linx 分区
## 3.4 构建 rootfs 镜像（task_build_rootfs_img）
对应源码：`bmcgo/tasks/task_build_rootfs_img.py`，编排节点 `work.task_build_rootfs_img`（等待 `work.build.conan`、`work.oct_rtos`、`work.build_wbd_up`、`work.task_package_metadata`、`task_download_dependency`）。
本步骤将组件产物、RTOS 裁剪结果整合为完整的 rootfs 根文件系统，并制作 ext4 镜像。该步骤等待**裁剪 RTOS**、**组件编译**及其衍生任务（WBD、元数据打包）全部完成后执行。
**主要动作**：
1. 解压 `rtos_with_ko.tar.gz`，组装 rootfs 基础目录
2. 拷贝组件构建产物到 rootfs，执行 strip 精简二进制体积
3. 记录代码分支和提交信息到 `/etc/bmc-release`
4. 执行产品定制化脚本（`rootfs_cust`）
5. 配置导入导出 schema 整合（`CombineJsonSchemas`）
6. 接口映射配置打补丁（Redfish / Web-backend / CLI / SNMP）
7. 合并硬件 SR 与软件 SR，生成 `csr_version.json`
8. 精简 MDS 和 SR 的 JSON 文件（删除 `description`、`required` 字段并压缩）
9. 制作 `rootfs_BMC.img`（ext4 格式）和 `rootfs_BMC.tar.gz`
## 3.5 构建 GPP 整包镜像（task_buildgppbin）
对应源码：`bmcgo/tasks/task_buildgppbin.py`，编排节点 `work.task_buildgppbin`（`work.task_hpm_envir_prepare` 的子任务，等待 `work.build.linxbin`）。
本步骤将 boot、rootfs、灵犀核固件等分区文件打包成 GPP（General Purpose Package）整包二进制镜像。该步骤嵌套在构建 rootfs 镜像的子任务中，并等待**灵犀核固件**构建完成。
**主要动作**：
1. 准备 boot 镜像（`Hi1711_boot_4096.bin`），自签名模式下对 uboot 重新签名
2. 复制 `gpp/files` 和 `gpp/pkg_headers` 配置的分区文件和头部配置
3. 调用 `gpp_header hpm` 生成 HPM 顶层和子头部
4. 拼接生成 `{board_name}_gpp.bin`，包含以下分区：
- `hpm_top_header`：HPM 顶层头部
- `Hi1711_boot_4096.bin`：boot 启动镜像
- `LiteOS_M.bin`：灵犀核固件（来自 3.3）
- `hpm_sub_header`：HPM 子头部
- `rootca.der`：根证书
- `rootfs_BMC.img.cms`：签名后的 rootfs 镜像
- `cms.crl`：吊销列表
- `rootfs_BMC.tar.gz`：rootfs 压缩包
**Hi1712 特有逻辑**：
- 必须配置 `gpp/pkg_headers`，使用 `/usr/share/bingo/emmc_uboot_header_1712.config`、`hpm_header_1712.config` 等专用分区头部配置文件
- 后续会继续执行 `buildhpm_ext4`（制作 HPM 升级包）和 `sign_and_pack_hpm`（签名打包）
# 第四步：集成到整机
整机产品（如服务器）基于 Hi1712 芯片构建时，需在产品 `manifest.yml` 中引用 Hi1712 的平台配置与整包 SDK，并按整机形态定制组件依赖。本步骤说明集成步骤和注意事项。
> 若仅进行 Hi1712 默认产品（`openUBMC_1712`）的独立构建，可跳过本步，直接进入第五步。
## 4.1 集成步骤
整机产品集成 Hi1712 时，在产品 `manifest.yml` 中按以下步骤完成配置。产品目录及 `manifest.yml`、辅助文件的完整说明请参考[新增产品](../../../integration/system_config/add_new_product.md)。
**步骤 1：引用 Hi1712 整包 SDK**
通过 `bmc_sdk_download` 引用 Hi1712 专用整包 SDK，构建时自动下载并解压到本地：
```yaml
bmc_sdk_download:
url: https://repo.openubmc.cn/26.06/sdk/bmc_sdk_1712.tar.gz
sha256: c3f3b7c51ca503b40ac090b7e773aae2798f2652fc1f5f006c769d0c7bf5d8ea
```
**步骤 2：引用 Hi1712 平台组件**
通过 `platform` 引用 Hi1712 平台组件，`rtos_version` 必须使用 1712 专用标识 `rtos_v2_1712`：
```yaml
platform:
conan: "ibmc_sdk/5.14.00.01.b001@openubmc/stable"
options:
rtos_version: rtos_v2_1712
enable_haf: false
package: community_unsign_webvnc_1712
```
**步骤 3：配置签名证书**
按整机签名方式（RSA4096 / SM2）在产品 `ca` 目录准备对应证书文件，并在 `base.signature` 中配置证书引用，证书文件按签名类型二选一生效，配置方法详见 2.4 签名配置。
**步骤 4：跳过 Linx 构建并配置 gpp 分区头部**
设置 `skip_linx: true` 跳过灵犀核固件构建（Hi1712 必配），并在 `gpp.pkg_headers` 中配置 1712 专用分区头部，确保 GPP 镜像分区布局正确，配置方法详见 2.5 Linx 配置和 2.6 gpp 分区配置：
```yaml
skip_linx: true
```
**步骤 5：定制整机组件依赖**
在 `dependencies` 中按整机需求添加或定制组件。整包内的平台组件默认继承整包配置，无需重复声明；如需替换或定制某个平台组件，对同名组件写出版本/options 即可覆盖（同名即覆盖），覆盖时构建日志会打印告警：
```yaml
dependencies:
- conan: vpd
options:
board_name: MyProduct
- conan: my_product_specific_component/1.0.0@openubmc/stable
```
**步骤 6：执行整机构建验证**
```bash
cd /path/to/manifest
export OPENUBMC_LICENSE=true # 首次构建需同意《BMC软件许可协议》
bingo build -b MyProduct -bt release --stage dev
```
构建完成后按第六步验证构建产物，确认 HPM 包完整可升级。若需构建发布包，还需在 `tosupporte` 中同步配置 `platform` 引用。整包引用方式的更多说明可参考[平台整包集成指导](../build_guide/platform_full_package_integration_guide.md)。
## 4.2 注意事项
集成 Hi1712 到整机时需注意以下关键约束：
1. **RTOS 版本标识**：必须使用 `rtos_v2_1712`，不能使用 `rtos_v2`，否则 RTOS 无法正确安装
2. **SDK 包名**：使用 `bmc_sdk_1712.tar.gz`，不能使用通用 `bmc_sdk.tar.gz`；`sha256` 校验值必须与文件服务器提供的一致，否则下载失败
3. **整包配置**：`platform.package` 使用 `community_unsign_webvnc_1712`；更新整包版本时需同步修改该配置
4. **Linx 配置**：必须设置 `skip_linx: true`，否则会触发灵犀核固件构建流程
5. **分区头部**：必须配置 `gpp.pkg_headers`，使用 `emmc_uboot_header_1712.config`、`hpm_header_1712.config` 等 1712 专用配置文件，否则 GPP 镜像分区布局错误，导致固件无法启动
6. **签名类型**：构建时通过 `--signature-type` 指定签名方式（rsa4096 / sm2），并确保 `ca` 目录下存在对应证书文件
7. **网络与协议**：`bmc_sdk_download` 下载需网络可访问 `repo.openubmc.cn`，且需同意《BMC软件许可协议》
8. **组件覆盖**：产品对整包同名组件写出版本/options 即覆盖整包默认配置，覆盖行为会在构建日志打印告警；仅在确需替换时才写，避免无意覆盖整包默认配置
9. **构建类型匹配**：`tosupporte` 中配置的 `build_type` 必须与构建命令 `-bt` 指定的类型一致，否则构建直接报错
# 第五步：执行构建
## 5.1 同意许可协议
首次构建需要同意《BMC软件许可协议》：
```bash
# 设置环境变量自动同意
export OPENUBMC_LICENSE=true
```
## 5.2 执行构建
```bash
# 进入 manifest 目录
cd /path/to/manifest
# 使用现有产品配置构建
# Debug 版本构建
bingo build -b openUBMC_1712 -bt debug --stage dev
# Release 版本构建
bingo build -b openUBMC_1712 -bt release --stage dev
```
## 5.3 构建参数说明
| 参数 | 说明 | 值 |
|------|------|------|
| `-b BOARD_NAME` | 单板名称（对应产品目录名） | openUBMC_1712 |
| `-bt BUILD_TYPE` | 构建类型 | debug / release |
| `--stage STAGE` | 包类型 | dev / rc / stable |
| `--signature-type` | 签名类型 | rsa4096 / sm2 |
## 5.4 查看构建产物
```bash
# 查看构建产物
ls -lh output/
# 输出示例：
# -rw------- 1 root root 70M Aug 11 20:00 rootfs_openUBMC_1712.hpm
# -rw------- 1 root root 68M Aug 11 20:00 rootfs_BMC.img
# -rw------- 1 root root 65M Aug 11 20:00 rootfs_BMC.tar.gz
# -rw------- 1 root root 70M Aug 11 20:00 rootfs_openUBMC_1712.hpm.signed
```
构建产物包括：
- `rootfs_openUBMC_1712.hpm`: HPM 固件包
- `rootfs_BMC.img`: rootfs 镜像文件
- `rootfs_BMC.tar.gz`: rootfs 压缩文件
- `rootfs_openUBMC_1712.hpm.signed`: 已签名 HPM 包
# 第六步：验证构建产物
## 6.1 检查构建日志
```bash
# 查看整体日志
cat temp/log/task.log
# 查看组件构建日志
cat temp/log/conan_Build_*.log
```
## 6.2 检查 HPM 包头部
```bash
# 查看 HPM 包头部
hexdump -C output/rootfs_openUBMC_1712.hpm | head -20
```
# 参考资料
- [manifest 配置指南](../../../feature_dev/component_interface_spec/manifest.md)
- [新增产品](../../../integration/system_config/add_new_product.md)
- [整包构建指导](../build_guide/platform_full_package_integration_guide.md)
- [SM2 国密签名规范](https://www.oscca.gov.cn/)
---
# 如何构建组件以及查找生成文件
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/how_to_build_app.html
> Language: zh
## 组件构建与发布
在构建组件时，我们需要切换到组件目录，执行`bingo`命令，否则`bingo`命令不生效，这里以组件`iam`组件来作为示例，演示组件的构建流程。
### 一、简述
进入到`iam`的源码目录，执行如下命令来查看支持的构建参数
```shell
[07:16:31 root(1110):/home/workspace/codehome/iam]# bingo --help
Component commands
build 构建出包
analysis BMC product or package analysis, including build dependency analysis, interface dependency analysis, etc
deploy 将组件及其依赖部署至temp/rootfs目录
test 构建DT.
gen 代码自动生成，支持Lua和C语言，C组件需要在service.json中添加`"language": "c",`配置.
Misc commands
help 获取命令帮助
upgrade 升级bingo版本
输入"bingo -h"获取子命令帮助
[07:16:33 root(1110):/home/workspace/codehome/iam]#
```
在上面返回的结果中，我们只使用到部分，`build`,`gen`为主要使用的命令，下面主要介绍这两条命令
### 二、自动生成命令
`gen`命令用来自动生成代码，现在组件的代码都是使用此工具来自动生成，自动生成后才能进行构建，所以这里先讲`gen`命令，查看`gen`命令的help菜单
```shell
[07:28:19 root(1110):/home/workspace/codehome/iam]# bingo gen --help
usage: bingo gen/当前只支持C和lua语言代码生成 [-h] [-v VERSION] [-w]
代码自动生成.
options:
-h, --help show this help message and exit
-v VERSION, --version VERSION
use specified version
-w, --with_template generate with template
[07:33:21 root(1110):/home/workspace/codehome/iam]#
```
从返回结果，可以看到这个参数结构相对比较简单，建立好模板文件，使用如下命令即可生成代码
```shell
# -bt debug: 构建类型
# --stage rc: 预发布包
# 如果在mds目录下配置了model.json，则带上-w参数来进行模板生成
bingo gen -bt debug --stage rc
# 日志截取，没有发生报错，则表示自动生成成功
python3 /home/workspace/codehome/iam/temp/lua_codegen/script/template.py -d /home/workspace/codehome/iam/proto -j /home/workspace/codehome/iam/temp/lua_codegen/temp/iam/ -n iam -i /home/workspace/codehome/iam/temp/lua_codegen/temp/iam/db_json.json -f /home/workspace/codehome/iam/temp/lua_codegen/script/lua_format.py -t orm_classes.lua.mako -o /home/workspace/codehome/iam/gen/iam/orm_classes.lua
make[3]: Leaving directory '/home/workspace/codehome/iam/temp/lua_codegen/templates/apps'
make[2]: Leaving directory '/home/workspace/codehome/iam/temp/lua_codegen/templates'
make[1]: Leaving directory '/home/workspace/codehome/iam/temp/lua_codegen'
```
### 三、构建命令
`build`命令用来构建组件的版本包，使用`help`命令来看下`build`命令的帮助文档
```shell
[07:16:33 root(1110):/home/workspace/codehome/iam]# bingo build --help
usage: bingo [-h] [-b BOARD_NAME] [-bt BUILD_TYPE] [--stage STAGE] [-u] [-r REMOTE] [-s] [-nc] [-o OPTIONS] [--user USER] [--summary] [--minimum]
[--package_info PACKAGE_INFO]
component dt different version
options:
-h, --help show this help message and exit
-b BOARD_NAME, --board_name BOARD_NAME
支持的单板名，请参考manifest/build/product目录
-bt BUILD_TYPE, --build_type BUILD_TYPE
构建类型，可选：dt,debug,release 默认：debug
--stage STAGE 组件包发布阶段, 可选: dev(developer), pre, rc, stable 默认：dev
-u, --upload 上传组件包到conan仓
-r REMOTE, --remote REMOTE
conan仓别名，请检查conan remote list查看已配置的conan仓 默认: openubmc_dev
-s, --from_source Build from source, include dependency component
-nc, --no_cache 不使用~/.conan/data目录下的缓存包(构建前删除缓存)
-o OPTIONS, --options OPTIONS
Define options values (host machine), e.g.: -o Pkg:with_qt=true
--user USER 指定conan包的user字段，尝试从/etc/bingo.conf文件读取conan.user字段，否则由程序管理
--summary 打印conan构建详细日志，默认：打印简要信息
--minimum, -m 获取 dt 构建的最小版本
--package_info PACKAGE_INFO, -pi PACKAGE_INFO
package_info 文件路径, 此文件在 manifest 构建时会在 inner 目录生成
[07:20:03 root(1110):/home/workspace/codehome/iam]#
```
根据上面的返回结果，需要使用的参数只有其中几个，以具体实例来讲解
```shell
# -b Openubmc: 指定单板名，某些组件和单板名挂钩，需要指定单板名来打入某些文件，如果组件和单板无关，不带此参数
# -bt debug: 构建类型，调试包
# --stage rc: 预发布包
bingo build -b Openubmc -bt debug --stage rc
# 截取部分日志放在这里
Downloading conanmanifest.txt completed [17.89k]
Downloading conaninfo.txt completed [2.97k]
Downloading conan_package.tgz completed [543.98k]
Decompressing conan_package.tgz completed [0.00k]
iam/1.20.31@hw.ibmc.release/rc: Package installed cb9794cb17b2f104bdddb1803a0104b29d12d75c
iam/1.20.31@hw.ibmc.release/rc: Downloaded package revision 35401b8fc57f5024055b6203bbd5abfe
Build successfully
[07:28:19 root(1110):/home/workspace/codehome/iam]#
```
在Build successfully上方，能看到编译完成的版本号，这个版本号就是生成的组件版本
### 四、构建生成文件
conan2:
组件下执行bingo build默认发布阶段为dev,此时通过cd ~/.conan2/p可进入到生成组件文件夹。
- 示例：
- 通过输入conan cache path vpd/1.80.18@openubmc/stable可以查看组件配方文件路径
/root/.conan2/p/vpd264d23efe75e8/e
- 通过输入conan cache path vpd/1.80.18@openubmc/stable:582e093ee6c9a154a84fdfd89574d24b71441f47可进入制品文件夹
/root/.conan2/p/b/vpd6d29851846626/p
bingo会根据组件的conanfile.py或者conanbase.py文件，会构建生成对应的conan文件，其中：
- e文件夹中是构建的配方文件，在文件的export()方法中定义。
- s文件夹中是构建的源代码文件，在文件的source()方法中定义。
- es文件夹是导出的source中的文件，在文件的exports_sources中配置相关信息。
- b文件夹是构建源代码生成的文件，是根据文件中build方法配置构建信息
- p文件夹中是打包构建后的代码，在文件的package方法中配置打包信息。
- 在metadata.json文件中，可以查看生成文件的recipe哈希值、包的唯一标志符以及包的修订哈希值，它用于跟踪包的变化。可通过此编号在conan仓中找到上传组件信息。
conan1(后续将不再维护):
组件下执行bingo build默认发布阶段为dev,此时通过cd ~/.conan/data/<组件名>/<版本号>/hw.ibmc.dev/dev可进入到生成组件文件夹。
bingo会根据组件的conanfile.py或者conanbase.py文件，会构建生成对应的conan文件，其中：
- source文件夹中是构建的源代码文件，在文件的source()方法中定义，如果没有定义，会默认复制文件同层文件和文件夹。
- export_source文件夹是导出的source中的文件，在文件的exports_sources中配置相关信息。
- build文件夹是构建源代码生成的文件，是根据文件中build方法配置构建信息
- package文件夹中是打包构建后的代码，在文件的package方法中配置打包信息。
- 在metadata.json文件中，可以查看生成文件的recipe哈希值、包的唯一标志符以及包的修订哈希值，它用于跟踪包的变化。可通过此编号在conan仓中找到上传组件信息。
---
# maint及conan_index说明
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/maint_and_conan_index.html
> Language: zh
## 方案概述
组件只有一个开发分支，所有代码都在主干修复和演进，转维版本的缺陷或特性需要由子系统完成上库和测试。组件按需发布补丁，由组件转维版本集成补丁，发布新的构建版本。
整体动作的基本原则：谁需要谁触发，责任owner负责发布补丁。
## 关键功能
组件转维patch方案主要是完成 **组件无分支条件下修改代码并构建发布版本** ，其核心功能包括：
1. 支持基于组件转维源码重复发布组件。
2. 支持在组件转维源码基础上追加补丁patch文件，管理多个patch文件和patch顺序。
3. 提供工程工具简化操作。
## 基本思路
[conan官方仓库](https://github.com/conan-io/conan-center-index) 中存储约1600+开源软件构建脚本，大部分都没有侵入式修改开源软件仓代码，对外体现就是开源软件本身没有适配任何conan构建代码。少部分开源软件无法直接使用conan构建的一般采用 **拉取到原生代码后应用patch方案** 修改构建脚本，最终完成构建。
openubmc的path方案采用conan的包管理方式完成，组件主干代码采用conanfile构建脚本与组件源码共仓管理模式（构建和发布），转维组件采用conanfile构建脚本和组件源码分仓管理模式。
## 实现方案
构建工程的bingo工具新增manitain辅助命令，帮助开发者生成维护版本构建脚本，支持从主干cherry-pick特定的commit提交或者人工指定patch文件。
openubmc使用conan-index管理开源软件、平台软件和芯片软件管理中，这种方式可以在免修改组件源码条件下实现组件的编译和发布。转维版本也借鉴该方式，由maintain命令在conan-index仓中生成构建脚本和patch文件，编译方式和发布流程与开源软件发布完全一样。
具体的转维组件生成、构建、发布和引用流程为：
1. 参与下面的场景完成转维版本conan_index代码生成
2. 构建出包`bingo build -cp /`，其它参数详见命令帮助
3. 完成转维版本功能验证
4. 完成conan_index代码上库
5. 完成转维版本发布
6. 在产品引入新发布的转维组件，可能涉及manifest.yml修改和代码上库
## maintain子命令说明
maintain子命令了4个参数用于辅助开发者使用：
```shell
root@DESKTOP-M0FU0HP:/home/xuhj/workspace/openubmc300/manifest# bingo maint --help
usage: bingo maintain [-h] -cp CONAN_PACKAGE [-p PATCH_FILE] [-b BRANCH] [-c COMMIT_ID]
BMC组件的维护管理工具
optional arguments:
-h, --help show this help message and exit
-cp CONAN_PACKAGE, --conan_package CONAN_PACKAGE
指定需要维护的组件版本，示例：iam/1.2.3
-p PATCH_FILE, --patch_file PATCH_FILE
添加patch文件，可指定多个，顺序追加到代码中
-b BRANCH, --branch BRANCH
用于提取patch的分支，与commit_id配合使用
-c COMMIT_ID, --commit_id COMMIT_ID
需要生成patch的提交节点，长度不低于8个字符，可指定多个，顺序追加到代码中。【不推荐使用】生成的patch文件可能存在冲突、功能验证不充分，建议使用-p参数使用人工生成的补丁。
```
具体实现的基本逻辑为：
1. 从组件中心仓查找`-cp`参数指定组件的源码仓`url`和`tag`
2. 自动生成或开发者指定待生成的组件版本号，生成的版本号格式必须为a.b.c-build.x，其中a.b.c是三段式版本号，一般与-cp指定的基础版本保持一致，x为补丁版本号，使用数字。
3. (如果有)`-c`参数指定提交id的，需要切换到用于提取patch的分支并提取差异生成patch文件，此过程使用到的命令为`git format-patch -1 {commit_id} --numbered-files -- ':!mds/service.json' ':!CHANGELOG'`，其中`{commit_id}`需要替换成真实的提交id，生成的patch文件将以数字命名并会被复制到组件recipes的`patches`子目录，`':!mds/service.json'`用于忽略文件名以`mds/service.json`文件的提交差异，`':!CHANGELOG*'`用于忽略文件名以`CHANGELOG`开头的提交差异。
4. (如果有)`-p`参数指定的独立patch文件，工具会从源路径复制到组件recipes的`patches`子目录。
> [!WARNING]
> 生成patch文件时已忽略了`mds/service.json`和`CHANGELOG*`文件变更，如果需要该文件内容，请手工生成patch文件。
## 使用示例
### 指定patch文件创建转维版本
`bingo maint`功能可以人工指定patch，需要人工修改源码后再发布版本，执行的流程为“编辑源码 -> 验证功能 -> git提交 -> 生成补丁 -> 创建转维版本”，操作步骤：
1. 本地代码切换到`-cp`指定的基础版本。
2. 执行`git cherry-pick`提取需要的代码，本地提交解决冲突并验证功能
3. 执行`git format-patch -1 --numbered-files -- ':!mds/service.json' ':!CHANGELOG*' ':!ChangeLog*'`命令生成新的patch文件`1`。注意，其中`':!mds/service.json'` `':!CHANGELOG*'` `':!ChangeLog*'`是需要排除的文件，**建议认真审视，减少非必要的修改** 。
4. 自动生成的补丁文件名为`1`，需要重命名为`.patch`。
在manifest或conan_index仓操作步骤：
1. 执行`bingo maint -cp / -p .patch`命令追加patch文件。
### 转维版本基础再次发布新的转维版本
如果要在一个patch方案发布的转维组件基础上再次使用cherry-pick生成补丁文件时，cherry-pick的基础源码需要打上补丁文件，一般的操作是：
1. 从conandata.yml中找到patch方案发布的转维组件的tag标签
2. 下载源码
3. 从conandata.yml中找到patch方案发布的转维组件的patch补丁，使用git am命令按顺序打上补丁，部分patch可能会报`trailing whitespace`错误，错误非常困难
上述操作很复杂且可能无法处理异常，bingo fetch命令适配了此场景，建议的完整操作逻辑是：
1. 执行`bingo fetch --package_info=/@hw.openubmc.release/stable`命令拉取组件源码并自动打补丁，其中`/@hw.openubmc.release/stable`是基础转维组件包。
2. 执行`git cherry-pick`提取需要的代码，本地提交解决冲突并验证功能
3. 执行`git format-patch -1 --numbered-files -- ':!mds/service.json' ':!CHANGELOG*' ':!ChangeLog*'`命令生成新的patch文件`1`
4. 自动生成的补丁文件名为`1`，需要重命名为`.patch`。
在manifest或conan_index仓操作步骤：
1. 执行`bingo maint -cp / -p .patch`命令追加patch文件。
## bingo fetch拉取源码 - 自动打补丁
采用 **指定patch文件追加新版本** 方案，建议在已打补丁的源代码基础上执行发布流程。
其中 **已打补丁的源代码** 是指在组件代码仓基础代码打上转维版本的全量补丁之后的源码，考虑到人工打补丁比较麻烦，操作易出错，将相关流程集成到`bingo fetch`命令，实现了拉取源码自动打补丁功能。
命令需要在manifest仓中执行（后续可能会切换到conan_index仓），命令格式为`bingo fetch --package_info /@/`，其中`/@/`为需要维护的组件。
完整的命令示例：
```shell
xuhj@DESKTOP:~/workspace/openubmc300/manifest$ bingo fetch --package_info skynet/1.7.0.B004@hw.openubmc.release/stable
====== 开始获取组件包信息: skynet/1.7.0.B004@hw.openubmc.release/stable ======
创建 1 个进程拉取代码
开始运行命令: /usr/local/bin/conan download skynet/1.7.0.B004@hw.openubmc.release/stable -r openubmc_dev -re
Downloading conanmanifest.txt completed [0.42k]
Downloading conanfile.py completed [8.07k]
Downloading conan_export.tgz completed [0.52k]
Decompressing conan_export.tgz completed [0.00k]
Downloading conan_sources.tgz completed [23.22k]
Decompressing conan_sources.tgz completed [0.00k]
更新 skynet 组件代码到 skynet/1.7.0.B004@hw.openubmc.release/stable 开始
更新代码(组件: skynet, 地址: https://szv-open.codehub.huawei.com/OpenSourceCenter/cloudwu/skynet.git, 分支: 1.7.0-htrunk1)
开始运行命令: git am /home/xuhj/.conan/data/skynet/1.7.0.B004/hw.openubmc.release/stable/export_source/patches/0001-Huawei-Replace-lua5.4-to-luajit.patch
Applying: Replace lua5.4 to luajit Offering: openubmc
skynet 应用源码补丁patches/0001-Huawei-Replace-lua5.4-to-luajit.patch
```
`bingo fetch`命令默认会将代码生成在source_code目录，如果需要生成到其它目录，可以使用`-p PATH, --path PATH 指定拉取源代码的存放路径`参数指定目标目录。
## ChangeLog
2024/12/10：转维版本号格式只允许a.b.c-build.x样式，其中a.b.c是三段式版本号，一般与-cp指定的基础版本保持一致，x为补丁版本号，使用数字。
---
# OEE+AST2600构建指南
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/oee_ast2600.html
> Language: zh
## 1. 概述
本文档介绍如何使用 bingo 工具构建基于 OEE (OpenEuler Embedded) 和 AST2600 芯片的 BMC 固件。
SDK 工具包（`oee_sdk.zip`）由 Yocto 源码构建产出，包含交叉编译器、bootloader、kernel 和 rootfs 等文件。bingo 基于这份 SDK 进行 HPM 升级包和 EMMC 烧片包的组装。
### 1.1 前置条件
- **操作系统**：推荐 Ubuntu 22.04+ 或兼容 Linux 发行版
- **bingo 工具**：尚未安装时，参考 [bingo 构建系统文档](https://gitcode.com/openUBMC/bingo) 了解安装方式
> bingo 默认已预装在 openUBMC 开发环境中，可跳过安装步骤直接使用；如使用自定义环境则需自行安装。
### 1.2 架构对比
| 对比项 | 1711/1712 (RTOS) | OEE+AST2600 (OEE) |
|--------|------------------|---------------------|
| 系统架构 | RTOS | Linux (OpenEuler Embedded) |
| 源码构建工具 | 内部构建系统 | oebuild + bitbake (Yocto) |
| 打包工具 | gpp_header + cat | FirmwarePackager (Python) |
| 配置格式 | hpm_header.config | hpm_layout.yml (YAML) |
| Boot文件 | Hi1711_boot系列 | u-boot-spl + u-boot (组合为 mmc-bootarea.img) |
| Rootfs | RTOS文件系统 | OEE Linux rootfs (core-image-tiny-initramfs) |
| 签名方式 | 打包进固件 | 外部 CMS 签名 |
### 1.3 SDK工具包结构
社区归档的SDK工具包由 Yocto 构建产物打包而成，结构如下：
```text
oee_sdk.zip
├── oee_sdk/ # Yocto 构建产物
│ ├── u-boot-spl.bin # SPL bootloader
│ ├── u-boot.bin # U-Boot
│ ├── u-boot-env.bin # U-Boot环境配置（原始）
│ ├── u-boot-env.img # U-Boot环境镜像（2M，由 u-boot-env.bin 制作）
│ ├── fitImage-obmc-phosphor-initramfs-evb-ast2600-evb-ast2600 # Linux kernel + initramfs (raw fitImage)
│ ├── fitImage.img # ext4 格式的 boot 分区镜像（内含 fitImage）
│ └── oee_rootfs.tar.gz # OEE rootfs 压缩包
└── oee_compiler/ # OEE专用编译器
└── openeuler-x86_64-obmc-armv7a-ast2600-toolchain-24.03-LTS.sh
```
**文件说明：**
| 文件 | 来源 | 用途 |
|------|------|------|
| `u-boot-spl.bin` | Yocto 构建产物 | SPL bootloader |
| `u-boot.bin` | Yocto 构建产物 | U-Boot |
| `u-boot-env.bin` | Yocto 构建产物 | U-Boot 环境配置（原始） |
| `u-boot-env.img` | 由 `u-boot-env.bin` 通过 truncate+dd 制作 | 2M 固定大小，烧入 emmc 的 u-boot-env 分区 |
| `fitImage-obmc-phosphor-initramfs-${board}-${machine}` | Yocto 构建产物（raw fitImage） | 用于制作 boot 分区镜像 `fitImage.img` |
| `fitImage.img` | 由 `mkfs.ext4` 将 raw fitImage 封装为 ext4 格式 | 写入 emmc boot-a/boot-b 分区 |
| `oee_rootfs.tar.gz` | Yocto 构建产物（rootfs） | 作为 HPM 升级包的 ROOTFS 分区 |
| `openeuler-x86_64-obmc-armv7a-ast2600-toolchain-24.03-LTS.sh` | 预编译 OEE 交叉编译器 | 安装到 `/opt/oee-sdk` |
### 1.4 分区配置文件
构建过程涉及分区配置文件：
| 配置文件 | 用途 | 位置 |
|----------|------|------|
| hpm_layout.yml | HPM升级包分区布局 | `${board_path}/hpm_layout.yml` |
| emmc_layout.yml | 真机烧片包GPT分区布局 | `${board_path}/emmc_layout.yml` |
**配置文件差异：**
| 特性 | hpm_layout.yml | emmc_layout.yml |
|------|----------------|-----------------|
| 格式 | YAML列表结构 | YAML字典结构 |
| 分区设计 | 简化分区（3个） | 双备份分区（7个） |
| 用途 | HPM在线升级包 | EMMC真机烧片包 |
| 分区类型 | type编号（0,32,1） | 类型字符串（raw, ext4） |
### 1.5 产品仓说明
产品仓（Product Repository）是存放产品配置的 Git 仓库，包含 `manifest.yml` 等配置文件，地址为：
- **GitCode**: [https://gitcode.com/openUBMC/manifest](https://gitcode.com/openUBMC/manifest)
仓库目录结构如下（以 openUBMC_ast2600 产品为例）：
```text
manifest/
├── build/
│ ├── product/
│ │ └── BMC/
│ │ └── openUBMC_ast2600/ # 产品目录，即 ${product}/${board_path}
│ │ ├── hpm_layout.yml
│ │ ├── emmc_layout.yml
│ │ ├── ca/ # 签名证书目录
│ │ │ ├── rootca.crl
│ │ │ └── rootca.der
│ │ └── ...
│ └── ...
└── manifest.yml # 产品顶层配置文件
```
- **`manifest.yml`**：产品顶层配置文件，位于仓库根目录
- **`${product}`**：指向 `manifest/build/product/BMC/openUBMC_ast2600/`
- **`${board_path}`**：与 `${product}` 相同，指向板级配置目录
## 2. 工具链安装
### 2.1 manifest.yml 配置
#### 2.1.1 SDK下载配置
在产品仓 `manifest.yml`（参见 1.5 节）中配置 SDK 和工具包下载：
```yaml
bmc_sdk_download:
url: "https://repo.openubmc.cn/26.03/oee_sdk/oee_sdk.zip"
sha256: "b6b870d973e5a94625daf1947df228c184ad43d391b226f53be26535416c4a48"
packages_download:
url: "https://repo.openubmc.cn/26.03/oee_sdk/packages.tar.xz"
sha256: ""
```
#### 2.1.2 工具安装配置
```yaml
tools_install:
build_tool:
label: "local"
work_path: "~/oee_compiler"
verify: true
install:
mode: "oee"
path: "/opt/oee-sdk"
sdk_tool:
label: "local"
work_path: "~/oee_sdk"
verify: true
install:
mode: "default"
path: "${sdk_path}"
```
**配置说明：**
| 配置项 | 说明 |
|--------|------|
| `label: "local"` | 使用本地已下载的工具，不执行远程下载 |
| `work_path` | 工具存放路径，支持 `~` 路径 |
| `mode: "oee"` | OEE模式，安装到 `/opt/oee-sdk` |
| `mode: "default"` | 默认模式，直接复制到目标路径 |
#### 2.1.3 平台配置
```yaml
platform:
conan: "oee_sdk/0.0.1@openubmc.dev/dev"
options:
rtos_version: "oee_ast2600"
enable_haf: false
```
### 2.2 安装命令
执行以下命令安装工具链：
```bash
bingo build -t install_sdk -b openUBMC_ast2600
```
**安装内容：**
| 内容 | 安装位置 | 说明 |
|------|----------|------|
| OEE编译器 | `/opt/oee-sdk` | arm-openeuler-linux-gnueabi交叉编译工具链 |
| SDK文件 | `${sdk_path}` | u-boot、kernel、rootfs等 |
| Conan制品缓存 | conan缓存目录 | 平台组件编译包 |
| Profile | `~/.conan2/profiles/profile_oee.ini` | 构建配置文件 |
### 2.3 安装验证
```bash
# 查看编译器版本
arm-openeuler-linux-gnueabi-gcc --version
# 查看SDK文件
ls ~/oee_sdk/
```
---
## 3. 组件适配
openUBMC 平台相关的 BMC 组件（如 `libmcpp/1.2.128@openubmc/stable`）支持使用 OEE 交叉编译工具链进行编译。以下说明组件适配流程。
### 3.1 Profile配置
OEE构建使用专用profile文件 `profile_oee.ini`（存放于产品仓根目录，参见 1.5 节），关键配置：
```ini
[settings]
os=Linux
arch=armv7hf
compiler=gcc
compiler.version=12.3
compiler.libcxx=libstdc++11
build_type=Release
[buildenv]
# 编译器路径
CC=arm-openeuler-linux-gnueabi-gcc
CXX=arm-openeuler-linux-gnueabi-g++
# Sysroot路径
CONAN_CMAKE_SYSROOT=/opt/oee-sdk/sysroots/armv7a-vfp-openeuler-linux-gnueabi/
```
### 3.2 构建命令
```bash
# 需在组件仓根目录（conanfile.py 所在目录）下执行
bingo build -pr profile_oee.ini
```
### 3.3 构件适配要点
以下编译参数需在 `profile_oee.ini` 中配置：
| 要点 | 说明 | profile_oee.ini 配置示例 |
|------|------|-------------------------|
| 编译器 | 使用 `arm-openeuler-linux-gnueabi-gcc` | `CC=arm-openeuler-linux-gnueabi-gcc` |
| Sysroot | 链接OEE sysroot库 | `CONAN_CMAKE_SYSROOT=/opt/oee-sdk/sysroots/armv7a-vfp-openeuler-linux-gnueabi/` |
| C标准 | 使用 `-std=gnu11` | `CFLAGS=-std=gnu11` |
| C++标准 | 使用 `-std=c++17` | `CXXFLAGS=-std=c++17` |
| ABI | `_GLIBCXX_USE_CXX11_ABI=0` | `CXXFLAGS=-D_GLIBCXX_USE_CXX11_ABI=0` |
---
## 4. 产品构建
### 4.1 manifest.yml 完整配置
以下为构建配置中使用的变量说明：
| 变量 | 含义 | 默认值/示例 |
|------|------|-------------|
| `${sdk_path}` | SDK工具包安装路径 | `~/oee_sdk`（由 `tools_install.sdk_tool.work_path` 指定） |
| `${work_out}` | 构建输出目录 | 由 bingo 自动设置，通常为构建工作区下的 `output/` 目录 |
| `${product}` | 产品配置目录 | `manifest/build/product/BMC/openUBMC_ast2600/` |
| `${board_path}` | 板级配置目录 | `${product}`（与 product 相同） |
```yaml
schema: /usr/share/bingo/schema/manifest.schema.json
platform:
conan: "oee_sdk/0.0.1@openubmc.dev/dev"
options:
rtos_version: "oee_ast2600"
base:
version: "26.06.00.01"
customization: "customization/prototype.py"
signature:
files:
- file: ${product}/ca/rootca.crl
dst: cms.crl
profile: "profile_oee.ini"
bmc_sdk_download:
url: "https://repo.openubmc.cn/26.03/oee_sdk/oee_sdk.zip"
sha256: ""
tools_install:
build_tool:
label: "local"
work_path: "~/oee_compiler"
install:
mode: "oee"
path: "/opt/oee-sdk"
sdk_tool:
label: "local"
work_path: "~/oee_sdk"
install:
mode: "default"
path: "${sdk_path}"
gpp:
gpt_config: "${board_path}/emmc_layout.yml"
files:
- file: ${sdk_path}/oee_rootfs.tar.gz
- file: ${sdk_path}/fitImage-obmc-phosphor-initramfs-${board}-${machine}
dst: kernel.bin
- file: ${sdk_path}/u-boot-spl.bin
- file: ${sdk_path}/u-boot.bin
- file: ${sdk_path}/u-boot-env.img
- file: ${sdk_path}/fitImage.img
- file: ${work_out}/rootfs_BMC.img
- file: ${work_out}/rootfs_BMC.tar.gz
- file: ${work_out}/rootfs_BMC.img.cms
- file: ${product}/ca/rootca.crl
dst: cms.crl
- file: ${product}/ca/rootca.der
dst: rootca.der
dependencies:
- conan: help
```
> `kernel.bin` 使用 SDK 中的 raw fitImage 文件重命名而来，而非 `fitImage.img`。
### 4.2 HPM包分区配置 (hpm_layout.yml)
HPM升级包的分区布局配置，位于 `${board_path}/hpm_layout.yml`：
```yaml
firmwares:
type: "hpm"
top_header:
size: 512 # Top Header大小（字节）
reserved: "" # 预留字段，最多15字节字符串
partitions:
- partition: BOOT
file: mmc-bootarea.img
type: 0 # 分区类型编号
site: 0 # 分区偏移，0表示自动计算
size: 0 # 分区大小，0表示按文件实际大小
- partition: KERNEL
file: kernel.bin
type: 32
site: 0
size: 0
- partition: ROOTFS
file: rootfs_BMC.tar.gz
type: 1
site: 0
size: 0
```
**配置说明：**
| 字段 | 说明 | 备注 |
|------|------|------|
| `type: "hpm"` | 固件类型标识 | 用于区分固件类型 |
| `top_header.size` | Top Header大小 | 固定512字节 |
| `top_header.reserved` | 预留字符串 | 最多15字节，用于标识固件信息 |
| `partition` | 分区名称 | 用于日志和调试 |
| `file` | 分区文件名 | 相对于构建目录 |
| `type` | 分区类型编号 | 用于区分分区类型（BOOT=0, ROOTFS=1, KERNEL=32等） |
| `site` | 分区偏移（字节） | 0表示自动计算，强制512字节对齐 |
| `size` | 分区大小（字节） | 0表示按文件实际大小 |
**分区说明：**
| 分区 | 文件 | 类型编号 | 说明 |
|------|------|----------|------|
| BOOT | mmc-bootarea.img | 0 | u-boot组合镜像（SPL + u-boot） |
| KERNEL | kernel.bin | 32 | Linux kernel + initramfs |
| ROOTFS | rootfs_BMC.tar.gz | 1 | BMC rootfs压缩包 |
### 4.3 真机烧片包分区配置 (emmc_layout.yml)
真机EMMC烧片包的GPT分区布局配置，位于 `${board_path}/emmc_layout.yml`：
```yaml
partitions:
settings:
sector_size: 512 # 扇区大小（字节），可选值: 512, 4096
gpt_header_sectors: 34 # GPT头占用扇区数
header_offset: 0x5000 # 数据头偏移（字节），首个分区起始位置
alignment: 1 # 分区对齐（扇区数），1表示不强制对齐
total_size: auto # 镜像总大小，auto自动计算，可指定如 512M
power_of_two_align: true # 镜像大小2次幂对齐
partition:
u-boot-env:
size: 2M # 分区大小
type: raw # 类型: raw, ext4
file: u-boot-env.img # 分区镜像文件名
boot-a:
size: 32M
type: ext4
file: fitImage.img
label: boot-a # 文件系统标签（可选）
boot-b:
size: 32M
type: ext4
file: fitImage.img
rofs-a:
size: 385028KB
type: ext4
file: rootfs_BMC.img
rofs-b:
size: 385028KB
type: ext4
file: rootfs_BMC.img
rwfs:
size: 200M
type: ext4
file: datafs.img
pflash:
size: 2M
type: raw
```
**Settings配置说明：**
| 字段 | 说明 | 默认值 |
|------|------|--------|
| `sector_size` | 扇区大小（字节） | 512 |
| `gpt_header_sectors` | GPT头占用扇区数 | 34 |
| `header_offset` | 数据区起始偏移（字节） | 0（从GPT头后开始） |
| `alignment` | 分区对齐（扇区数） | 1（不强制对齐） |
| `total_size` | 镜像总大小 | auto（自动计算） |
| `power_of_two_align` | 镜像大小2次幂对齐 | true |
**分区说明：**
| 分区 | 大小 | 类型 | 文件 | 说明 |
|------|------|------|------|------|
| u-boot-env | 2M | raw | u-boot-env.img | U-Boot环境变量分区 |
| boot-a | 32M | ext4 | fitImage.img | A分区kernel镜像 |
| boot-b | 32M | ext4 | fitImage.img | B分区kernel镜像（双备份） |
| rofs-a | 385028KB | ext4 | rootfs_BMC.img | A分区rootfs镜像 |
| rofs-b | 385028KB | ext4 | rootfs_BMC.img | B分区rootfs镜像（双备份） |
| rwfs | 200M | ext4 | datafs.img | 可读写数据分区 |
| pflash | 2M | raw | - | 保留分区（无文件） |
### 4.4 构建命令
```bash
# 默认构建，生成 HPM 升级包、真机 emmc 烧片包 (.wic) 和 qemu 仿真包 (.img)
bingo build -b openUBMC_ast2600
```
### 4.5 构建产物
| 产物文件 | 说明 |
|----------|------|
| `rootfs_openUBMC_ast2600.hpm` | HPM升级包 |
| `openUBMC_ast2600_real.wic` | 真机emmc烧片包 |
| `openUBMC_ast2600_real.img` | qemu仿真包 |
---
## 5. 其他配置
### 5.1 签名配置
OEE 固件包支持 CMS 签名，用于升级包的完整性校验。签名流程由 bingo 自动完成：构建时若环境存在 `signatrust-client`，则根据 `manifest.yml` 中配置的签名策略自动调用签名服务，对 `rootfs_BMC.img` 进行 CMS 分离签名，生成 `rootfs_BMC.img.cms`。
产品仓中 `base.signature` 仅配置证书吊销列表的分发：
```yaml
base:
signature:
files:
- file: ${product}/ca/rootca.crl
dst: cms.crl
```
证书文件（`rootca.der`、`rootca.crl`）通过 `gpp.files` 打包进固件：
```yaml
gpp:
files:
# rootfs_BMC.img的cms签名文件
- file: ${work_out}/rootfs_BMC.img.cms
# 签名文件的证书吊销列表
- file: ${product}/ca/rootca.crl
dst: cms.crl
# 签名的根证书
- file: ${product}/ca/rootca.der
dst: rootca.der
```
**签名相关文件说明：**
| 文件 | 格式 | 用途 |
|------|------|------|
| `rootfs_BMC.img.cms` | CMS | rootfs 签名文件（由 bingo 自动生成） |
| `rootca.der` | DER | 根证书，用于验签 |
| `rootca.crl` | DER | 证书吊销列表 |
更详细的签名说明参考：
- [bingo支持固件完整性保护签名能力](https://gitcode.com/openUBMC/bingo/blob/main/docs/26.06/bingo%E6%94%AF%E6%8C%81%E5%9B%BA%E4%BB%B6%E5%AE%8C%E6%95%B4%E6%80%A7%E4%BF%9D%E6%8A%A4%E7%AD%BE%E5%90%8D%E8%83%BD%E5%8A%9B.md)
- [cms_sign Demo](https://gitcode.com/openUBMC/bingo/blob/main/demo/cms_sign/README.md) — 包含自制签名证书链、签名服务器搭建、`bingo simple_sign` 签名验证等完整流程
---
## 6. 常见问题
### 6.1 SDK下载许可协议
首次下载SDK需要同意许可协议：
```bash
# 设置环境变量自动同意
export OPENUBMC_LICENSE=true
# 或交互式确认
bingo build -t install_sdk -b openUBMC_ast2600
# 输入 Y 同意协议
```
### 6.2 编译器路径问题
如果 `~/oee_compiler` 路径不正确，检查：
```bash
# 确认编译器位置
ls ~/oee_compiler/
```
### 6.3 GPT镜像文件大小不足
GPT镜像构建时，文件小于分区大小会自动补0填充：
```text
分区 ROOTFS 文件大小不足，补0填充: 实际 50000000 字节 -> 目标 134217728 字节
```
### 6.4 分区配置文件位置
分区配置文件默认位置：
| 配置文件 | 默认位置 | 说明 |
|----------|----------|------|
| hpm_layout.yml | `${board_path}/hpm_layout.yml` | HPM升级包分区配置 |
| emmc_layout.yml | `${board_path}/emmc_layout.yml` | 真机烧片包分区配置 |
`${board_path}` 变量指向产品仓（参见 1.5 节）内的板级配置目录。
### 6.5 自定义分区配置
如需自定义分区配置：
1. **HPM包分区**：复制并修改 `hpm_layout.yml`
2. **真机烧片包**：复制并修改 `emmc_layout.yml`，并通过 `gpt_config` 指定新路径
```yaml
gpp:
gpt_config: "${board_path}/custom_emmc_layout.yml"
```
### 6.6 分区偏移自动计算
HPM包和真机烧片包的分区偏移均可自动计算：
- **HPM包**：在 `hpm_layout.yml` 中设置 `site: 0`，系统自动计算并强制512字节对齐
- **真机烧片包**：在 `emmc_layout.yml` 中设置 `start: null` 或不配置，系统自动计算偏移
---
## 7. QEMU 仿真验证
### 7.1 安装 QEMU
```bash
wget https://download.qemu.org/qemu-11.0.0.tar.xz
tar xvJf qemu-11.0.0.tar.xz
cd qemu-11.0.0
./configure
make -j8
make install
```
### 7.2 启动仿真
```bash
cd manifest/output
qemu-system-arm -M ast2600-evb,boot-emmc=true \
-drive file=openUBMC_ast2600_real.img,format=raw,if=sd,index=2 \
-nographic
```
---
## 8. 参考文档
- [bingo支持基于OEE和ast2600芯片配置构建hpm包](https://gitcode.com/openUBMC/bingo/blob/main/docs/26.06/bingo%E6%94%AF%E6%8C%81%E5%9F%BA%E4%BA%8EOEE%E5%92%8Cast2600%E8%8A%AF%E7%89%87%E9%85%8D%E7%BD%AE%E6%9E%84%E5%BB%BAhpm%E5%8C%85.md)
- [bingo支持OEE产品策略配置](https://gitcode.com/openUBMC/bingo/blob/main/docs/26.06/bingo%E6%94%AF%E6%8C%81OEE%E4%BA%A7%E5%93%81%E7%AD%96%E7%95%A5%E9%85%8D%E7%BD%AE.md)
- [manifest.schema.json](https://gitcode.com/openUBMC/bingo/blob/main/tools/payload/usr/share/bingo/schema/manifest.schema.json)
---
# 平台整包集成指导
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/platform_full_package_integration_guide.html
> Language: zh
## 背景介绍
平台整包将平台组件预先打包，提供统一的依赖版本和配置。相比传统的逐个引用组件方式，具有以下优势：
- 简化产品配置，无需单独管理多个平台组件
- 避免组件版本冲突，提升构建稳定性, 削减多个conan中心仓
- 缩短依赖下载时间，加快构建速度
## 适用范围
ibmc_sdk>=5.14
## 整包结构介绍
整包存在形式：
单独文件，tar压缩包
整包解压后目录结构：
```shell
full_package/
├── conan_cache/ conan缓存合集
├── community_webvnc_1711_manifest.yml 整包配置文件1
├── community_webvnc_manufacture_1711_manifest.yml 整包配置文件2
└── ...
```
### 配置说明
#### manifest.yml 文件说明
manifest.yml 文件定义了整包的基本信息，包括版本、描述和组件依赖关系：
```yaml
base:
version: 5.14.00.01.B001
description: 社区1711支持webvnc整包，组件开启options：firmware_mgmt:community_enable=True remote_console:webvnc_supported=True nsm:webvnc_supported=True, 可用于社区webvnc整包构建
dependencies:
- conan: firmware_mgmt/1.0.0@openubmc/stable
options:
community_enable: true
```
字段说明：
- `base.version`: 整包版本号
- `description`: 整包描述信息，包含支持的特性和组件配置说明
- `build_type`: 整包构建类型，必须和构建匹配，否则会直接失败
- `dependencies`: 组件依赖列表
- `conan`: 组件名称及版本
- `options`: 组件配置选项
## 如何合并Debug/Release整包
在下载过程中，往往伴随着Debug和Release整包文件是单独存在的，在实际过程中需要进行合并。支持两种不同的方式合并，分别对应整包不同的使用方案。
### 1. 整包方案
合并流程：
1. 分别下载debug/release压缩包文件
2. 将文件迁移到linux系统进行解压
3. 参考[bingo脚本](https://gitcode.com/openUBMC/bingo/blob/main/bmcgo/utils/merge_conan2.py)
4. 执行脚本
```python
python3 merge_conan2.py --base_dir=debug_path/conan_cache --merge_dir=release_path/conan_cache
```
5. 将合并后的debug文件夹单独压缩为一个整体的tar包，支持.tar.gz和.tar.xz格式，参考命令:
```shell
cd debug_path
tar -czf bmc_sdk.tar.gz *
sha256sum bmc_sdk.tar.gz
```
6. 将sha256文件和bmc_sdk.tar.gz整体上传到文件服务器，供后续整包方案下载使用
### 2. 传统方案
将debug和release缓存分别上传conan中心仓
```shell
rm -rf ~/.conan2/p
mv conan_cache ~/.conan2/p
conan upload * -r conan远程仓 -c
```
## 产品引用整包
产品通过在manifest仓库的manifest.yml文件中配置`bmc_sdk_download`和`platform`字段来引用整包。
### bmc_sdk_download配置
`bmc_sdk_download`用于配置整包文件的下载信息：
```yaml
bmc_sdk_download:
url: https://example.com/full_package.tar.gz
sha256: xxxxxx
```
具体整包的sha256值在下载链接文件夹有文本承载，复制即可。
配置说明：
- `url`: 整包文件的下载地址
- `sha256`: 整包文件的SHA256校验值，用于验证文件完整性
下载流程：
1. 构建时会自动下载整包文件到`~/bmc_sdk_download`目录
2. 使用sha256校验文件完整性
3. 解压整包文件（tar.gz格式）
4. 需要同意《BMC软件许可协议》才能下载
### platform配置
在产品的manifest.yml文件中添加以下配置：
```yaml
platform:
conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
options:
rtos_version: rtos_v2
enable_haf: false
package: "community_webvnc_1711" #无需配置文件名最后一段_manifest.yml
```
默认情况下，整包内的平台组件以整包配置为准，产品 manifest 中无需再重复描述这些组件；若确需替换或定制某个平台组件的版本/options，可按"覆盖平台组件"一节的写法直接在 `dependencies` 中写出，无需额外声明。
### 配置说明
- `platform.conan`: 指定要使用的ibmc_sdk版本
- `platform.options`: 整包配置选项
- `rtos_version`: RTOS版本，可选 rtos_v2 等
- `platform.package`: 指定要使用的整包配置，对应整包目录下的manifest.yml
### 完整示例
以下是一个完整的产品manifest.yml配置示例。整包内部组件（如 firmware_mgmt）的版本/options 默认以整包为准，产品端不必再写一遍；如确需覆盖整包内部组件，参见下文"覆盖平台组件"一节：
```yaml
bmc_sdk_download:
url: https://example.com/full_package.tar.gz
sha256: xxxxxx
platform:
conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
options:
rtos_version: rtos_v2
enable_haf: false
package: "community_webvnc_1711"
openubmc_sdk:
conan: "openubmc_sdk/latest@openubmc/stable"
base:
version: "26.06.00.01"
customization: "customization/prototype.py"
dependency_buildtools: dependency/dependency_buildtools.xml
signature:
files:
- file: ${product}/ca/rootca.crl
dst: cms.crl
- file: ${product}/ca/rootca.der
dst: rootca.der
dependencies:
# - conan: firmware_mgmt
# options:
# community_enable: true
- conan: vpd
options:
board_name: openUBMC
# ... 其他依赖组件
```
### 覆盖平台组件（产品同名组件即覆盖）
> 自 openUBMC 26.09 起新增（对应 bingo ≥ 0.7.67 版本）。早期版本在使用整包配置（`platform.package`）时，会拦截产品对平台同名组件的版本/options 定制（报错"不允许对平台组件进行定制"），现已放开为"同名即覆盖"。
整包将平台组件预先打包，提供统一的版本与配置。但在紧急采纳上游修复版本、适配产品专有分支、或仅调整某个组件编译选项等场景下，产品可能需要替换或定制整包中的某个平台组件。bingo 现支持**同名即覆盖**：产品只需在 `manifest.yml` 的 `dependencies` 中对同名组件写出版本/options，即覆盖整包（以及 `openubmc_sdk`）中的定义，无需任何额外声明。
> 上文"完整示例"中被注释掉的 `firmware_mgmt` 即属于整包内部组件：默认不写、继承整包配置即可；确需覆盖时，按下文写法在产品 `dependencies` 中写明。
#### 层间优先级
构建时，产品 manifest 与下层 manifest 按以下优先级合并（高 → 低）：
**产品 > openubmc_sdk > platform**
- 产品优先级始终最高，对同名组件写出版本/options 即生效。
- 产品未写时，`openubmc_sdk` 的同名组件优先级高于 `platform`（整包），即上游基线可盖过整包中的旧版本定制。
> "同名"按组件名判断，例如 `firmware_mgmt/1.0` 与 `firmware_mgmt/1.1` 视为同名，生效方以高优先级层的版本为准。
#### 替换整包组件版本
直接在产品 `dependencies` 中对整包同名组件写出新版本，整包钦定的版本即被产品版本覆盖：
```yaml
dependencies:
- conan: firmware_mgmt/1.1.0 # 整包中的版本被产品版本覆盖;整包中该组件的 options 被清空为 None
```
> **注意**：覆盖按"整条目替换"生效，整包中该组件原有的 `options` 不会自动继承。只写版本、不带 `options` 时，产品侧未写的 `options` 会被清空（置为 None，即恢复默认）。因此若整包原本带了 `options`，仅按上例替换版本会一并丢掉这些 `options`；需要保留时，请在产品条目中把 `options` 显式写回（见下文「同时覆盖版本与 options」）。
#### 定制 options（版本沿用整包）
若只想调整某个组件的编译选项、版本仍沿用整包默认，省略版本号即可，版本由整包补齐：
```yaml
dependencies:
- conan: firmware_mgmt # 无版本号 → 版本由整包补齐
options:
community_enable: true
```
#### 同时覆盖版本与 options
版本与 options 也可在同一组件上同时写明，二者都按产品侧覆盖整包（最常用的覆盖方式）：
```yaml
dependencies:
- conan: firmware_mgmt/1.1.0 # 版本覆盖整包
options:
community_enable: true # options 同时覆盖整包
```
#### 清空整包组件 options
若整包中某组件带了 options，而产品侧希望清空这些 options（恢复默认），对该组件**仅写名字、不带 options** 即可，整包中的 options 会被清空（置为 None）：
```yaml
dependencies:
- conan: firmware_mgmt # 版本由整包补齐；整包中该组件的 options 被清空为 None
```
#### 覆盖告警
为便于平台/SDK维护者审计，`bingo build`（出包阶段）在同名组件的版本/options发生覆盖时，会在构建日志中打印告警。分别对应"替换版本"、"定制options""清空options"三种场景各自输出的告警；当同一组件的版本与options同时变化时，二者会合并为一条告警（以`;`连接）输出：
```shell
WARN: 组件 firmware_mgmt 被覆盖: 版本 firmware_mgmt/1.0.0 → firmware_mgmt/1.1.0; options {'community_enable': True} → None
WARN: 组件 firmware_mgmt 被覆盖: options {'community_enable': False} → {'community_enable': True}
WARN: 组件 firmware_mgmt 被覆盖: options {'community_enable': True} → None
WARN: 组件 firmware_mgmt 被覆盖: 版本 firmware_mgmt/1.0.0 → firmware_mgmt/1.1.0; options {'community_enable': False} → {'community_enable': True}
```
覆盖行为一览：
| 产品对整包同名组件的写法 | 生效版本 | 生效 options | 是否告警 |
| ---- | ---- | ---- | ---- |
| 仅写名字，整包无 options | 整包版本补齐 | 无 | 否 |
| 仅写名字，整包带 options | 整包版本补齐 | 清空（None） | 是 |
| 写出新版本（与整包不同，可同时写 options） | 产品版本 | 产品 options | 是 |
| 版本相同，options 不同 | 整包版本 | 产品 options | 是 |
| 版本与 options 与整包完全一致 | 不变 | 不变 | 否 |
> 当版本与 options 与整包完全一致（或仅写名字且整包本身也无 options）时，不触发告警。
### 发布包配置
在构建发布包时，需要在tosupporte/manufacture配置中添加对应的platform配置：
```yaml
tosupporte:
default:
platform:
conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
options:
rtos_version: rtos_v2
enable_haf: false
package: "community_webvnc_1711"
package_name: "openUBMC/openUBMC-CMT_${version}.zip"
build_type: release
```
### 三种引用方式的区别
产品引用整包有三种方式：
#### 1. 使用整包文件（推荐）
通过`bmc_sdk_download`下载bmc_sdk整包文件，然后通过`platform.package`引用：
```yaml
bmc_sdk_download:
url: https://example.com/full_package.tar.gz
sha256: xxxxxx
platform:
conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
options:
rtos_version: rtos_v2
enable_haf: false
package: "community_webvnc_1711"
```
特点：
- 需要将整包上传到文件服务器，校验sha256值
- 整包文件自动下载并解压到`~/bmc_sdk_download`目录
- 适合社区统一发布的整包
- 需要同意许可协议才能下载
#### 2. 使用本地整包目录
手动指定参数--debug_platform_path，适用于手动指定整包路径联调
直接通过`platform.package`引用本地整包目录配置：
```yaml
platform:
conan: ibmc_sdk/5.14.00.01.b001@openubmc/stable
options:
rtos_version: rtos_v2
enable_haf: false
package: "community_webvnc_1711"
```
特点：
- 需要手动将整包解压到指定目录
- 适合本地开发或自定义整包
#### 3. 使用Conan包（传统方式）
通过`platform.conan`引用Conan包：
```yaml
platform:
conan: "ibmc_sdk/5.13.00.01.b002@openubmc/stable"
options:
rtos_version: rtos_v2_1712
enable_haf: false
```
特点：
- 不需要整包文件
- 通过Conan仓库管理SDK版本
- 适合传统SDK管理方式
## 使用流程
### 使用bmc_sdk_download自动下载
1. **配置引用**：在产品manifest.yml中配置bmc_sdk_download和platform字段
2. **构建产品**：使用bingo工具构建产品包，构建时会自动下载并解压整包
```bash
bingo build -b openUBMC
```
3. **同意协议**：下载时需要同意《BMC软件许可协议》
- 可设置环境变量自动同意：`export OPENUBMC_LICENSE=true`
- 或在构建时手动输入Y同意
4. **验证下载**：整包文件会下载到`~/bmc_sdk_download`目录，并使用sha256校验
### 手动使用整包目录
1. **获取整包**：从发布渠道获取整包文件（tar.gz格式）
2. **解压整包**：使用`tar -xzf <整包文件名>.tar.gz`解压到指定目录
3. **配置引用**：在产品manifest.yml中配置platform字段，指向解压后的整包目录
4. **构建产品**：使用bingo工具构建产品包
```bash
bingo build -b openUBMC --debug_platform_path=/test/full_packages
```
## 注意事项
1. 整包配置名称需与产品需求匹配
2. platform.package配置将直接引入产品manifest.yml
3. 更新整包版本时，需同步修改platform.package配置为新的整包名称
4. 使用bmc_sdk_download下载整包时：
- 确保网络可访问下载地址
- sha256校验值必须正确，否则下载会失败
- 下载需要同意许可协议
- 整包会下载到`~/bmc_sdk_download`目录并自动解压
5. 本地已有整包目录时，可直接使用platform.package引用，使用参数--debug_platform_path指定整包路径
6. 使用platform.conan方式时，需要确保Conan仓库中有对应的SDK包版本
7. 产品对整包同名组件写出版本/options 即覆盖整包默认配置（同名即覆盖，无需额外声明，详见"覆盖平台组件"一节）。覆盖发生时构建日志会打印告警以便审计；仅在确需替换时才写，避免无意覆盖整包默认配置。
---
# 产品构建
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/product_build.html
> Language: zh
- openUBMC各个组件有其独立的构建代码以及代码仓，在manifest仓中会对所有参与构建的代码进行整合，通过拉起一个主组件解析依赖(conan内置解析逻辑)，然后由依赖逻辑进行并发构建
- 构建以manifest仓作为总入口，且将所有的构建能力都集成在`bingo`命令中以供开发者便捷使用
# 构建命令总览
- 以下为`bingo`的帮助文档，这个帮助文档在`manifest`仓路径(也就是产品路径)和组件仓路径下显示内容不同，在产品构建时只需关注在manifest仓下的行为
```shell
# 在manifest路径下执行命令
[04:51:58 root(1110):/home/workspace/codehome/manifest]# bingo --help
Integrated commands
build 构建出包
publish 构建版本发布包，-sc参数指定ToSupportE编码，-z参数指定ToGPD生产装备编码
qemu 创建仿真环境，运行构建的产品包
fetch 基于参数指定的组件版本拉取全量代码
Misc commands
help 获取命令帮助
输入"bingo -h"获取子命令帮助
[04:52:01 root(1110):/home/workspace/codehome/manifest]#
```
- 从上面返回的信息，可以看到我们能够使用的命令，构建产品以及发布包只使用到其中一个命令，当前`build`命令与`publish`效果相同。
```shell
[04:52:01 root(1110):/home/workspace/codehome/manifest]# bingo build --help
构建BMC
options:
-h, --help show this help message and exit
-b BOARD_NAME, --board_name BOARD_NAME
单板包，可选值为build/product/|...>/下的目录名
-bt BUILD_TYPE, --build_type BUILD_TYPE
构建类型，可选：debug（调试包）, release（正式包）, dt（开发者测试包）
--stage STAGE 包类型，可选值为: dev(调试包), rc（预发布包）, stable（发布包）
默认：dev
--verbose 使能conan构建详细日志打印
-ucc, --update_conan_cache
全量更新本地conan缓存
-r REMOTE, --remote REMOTE
conan仓别名，请检查conan remote list查看已配置的conan仓
默认: openUBMC_dev
-sc SUPPORTE_CODE, --supporte_code SUPPORTE_CODE
待发布的SupportE编码，可选值参考单板manifest.yml/tosupporte
默认：default
-q, --enable_qemu QEMU打包使能
-qi, --qemu_in QEMU使能，自动拉起qemu环境
-as, --asan Enable address sanitizer
-v VERSION, --version VERSION
构建版本号，不指定时从manifest.yml读取
-t TARGET, --target TARGET
构建目标，请查看build/target目录, 支持的目标：
personal
publish
[04:59:33 root(1110):/home/workspace/codehome/manifest]#
```
## 一、构建产品包命令
1. 直接构建`hpm`包
- 现在，开始构建一个`hpm`包，查看上面的`help`文档，可分析其具体含义，命令执行结束后，可在`manifest`目录下的`output`目录下找到构建出来的`hpm`包
```shell
# 进入到集成构建环境
cd manifest
# -t personal: 构建目标，个人构建指 hpm 包
# -b openUBMC: 单板名，查看帮助文档，可以看到支持哪些单板
# -bt release: 构建类型，release正式包
# --stage rc: 包类型，预发布包
bingo build -t personal -b openUBMC -bt release --stage rc
```
- 以下为列出的生成件目录下文件，其中`rootfs_openUBMC.hpm`即为产品包
```shell
[05:22:48 root(1110):/home/workspace/codehome/manifest/output]# ls -la
total 70172
-rw-r--r-- 1 root root 1349 Mar 12 17:22 openubmc.perf
-rw-r--r-- 1 root root 54813 Mar 12 17:22 package.lock
drwxr-xr-x 5 root root 4096 Mar 7 14:32 packet
-rw-r--r-- 1 root root 0 Mar 12 17:20 prof.perf.lock
-rw-r--r-- 2 root root 70144173 Mar 12 17:22 rootfs_openUBMC.hpm
[05:23:04 root(1110):/home/workspace/codehome/manifest/output]#
```
2. 集成发布的组件场景：在组件发布以后，我们需要将其版本集成到产品包中，具体修改方法如下：
- 我们需要在`subsys`目录下添加新增的组件，组件属于什么类型，则添加到相应类型下，`subsys`目录下有`rc`和`stable`区分，组件发布对应的类型并在`rc`和`stable`目录下同时更改，这里的示例为`rc`版本，`stable`版本后缀要更新为`stable`
```yaml
# yaml-language-server: $schema=../../schema/subsys.rc.schema.json
dependencies:
- conan: "rackmount/1.20.97@openUBMC.release/rc"
- conan: "Kunpeng/1.10.2@openUBMC.release/rc"
```
- 在`manifest.yml`文件中配置添加的组件
新引入的组件，要在产品目录下配置相应的依赖，否则不会集成到产品包当中，`dependencies`
字段中，每配置一个组件，则集成进一个组件，这里不要去填版本号，填入版本号后，更新组件版本时，则需要变更多个文件
```yaml
dependencies:
- conan: "huawei_secure_c"
- conan: "kmc"
- conan: "Signature_Verify_CBB_Library"
- conan: "sqlite3"
- conan: "openssh"
```
## 二、构建发布包命令
- 构建发布包命令与上面的命令稍有差异，如下所示
```shell
# 进入到集成构建环境
cd manifest
# -t publish: 构建目标，发布包
# -sc default: 发布包编码，这个编码可以在manifest.yml文件中的 tosupporte 字段中查询
# -b openUBMC: 单板名，查看帮助文档，可以看到支持哪些单板
# -bt release: 构建类型，release正式包
# --stage stable: 包类型，发布包
bingo build -t publish -sc default -b openUBMC -bt release --stage stable
```
- 执行完成以后，在`output`目录下会生成文件，如下为`output`树（仅供参考）
```shell
[07:05:30 root(1110):/home/workspace/codehome/manifest/output]# tree
.
|-- openUBMC.perf
|-- package.lock
|-- packet
| |-- openUBMC
| | |-- openUBMC-CMT_1.00.00.00.zip
| `-- inner
| |-- release
| | |-- package_openUBMC.lock
|-- prof.perf.lock
`-- rootfs_openUBMC.hpm
4 directories, 6 files
[07:05:31 root(1110):/home/workspace/codehome/manifest/output]#
```
---
# 如何使用schema文件描述规范
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_guide/schema.html
> Language: zh
本文讲解openubmc构建工程如何管理自己的配置文件。
## 背景
openubmc构建工程广泛采用机制和策略解耦，构建代码和产品配置划分出明确的业务边界，两者使用manifest.yml、subsys等配置文件互动。
1. 构建工具与代码分离会产生版本匹配。
2. 功能引入和变更如何赋能和指导开发者配置。
一般的做法是在设计文件或更新wiki中描述需要配置什么属性、这些属性需要什么样的值、哪些是必须哪些是可选等要求。
文档传递在实践过程效果不明显，定义和使用之间脱节，开发者感知低，无法高效传递，容易导致不正确的配置上库，降低了整体效率。
## 流程
openubmc的构建工程采用自动化的工程和工具解决，构建工程提供的每个json/yaml文件的格式都使用json schema描述，通过schema文件自动传递规范和要求，看护配置文件正确性，构建过程会提前检查配置正确性，提前配置，并且schema校验一般不接受。
openubmc要求构建机制影响策略配置的都需要按如下流程完成设计和开发：
1. 设计新机制、新功能时优先完成配置项值类型、可选值、可选必选定义，分析兼容性影响。
2. 分配配置项兼容性，一般按兼容处理，不影响既有配置。如果的确存在影响的，需要协同产品共同完成配置适配。
> [!WARNING]
>构建工程会独立演进，维护工具的兼容性是非常重要，一个完全兼容的工具可以减少大量的适配成本，广泛适用于伙伴构建。
### yaml文件schema标注
yaml文件标注使用`yaml-language-server: $schema=`格式，其中url支持本地文件或远程文件，示例：
```yaml
# yaml-language-server: $schema=../../../schema/manifest.schema.json
base:
version: "5.01.00.01.B004"
customization: "customization/prototype.py"
```
### json文件schema标注
json文件标注需要在顶层对象中添加`$schema`配置项指定schema文件路径，示例：
```yaml
{
"$schema": "http://json-schema.org/draft-07/schema#",
}
```
## 开发者使用
开发者需要在vscode中安装`redhat.vscode-yaml`插件，该插件提供了格式提醒功能，辅助开发者正确配置。
schema校验只在版本构建场景开启，开发者修改manifest以及subsys配置时，建议执行一次`bmcgo build -t publish`命令。
> [!TIP]
> schema校验计划在所有场景默认开启。
---
# 构建常见问题
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/build_project.html
> Language: zh
# 构建时提示输入git的账号密码，出现Username for xxx Password for xxx，或提示权限403 错误
报错原因是使用https访问代码仓，未正确配置git凭证导致需要用账号密码鉴权，请参考以下步骤设置git凭证：
1. 首先参考gitcode文档 [创建token](https://docs.gitcode.com/docs/help/home/user_center/security_management/user_pat)。
2. 创建 `~/.git-credentials文件`，添加 `https://token:token@gitcode.com`，其中token是第一步创建的凭证。
3. 使能配置：`git config --global credential.helper 'store --file ~/.git-credentials'`。
* 备注：不同git平台创建凭证的方式有差异，请参考官方文档
# 产包出包build时卡在mount阶段一直失败
1. 使用的镜像权限不足，mount失败，此时使用的是旧版bingo，需要在运行镜像 `docker run`的时候加上`--privileged=true`参数。
2. 升级bingo版本，使用最新bingo，优化了mount的权限逻辑。
# 构建时报错：`No remote 'openubmc_dev' defined in remote`
请参考[openUBMC社区conan仓使用指导](https://discuss.openubmc.cn/t/topic/186)。
# 构建时报进程异常退出，报错：`internal compiler error: Killed (program cciplus)`
请参考[openUBMC构建运行内存不足问题解决说明](https://discuss.openubmc.cn/t/topic/239)。
# manifest仓出包失败，报错：组件 `was not found in remote 'openubmc_dev'`
1. 原因是conan仓中不存在指定版本的组件，可使用`conan search 'name/*' -r openubmc_dev`获取`openubmc_dev`组件仓已发布的`name`组件版本清单，选择正确的组件版本，如果组件未发布的请发布后使用。
2. 在manifest中引入了错误的组件名包，检查build/subsys下的组件的版本配置。
# 构建组件失败，报错：`CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage`
1. 在编译环境查看`/opt/RTOS`和`/opt/hcc_arm64le`文件夹是否存在。若不存在，则环境缺少编译需要的依赖组件。
2. 通过初始化本地环境 `bingo build -t install_sdk`解决。
# 本地出组件dev包测试时，在manifest执行 bingo build出现报错：`下载组件（xxx/xxx.dev/dev）的构建配方（recipe）失败，退出码：1`
本地缓存被 `rm -rf ~/.conan/data`（conan1）或`rm -rf ~/.conan2/p`（conan2）删除，重新在组件仓执行 `bingo build`。
# 本地出组件构建，bingo build出现报错：具体错误为闭源组件触发源码构建，类似错误为`ERROR in xx Method` `ERROR XX pwd`等
这种问题一般为开发者本地bmc_sdk和当前版本依赖不配套：
1. 切换到对应版本构建时，应使用官网相应版本bmc_sdk初始环境，如：切换到2509版本构建时，应使用官网2509版本bmc_sdk初始环境。
2. 简易操作为：下载官网bmc_sdk，替换本地~/sdk、~/rtos_compiler文件夹（先删除本地再复制）
# conan升级2.0后，本地出现组件构建bingo build出现报错：具体错误为`ERROR: luajit/xx@openubmc/stable: Error in source() method`
这种问题一般为开发者本地环境不匹配：
1. 升级最新bingo工具。
2. 切换到对应版本的manifest，执行一次bingo build -t install_sdk
# conan升级2.0后，本地出组件构建bingo test出现报错：具体错误为闭源组件缺包触发源码构建，类似错误为`ERROR in xx Method`
短期内bingo test应更改为bingo test -jit,附加-jit参数即可运行
# 构建时出现`Couldn't checkout xx git -c xx checkout 'xxxxxx' returned non-zero exit status 128, reference is not a tree`
应排查是否在组件发布后又变更了git信息，如删除了commit，强推送了git提交？
开发者应遵守社区规范，版本发布后不应修改git信息树，如发生变更应重新推送组件版本。
# 整包构建时出现长时间等待，排查log后发现是卡在conan认证失效
1. 升级最新bingo，版本做了优化，如认证失效会提示重新登录。
2. 如老版本想解决此问题，可进入task.log文件按提示输入账号密码也可。
# 自签名报错问题，具体错误：`ERROR: 任务 work.task_buildgppbin 执行失败，打开了自签名模式但未找到待签名的uboot文件，构建失败`
1. 排查本机是否存在待签名的uboot，ls -al ~/sdk，如不存在文件hi1711_xxx(带时间戳结尾的文件), 需要官网下载bmc_sdk。
2. 下载官网bmc_sdk，替换本地~/sdk, 确保带时间戳结尾的文件存在。
# Linux下执行 `docker` 命令提示 "permission denied" 或 "connect to the Docker daemon socket"
**原因：** Docker守护进程默认绑定Unix socket而不是TCP端口，该socket默认属于`root`用户。普通用户执行命令需要`sudo`权限，或者需要被加入到`docker`用户组。
**解决方案：**
1. 创建docker用户组（如果不存在）：
```bash
sudo groupadd docker
```
2. 将当前用户加入docker组：
```bash
sudo usermod -aG docker $USER
```
3. **重要：** 执行完上述命令后，需要注销并重新登录系统（或重启）才能生效。
# 运行构建脚本 `build.py` 时报错 "FileNotFoundError: 找不到 SDK 文件"
**原因：** 传入的SDK路径不正确，或者使用了脚本无法识别的相对路径。
**解决方案：**
请在 `-s` 参数中使用**绝对路径**。
例如：
```bash
python3 build.py -s /home/user/downloads/bmc_sdk.zip ...
```
# 构建时报错 "failed to solve with frontend dockerfile.v0" 或语法错误
**原因：** 您的Docker版本过低，或者未启用BuildKit构建引擎（新方案依赖BuildKit特性）。
**解决方案：**
1. 确保Docker版本 \>= 18.09。
2. 尝试手动开启BuildKit环境变量后再次运行：
```bash
export DOCKER_BUILDKIT=1
python3 build.py ...
```
# 容器启动后立即退出 (Exited)
**原因：** Docker容器必须有一个前台进程在运行，否则会自动退出。
**解决方案：**
请确保在 `docker run` 命令中加入了 `-itd` 参数，或者在命令末尾指定了保持运行的指令（如 `sleep infinity` 或 `/bin/bash`）。使用 `sleep infinity` 保持容器常驻时，建议同时配置 `--init`，避免构建异常中断后子进程无法被可靠回收。
如果是使用本地构建的镜像，推荐命令：
```bash
docker run -itd --init --pids-limit=32768 --name openubmc openubmc/dev:latest sleep infinity
```
# 容器内 `apt-get update` 或 `conan` 连接失败
**原因：** 宿主机的网络环境存在DNS污染或需要代理才能访问外网。
**解决方案：**
1. **DNS问题**：尝试重启Docker服务。
```bash
# Linux
sudo systemctl restart docker
```
2. **代理问题**：如果宿主机配置了VPN或代理，容器内默认不会自动继承。需要在 `docker run` 时通过环境变量传入代理配置：
```bash
docker run -e http_proxy=http://your_proxy:port -e https_proxy=http://your_proxy:port ...
```
---
# 构建目标描述文件管理
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/concept_principle/Build_Target_Description.html
> Language: zh
`bingo build`命令支持基于任务的多进程并行调度，其`-t`参数依赖一个目标描述文件，该文件是yml格式，具体参考 [构建框架-目标描述文件](./build.md#目标描述文件)
或者参考已实现的目标，代码位置 `bingo/target`
目标描述文件原本由产品管理，考虑其中的目标为多个产品共用，当前已提取至bingo管理。
## 产品目标描述文件定制
产品可以继承或重写目标描述文件，bingo构建时会优先查询当前目录（build/target）是否存在`-t`指定的目标描述文件，如果文件存在则会使用产品自定义的目标描述文件。
只有产品未定制目标描述文件时才会使用bingo定义的目标描述文件。
> [!TIP]
> 示例：
> `bingo build -t publish`用于XX产品版本发布，如果XX产品需要自定义发布流程，可在manifest/build/target目录下新增`publish.yml`文件并编写目标实现逻辑，bingo构建时检查到XX产品有自定义的`publish`目标，则会直接加载，此时不会加载bingo定义的`publish`目标。
> 如果YY产品没有自定义`publish`目标，则会使用bingo定义的`publish`目标描述文件。
## 防冲突机制
目标描述文件的文件名代表了目标的功能和应用，如果产品在build/target目录新增了目标描述文件且该目标在bingo中不存在，需要在bingo的target目录中创建一个文件名相同的文件，内部增加注释注意（什么产品使用此目标完成了什么功能）。
上述防冲突机制用于产品向bingo申明某一名称的目标已被占用，避免bingo新增功能占用产品已经实现的目标，防止目标名称冲突。
对于产品未申明目标，bingo有优先使用权。
> [!TIP]
> 示例：
> bingo新增一个无任何产品申明的`test_target`这一目标实现某种公共能力。XX产品报告因产品自定义了`test_target`目标导致无法使用公共能力的，需要产品修改自己的目标描述文件的文件名。
---
# 构建策略
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build/concept_principle/build.html
> Language: zh
# 装配式构建架构
为满足构建场景和目标，实现构建系统的灵活定制和可扩展能力，openUBMC重构了构建框架，形成一套任务编排框架，其核心是任务标准化、目标可描述和自动化调度。
- 任务标准化：框架提供了一个任务基类，所有任务都继承该基类，具有相同的参数传递方式、任务创建逻辑，统一任务执行和产物收集，为调度核心提供统一的调度范式；
- 目标可描述：使用文本文件描述完成构建目标所需要的任务拓扑，包括需要执行任务类、依赖的任务、子任务等。
- 自动化调度：调度器会分析目标描述文件得到完整的任务拓扑，依据任务间依赖关系和任务状态，创建多进程实例化任务类，实现并行构建。
装配式构建框架由全局配置、基础任务类、任务实现、目标描述文件、多进程调度框架、性能测试工具、全局状态管理进程功能。
## 全局配置
- 为了在装配式方案调用任务时传递参数，我们定义了一个Config对象，该对象记录了公共配置清单。
## 基础Work类
- Work类定义了run和install方法，还提供了一些具体任务实现需要的基础能力，基础类初始化需要还会传入一个全局配置对象，为后续任务执行提供输入。
```python
import sys
import os
import logging
from colorama import Fore, Back, Style
from iutils.config import Config
from multiprocessing import Process
cwd = os.path.join(os.getcwd(), os.path.dirname(__file__))
sys.path.append(f"{cwd}/../")
class Work(Process):
name = "WorkBase"
description="基础类"
work_name = ""
def __init__(self, config: Config, work_name=""):
Process.__init__(self)
self.config = config
self.work_name = work_name
# 子类必须实现run方法,未实现时异常
def run(self):
logging.info(f"{__file__} error")
raise Exception
# 安装函数，将各work的产出安装到config.rootfs目录中
def install(self):
pass
# 命令执行标准接口，具体实现已省略
def run_command(self, command, ignore_error=False, show_log=False, sudo=False, command_echo=True, timeout=600, command_key = None):
pass
# 带颜色的错误日志，具体实现已省略
def log_error(self, msg, frame_cnt=1):
pass
# 带颜色的告警日志，具体实现已省略
def log_warn(self, msg, frame_cnt=1):
pass
```
## 任务实现
- 任务的实现需要从Work类继承，从Work类定义可知任务类从Process类继承了多进程执行能力，调度框架正式基于Proess的能力实现了多进程调度执行。
- 如下是简单的环境初始化文件示例。
```python
#!/usr/bin/env python
# coding:utf-8
import os
import sys
import subprocess
import jsonschema
import json
import yaml
import logging
cwd = os.path.join(os.getcwd(), os.path.dirname(__file__))
sys.path.append(f"{cwd}/../")
sys.path.append(f"{cwd}/../../")
sys.path.append(f"{cwd}/../../../")
from works.work import Work
from iutils.config import Config
class WorkPrepare(Work):
def __init__(self, config: Config, work_name = ""):
""" 任务初始化，会传入一个Config全局配置对象，实现全局配置归一 """
super(WorkBuildCommon, self).__init__(config, work_name)
def run(self):
# 任务执行，此处实现任务逻辑
def install(self):
# 安装阶段
# 提供脚本单独调试运行能力
if __name__ == "__main__":
cfg = Config()
cfg.parse_args()
wk = WorkEnvirPrepare(cfg)
wk.run()
```
- 所有任务都有if __name__ == "__main__":的代码，所有脚本都可以单独调用，调用时需要进入build目录，再执行python3 works/work_prepare.py
## 目标描述文件
- 目标描述文件采用yaml格式，描述内容有任务名、任务类、子任务和依赖任务等。
```yml
# 任务示例，当任务被依赖时需要
- name: work.prepare_env
# 任务python类，由独立进程执行
klass: works.work_prepare.WorkPrepare
# 子任务列表，当klass执行完成后递归执行子系统，执行逻辑完全相同
subworks:
- name: work.dependency.bison
klass: works.dependency.work_install_bison.WorkInstallBison
- name: work.dependency.flatbuffers
klass: works.dependency.work_install_flatbuffers.WorkInstallflatbuffers
- name: work.build.conan_debug_rc
klass: works.build.work_build_conan.WorkBuildConan
# 任务的依赖列表，可以等待多个任务，只有当所有依赖都执行完成后当前任务才会执行
wait:
- work.prepare_env
# 任务私有配置，构建框架会查询任务是否有set_xxx方法（以下示例则是查询set_stage(self, value)方法是否存在）
# 随后调用set_xxx方法配置任务。
work_config:
stage:
rc
# 全局任务配置，不同于任务私有配置，该配置会作用于全局配置对象，调用配置对象的set_xxx方法变更全局配置对象的值
target_config:
build_type: release
```
- 如示例注释，任务目录为扩展框架的配置能力，我们定义了target_config和work_config配置能力，前者配置Config对象，后者配置Work对象。在调度框架中会解释两者的作用。
## 多进程调度框架
- 我们采用了多进程调度方案，每个任务都是在独立进程中执行，每一个任务（包括子系统）都有创建任务、等待依赖、执行任务和创建子进程4个运行阶段，以及运行、完成、错误3种状态。
1. 创建任务：创建一个任务进程，
2. 等待依赖：多进程意味着不能直接共享状态，为此我们创建了一个全局状态管理进程，任务会向全局状态管理进程轮询被依赖任务的状态。
3. 执行任务：依赖任务都已完成后开始执行任务的run方法。当任一依赖任务失败时当前任务报错并退出执行；
4. 创建子进程：每个子进程重复父进程的4个阶段，周而复始，直至所有任务执行完成，构建目标也就达成了。
- 在创建子进程阶段会将任务自己的Config对象传递给子进程，这就是target_config类存在的意义，这个对象会由调度框架在任务的调度链往子进程方向传递。 work_config只是配置任务，可以修改也可以不修改Config对象，这完全是任务自己的行为，不受框架限制。
- 任务状态
- 任务可能执行成功也可能失败，每个进程都会对外报告自己的状态，当前的机制要求任一任务失败则会终止其它任务，整体报错退出。
- 各任务处于不同的进程中，任务状态同步需要借助进程间通信完成，为此我们创建了一个全局状态管理进程用于进程间状态同步，该进程会在TCP:23456上接收任务上报的执行状态报文并记录在全局任务状态表中，也能接收任务状态查询报文并返回指定任务的运行状态。 任务等待过程就是向全局状态管理进程发送TCP报文轮询状态。
---
# 概述
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/build_overview.html
> Language: zh
欢迎来到openUBMC构建升级，本文档将介绍openUBMC的构建和升级概念原理、具体操作、常见问题，以及调测环境准备事项，方便开发者快速了解构建升级基本概念，以及完成相关操作。
[**构建**](./build/concept_principle/build.md)
介绍openUBMC构建相关概念原理，以及具体操作指导和常见问题。
[**升级**](./upgrade/concept_principle/upgrade_principle.md)
介绍openUBMC升级相关概念原理，以及具体操作指导和常见问题。
---
# 整机环境搭建
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/debug_env_setup/system_env_setup.html
> Language: zh
iBMC 与 openUBMC 均为 BMC 固件。iBMCv2、iBMCv3 是 iBMC 的不同代际版本，openUBMC 为社区版本。当需要在 iBMC 整机环境上开展 openUBMC 的构建、部署和调测时，需要将整机升级到 openUBMC。整机升级分为两种场景：iBMCv3 升级到 openUBMC 和 iBMCv2 升级到 openUBMC。两种场景都需要先升级过渡包，再升级 openUBMC 社区包。升级完成后，整机环境可用于后续的构建、部署和调测。
# 升级前准备
- 确认整机设备型号，记录当前 BMC 版本号
```shell
ipmcget -d version
```
- 准备串口线（RJ45 或 USB 转串口），连接 BMC 串口用于调试
- 准备网线连接 BMC 管理口，确保可 SSH 登录
- 准备 SSH/SFTP 客户端工具，用于登录 BMC 和上传升级包
- 准备过渡 HPM 包（联系 PAE 获取）
- 准备 openUBMC 社区包 `rootfs_openUBMC.hpm`：可从 [openUBMC 官网](https://www.openubmc.cn/zh/download) 下载社区发行版，或参考[一键出包](https://www.openubmc.cn/docs/zh/development/quick_start/build_your_own_bmc.html) 本地构建
- 确保服务器供电稳定，升级过程中不可断电
- 确保 BMC 上 `/tmp` 目录至少预留 100MB 空间
```shell
du -sh /tmp
```
- 确保 BMC 空闲内存不低于 100MB，CPU 空闲率不低于 20%
```shell
free -m
top
```
# iBMCv3 升级到 openUBMC
iBMCv3 无法直接升级到 openUBMC 社区包，需要先升级过渡包，再升级社区包。与 iBMCv2 升级相比，iBMCv3 无伙伴根证书兼容问题，且 26.03 及之后版本支持 SSL 证书内置。
## 出包
### 咨询 PAE 获取过渡包
联系 PAE 获取用于过渡升级的 HPM 包。
### 获取 openUBMC 社区包
从社区获取 `rootfs_openUBMC.hpm` 包，或本地构建 hpm 包。
## 升级
### 确认当前 V3 环境
```shell
ipmcget -d version
# 记录当前 Active 和 Available 分区版本号
```
### 上传过渡包并升级
通过 SFTP 将 HPM 包上传到 BMC 的 `/tmp` 目录：
```shell
scp transition.hpm Administrator@:/tmp/
```
也可通过 Web 界面“系统管理 → 固件升级”上传。上传前确保 `/tmp` 空间充足：
```shell
rm -rf /tmp/*.hpm /tmp/*.tmp
```
执行升级：
```shell
ipmcset -d upgrade -v /tmp/transition.hpm
```
BMC 固件升级完成后，默认自动重启使新版本生效。如未自动重启，请手动重启 BMC 使新版本生效。重启后执行 `ipmcget -d version`，预期 Active 分区版本号变为过渡包版本号。
### 确认过渡包升级成功
```shell
ipmcget -d version
```
### 上传 openUBMC 社区包并升级
```shell
scp rootfs_openUBMC.hpm Administrator@:/tmp/
ipmcset -d upgrade -v /tmp/rootfs_openUBMC.hpm
```
升级完成后 BMC 自动重启使新版本生效。重启后执行 `ipmcget -d version`，预期 Active 分区版本号变为 openUBMC 社区包版本号，Available 分区为升级前版本。
## 升级后操作
### 导入 SSL 证书（26.03 之前版本需要）
```shell
# 通过 SSH 登录 BMC
# 导入 SSL 证书（文件名和密码按自己生成的证书为准）
ipmcset -t certificate -d import -v /tmp/server.p12 1 123456
```
26.03 及之后版本支持 SSL 内置，在 `manifest 目录/build/product/BMC/openUBMC/rootfs/opt/bmc/trust/partner/ssl` 下放置密码为空的 SSL 证书文件出包即可，无需手动导入。
### 自签名（可选）
如果选择使用自签名固件包，则后续只能升级该签名证书生成的 HPM 包。使用 `bingo` 进行自签名构建。
## 升级后验证
1. 查看版本号确认升级成功
```shell
ipmcget -d version
# Active 分区版本号应等于升级包版本号
# Available 分区版本号为升级前的旧版本
```
2. 验证 Web 界面可正常访问
3. 验证 SSH/串口登录正常
4. 验证基本命令可用
```shell
ipmcget -d ipinfo
ipmcget -d powerstatus
```
5. 验证网络连通性
```shell
ping
```
## V3 升级常见问题
以下为 V3 升级过程中的高频问题，更多问题可参考[升级常见问题](../upgrade/upgrade_faq.md)。
### 升级卡住显示“请等待”
上一次升级被中断后触发了自愈机制，此时 app.log 中会出现 `resume files(%s) exist and will be upgraded again` 日志，表示检测到上次未完成的升级任务，系统会自动再次执行升级。解决方法：
```shell
systemctl restart bmc_core
rm -rf /data/upgrade_resume/reset/
systemctl restart bmc_core
```
### 升级成功但版本号未变
升级实际成功，但新版本启动失败后自动回切到原分区。排查步骤：
1. 通过串口查看启动日志，确认失败原因
2. 查看 app.log，搜索 `get current nvm_active`，如果分区从 `nvm_temp` 变为 `nvm_active` 则说明升级失败回滚
3. 常见原因：
- 组件服务启动检查失败 → 查看串口日志定位具体组件
- 安全启动拦截 → 需要清根操作
- 内存不足 → 清理文件后重启
### 升级报错：机型不匹配
日志显示 `sys-uid not in update.cfg's ProductUIDList`，说明升级包与当前环境机型不匹配。解决方法：
1. 先尝试回滚：`ipmcset -d rollback`
2. 构建过渡版本：修改 manifest 中 update.cfg 的 ProductID 为 65535（匹配所有机型），出包后先升级过渡包，再升级目标版本
### 升级包过旧
1. **DowngradeAllowed=false**：不允许降级
```shell
busctl --user set-property bmc.kepler.bmc_upgrade \
/bmc/kepler/UpdateService/UpdateMgmt \
bmc.kepler.UpdateService.UpdateMgmt DowngradeAllowed b true
```
2. **RevisionNumber 过大**：日志显示 `base version is not matched and cannot be allowed to upgrade`
### 传包失败导致签名校验失败
`/tmp` 目录空间不足导致上传的包不完整：
```shell
rm -rf /tmp/*.hpm /tmp/*.tmp
# 重新上传升级包
```
### 升级后网络不通
1. 检查 IP，若不符合预期重新配置：
```shell
ipmcset -d ipaddr -v
```
2. 检查路由和防火墙规则：
```shell
route -n
iptables -t filter -nvL
```
# iBMCv2 升级到 openUBMC
iBMCv2 无法直接升级到 openUBMC，需要先升级过渡包，再升级社区包。整体流程与 V3 升级类似，但 V2 有额外的签名兼容性问题需注意。
## 出包
出包步骤与“iBMCv3 升级到 openUBMC”的出包步骤相同，包括过渡包获取和社区包制作。
## 升级
升级流程与“iBMCv3 升级到 openUBMC”相同，分四步：
1. 确认当前 V2 环境：执行 `ipmcget -d version`，记录当前 Active 和 Available 分区版本号
2. 上传过渡包并升级：执行 `ipmcset -d upgrade -v /tmp/transition.hpm`，升级完成后 BMC 自动重启，重启后执行 `ipmcget -d version`，预期 Active 分区版本号变为过渡包版本号
3. 确认过渡包升级成功：执行 `ipmcget -d version`，确认 Active 分区版本号已更新为过渡包版本号
4. 上传 openUBMC 社区包并升级：执行 `ipmcset -d upgrade -v /tmp/rootfs_openUBMC.hpm`，升级完成后 BMC 自动重启，重启后预期 Active 分区版本号变为 openUBMC 社区包版本号
V2 特有的伙伴根证书、签名格式等注意事项见本文档“V2 升级常见问题”章节。
## 升级后操作
与“iBMCv3 升级到 openUBMC”的升级后操作相同，包括 SSL 证书导入和自签名配置。
## 升级后验证
与“iBMCv3 升级到 openUBMC”的升级后验证相同。
## V2 升级常见问题
V2 升级除可能遇到 V3 的常见问题外，还有以下特有问题：
### 缺乏伙伴根证书导致签名校验失败
日志显示 `partner_cert is NULL`，当前版本无法升级。解决方法：使用镜像倒换功能切换到另一个分区版本，然后尝试升级。
```shell
ipmcset -d rollback
```
### 老版本签名仅支持 PKCS 不支持 PSS
较老的 V2 版本签名只支持 PKCS 格式，不支持 PSS。需先升级到一个支持 PSS 的较新 V2 中间版本，再升级过渡包到 openUBMC。
---
# 固件升级机制
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/upgrade/concept_principle/upgrade_principle.html
> Language: zh
# 固件升级整体描述
固件升级动作主要包含启动固件升级和升级进度查询，其中启动固件升级分为两个场景，即本地升级和远程升级，实际的升级动作由实际的固件子模块完成，固件管理模块驱动完成整个固件升级流程，因此固件管理模块需要与固件子模块机型交互：
# 固件升级具体实现
固件升级阶段分为Initialize，prepare，process，和finish四个阶段，在两个阶段间插入公共处理动作，每个固件子模块包含prepare，process，和finish三个特有动作。
## prepare
在接收到固件管理组件发送的prepare消息后，确认收到的消息是当前子模块的升级消息，判断是否允许升级，回复prepare结果。
## process
- 升级包数据预处理。通过AES,CBC,128算法加密，解密并将升级数据写入bin文件；
- 写升级数据到flash。将bin文件打包写入flash，并最终输出到对应的分区；
- 设置M3标志位。设置BMC升级标志位。
## finish
- 判断若first boot脚本存在，则执行该脚本；
- 给固件管理组件注册生效模式，生效动作由固件管理组件统一管理。
固件升级时序流程如下：
三个阶段都通过之后则升级成功，中间任意一个阶段收到固件子系统”升级失败“的结果，则认为此次升级失败，或者在规定时间段内固件子系统未回复固件管理阶段性结果，则认为超时失败。
# 固件生效
固件子模块感知到生效条件满足后，找固件管理模块进行裁决，由固件管理模块决定其是否能执行生效动作。基础的处理流程如下：
# 并行升级
## 并行升级流程
iBMC除了常用的升级方式单独升级固件以外，还配置了并行升级方式，具体的升级流程如下：
## 互斥处理
### 并行升级与串行升级互斥
升级流程（如固件生效）需串行执行，避免并发冲突。生效接口调用时，若已经在生效流程中，直接报错。
### 固件互斥规则
- 相同ComponentID和ComponentIDEx的固件不支持并行升级；
- 不同ComponentIDEx的固件可能支持并行，但需要业务组件在prepare阶段返回错误码；
- 硬件对象间（如管理板与接口卡）禁止并行升级；BMC必须优先升级且独立。
### 互斥处理
互斥场景（如加锁失败或者下游组件判断不支持并行升级）时，任务移动至队尾等待，不记录重试次数，相同ComponentID和ComponentIDEx的固件在升级时，新任务排队等待重试。
## 资源限制
- 并行任务上限：同时升级的固件数量通过CSR配置，默认上限为5；等待队列任务数默认任务上限为10，超限后新掉用报错。
- 存储队列管理：本地升级需要先缓存固件包，优先处理本地任务以释放资源。
---
# 升级常见问题
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/upgrade/upgrade_faq.html
> Language: zh
# 【Q1】升级成功但是版本号没变化
版本号没变化请直接咨询子固件组件，版本号更新由子固件组件自行管理，固件管理仅为外部提供版本号展示，不修改版本号内容
# 【Q2】升级框架问题与各固件组件问题快速定位
升级非bmc固件的时候，有时候会升级失败，通过 /var/log/app_debug_log_all（最新版的日志已经移到/var/log/app.log） 有时候可以快速定界是firmware_mgmt升级框架问题还是各固件组件升级生效导致的固件失败（cpld、bios、vrd等）。firmware_mgmt解包成功并识别到是什么固件之后，会发送信号通知多样硬件触发升级，多样硬件收到信息进行升级，然后把升级结果返回给firmware_mgmt。所以当出现以下日志，就可以确认多样硬件给firmware_mgmt返回了升级失败信号。
**关键日志：Upgrade <某固件> process failed, ret=<非0返回值>**
有这条打印说明firmware明确收到了来自多样硬件的升级失败信息。
# 【Q3】升级BIOS升级完成，上电后发现未生效
1.查看BIOS升级完是否注册到了firmware_mgmt：
查看firmware_mgmt资源树，若存在以下字段，则已注册到firmware_mgmt；若无以下字段，优先找Bios组件定位
2. 若已注册到firmware_mgmt，自查未生效方式如下：
查找关键词“PowerState changed to xxx”，若不存在**PowerState changed to OFF**，则有可能是下电失败，只有完全下电，即OFF状态才会触发生效
以下图片即为无OFF的情况
本问题经过上下电组件定位：
下电超时了，可能环境逻辑版本有误
# 【Q4】上电升级CPLD，下电后未生效
场景：上电情况下升级了CPLD，下电后CPLD未触发生效，环境没AC，CPLD版本没变
定位（三板斧）Q：
1、查看操作日志，找到对应操作的时间
2、搜索app日志对应时间点，查看详细升级日志
3、在相关事件点附近查看日志，观察CPLD升级生效流程日志是否按照正常预期执行：
（1）CPLD上电升级，向firmware_mgmt注册生效item
（2）环境下电
（3）firmware_mgmt监听到下电，触发生效
在步骤（1）中，我们（敏锐地）看到CPLD注册的生效条件是PowerCycle，说明跑了CPLD生效定制化（BMCSet_CPLD_UpgradeActiveCondition），此定制项定制之后，下电和强制下电将不会生效CPLD，只有PowerCycle才会生效CPLD。
所以本次CPLD没生效的原因是环境被人跑了定制化，firmware_mgmt的mdb_info.log资源树可以佐证：
消除此定制化：
`busctl --user call bmc.kepler.general_hardware /bmc/kepler/general_hardware/MicroComponent bmc.kepler.MicroComponent.ConfigManage Import a{ss}ss 0 {\"ConfigData\":{\"CustomSettings\":{\"BMCSet_CPLD_UpgradeActiveCondition\":{\"Import\":true,\"Value\":\"PowerOff\"}}}} custom`
或 执行一次空定制
若以上三个步骤均没问题，general_hardware与firmware_mgmt均不存在报错信息，查看fructrl是否有以下日志重复打印，以下日志表明AC失败了
此时需咨询上下电，即fructrl组件责任人
如有关键字“refresh the cache, and then execute ac down”打印，表示写寄存器触发ac成功了，但是硬件没有做对应的ac动作，需咨询相关硬件负责人
注：使用上述的定位三板斧，已经能够定位出大部分的升级问题。
# 【Q5】cli升级期间，cli连接突然断开
现象：用例执行cli升级期间，查询升级进度突然无响应
正常的升级进度应该是这样的：
问题根因：Administrator用户信息被改，导致Administrator的连接断开，所以cli突然登出，导致突然查不到升级进度
操作日志如下：一个IP使用Administrator登录cli触发升级，升级期间，另一个IP也登录了Administrator，并修改了用户信息。修改用户信息将导致Administrator用户登出，导致升级的那个cli会话直接断开，最终升级进度回显被中断
# 【Q6】升级报错：无效升级包/FirmwareType is nil
日志如下："get obj nil for Id="
新日志如下："FirmwareType is nil, invalid package config"
firmware_mgmt版本>=1.10.50之后，固件类型的定义被外置，详情参考V3固件管理一本通文档
遇到这种报错，就是因为**没有在vpd仓定义需要升级的固件类型**，自发现没分发此固件的对象给firmware_mgmt，导致firmware_mgmt无法识别此固件。
新增固件对象的方法：vpd仓中对应的机型的platform.sr中新增对象，
`"FirmwareComponentInfo_BMC": { "ComponentID": 2, "ComponentIDEx": 131, "Name": "Bios", "RevisionNumber": 0 }`
ComponentID与ComponentIDEx数据需与update.cfg内数据保持一致
# 【Q7】升级失败报错：升级文件与机型不匹配 关键字update.cfg
app日志：sys-uid(1030abf00) not in update.cfg's ProductUIDList 等几条日志
原因：就是升级的包，与当前环境的机型信息不匹配。不允许升级
想要强行升级的办法：
1、ipmcset -d rollback尝试回滚，使用另一个看能否升级
2、如果另一个分区也报机型不匹配，自己通过本地manifest构建出一个过渡版本，先升级到过渡版本，然后在升级到预期版本。
以DA123C举例，想要把当前 非DA123C机型 升级到 DA123C，按以下步骤操作：
（1）在manifest仓找到DA123C机型的BMC固件的update.cfg文件
（2）修改ProductID字段，改成65535，表示匹配所有的产品系列
3、个人构建出包：python3 frame.py -t target_personal --stage=dev -b TaiShan200_DA123C
把此包升级到环境上，然后就可以升级到目标DA123C版本了
# 【Q8】升级超时失败
三个现象代表三个阶段的超时失败：
（1）prepare阶段超时失败。现象：升级进度在5%持续一分钟，然后升级失败，app.log存在以下打印：
说明子固件在prepare阶段没有在一分钟内响应firmware_mgmt，导致超时失败。
关键日志：Wait message reply timeout
（2）process阶段超时失败。现象：升级进度在>=15%持续一小时，然后升级失败，app.log存在Wait message reply timeout相关打印
（3）finish阶段超时失败。现象：升级进度在99%持续一分钟，然后升级失败，app.log存在Wait message reply timeout相关打印。
# 【Q9】升级iBMC成功，复位起来之后iBMC当前版本号没变
烧片了2023.5的烧片包，升级最新版本BMC，升级成功后BMC起不来。
环境烧片了23年5月份的BMC包，然后升级当前较新的版本（TR5-1以后的版本），能够升级成功，但是发现BMC多次起不来，然后自动回退成原来5月份的版本。
观察到串口日志有如下打印：
从上述串口打印发现，每次到启动Rsyslog服务时，反复启动几次失败，紧接着BMC就挂了，说明Rsyslog启动失败与BMC服务起不来强相关。
（找相关专家询问后，基本确认就是Rsyslog起不来导致BMC无法启动）
解决方案：烧片一个TR5的BMC
注：iBMC升级成功之后，多次启动失败然后切分区到原来的版本，导致的一个直接现象就是 升级之后版本号不变。
这一类的问题，共性情况如下：
现象：升级成功之后，主分区版本号没变，可用分区版本号变了。
原因：升级实际上是成功的，升级成功后复位iBMC，iBMC系统启动失败，三次未启动成功之后触发分区切换，切回了原版本。
根因：定位根因需要进一步查看串口日志，串口日志 dump_info\OSDump\uart2com.dat
举例一：串口打印内核异常日志，说明rtos内核crash，问题出在RTOS或SDK，应当找相关领域定位
举例二：查看framework.log，看是否有组件启动异常，连续两次启动检查失败会触发切分区
如上日志发现确实有组件服务异常，启动检查失败，找对应领域责任人定位
# 【Q10】传包失败导致签名校验失败
1、app日志看firmware_mgmt错误打印，发现是签名校验失败
2、 分析用例发现传包阶段失败
3、查看/tmp空间使用情况
原因是/tmp目录存在一些临时文件，导致空间被占用了60M，而/tmp目录容量只有100M，再次上传一个升级包的时候，由于/tmp目录容量不够，导致传了一个不完整的hpm上去，导致签名校验失败。
建议：（1）优化脚本，触发升级之前先清理/tmp目录。（2）提需求，通过手动或自动方式清理tmp目录
# 【Q11】网络波动导致传包中断，升级失败
同上一个传包失败导致升级失败的问题，从日志看还是签名校验失败，
但是这一次导致传包失败的不是/tmp目录满了，而是BMC突然断开连接。
问题原因可能是 网络波动 或 当时BMC突然复位 或 部分服务重启 导致BMC不可达。
此类问题具体问题具体分析，非升级问题。
# 【Q12】升级过程中bmc_core重启导致升级失败
升级过程中升级失败，观察bmc_core启动日志发现当时bmc_core刚好重启过。
重启原因是bmc_core中的event组件存在内存泄漏，导致bmc_core达到512M内存使用阈值，触发重启。
当时刚好正在进行升级。
措施（已执行）：从bmc_core中分离event组件的服务。
# 【Q13】升级密钥解密失败导致升级失败
升级失败，查看app日志存在如下解密密钥失败打印
说明是升级需要的密钥解密失败，可能原因是key_mgmt更新密钥之后，ksf密钥与升级密钥不匹配，导致升级密钥无法解密。这部分有可能是key_mgmt存在缺陷。
当前firmware版本 >=1.0.30 已经从firmware角度增强健壮性解决了这个问题。
规避措施：
1、 删除环境密钥
```
rm /data/opt/bmc/upgrade/profile_en
rm /data/opt/bmc/upgrade/profile_en.bak
```
2、 重启bmc_core服务
```
systemctl restart bmc_core
```
3、 等firmware服务起来之后，重新升级即可
# 【Q14】升级卡住不想等两小时或无法平滑重启 急需重启一下恢复环境
**！！慎用**
方法有以下两类
【强制重启】
1.telnet下执行 systemctl reboot
若无法进入telnet
2.clp调试命令：reboot -f --》进入clp：输入clp_commands
【AC】
cli命令：ipmcset -t maintenance -d accycle
AC约等于拔电源，没有什么能阻止AC，fructrl组件起不来除外
# 【Q15】升级包版本太低/过旧的升级包
**情况1** 环境上允许降级升级属性DowngradeAllowed可能被置成了false
查询方式：
```
busctl --user get-property bmc.kepler.bmc_upgrade /bmc/kepler/UpdateService/UpdateMgmt bmc.kepler.UpdateService.UpdateMgmt DowngradeAllowed
```
值为false则不允许降级升级，即不允许升比当前环境版本低的升级包
恢复方式
```
busctl --user set-property bmc.kepler.bmc_upgrade /bmc/kepler/UpdateService/UpdateMgmt bmc.kepler.UpdateService.UpdateMgmt DowngradeAllowed b true
```
**情况2** RevisionNumber值大于升级包中配置的Revision值
查看RevisionNumber：
```
ipmitool -H *bmc_ip* -I lanplus -p 623 -U *用户名* -P *密码* -C 17 raw 0x30 0x93 0xdb 0x07 0x00 0x5b 0x2d 0x00 0x06 0x00 0xc0 *0x19*(ComponentId) *0xff 0xff 0xff 0xff*(ComponentIdEx)
```
RevisionNumber设置成0：
```
ipmitool -H *bmc_ip* -I lanplus -p 623 -U *用户名* -P *密码* -C 17 raw 0x30 0x93 0xdb 0x07 0x00 0x5a 0x2d 0x00 0x07 0x00 0xc0 *0x19*(ComponentId) *0xff 0xff 0xff 0xff*(ComponentIdEx) *0x00*(RevisionNumber)
```
# 【Q16】升级报错：无效升级包/FirmwareType is nil
日志报错如下：
固件类型的定位被外置，遇到这种报错就是因为没有在VPD仓定义需要升级的固件类型，自发现没分发此固件的对象给固件管理组件，导致固件管理组件无法识别此固件。新增固件对象的方法：VPD仓中对应的机型的platform.sr中新增对象，如下如所示，且ComponentID与ComponentIDEx数据需与update.cfg内数据保持一致。
# 【Q17】 密钥解密失败导致升级失败
如上图日志打印说明是升级需要的密钥解密失败，可能原因是key_mgmt更新密钥后，ksf密钥与升级密钥不匹配，导致升级密钥无法解密，当前固件版本大于等于1.0.30，已经从firmware角度增强健壮性，解决了整个问题。如果遇到该问题规避措施如下：
- 删除环境密钥
- 重启bmc_core服务；
- 组件服务起来之后，重新升级。
# 【Q18】 升级白牌包时报"p12 parse fail"
白牌包在制作的过程中涉及到ssl证书，证书分为加密和不加密两种，该日志对应的是加密证书，加密证书的制作分为四个步骤，分别为原始加密.pxf证书制作，确认加密密码，去密码，设置加密密码，而该报错是因为在制作证书的时候未按照要求去密码设置，导致在解密的时候系统解密密钥与加密密钥不匹配。
# 【Q19】 保留配置升级和不保留配置升级BIOS均失败
日志上显示get snaphot failed,尝试下发如下图命令，确实是否有返回：
返回报错，此时根本原因是上图中的BIOS资源树未成功加载，从而生成快照失败。沟通后发现，环境为天池模组环境，无bcu，导致bcu中涉及bios升级的资源树全部未加载，解决方案是将bcu中涉及bios的资源树部分功能进行迁移，最好跟着产品走。
# 【Q20】 V2无法升级V3
ipmcget -d v 获取V2版本信息
收集日志或重启触发升级，分析升级相关日志：
从日志可以看到此版本BMC缺乏或缺少根证书，导致签名校验失败，当前版本的BMC不但无法从V2升级到V3，也无法升级V2，需要先解决证书问题。解决办法：使用镜像倒换功能切换到另一个分区的BMC版本，然后再尝试升级。
# 【Q21】 烧片包的V2无法升级V3
环境上的BMC是一个较老的V2烧片BMC，V2升级V3日志报错如下：
原因是V2较老版本的签名只支持PKCS，不支持PSS，需要升级到中间版本作预埋，然后B版本就可以同时校验PKCS和PSS，此时再升级V3的BMC就可以成功。
# 【Q22】 上电升级CPLD，下电后未生效
现象：上电情况下升级了CPLD，下电后CPLD未触发生效，环境没AC,CPLD版本未变化。
定位步骤：
- 查看操作日志，确定操作时间：
- 搜索app.log日志对应时间点，查看详细升级日志：
- 在相关事件点附近查看日志，管擦和CPLD生效流程日志是否按照正常预期执行：
1. CPLD上电升级，向固件管理组件注册生效item；
2. 环境下电；
3. 固件管理组件监听到下电，触发生效
在步骤（1）中，看到CPLD注册的生效条件是PowerCycle，说明跑了CPLD生效定制化，此定制项定制之后，下电和强制下电将不会生效CPLD，此时只需要消除此定制化即可。
# 【Q23】 升级超时失败
升级的三个现象代表三个阶段的超时失败：
- prepare阶段超时失败：
现象：升级进度在5%持续一分钟，然后升级失败，app.log存在如下打印：
说明子固件在prepare阶段没有在一分钟之内响应固件管理组件，导致超时失败。
- process阶段超时失败
现象：升级进度在大于等于15%持续一小时，然后升级失败，app.log存在超时相关日志打印
- finish阶段超时失败
现象：升级进度在99%持续一分钟，然后升级失败，app.log存在超时相关日志打印
# MCU升级
## 【Q1】 VRD正在升级，无法升级MCU
上电升级VRD，下电后升级MCU返回失败：
* 当前MCU和VRD走的是一个升级通道，做了互斥限制
* VRD作为二级电源，只能在下电情况下进行升级，在os上电时缓存升级文件，返回升级成功，下电取升级文件，开始生效
需要等VRD下电生效后升级MCU，才能返回成功。
5.2最新版本更新了错误码，在VRD生效期间升级MCU返回特殊的失败提示：
## 【Q2】 升级riser卡MCU升级失败
storage组件使用插件式访问调用I2C，如果没有加载raid卡，在获取不到预期信息时会长时间独占总线，导致命令阻塞
## 【Q3】 如何查询BCU的MCU和VRD的版本号
命令查询版本号：
mcu:
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018500 7
VRD:
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018501 7
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018502 7
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018503 7
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018504 7
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018505 7
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018506 7
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018507 7
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc\_CpuBrdSMC\_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018508 7
# VRD升级
## 【Q1】 没有找到对应的升级文件
日志打印如下：对应的bin文件规则为VRD_厂商_SKU_NO.bin
厂商和SKU如下（当前B830版本只支持00_00和01_00）：
# CSR升级
## 【Q1】 BC83PRUU(蝴蝶卡)CSR为1.17之前的版本升级出现升级失败
1.17版本CSR的port配置有问题，会导致raid卡无法正常加载，BMC会占用总线通道一直访问Raid，导致CSR升级时总线被占用，访问超时，会出现概率性升级失败的情况，需要重试几次
# CPLD升级
## 【Q1】 获取厂商信息
下一步是获取芯片的厂商信息，根据厂商选择升级方式，在/logDump/app.log中筛选general_hardware:
大概率是ChipInfo无法获取，该Chip是挂在Jtag链路上的，有三种情况：
1、jtag链路没有切过去，在BMC中输入一下命令，看看是否可以获取到版本信息：
busctl --user set-property bmc.kepler.hwproxy /bmc/kepler/Accessor/Accessor\_JtagSwitch\_010101 bmc.kepler.Accessor Value t \_( \_ 为对应的链路，当前EXU为0，BCU为1，具体查看CSR的FirmwareRoute属性)
设置后查看信息，value是否改变：
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Cpld/Cpld\_1\_0101 bmc.kepler.Chip.JtagTarget GetChipIdcode a{ss} 0（0101为EXU，010101为BCU，具体查看板卡的position）
以基础板为例子，正常获取到chip信息：
2、cpld扫链失败，输入dmesg驱动日志查看，可能是扩展板CPLD的版本问题，或者BMC测链路未通，未将CPLD和1711选通
3、jtag链路异常，测波形排查Jtag链路
## 【Q2】紫光CPLD的IIC升级失败（二盘背板）
在驱动日志中出现如下打印：
传输数据时出现丢失的情况，大概率是有毛刺影响，建议更换线缆
## 【Q3】 主板SVF格式升级成功后版本不变
1. 查看升级的framework.log日志，发现升级时间很短就返回send data成功
2. 查看linux_kenl日志（环境上输入dmesg），发现文件校验失败
---
# 整包升级指导
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/upgrade/upgrade_guide/Firmware_Packaging_Guide.html
> Language: zh
# 1. 概述
针对产品整机固件升级场景，为解决固件包数量多，固件下载效率低，版本配套管理困难问题，BMC提供产品级固件整包升级能力，避免运维人员由于误操作导致版本不匹配问题，同时提升整机升级效率。
# 2. 压缩包格式
* **文件格式**：`zip`
* **压缩包大小限制**：
* **压缩前**：≤ 110 MB
* **压缩后**：≤ 150 MB
* **推荐压缩方式**：
* **windows**：7zip
* **linux**：zip命令
# 3. 压缩包内容
压缩包内应包含以下内容：
|类型|数量|说明|
| --- | --- | --- |
|`.hpm` 文件|≥1 个，最多支持并行升级最大数量|固件升级包（HPM: Huawei Package Module）|
|`full_image_profile.json`|≤1 个|用于描述包内各模块信息，不包含该配置文件则默认并行升级所有hpm包|
> ✅ **示例结构**：
```
fullimage.zip
├── a.hpm
├── b.hpm
└── full_image_profile.json
```
> ⚠️ **注意**：
> * 仅允许包含 `.hpm` 和 `full_image_profile.json` 文件。
> * 禁止包含其他无关文件（如 `.txt`, `.log`, `.tmp` 等）。
> * 禁止包含隐藏文件或目录。
# 4. 文件命名规范
|项目|规则|
| --- | --- |
|**压缩包文件名**|不超过 **128 字节**
不包含非法字符（如：`< > : " / \）|
|**.hpm 文件名**| 与 `full_image_profile.json` 中 `FileName` 字段一致|
|所有文件名|可由数字、大小写英文字母、空格、圆括号（）、点号（.）、下划线（_）和连接号（-）组成|
|**full_image_profile.json**|遵循所有文件名规范|
# 5. `full_image_profile.json` 格式说明
## 5.1 基本结构
```json
{
"Packages": [
{
"Module": "CPLD_EXU",
"FileName": "a.hpm",
"Priority": 1
},
{
"Module": "BMC",
"FileName": "b.hpm",
"Priority": 2
}
]
}
```
## 5.2 字段说明
|字段名|类型|必填|说明|
| --- | --- | --- | --- |
|`Module`|string|是|模块标识符，如 `BMC`, `CPLD_EXU` 等|
|`FileName`|string|是|对应 `.hpm` 文件的文件名，必须与压缩包中一致|
|`Priority`|number|否|优先级数值，范围：`1` ~ `16`
数值越小，优先级越高
**未配置时默认为 `16`**|
> ✅ **优先级示例**：
> * `Priority: 1` → 最高优先级，最先升级
> * `Priority: 16` → 最低优先级，最后升级
> ⚠️ **注意事项**：
> * 所有 `Priority` 必须为整数，非数字将导致解析失败。
> * 若多个模块优先级相同，则它们同时执行并行升级。
# 6. 并行升级数量限制
* 固件包中 `.hpm` 文件数量应**不超过系统支持的并行升级最大数量**（可CSR配置，默认为20个）。
* 超出数量将导致升级失败。
* 建议：使用 `Packages` 列表中 `Priority` 字段合理调度升级顺序。
# 7. 注意事项
* 使用Redfish进行整包升级时，由于涉及远程升级，为保证接口响应时间，需要提前创建最大并行升级个数的子任务。在获取到具体固件后，再将子任务与对应固件匹配，多余的子任务状态标记为"exception"，多余子任务不影响主任务的升级状态及进度。
# 8. 接口使用说明
## 8.1. Redfish接口升级
- URL POST
```text
https:///redfish/v1/UpdateService/Actions/Oem/{OemIdentifier}/UpdateService.FullImageUpdate
```
- 请求头：
```
X-Auth-Token : auth_value
Content-Type : header_type
```
- 请求消息体：
```json
{
"ImageURI": image_uri,
"TransferProtocol": transfer_protocol,
"ForceUpdate": force_update
}
```
|参数|参数说明|取值|
| --- | --- | --- |
|device_ip|登录设备的IP地址|IPv4或IPv6地址|
|auth_value|请求消息的鉴权参数|可通过/redfish/v1/SessionService/Sessions创建会话时获得|
|header_type|请求消息的格式|支持的消息格式包括：`application/json`或者`application/json;charset=utf-8`|
|transfer_protocol|BMC从远程服务器下载升级包时使用的协议|取值：HTTPS、SCP、SFTP、CIFS、NFS。本地升级不需要该字段|
|image_uri|升级包所在路径，文件为zip格式|升级包的URL（支持本地tmp目录升级
例如：“sftp://username:password@10.10.10.191/tmp/package.zip”
本地升级：“/tmp/cpldimage.zip”|
|force_update|固件是否强制升级|true：版本号一致的固件升级
false：版本号一致的固件不升级
可选参数，如果不加该参数。默认为版本号一致的固件升级|
## 8.2 IPMI接口升级
### 8.2.1 触发固件整机升级
**命令权限：** BasicSetting
**是否锁定之后可以访问：** 是
**命令样式：**
* 请求：`ipmitool raw 0x30 `
* 响应：``
**命令请求参数：**
|字节顺序|域取值说明|
| --- | --- |
|NetFn|30h|
|Cmd|93h|
|1:3|Manufacturer ID，LB Byte first。长度固定 3 个字节，例如，某厂家ID时 2011，对应十六进制为0x0007DB，则字节序为第1个字节为 DBh，第二个字节为 07h，第三个字节为 00h。|
|4|94h|
|5|Operation type:
AA initiate upgrade|
|6|Reserved，当前统一填0，为后续可能添加的参数做预留|
|7|Reserved，当前统一填0，为后续可能添加的参数做预留|
|8|Length：路径名长度，大小不超过128字节|
|9:N|Filename：绝对路径名|
**命令响应参数：**
|字节顺序|域取值说明|
| --- | --- |
|1|Completion Code|
|2:4|Manufacturer ID，LB Byte first。长度固定 3 个字节，例如，某厂家ID时 2011，对应十六进制为0x0007DB，则字节序为第1个字节为 DBh，第二个字节为 07h，第三个字节为 00h。|
**命令示例：**
**样例：开始升级整包/tmp/fullimage.zip**
* 请求：`ipmitool raw 0x30 0x93 0xdb 0x07 0x00 0x94 0xaa 0x00 0x00 0x00 0x12 0x2F 0x74 0x6D 0x70 0x2F 0x66 0x75 0x6C 0x6C 0x69 0x6D 0x61 0x67 0x65 0x2E 0x7A 0x69 0x70`
* 响应：`0xdb 0x07 0x00`
### 8.2.2 查询整包升级进度
**命令权限：** ReadOnly
**是否锁定之后可以访问：** 是
**命令样式：**
* 请求：`ipmitool raw 0x30 `
* 响应：` `
**命令请求参数：**
|字节顺序|域取值说明|
| --- | --- |
|NetFn|30h|
|Cmd|93h|
|1:3|Manufacturer ID，LB Byte first。长度固定 3 个字节，例如，某厂家ID时 2011，对应十六进制为0x0007DB，则字节序为第1个字节为 DBh，第二个字节为 07h，第三个字节为 00h。|
|4|95h|
|5|Reserved，当前统一填0，为后续可能添加的参数做预留|
|6|Reserved，当前统一填0，为后续可能添加的参数做预留|
**命令响应参数：**
|字节顺序|域取值说明|
| --- | --- |
|1|Completion Code|
|2:4|Manufacturer ID，LB Byte first。长度固定 3 个字节，例如，某厂家ID时 2011，对应十六进制为0x0007DB，则字节序为第1个字节为 DBh，第二个字节为 07h，第三个字节为 00h。|
|5|Length，返回数据长度|
|6:N|整包中各固件升级进度和状态，每两个字节描述一个固件，其中进度百分比使用低字节，升级状态码使用高字节的低4bit，高字节的高4bit预留，状态码定义如下：
0：正常
1：升级失败
2：未匹配到具体板卡而未升级
如：0x00 0x50固件升级进度为80%，当前状态码为0
0x01 0x00固件升级进度为0%，当前状态码为1|
**命令示例：**
**样例1：查询整包升级进度及状态**
* 请求：`ipmitool raw 0x30 0x93 0xdb 0x07 0x00 0x95 0x00 0x00`
* 响应：`0xdb 0x07 0x00 0x0a 0x00 0x50 0x00 0x53 0x01 0x00 0x00 0x64 0x02 0x00`
* 固件1、2升级到80%，固件3升级失败，固件4升级到100%，固件5未匹配到具体板卡而未升级
## 8.3 Web Rest接口升级
### 8.3.1 整包上传接口
**uri**：
```text
/UI/Rest/BMCSettings/UpdateService/Actions/UpdateService.FullImageUnpack
```
**操作类型**： POST
**请求参数**：
|参数|参数说明|取值|
| --- | --- | --- |
|FilePath|升级包所在路径|string|
**操作权限**：BasicSetting
**样例展示：**
请求参数：
```json
{
"FilePath": "/tmp/fullimage.zip",
}
```
响应消息体举例：
```json
{
"url":"/UI/Rest/Task/1"
}
```
### 8.3.2 整包升级下发二次确认
**uri**：
```text
/UI/Rest/BMCSettings/UpdateService/ParallelUpdate
```
**操作类型**： POST
**请求参数**：
|参数|参数说明|取值|
| --- | --- | --- |
|ImageType|固件升级的类型|“SingleImage”
“FullImage”|“SingleImage”|
|FullImageNames|string数组，ImageType为FullImage时不允许为null|整包升级各固件名称|
### 8.3.3 获取并行升级各固件信息
**uri**：
```text
/UI/Rest/BMCSettings/UpdateService/UpdateProgress
```
**操作类型**： GET
**响应参数**：
|参数|参数说明|取值|
| --- | --- | --- |
|UpgradeMode|表明当前升级模式|“Serial”：串行升级中
“Parallel”：并行升级中
“FullImageUnpacking”：整包解包中|
|UpgradeTasks|升级任务的进度信息对象|属性包括：
TaskName：升级任务名
Component：升级固件描述
FileName：升级包名称
Percentage：升级进度
TaskState：升级状态
ErrorCode：升级任务错误码
EstimatedRemainingTime：固件预计升级的剩余时间
FirmwareId：固件ID|
### 8.4 相关资源协作接口
**interface:** `bmc.kepler.UpdateService`
**path:** `/bmc/kepler/UpdateService`
|方法名称|请求签名|请求参数描述|响应签名|响应参数描述|方法描述|访问权限|
|---|---|---|---|---|---|---|
|FullImageUnpack|s|整包路径|u|任务id|将整包进行解析、校验|BasicSetting|
---
# 固件验签、拆包解析定制要求及使用指导
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/upgrade/upgrade_guide/Firmware_Signature_Verification_Guide.html
> Language: zh
## 1. 固件验签、拆包解析定制要求
定制固件验签、拆包解析需要配置CSR，需要在FirmwareCustomConfig对象中配置CustomVerifyEnabled、CustomVerifyLibraryName、CustomParseEnabled、CustomParseLibraryName属性。属性说明见下表：
| 属性名 | 属性类型 | 取值说明 |
| ----------------------- | -------- | -------------------------------------------------------------------- |
| CustomVerifyEnabled | Boolean | 客户验签流程定制使能，true：使能；false：禁用，默认值为false |
| CustomVerifyLibraryName | String | 客户验签流程定制库名称，默认值为"hpm_parser" |
| CustomParseEnabled | Boolean | 客户拆包解析流程定制使能，true：使能；false：禁用，默认值为false |
| CustomParseLibraryName | String | 客户拆包解析流程定制库名称，默认值为"hpm_parser"，字符串长度约束1~32 |
## 2. 流程
### 固件验签
1. 客户新增 `/opt/bmc/luaclib/xxx.so`，作为定制hpm解析的接口库(xxx为定制so名称，下同)
2. 客户自行实现 `xxx.so`内容，需要提供方法 `parse_hpm_file`供lua接口调用，入参file_path为hpm包路径；响应为状态码，通过约定返回的状态码标识，确定解析状态。当前实现返回状态码如下：
- 正数表示解析成功，负数表示失败，返回负数则直接退出升级流程；
- 返回状态码为1：解析验证固件成功，需要继续openUBMC的验签+解析+升级；
- 返回状态码为2：解析验证固件成功，需要继续openUBMC的解析+升级；
- 返回状态码为3：解析验证固件成功，直接结束固件解析，跳到后续升级
### 拆包解析
1. 客户新增 `/opt/bmc/luaclib/xxx.so`，作为定制hpm解析的接口库(xxx为定制so名称，下同)
2. 客户自行实现 `xxx.so`内容，需要提供方法 `custom_parse_pkg`供lua接口调用，入参file_path为hpm包路径，output_dir为拆包解析后数据存放目录；响应为true（解析成功）/false（解析失败），且在output_dir下存放必带文件。
## 3. 配置示例：
### 固件验签
```json
"FirmwareCustomConfig": {
"CustomVerifyEnabled": true, //客户签名定制使能
"CustomVerifyLibraryName": "sign_verify" //客户签名定制库为sign_verify.so
}
```
### 拆包解析
```json
"FirmwareCustomConfig": {
"CustomParseEnabled": true, //客户拆包解析定制使能
"CustomParseLibraryName": "hpm_parser" //客户拆包解析定制库为hpm_parser.so
}
```
## 4. 客户定制仓自行实现要求
### 固件验签定制库内容流程图
### 拆包解析定制库输入输出要求
固件管理标准流程调用客户定制库时，会传入file_path（hpm包路径），output_dir（拆包解析后数据存放目录），定制库自行对hpm包进行拆包解析，并将解析内容存放在output_dir下，output_dir必带数据如下：
- beforeaction.sh（升级前自定义动作，内容可为空）
- afteraction.sh（升级后自定义动作，内容可为空）
- update.cfg（参考update.cfg规范）
- 解压后的各个固件镜像的二进制数据（命名为FirmwareX，X为固件索引，起始值为1，随着固件数量递增，如Firmware1、Firmware2...，Firmware0用于将update.cfg这个文件作为固件进行描述）
## 5. update.cfg 规范
### Basic 基础信息域
| 字段名称 | 说明 | 必选(M/O) | 约束 | 样例 |
| -------- | -------- | --------- | -------- | -------- |
| Version | 固件的内部版本号 | M | 按照各个不同的固件的版本规范进行定义。比如：BMC固件内部采用4段式版本号 | `[Basic]`
`Version=X.XX.XX.XX` |
| Revision | 固件的防回退登记号 | O | 当前固件配置了Revision并且是大于0的则生效。每个固件都可以定义自己的Revision，分为两种：
- RevisionNumber：硬件确定的防回退标记
- RevisionNumber4User：软件确定的防回退标记当固件配置的任何一个Revision小于待升级固件的Revision则不允许升级 | `[Basic]`
`Revision=20` |
### Firmware 固件描述域
| 字段名称 | 说明 | 必选(M/O) | 约束 | 样例 |
| -------- | -------- | --------- | -------- | -------- |
| FileNum | 固件由多少个部分的子固件组成 | M | 最大32个 | `[Firmware]`
`FileNum=2` |
| FirmwareMode | 固件升级模式 | O | 取值：Multiple/Single 表示多firmware升级/单firmware升级 | `[Firmware]`
`FirmwareMode=Multiple` |
### FirmwareX 固件描述详细域
当前域会分为多个域进行描述。
| 字段名称 | 说明 | 必选(M/O) | 约束 | 样例 | 补充说明 |
| -------- | -------- | -------- | -------- | -------- | -------- |
| ProductID | 固件适用的产品标识 | M | 2字节的数字，配置必须是10进制，默认是65535。如果不为默认值并且和当前product的低字节不匹配或者完全不匹配则阻止升级 | `[Firmware1]`
`ProductID=65535` | |
| BoardID | 固件适用的单板标识 | M | 2字节的数字，配置必须是10进制，默认是65535。如果不为默认值并且和当前product的低字节不匹配或者完全不匹配则阻止升级 | `[Firmware1]`
`BoardID=65535` | |
| Model | 固件适用的硬盘型号列表 | O | 字符串，用英文逗号（,）分隔的多个硬盘型号元素，每个元素是具体的硬盘型号 | `[Firmware1]`
`Model=XXX,YYY,ZZZ` | |
| ComponentID | 固件适用的固件类型标识 | M | 1字节的数字，配置必须是10进制，通配是255。根据 ComponentID 和 ComponentIDEx 共同确认一个具体的固件类型。具体参考《IPMI接口说明》附录《固件ID管理》 | `[Firmware1]`
`ComponentID=0` | IPMI接口说明 |
| ComponentIDEx | 固件适用的固件扩展标识 | O | 4字节的数字，配置必须是10进制，通配是4,294,967,295（0xFFFFFFFF）。根据 ComponentID 和 ComponentIDEx 共同确认一个具体的固件类型。如果 ComponentIDEx 是通配则仅由 ComponentID 确认具体的固件类型。具体参考《IPMI接口说明》附录《固件ID管理》 | `[Firmware1]`
`ComponentIDEx=0` | IPMI接口说明 |
| Uid | 固件适用的UID | O | 24字节的字符串，由 Vendor(8) + Type(2) + ComponentID(14) 组成。仅天池机型固件使用 | | |
| UID | DPU固件的UID | O | 仅DPU使用 | | |
| ProductUIDList | 固件适用的产品UID列表 | O | 字符串，用英文逗号（,）分隔的多个 ProductUID 元素，每个元素是4字节的16进制数字，默认为空。如果产品 Product 配置中 ProductVendorID 不为 0xFFFFFFFF 则联合 ProductUniqueID 判定固件的匹配；否则单独采用ProductUniqueID 判定固件的匹配，不匹配则阻止升级。和下文中的 BoardIDList 作用同样，优先判定 ProductUIDList | `[Firmware1]`
`ProductUIDList=0xXXXXXXXX,0xXXXXXXXX,...` | |
| BoardIDList | 固件适用的单板UID列表 | O | 字符串，用英文逗号（,）分隔的多个 BoardID 元素，每个元素是2字节的数字，配置为10进制。如果上文中 BoardID 配置不为 65535 则优先匹配FRU0的 BoardId，不匹配则阻止升级。然后遍历当前 BoardIDList，如果元素不为65535 则匹配FRU0的 BoardId，不匹配则阻止升级 | `[Firmware1]`
`BoardIDList=XXX,XXX` | |
| Version | 当前固件包此Firmware的内部版本号 | O | 按照各个不同的固件的版本规范进行定义。比如：BMC固件内部采用4段式版本号 | `[Firmware1]`
`Version=X.XX.XX.XX` | 2026/1/8新增，用于版本一致则跳过升级的特性 |
| SubComponentNum | 当前固件下对应的Firmware适用的子固件 | O | 仅openUBMC升级使用，compute和bios使用 | | |
| CPLDChipNummbers | 多供应商模式下的CPLD芯片数量 | O | 仅cpld升级使用，和MultipleSuppliersMode配套使用 | | |
| ColdValidList | 固件适用的冷升级片选标识 | O | 仅cpld升级使用 | | |
| HotValidList | 固件适用的热升级片选标识 | O | 仅cpld升级使用 | | |
| MultipleSuppliersMode | 多供应商模式 | O | 仅cpld升级使用 | | |
| UpdateLink | CPLD升级的链路 | O | 仅cpld升级使用 | | |
| UpdateFileType | CPLD升级的格式 | O | 仅cpld升级使用 | | |
### Custom 自定义域
可选域，对于固件的自定义描述，如果固件不涉及自定义可不写。
| 字段名称 | 说明 | 必选(M/O) | 约束 | 样例 |
| -------- | -------- | -------- | -------- | -------- |
| VersionXXX | 自定义对外版本号，其中 XXX 是具体的客户标识，不同的客户可以有多个 | | 1、Version之后的描述产品包构建时根据不同的客户动态写入，必须和定制化客户保持一致
2、该属性如果没有则认为不需要自定义对外版本号，默认采用BMC的内部版本号，取自Basic域的Version属性 | `[Custom]`
`VersionCustomerA=X.X.X`
`VersionCustomerB=X.XX` |
### BMC固件升级update.cfg示例
升级时默认从Firmware1开始读取除update.cfg文件之外的固件相关信息
```ini
[Basic]
Version=X.XX.XX.XX
Revision=31
[Firmware]
FileNum=2
[Firmware0]
ProductID=0 # 天池机型的productId为0
ComponentID=0
BoardID=255
ProductUIDList=0xXXXXXXXX,0xXXXXXXXX
[Firmware1]
ProductID=0
ComponentID=25
BoardID=255
ProductUIDList=0xXXXXXXXX,0xXXXXXXXX
[Custom]
VersionCustomerA=X.XX.XX
VersionCustomerB=X.XX.XXXXXXXX
```
---
# 固件升级指导
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/upgrade/upgrade_guide/upgrade.html
> Language: zh
固件升级接口由多个，其中包括web页面升级，cli命令升级，Redfish接口升级，snmp接口升级及ipmi命令升级等，但是常用的有web页面升级及cli升级，下文将分别介绍。
# web页面升级
操作位置：iBMC管理>>固件升级>>固件更新
# cli命令升级
xshell登录后，下发如下命令即可升级：
# Redfish命令升级
- URL POST `https:///redfish/v1/UpdateService/Actions/Oem/{{OemIdentifier}}/UpdateService.ParallelUpdate`
- 请求头：
```
X-Auth-Token : auth_value
Content-Type : header_type
```
- 请求消息体：
```json
{
"Packages": packages_value,
"Stage": true
}
```
|参数|参数说明|取值|
| --- | --- | --- |
|device_ip|登录设备的IP地址|IPv4或IPv6地址|
|auth_value|请求消息的鉴权参数|可通过/redfish/v1/SessionService/Sessions创建会话时获得|
|header_type|请求消息的格式|支持的消息格式包括：`application/json`或者`application/json;charset=utf-8`|
|packages_value|升级参数|对象数组，内容如下：
SystemId
TransferProtocol
ImageURI
ForceUpdate
Stage|
|SystemId|Multi-Host场景（一个BMC管理多个host主机）下指定升级某host的固件|字符串[1~N]：表示升级第[1~N]个host上的固件，要求对应的host在位|
|TransferProtocol|BMC从远程服务器下载升级包时使用的协议|取值：HTTPS、SCP、SFTP、CIFS、NFS。本地升级不需要该字段|
|ImageURI|升级包所在路径|升级包的URL（支持本地tmp目录升级），本地tmp目录支持的最大长度为255个字符，远程目录支持的最大长度为1004个字符（传输协议长度不计算在内，如"**sftp://**"）|
|ForceUpdate|固件是否强制升级|true：版本号一致的固件升级
false：版本号一致的固件不升级
可选参数，如果不加该参数，默认为版本号一致的固件升级|
|Stage|固件是否暂存|true：暂存
false：不暂存
可选参数，不加该参数默认为不暂存|
# SNMP接口升级
**启动升级**
```
snmpset -t 10 -v3 -l priv -a -X -u -A -X 1.3.6.1.4.1.{SnmpOemIdentifier}.30.1.0 s
```
**查看升级状态**
```
snmpget -t 10 -v3 -l priv -a -X -u -A -X 1.3.6.1.4.1.{SnmpOemIdentifier}.30.2.0
```
# IPMI命令升级
**启动升级**
```
ipmitool -H -I lanplus -p 623 -U -P -C 17 raw 0x30 0x91 0x06 0xaa 0x00 0x00
```
- `flag` ：[0-6]:offset [7]级联标志，0=最后一帧数据 1=后面还有数据
- `length`：本帧数据的长度
- `filepath`：路径名，单帧请求不超过16个字节
例：
```
ipmitool -H -I lanplus -p 623 -U -P -C 17 raw 0x30 0x91 0x06 0xaa 0x00 0x00 0x00(flag) 0x0c(length，此处为/tmp/BMC.hpm的长度，即12个字节) 0x2f 0x74 0x6d 0x70 0x2f 0x42 0x4d 0x43 0x2e 0x68 0x70 0x6d(filepath，此处为/tmp/BMC.hpm)
```
---
# SVF文件介绍
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/upgrade/upgrade_guide/upgrade_svf_file.html
> Language: zh
## 1. SVF基本概述
SVF 是 `Serial Vector Format` 的缩写，常用于 `JTAG (IEEE 1149.1)` 场景。
它本质上是**可读文本脚本**，用于描述测试/烧录时序与向量数据，通常由开发工具生成，再由烧录或边界扫描工具执行。
在硬件升级流程中，SVF 常用于 FPGA/CPLD 等可编程器件的下载与验证，也可用于产线测试和板级调试。
> 说明：`SVF` 在不同领域有同名含义。本文默认指 JTAG 的 `Serial Vector Format`，不是 Autodesk 生态中的 `Streaming Vector Format`。
### 1.1 缩写与术语表
| 缩写或写法 | 英文全称 / 含义 | 说明 |
|------------|-----------------|------|
| **SVF** | Serial Vector Format | 串行向量格式，JTAG 场景下为文本化向量脚本（勿与 Autodesk 的 Streaming Vector Format 混淆） |
| **JTAG** | Joint Test Action Group | 业界通称；对应标准为 **IEEE 1149.1**，边界扫描 / 在线测试常用接口 |
| **IEEE** | Institute of Electrical and Electronics Engineers | 电气电子工程师学会；文中 **IEEE Std 1149.1** 即 JTAG 边界扫描标准 |
| **TAP** | Test Access Port | 测试访问端口；芯片内 JTAG 控制器对外接口，含状态机与 `TCK`/`TMS`/`TDI`/`TDO` 等信号 |
| **IR** | Instruction Register | 指令寄存器；`SIR` 扫描的对象，用于选择器件当前执行的 JTAG 指令 |
| **DR** | Data Register | 数据寄存器；`SDR` 扫描的对象，用于读写数据或配置位流 |
| **TCK** | Test Clock | JTAG 测试时钟 |
| **TMS** | Test Mode Select | 模式选择，配合 `TCK` 驱动 TAP 状态迁移 |
| **TDI** | Test Data In | 测试数据输入（移位链输入侧） |
| **TDO** | Test Data Out | 测试数据输出（移位链输出侧）；可与期望值比对做校验 |
| **TRST** / **TRST#** | Test Reset（低有效常写作 `#`） | 可选硬件复位脚；未引出时可用 `TMS` 序列使 TAP 进入复位类状态 |
| **LSB** | Least Significant Bit | 最低有效位；本文约定扫描数据常从 LSB 一侧先移入/移出 |
| **ASCII** | American Standard Code for Information Interchange | 美国信息交换标准代码；SVF 文件为可读文本编码 |
| **Hz** | Hertz | 赫兹；`FREQUENCY` 中声明的时钟频率单位 |
| **SEC** / **TCK**（`RUNTEST` 参数） | Second / Test Clock | `RUNTEST` 可按秒（`SEC`）或按 `TCK` 周期数等待 |
| **BMC** | Baseboard Management Controller | 基板管理控制器；可运行 SVF 解析并通过 GPIO 或专用硬件驱动 JTAG |
| **CPLD** | Complex Programmable Logic Device | 复杂可编程逻辑器件；文中为 SVF/JTAG 升级的典型目标之一 |
| **FPGA** | Field-Programmable Gate Array | 现场可编程门阵列；亦常用 SVF/JTAG 下载配置 |
| **PC** | Personal Computer | 个人计算机；可连接下载器运行 SVF |
| **ATE** | Automatic Test Equipment | 自动测试设备；产线或实验室批量执行 SVF 的常见宿主 |
| **MCU** | Microcontroller Unit | 单片机 / 微控制器；可作嵌入式 SVF 解析与 bit-bang JTAG 宿主 |
| **GPIO** | General-Purpose Input/Output | 通用输入输出；软件模拟 JTAG 时常用 GPIO 连接 `TCK`/`TMS`/`TDI`/`TDO` |
| **IDCODE** | Identification Code（Device ID） | 器件标识寄存器读回值；用于确认 JTAG 链路与器件型号 |
| **UID** | Unique Identifier | 唯一标识；升级包与固件对象匹配时常用 |
| **HIR / HDR** | Header Instruction / Data Register | 头部位：正式 `SIR`/`SDR` 前附加的移位前缀 |
| **TIR / TDR** | Trailer Instruction / Data Register | 尾部位：正式 `SIR`/`SDR` 后附加的移位后缀 |
| **PIO** | Parallel I/O | 并行 I/O；SVF 扩展指令，非所有工具实现 |
| **PATHDATA** | （扩展指令名） | 部分工具链扩展；非核心 JTAG/SVF 必备 |
| **SVF_MISMATCH** | （实现侧错误码示例） | 表示 TDO 等回读与期望不一致导致中止 |
## 2. SVF文件结构与常见指令
SVF 文件由一系列指令组成，每条指令以分号结尾，常见内容包括：
- `SIR`：Shift Instruction Register，向 IR 移位指令
- `SDR`：Shift Data Register，向 DR 移位数据
- `RUNTEST`：保持一定时钟周期或时间，用于等待器件内部操作完成
- `STATE`：切换 TAP 状态机状态
- `TRST`：复位测试逻辑（按平台支持情况使用）
- `ENDIR` / `ENDDR`：设置 IR/DR 移位结束后的目标状态
SVF 语法规则补充说明：
- **文件形式**：SVF 文件是由多条 SVF 语句构成的 ASCII 文本文件
- **语句结构**：一条 SVF 语句由“指令 + 参数”组成，以 `;` 作为结束标记
- **多行支持**：单条 SVF 语句可跨多行书写；单行最大长度通常为 256 个字符
- **大小写规则**：SVF 关键字大小写不敏感
- **注释规则**：支持行内注释，以 `!` 或 `//` 起始，起始符之后本行剩余内容视为注释（部分工具仅支持整行注释，不支持行尾注释，需以实际工具手册为准）
- **扫描数据表示**：扫描类语句的数据写在圆括号内，使用十六进制表示
- **位宽约束**：扫描数据长度不能超过语句声明的比特长度；若超过，超出部分的高位会被丢弃
- **位序约定**：扫描数据按最低有效位（最右侧）优先的顺序处理，适用于 `TDI`、`TDO` 和 `MASK`
示例（简化）：
```svf
TRST OFF; // 关闭可选 TRST#，仅用 TMS 序列控制 TAP
ENDIR IDLE; // IR 扫描结束后进入 Run-Test/Idle（IDLE）
ENDDR IDLE; // DR 扫描结束后进入 Run-Test/Idle（IDLE）
SIR 8 TDI (AB); // 向指令寄存器移入 8 位指令 0xAB
SDR 32 TDI (12345678) TDO (XXXXXXXX) MASK (00000000); // 向数据寄存器移入 32 位；TDO/MASK 为占位示例（MASK 全 0 表示不校验 TDO）
RUNTEST 100 TCK; // 在 Run-Test/Idle 下输出 100 个 TCK 周期
```
## 3. SVF核心指令介绍（按功能分组）
根据常见实践（含 IEEE Std 1149.1 相关约定与行业工具通用用法），可将 SVF 指令按功能分组理解为“状态控制、扫描执行、时序复位、扩展指令”四大类。
### 3.1 状态控制类（让 TAP 停在哪、走哪条路）
| 指令 | 作用（通俗版） | 常见示例 |
|------|----------------|----------|
| `ENDDR` | DR 扫描结束后，TAP 回到什么状态（常见 `IDLE` 或 `PAUSE`） | `ENDDR IDLE;` |
| `ENDIR` | IR 扫描结束后，TAP 回到什么状态 | `ENDIR IDLE;` |
| `STATE` | 让 TAP 进入指定状态（如复位、空闲） | `STATE RESET;` / `STATE IDLE;` |
| `RUNTEST` | 在 `Run-Test/Idle` 保持一段时间或一定时钟周期 | `RUNTEST 5000E-6 SEC;` / `RUNTEST 100 TCK;` |
通俗理解：
- `ENDDR`/`ENDIR` 是“扫完后去哪里”
- `STATE` 是“立刻去哪里”
- `RUNTEST` 是“在空闲区等待多久”
### 3.2 扫描操作类（真正移位与校验）
| 指令 | 作用（通俗版） | 典型格式 | 格式解释 |
|------|----------------|----------|----------|
| `SIR` | 扫描 IR，选择待执行 JTAG 指令 | `SIR 8 TDI (55);` | `8` 表示扫描位宽为 8 bit；`TDI(55)` 表示移入的 IR 数据为 `0x55`。 |
| `SDR` | 扫描 DR，执行读写数据与可选回读校验 | `SDR 16 TDI (1234) TDO (ABCD) MASK (FFFF);` | `16` 为 DR 位宽；`TDI` 为移入值；`TDO` 为期望回读值；`MASK` 指定参与比较的位（`1` 参与，`0` 忽略）。 |
| `HIR` / `HDR` | 在正式扫描前追加前导位（链路对齐/绕过） | `HIR 4 TDI (0);` | `HIR` 作用于 IR 链，`HDR` 作用于 DR 链；示例表示在正式扫描前先追加 4 bit 前导数据。 |
| `TIR` / `TDR` | 在正式扫描后追加尾随位 | `TDR 4 TDI (0);` | `TIR` 作用于 IR 链，`TDR` 作用于 DR 链；示例表示在正式扫描后追加 4 bit 尾随数据。 |
通俗理解：
- `SIR` 负责“选命令”
- `SDR` 负责“传数据 + 可选验证”
- `HDR/HIR` 与 `TDR/TIR` 主要用于链路对齐与多器件场景
### 3.3 时序与复位控制类（速度与复位信号）
| 指令 | 作用（通俗版） | 示例 | 示例解释 |
|------|----------------|------|----------|
| `FREQUENCY` | 声明可用的 JTAG 时钟上限（Hz） | `FREQUENCY 10E6 HZ;` | 声明后续操作可使用不高于 10 MHz 的 TCK 频率（`10E6` 即 `10,000,000 Hz`）。 |
| `TRST` | 控制可选 `TRST#` 复位信号 | `TRST ON;` / `TRST OFF;` | `TRST ON` 表示使能复位（通常将低有效 `TRST#` 拉低）；`TRST OFF` 表示释放复位。 |
注意：
- `FREQUENCY` 常用于约束或提示执行工具按该上限工作
- `TRST` 依赖硬件是否提供该引脚
### 3.4 扩展/并行类指令（工具相关，较少使用）
| 指令 | 说明 |
|------|------|
| `PIO` | 并行读写一组引脚（非 JTAG 核心指令） |
| `PIOMAP` | 将 PIO 通道映射到物理引脚 |
说明：`PIO`/`PIOMAP` 不属于通用 JTAG/SVF 核心流程，常见于特定测试平台。若目标是常规烧录/调试，可暂不使用。
### 3.5 简化片段示例（按执行顺序理解）
```svf
ENDDR IDLE; // 设置 DR 扫描结束行为
ENDIR IDLE; // 设置 IR 扫描结束行为
FREQUENCY 10E6 HZ; // 最高频率 10MHz
STATE RESET; // 进入复位状态
STATE IDLE; // 转入空闲状态
SIR 8 TDI (FF); // 扫描指令：示例值
SDR 16 TDI (1234) TDO (5678) MASK (FFFF); // 扫描数据：写入并校验返回值
RUNTEST 1E-3 SEC; // 等待 1ms
STATE IDLE; // 结束状态
```
### 3.6 两个易混淆点
1. `HDR/HIR` 与 `TDR/TIR` 不是必须项
在简单单器件场景中，常仅使用 `SIR`/`SDR`；多器件链路或需要填充位时再引入头尾位。
2. `ENDDR`/`ENDIR` 只定义扫描后的目标状态
它们不改变当前扫描的数据本身，而是影响扫描结束时 TAP 停留位置。
## 4. 在升级流程中的使用方式
BMC 支持通过 SVF 对 CPLD 进行升级。其本质是：解析 SVF 中的扫描数据与控制指令（如 `TDI` 数据字段、`SIR`、`SDR` 等语句），并通过 JTAG 链路驱动 `TDI`、`TMS`、`TCK` 等信号，按既定时序将配置数据下发到目标 CPLD，最终完成升级。
是否需要控制 `TRST` 信号取决于硬件设计：若板级已引出并接入该引脚，可在流程中使用；若未引出，则通常通过 `TMS` 序列完成 TAP 复位。
典型流程如下：
1. 由原厂工具或工程工具链导出 SVF 文件
2. 使用支持 JTAG/SVF 的执行工具加载该文件
3. 连接目标板卡并校验 JTAG 链路（器件顺序、IDCODE）
4. 执行 SVF，完成烧录/配置
5. 读取状态或回读关键寄存器进行结果确认
注意事项：
- **版本匹配**：SVF 与目标器件型号、工程版本需严格一致
- **链路一致性**：JTAG 链顺序变化会导致向量错位
- **时序要求**：某些器件对 `RUNTEST` 等等待时长敏感
- **供电与复位**：升级前应确认电源、时钟、复位状态稳定
### 4.1 参考实现补充（general_hardware）
结合 `general_hardware` 的实现，BMC 侧基于 SVF 升级 CPLD 的工程化流程可进一步归纳为：
1. **升级包匹配与解包**
- 根据 `Firmware` 包名匹配配置项（`update.cfg`），再按 `uid/system_id` 过滤目标 CPLD 对象
- 升级前先安全解包到临时目录，再按文件命名规则装载
2. **文件组织与命名约定**
- 单厂商常见命名：`cpld.svf` + `valid.svf` + `bypass.svf`
- 多器件/多厂商常见命名：`cpld01.svf`、`valid01.svf`、`bypass01.svf`（按 `file_id` 递增）
- `valid` 文件用于后续生效阶段，`bypass` 文件用于链路偏移/对齐场景
3. **链路准备与串行执行**
- 升级前切换到 firmware route（`switch_to_firmware_route`）
- 按需使能 bypass 模式，并通过 `set_upg_cpld_chip` 选中目标链上器件
- 逐片执行升级，单片完成后短暂等待，再继续下一片
4. **总线锁与并发保护**
- 升级与校验前尝试获取芯片锁（带重试和超时），避免并发访问同一硬件通道
- 成功后执行 SVF 写入流程，结束后立即解锁
5. **校验与生效管理**
- 升级成功后保存 `valid_*`（及 `bypass_*`）文件，供后续生效任务使用
- 冷生效路径通常由系统在后续阶段统一执行；热生效路径可按 chip 粒度快速生效
- 失败场景应删除残留生效文件并清理标志，避免下次误生效
### 4.2 安全自检场景（verify.svf）
CPLD 通过 `verify.svf` 实现安全自检流程：
- 升级后可加载 `verify.svf`（或 `verify01.svf` 等）进行 JTAG 侧回归校验
- 多厂商场景下，按 chip 信息映射到对应 `verifyXX.svf`，逐片校验
- 若校验失败或锁获取失败，流程应立即返回错误并记录审计日志
上述做法可显著提升 SVF 升级在量产环境下的可追踪性、并发安全性与生效可靠性。
## 5. 常见问题与排查建议
### 5.1 扫链失败（扫链结果为空）
现象：
- BMC `app.log` 中出现：`[cpld]get cpld device info failed`
- 同时 `framework.log` 中出现：`get cpld id:[] success`
- `id` 数组为空，表示业务流程成功调用了扫链接口，但返回的链路扫描结果为空
定位思路：
1. 排查 CSR 中配置的硬件链路是否正确
2. 排查实际硬件链路是否正常（连接、供电、时钟、复位、信号完整性等）
验证命令：
`mdbctl call Cpld_1_010101 bmc.kepler.Chip.JtagTarget GetChipIdcode 0`
### 5.2 升级失败（TDO 校验不通过）
现象：
- `linuxkernel_log` 中出现日志：`verify TDO [0] expect:03b, mask: 0xff, sample:0x0`
含义：
- 升级使用的 SVF 文件中，期望值（`expect`）是 `0x3b`
- 实际从 CPLD 链路读到的 TDO 采样值（`sample`）是 `0x0`
定位思路：
1. 先排查 CSR 配置的链路是否符合预期（例如应使用 `jtag0` 还是 `jtag1`）
2. 若日志中 `sample` 值**非 0**，优先排查 SVF 文件本身是否有问题（指令/位宽/掩码/目标器件不匹配）
3. 若 `sample` 值为 **0**，通常表示链路基本未读到有效值，需要从硬件侧观察 CPLD 的 TDO 波形
## 6. SVF文件加载与执行流程（深入）
SVF 的加载过程可以理解为：**SVF 解析器（运行在 PC、ATE 或嵌入式 MCU）逐行读取文本指令，并翻译为 JTAG 硬件接口上的精确时序波形。**
核心逻辑如下：
```mermaid
flowchart TD
A[开始加载SVF文件] --> B[初始化JTAG硬件
设置TCK等参数]
B --> C[逐行读取SVF语句]
C --> D{解析命令类型}
D -- FREQUENCY --> E[重新配置TCK时钟频率]
D -- STATE --> F[驱动TAP状态机到指定状态]
D -- SIR/指令扫描 --> G[执行指令寄存器扫描
移入特定指令]
D -- SDR/数据扫描 --> H[执行数据寄存器扫描
移入/移出数据并校验TDO]
D -- RUNTEST --> I[保持Run-Test/Idle状态
等待固定时间或时钟周期]
D -- HDR/HIR/TDR/TIR --> J[设置头部/尾部数据
用于后续扫描]
D -- ENDDR/ENDIR --> K[设置扫描结束后的 TAP 状态]
D -- TRST --> L[控制可选复位信号]
D -- 其他 --> M[处理PIO、PATHDATA等扩展命令]
G & H --> N{TDO校验是否通过？}
N -- 否 --> O[报告错误，停止加载]
N -- 是 --> P{是否还有更多语句？}
E & F & I & J & K & L & M --> P
P -- 是 --> C
P -- 否 --> Q[加载完成，成功]
O --> R[加载失败]
```
下面详细拆解关键步骤。
### 6.1 初始化阶段
在解析任何 SVF 命令之前，解析器需完成以下基础设置：
- **硬件接口初始化**：配置 JTAG 引脚（`TCK`、`TMS`、`TDI`、`TDO`），设置初始 TCK 频率（常见默认 1MHz 或更低，再由 `FREQUENCY` 动态调整）
- **状态机复位**：通过 TMS 序列将 TAP 强制复位到 `Test-Logic-Reset`，确保链上器件处于已知初态
- **参数初始化**：清空内部上下文，如 `HDR`/`HIR`/`TDR`/`TIR` 缓存与默认 `ENDDR`/`ENDIR` 状态
### 6.2 逐行解析与执行（核心循环）
解析器按顺序读取每条语句，忽略注释，识别命令与参数，调用底层 JTAG 驱动完成执行。
常见命令执行逻辑示例：
- **`FREQUENCY 10000000 HZ;`**
- 重新配置 TCK 频率
- 后续 `SIR`/`SDR` 在新频率下执行
- **`STATE RESET;`**
- 通过 TMS 输出特定序列（例如保持高电平并给出 5 个 TCK）进入 `Test-Logic-Reset`
- **`SIR 6 TDI(09);`**
- 进入 `Shift-IR`
- 按位序串行移入 6 位指令数据
- 退出到 `Update-IR` 使指令生效
- 根据 `ENDIR` 停留到目标状态（默认常见为 `Run-Test/Idle`）
- **`SDR 32 TDI(00000000) TDO(0484a093) MASK(0fffffff);`**
- 进入 `Shift-DR`
- 在移入 `TDI` 同时采集 `TDO`
- 按 `MASK` 指定位对比采样值与期望 `TDO`
- 不匹配则立即报错并停止（`SDR` 既传输也验证）
- 根据 `ENDDR` 退出到目标状态
- **`RUNTEST 10000 TCK;`**
- 保持 `Run-Test/Idle` 状态，输出指定数量 TCK 周期
### 6.3 错误处理与流程控制
- **TDO 校验失败**：`SIR`/`SDR` 期望值与实测值不一致时立即中止，并返回错误码（如 `SVF_MISMATCH`）
- **语法错误**：命令无法识别、参数格式非法（如错误十六进制字符）时停止加载
- **超时/资源错误**：`RUNTEST` 超出平台限制、内存分配失败等均可触发终止
### 6.4 实现注意事项（常见坑点）
1. **TAP 状态迁移精确性**
`STATE` 可指定中间态（如 `SELECT-DR-SCAN`），解析器需从当前态计算合法路径并输出正确 TMS 序列。
2. **`HDR`/`HIR` 与 `TDR`/`TIR` 的拼接处理**
这些前后缀会影响后续 `SIR`/`SDR` 的实际移位位流；若拼接错误会导致链路对齐失败。
3. **`RUNTEST` 时间精度**
使用 `SEC` 时需结合当前频率准确换算时钟数，并明确取整策略，避免累积时序偏差。
4. **长位流命令的内存管理**
超长 `SDR`（如 FPGA 配置位流）建议流式处理，边解析边下发，避免一次性分配大缓冲。
### 6.5 小结
SVF 加载本质是一个**解释执行**过程，关键在于：
- 正确实现 JTAG 底层时序与 TAP 状态机控制
- 稳健地解析文本命令并执行校验、错误中止与资源管理策略
这些细节处理到位，SVF 解析器才能稳定完成器件编程与测试任务。
---
# 升级生效管理指导
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/upgrade/upgrade_guide/upgrade_task_management_guide.html
> Language: zh
# 1 升级生效单任务管理机制
**升级生效单任务管理**将升级和生效操作为一个连续的单一任务进行管理。在任务创建并且满足**生效**条件后，系统会自动执行升级动作，升级完成后自动触发生效动作。
# 2 升级生效分别管理机制
**升级生效分别管理**将升级和生效操作分为两个独立的任务进行管理。首先创建并执行升级任务，升级完成后，创建生效任务，然后再判断是否满足**生效**条件，满足条件则自动立即生效，不满足生效条件时等待满足条件后再生效。两个任务可独立监控状态和进度。
# 3 定制化方法
### 3.1 定制是否采用异步升级策略
**定制化项**
|项目|值|
| --- | --- |
|定制化项|Custom_AsyncFirmwareUpdate定制项|
|定制化接口名称|Custom_AsyncFirmwareUpdate|
|取值类型|string|
|取值范围|“on” 或 “off”|
|默认值|“off”|
|处理逻辑|if (Custom_AsyncFirmwareUpdate== “on”)
redfish标准升级接口采用异步升级策略，待生效条件满足后再开始升级
else
redfish标准升级接口采用原有的升级与生效分离策略|
**定制化流程**
# 4. 导入导出方法
## 4.1 是否采用异步升级策略
|项目|值|
| --- | --- |
|导出项|UpgradeService|
|导出子项|AsyncFirmwareUpdate|
|取值类型|string|
|属性类型|ImportAndExport|
|取值范围|“on” 或 “off”|
|含义说明|是否采用异步升级策略|
|导出后是否可以直接导入|是|
# 5. 资源协作接口
**path：** `/bmc/kepler/UpdateService/FirmwareInventory/:Id`
**资源interface：** `bmc.kepler.UpdateService.FirmwareInfo`
**变化类型：** 新增资源协作接口属性
**属性：**
|属性名称|签名|只读|变化通知|属性描述|取值范围|访问权限|属性来源|持久化类型|易变属性|
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|ActiveCondition|as|true|false|属性描述：固件的生效条件|None、PowerOff、PowerOn、ResetBMC、ResetTargetDevice|R：ReadOnly|各固件下游组件启动时注册|无需持久化|false|
---
# VME文件介绍与CPLD升级实践指南
> URL: https://openubmc.cn/docs/zh/latest/build_upgrade/upgrade/upgrade_guide/upgrade_vme_file.html
> Language: zh
## 1. VME基本概述
VME 文件（Virtual Machine Environment file）是莱迪思半导体（Lattice Semiconductor）在 `ispVM Embedded` 体系中定义并推广的专有文件格式。
从工程实现角度看，VME 可理解为将 SVF（Serial Vector Format，串行向量格式）中的文本指令与数据转换为面向执行侧的紧凑表示（常见为二进制化/编码化，并支持可选压缩）的结果文件，用于嵌入式处理器高效解析与执行 JTAG 编程流程。
因此，相比标准 SVF 文本，VME 的核心价值在于在资源受限场景下兼顾存储效率与执行效率。
在 `general_hardware` 代码中，如果 CPLD 升级需要使用 VME 文件，需要在 HPM 升级包的 `update.cfg` 配置文件中设置 `UpdateFileType=vme`。
该配置用于告知升级框架按 VME 路径解析与执行后续流程。
VME 文件在本项目中主要用于 CPLD 固件升级场景，可理解为一类用于 JTAG 升级流程的向量文件格式。
在工程实现上，BMC 会将 VME 文件封装后下发给底层驱动，由驱动执行实际链路操作与数据写入。
### 1.1 缩略语表
| 缩略语 | 英文全称 | 解释 |
|--------|----------|------|
| `VME` | Virtual Machine Environment | Lattice `ispVM Embedded` 体系中的专有升级文件格式。 |
| `SVF` | Serial Vector Format | 文本化 JTAG 向量脚本格式，常作为 VME 的输入来源。 |
| `JTAG` | Joint Test Action Group | IEEE 1149.1 边界扫描接口，用于器件编程与测试。 |
| `BMC` | Baseboard Management Controller | 服务器板级管理控制器，可执行固件升级流程。 |
| `CPLD` | Complex Programmable Logic Device | 复杂可编程逻辑器件，本文主要升级对象。 |
| `FPGA` | Field-Programmable Gate Array | 现场可编程门阵列，常与 CPLD 同属可编程逻辑器件。 |
| `ASCII` | American Standard Code for Information Interchange | 文本编码标准，SVF 通常以 ASCII 文本形式存在。 |
| `ATE` | Automatic Test Equipment | 自动测试设备，常用于生产测试与烧录。 |
| `MCU` | Microcontroller Unit | 微控制器，常作为嵌入式执行 VME 的处理器。 |
| `DSP` | Digital Signal Processor | 数字信号处理器，部分嵌入式编程场景会使用。 |
| `HPM` | Hardware Platform Management | 服务器固件升级常用封装格式（`.hpm`）。 |
| `ISP` | In-System Programming | 在系统编程，指器件在板内完成下载/升级。 |
| `TMS/TCK/TDI/TDO` | JTAG Signals | JTAG 四个核心信号：模式、时钟、数据输入、数据输出。 |
| `UID` | Unique Identifier | 升级对象唯一标识，用于匹配固件与目标器件。 |
## 2. VME与SVF的关系
VME 文件的主要用途之一是对 SVF 文件进行简化与优化：SVF 通常是包含算法与数据的 ASCII 文本格式，而 VME 可视为其面向执行侧的二进制优化版本。
与 SVF 相比，VME 通常占用更少的存储空间用于保存码流文件，并对编码长度进行了优化，更适合资源受限场景。
简单来说，你可以把 SVF 想象成一份文本格式的说明书（人可读，但体积大），而 VME 文件则是这份说明书被编译成二进制代码后的版本（机器更易执行）。二者都能用于 JTAG 升级流程。
进一步对比如下表所示：
| 对比维度 | SVF文件 | VME文件 |
|----------|---------|---------|
| 文件格式 | 文本（ASCII），人类可读 | 二进制，机器可读 |
| 文件体积 | 大（文本描述冗长） | 小（二进制 + 压缩） |
| 解析方式 | 需逐行解析文本指令 | 直接按二进制结构执行 |
| 处理效率 | 需要文本解析，执行开销较高 | 可按预定义结构快速解析与执行 |
| 主要用途 | PC 端 ATE/调试器 | 嵌入式微处理器编程 |
| 可移植性 | 通常跨工具可读性更好 | 往往与具体平台/工具链绑定更紧 |
| 形态定位 | 更偏标准化文本脚本 | 更偏工程工具链产物 |
## 3. 文件格式与结构
从工程视角看，VME 文件可理解为“结构化执行载体 + 两类效率优化”的组合：
1. **存储形式**
VME 常以机器高效解析为目标，实际交付中可表现为二进制文件或十六进制编码载体（取决于工具链与发布方式）。
2. **数据结构**
- **算法部分（Algo）**：描述编程控制流程（如进入编程模式、擦除、校验）
- **数据部分（Data）**：承载实际待烧录数据（例如由设计文件转换得到的器件配置数据）
3. **内容来源**
通常由上位机工具结合 JTAG 链路拓扑信息、器件信息与用户设计数据打包生成。
### 3.1 压缩格式与循环格式
“压缩格式”和“循环格式”的 VME 文件，是 Lattice 为提升 `ispVM Embedded` 编程效率而设计的两种优化策略。
简单理解：**压缩格式**主要优化文件“体积”，**循环格式**主要优化执行“流程”。
#### 3.1.1 压缩格式（Compressed VME）
核心目标是**最小化文件体积**。
- **特点与原理**：将标准 SVF 指令/数据转换为更紧凑表示，并结合压缩算法（如游程编码）减少冗余；对大量重复数据场景效果明显。
- **应用场景**：适用于存储资源紧张的嵌入式设备（如 MCU Flash 空间有限）。
- **差异点**：执行前或执行时通常需要解压步骤，会带来一定 CPU/RAM 开销，属于“以算力换空间”的策略。
#### 3.1.2 循环格式（Looped VME）
核心目标是**优化执行效率**。
- **特点与原理**：通过可重复执行的块结构（循环/子流程）描述高重复操作，避免把同类指令逐条展开。
- **应用场景**：适用于对编程速度敏感，或处理器主频/RAM 受限但需高效执行的场景。
- **差异点**：要求执行引擎支持循环控制码解析，属于“以结构换速度”的策略。
#### 3.1.3 选型建议
在实际应用中两者通常可组合使用：
- **追求最小体积**：优先压缩格式
- **追求最快编程速度**：优先循环格式
- **通用嵌入式场景**：建议“压缩 + 循环”组合，通常能在体积与效率间取得更好平衡
## 4. VME命令集
SVF 的 `SIR`、`SDR`、`RUNTEST` 等命令是文本可读的；VME 侧通常不是以同样的文本命令直接呈现。
在嵌入式场景中，更常见做法是由配套解析器/库读取 VME 内部算法与数据，再翻译为底层 JTAG 信号序列（`TMS`、`TCK`、`TDI`、`TDO`）执行。
可简化理解为：**SVF 更偏“人可读脚本”，VME 更偏“机器可执行载荷”。**
VME 在指令组织上还引入了一些用于减少重复结构的机制（如 `BEGIN_REPEAT`、`CONTINUE`、`END_FRAME`、`END_REPEAT`、`DATA`、`PROGRAM`、`VERIFY`、`ENDVME`、`DTDI`、`DTDO`）。
这类结构化能力在标准 SVF 文本中通常没有一一对应的同名特性。
其中：
- `CONTINUE` 常出现在每个 `SIR`/`SDR` 逻辑段之后，用于标识该段结束并继续后续流程
- `END_FRAME` 常出现在每个 VME 数据帧之后，用于标识当前数据帧结束
### 4.1 指令映射汇总表
| 指令 | 指令码 | 指令说明 |
|------|--------|----------|
| `STATE` | `0x10` | 控制 TAP 状态机跳转到目标状态（如 `RESET`、`IDLE`）。 |
| `SIR` | `0x11` | 执行 IR 扫描，向指令寄存器移入指令位流。 |
| `SDR` | `0x12` | 执行 DR 扫描，进行数据移入/移出与可选校验。 |
| `TCK` | `0x1B` | 产生指定数量的测试时钟脉冲。 |
| `WAIT` | `0x1A` | 执行等待动作（按时间或时钟周期等待）。 |
| `ENDDR` | `0x02` | 指定 DR 扫描结束后 TAP 停留状态。 |
| `ENDIR` | `0x03` | 指定 IR 扫描结束后 TAP 停留状态。 |
| `HIR` | `0x06` | 定义 IR 扫描前导位（Header-IR）。 |
| `TIR` | `0x07` | 定义 IR 扫描尾随位（Trailer-IR）。 |
| `HDR` | `0x08` | 定义 DR 扫描前导位（Header-DR）。 |
| `TDR` | `0x09` | 定义 DR 扫描尾随位（Trailer-DR）。 |
| `BEGIN_REPEAT` | `0xA0` | 重复块起始标记，用于压缩重复执行结构。 |
| `TDI` | `0x13` | 指定移入链路的测试数据（Test Data In）。 |
| `CONTINUE` | `0x70` | 当前 `SIR`/`SDR` 逻辑段结束并继续后续流程。 |
| `END_FRAME` | `0xA2` | 当前 VME 数据帧结束标记。 |
| `TDO` | `0x14` | 指定期望回读数据（Test Data Out）用于比对。 |
| `MASK` | `0x15` | 指定回读校验掩码位（`1` 参与比较，`0` 忽略）。 |
| `END_REPEAT` | `0xA1` | 重复块结束标记。 |
| `DATA` | `0xA3` | 数据段标记，表示后续为待处理数据载荷。 |
| `PROGRAM` | `0xA4` | 进入或执行编程动作流程。 |
| `VERIFY` | `0xA5` | 进入或执行校验动作流程。 |
| `ENDVME` | `0x7F` | VME 文件/流程结束标记。 |
| `DTDI` | `0xA6` | 压缩/差分 TDI 数据段（用于减少重复编码）。 |
| `DTDO` | `0xA7` | 压缩/差分 TDO 数据段（用于减少重复编码）。 |
从 SVF 文件到 VME 文件的翻译通常按“逐条指令映射”的方式进行。示例如下：
- SVF 指令：`SIR 8 TDI (16)`
- 翻译后的 VME 字节序列：`0x02 0x08 0x0E 0x68`
## 5. 工程中的 VME 文件组织方式
结合现网实现，VME 相关文件通常按以下命名组织：
### 5.1 单文件（单厂商）模式
- `cpld.vme`：升级主文件
- `valid.vme`：后续生效文件
- `bypass.vme`：链路偏移/对齐相关辅助文件
### 5.2 多文件（多器件/多厂商）模式
- `cpld01.vme`、`cpld02.vme` ...
- `valid01.vme`、`valid02.vme` ...
- `bypass01.vme`、`bypass02.vme` ...
其中 `XX` 文件序号可由链路设备信息与芯片映射规则计算得到，用于多器件按片升级。
## 6. BMC侧VME升级流程
在服务器 BMC 领域，VME 文件是用于升级 CPLD（复杂可编程逻辑器件）的核心文件格式。为更好理解其应用位置，可先看端到端流程：
```mermaid
flowchart TD
A[开发人员生成VME文件] --> B[打包VME文件为HPM固件包]
B --> C[管理员通过BMC Web界面上传HPM包]
C --> D[BMC解析HPM包并提取VME文件]
D --> E[BMC通过JTAG接口烧录CPLD]
E --> F{烧录方式}
F -->|后台模式| G[先写入Flash
不影响CPLD当前运行]
F -->|直接模式| H[直接编程CPLD
期间CPLD逻辑失效]
G --> I[等待业务空闲
加载新固件并复位]
H --> J[CPLD复位后新固件生效]
I --> J
```
### 6.1 HPM包：VME文件的标准包装形态
服务器场景中的 VME 文件通常不会以“裸文件”直接交付，而是作为 HPM 包中的组成部分。
- **是什么**：HPM 是标准化固件升级容器，可理解为服务器固件升级“安装包”
- **为什么需要它**：可统一封装 CPLD/BIOS/BMC 等多类固件，并提供版本管理、签名校验等机制
- **怎么做**：研发阶段通常使用 `hpmimage` 等工具，将 `.vme`、配置与脚本打包为 `.hpm`
### 6.2 BMC如何执行VME升级
当通过 Web 或 CLI 上传包含 VME 的 HPM 包后，BMC 内部流程通常包括：
1. **解析与验证**：解包并校验签名/完整性，确认来源可信且未被篡改
2. **驱动 JTAG**：BMC 作为 JTAG 控制端，通过 `TMS/TCK/TDI/TDO` 与 CPLD 交互
3. **执行 VME**：升级引擎按 VME 内容执行擦除、编程、校验等步骤
### 6.3 平滑升级（无感升级）机制
为降低业务影响，工程上常采用“两阶段”策略：
- **阶段一：后台烧录**
将新固件写入 CPLD 外挂/片上 Flash，不立即切换运行镜像，业务侧通常无感知。
- **阶段二：择机生效**
在业务低峰、计划维护窗或受控重启时执行加载生效。必要时先锁定输出，再完成固件加载与复位，最后释放输出。
这种“后台烧录 + 择机生效”模式可显著降低在线升级风险。
### 6.4 行业实践（简要）
- **openUBMC 场景**：支持 VME 相关升级能力，并可通过 API 形式对接上层管理系统
- **主流服务器平台**：普遍采用 “BMC + JTAG + VME/HPM” 的 CPLD 升级技术路线
- **平台差异**：早期平台可能采用 I2C 流程，现有主流多收敛到 JTAG 方案
### 6.5 常见风险点（服务器场景）
- **文件兼容性**：不同 BMC 版本/硬件平台对 VME 支持可能存在差异
- **升级中断**：升级过程掉电或链路中断可能导致器件状态异常
- **方案代际差异**：老平台与新平台在链路和生效策略上可能不同，需按平台文档确认
### 6.6 与当前项目实现的流程映射
结合当前项目（`general_hardware`）实现，VME 升级可映射为以下工程步骤：
1. 解析升级包（`update.cfg` + 固件包）并匹配目标组件（`uid/system_id`）
2. 根据配置确定 `file_type=vme`，选择对应 `cpld*.vme` 文件
3. 切换固件路由（firmware route），必要时使能 bypass 并选中目标 chip
4. 获取芯片锁（带重试和超时）后执行升级写入
5. 升级成功后保存 `valid*.vme` / `bypass*.vme` 供后续生效
6. 解锁并恢复默认路由，进入生效或校验阶段
说明：升级写入阶段本质是将文件描述信息（文件类型、路径、长度等）按约定结构打包并传给底层接口执行；成功后进入 `valid/bypass` 生效链路。
## 7. 总结
VME 在本项目中是 CPLD 升级链路的核心输入格式，重点价值在于面向嵌入式执行场景的效率优化。
从工程落地看，应同时关注格式理解（SVF 关系、指令与结构）与流程闭环（打包、执行、生效、回归校验），以确保升级过程稳定可控。
---
# openUBMC Studio CLI (bingo)
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bingo/cli_tool.html
> Language: zh
openUBMC Studio CLI (bingo) 是BMC Studio的CLI命令行，常用于组件构建、产品构建等命令执行。本文档介绍bingo的具体使用方式。
# 构建产品包与发布包
我们构建命令目前已经集成到`bingo`命令中，这个命令在环境中已安装，只需要执行命令即可，我们先来看下`bingo`的帮助文档，这个帮助文档会在`manifest`仓路径(也就是产品路径)和组件仓路径显示不同，此节只讨论产品构建。
```shell
# 在manifest路径下执行命令
[04:51:58 root(1110):/home/workspace/codehome/manifest]# bingo --help
>> whoami
root
conan版本: 2.23.0
Integrated commands
build 构建出包
publish 构建版本发布包，-sc参数指定ToSupportE编码
Misc commands
help 获取命令帮助
new 创建组件
diff 获取两个产品版本间, 组件版本变更时的合并记录
fetch 基于参数指定的单个、部分、全量组件版本拉取源代码
config bingo参数配置
upgrade 升级 bingo 版本
analysis 依赖和接口分析
json_check json 文件检查
hpm_signer HPM 文件重签名
Studio commands
studio 执行bmc studio启动停止操作
check BMC Studio语法正确性与模型一致性检查
输入 "bingo -h" 获取子命令帮助
[04:52:01 root(1110):/home/workspace/codehome/manifest]#
```
从上面返回的日志，可以看到我们能够使用的命令，构建产品以及发布包只使用到其中一个命令，当前`build`命令与`publish`效果相同，其余命令后续自行深入学习，输入`build`的`help`命令，可以看到这个命令有很多的内容，部分版本有些命令没有，但是可以构建出`hpm`包，对出包没有影响
```shell
[04:52:01 root(1110):/home/workspace/codehome/manifest]# bingo build --help
>> whoami
root
conan版本: 2.23.0
usage: bingo [-h] [-b BOARD_NAME] [-bt BUILD_TYPE] [--stage STAGE]
[--verbose] [-ucc] [-r REMOTE] [-sc SUPPORTE_CODE]
[-v VERSION] [-t TARGET] [--deploy]
构建openUBMC
options:
-h, --help show this help message and exit
-b BOARD_NAME, --board_name BOARD_NAME
单板包，可选值为build/product//下的目录名
默认：openUBMC
支持的单板列表：
openUBMC
-bt BUILD_TYPE, --build_type BUILD_TYPE
构建类型，可选：debug（调试包）, release（正式包）
--stage STAGE 包类型，可选值为: dev(调试包), rc（预发布包）, stable（发布包）
默认：dev
--verbose 使能conan构建详细日志打印
-ucc, --update_conan_cache
全量更新本地conan缓存
-r REMOTE, --remote REMOTE
conan仓别名，请检查conan remote list查看已配置的conan仓
-sc SUPPORTE_CODE, --supporte_code SUPPORTE_CODE
待发布的SupportE编码，可选值参考单板manifest.yml/tosupporte
默认：default
-v VERSION, --version VERSION
构建版本号，不指定时从manifest.yml读取
-t TARGET, --target TARGET
构建目标，请查看build/target目录, 支持的目标：
install_sdk
publish
personal
app
--deploy 将hpm包部署至bmc设备
```
## 构建产品包
1. 构建`hpm`包
现在，开始构建一个`hpm`包，查看上面的`help`文档，可分析其具体含义，命令执行结束后，可在`manifest`目录下的`output`目录下找到构建出来的`hpm`包
```shell
# 进入到集成构建环境
cd manifest
# -t personal: 构建目标，个人构建指 hpm 包
# -b openUBMC: 单板名，执行bingo build -h，可以看到支持哪些单板
# -bt release: 构建类型，release正式包
# --stage rc: 包类型，预发布包
bingo build -t personal -b openUBMC -bt release --stage rc
```
以下为列出的生成件目录下文件，其中`rootfs_openUBMC.hpm`即为产品包
```shell
[05:22:48 root(1110):/home/workspace/codehome/manifest/output]# ls -l
total 70172
-rw-r--r-- 1 root root 1349 Mar 12 17:22 openubmc.perf
-rw-r--r-- 1 root root 54813 Mar 12 17:22 package.lock
drwxr-xr-x 5 root root 4096 Mar 7 14:32 packet
-rw-r--r-- 1 root root 0 Mar 12 17:20 prof.perf.lock
-rw-r--r-- 2 root root 70144173 Mar 12 17:22 rootfs_openUBMC.hpm
[05:23:04 root(1110):/home/workspace/codehome/manifest/output]#
```
2. 集成发布的组件
根据章节的流程，已经了解了组件的发布，组件发布以后，我们需要集成到产品包中，具体修改方法如下
* 第一步: 构建组件发布版本
在流程中，已经有组件的构建方法与发布方法，如果不清楚，请查看[组件构建与发布](../../build_upgrade/build/build_guide/build_process.md)
* 第二步: 在`subsys`目录下配置发布的组件版本
我们需要在`subsys`目录下添加新增的组件，当前组件发布只有`stable`版本，但仍需在`rc`和
`stable`目录下同时更改，这里的示例为`rc`版本，`stable`版本的修改同样如此
```yaml
# yaml-language-server: $schema=../../schema/subsys.rc.schema.json
dependencies:
- conan: "rackmount/1.90.198@openubmc/stable"
```
* 第三步: 在`manifest.yml`文件中配置添加的组件
新引入的组件，要在产品目录下配置相应的依赖，否则不会集成到产品包当中，`dependencies`字段中，每配置一个组件，则集成进一个组件，这里不要去填版本号，填入版本号后，更新组件版本时，则需要变更多个文件
```yaml
dependencies:
- conan: "huawei_secure_c"
- conan: "kmc"
- conan: "Signature_Verify_CBB_Library"
- conan: "sqlite3"
- conan: "openssh"
```
* 第四步: 构建产品包
使用第1小节的构建命令，则可以构建出产品包`hpm`
## 构建发布包
构建发布包命令与上面的命令稍有差异，如下所示
```shell
# 进入到集成构建环境
cd manifest
# -t publish: 构建目标，发布包
# -sc default: 发布包编码，这个编码可以在manifest.yml文件中的 tosupporte 字段中查询
# -b openUBMC: 单板名，查看帮助文档，可以看到支持哪些单板
# -bt release: 构建类型，release正式包
# --stage stable: 包类型，发布包
bingo build -t publish -sc default -b openUBMC -bt release --stage stable
```
执行完成以后，在`output`目录下会生成文件，如下为`output`树
```shell
[07:05:30 root(1110):/home/workspace/codehome/manifest/output]# tree
.
|-- openUBMC.perf
|-- package.lock
|-- packet
| |-- openUBMC
| | |-- openUBMC-CMT_1.00.00.00.zip
| `-- inner
| |-- release
| | |-- package_openUBMC.lock
|-- prof.perf.lock
`-- rootfs_openUBMC.hpm
4 directories, 6 files
[07:05:31 root(1110):/home/workspace/codehome/manifest/output]#
```
---
# 组件构建与发布
在构建组件时，我们需要切换到组件目录，执行`bingo`命令，否则`bingo`命令不生效，这里以组件`iam`组件来作为示例，演示组件的构建流程。
进入到`iam`的源码目录，执行如下命令来查看支持的构建参数
```shell
[07:16:31 root(1110):/home/workspace/codehome/iam]# bingo --help
>> whoami
root
conan版本: 2.13.0
Component commands
build 构建出包
deploy 将组件及其依赖部署至temp/rootfs目录
test 构建DT.
gen 代码自动生成，支持Lua和C语言，C组件需要在service.json中添加`"language": "c",`配置.
git_history 获取指定开始时间与结束时间之间提交信息，并生成release note
Misc commands
help 获取命令帮助
new 创建组件
config bingo参数配置
upgrade 升级 bingo 版本
analysis 依赖和接口分析
json_check json 文件检查
hpm_signer HPM 文件重签名
Studio commands
studio 执行bmc studio启动停止操作
check BMC Studio语法正确性与模型一致性检查
输入 "bingo -h" 获取子命令帮助
[07:16:33 root(1110):/home/workspace/codehome/iam]#
```
在上面返回的结果中，我们只使用到部分，`build`,`gen`为主要使用的命令，下面主要介绍这两条命令
## 代码自动生成
`gen`命令用来自动生成代码，现在组件的代码都是使用此工具来自动生成，自动生成后才能进行构建，所以这里先讲`gen`命令，查看`gen`命令的help菜单
```shell
[07:28:19 root(1110):/home/workspace/codehome/iam]# bingo gen --help
>> whoami
root
conan版本: 2.13.0
usage: bingo gen/当前只支持C和lua语言代码生成 [-h] [-v VERSION] [-r REMOTE] [-s SERVICE_FILE] [-w]
代码自动生成.
options:
-h, --help show this help message and exit
-v VERSION, --version VERSION
use specified version
-r REMOTE, --remote REMOTE
conan remote, 如不设置则默认读取本地conan配置
-s SERVICE_FILE, --service_file SERVICE_FILE
Service file
-w, --with_template generate with template
[07:33:21 root(1110):/home/workspace/codehome/iam]#
```
从返回结果，可以看到这个参数结构相对比较简单，建立好模板文件，使用如下命令即可生成代码
```shell
# -bt debug: 构建类型
# --stage rc: 预发布包
# 如果在mds目录下配置了model.json，则带上-w参数来进行模板生成
bingo gen -bt debug --stage rc
# 日志截取，没有发生报错，则表示自动生成成功
python3 /home/workspace/codehome/iam/temp/lua_codegen/script/template.py -d /home/workspace/codehome/iam/proto -j /home/workspace/codehome/iam/temp/lua_codegen/temp/iam/ -n iam -i /home/workspace/codehome/iam/temp/lua_codegen/temp/iam/db_json.json -f /home/workspace/codehome/iam/temp/lua_codegen/script/lua_format.py -t orm_classes.lua.mako -o /home/workspace/codehome/iam/gen/iam/orm_classes.lua
make[3]: Leaving directory '/home/workspace/codehome/iam/temp/lua_codegen/templates/apps'
make[2]: Leaving directory '/home/workspace/codehome/iam/temp/lua_codegen/templates'
make[1]: Leaving directory '/home/workspace/codehome/iam/temp/lua_codegen'
```
## 组件构建
`build`命令用来构建组件的版本包，使用`help`命令来看下`build`命令的帮助文档
```shell
[07:16:33 root(1110):/home/workspace/codehome/iam]# bingo build --help
>> whoami
root
conan版本: 2.13.0
usage: bingo build [-h] [-bt BUILD_TYPE] [--stage STAGE] [-u] [-r REMOTE] [--conan2] [-nc] [-o OPTIONS] [--user USER] [-wb]
Build conan
options:
-h, --help show this help message and exit
-bt BUILD_TYPE, --build_type BUILD_TYPE
构建类型，可选：debug, release
默认：debug
--stage STAGE 组件包发布阶段, 可选: ['dev', 'pre', 'rc', 'stable']
默认：dev
-u, --upload 上传组件包到conan仓
-r REMOTE, --remote REMOTE
conan仓别名，请检查conan remote list查看已配置的conan仓
--conan2 强制使用conan2构建组件，此参数仅用于临时兼容组件conan1和conan2构建场景
-nc, --no_cache 不使用~/.conan/data目录下的缓存包(构建前删除缓存)
-o OPTIONS, --options OPTIONS
Define options values (host machine), e.g.: -o Pkg/*:with_qt=True
--user USER 指定conan包的user字段，未指定时依次尝试读取mds/service.json的user字段，都未指定时使用'openubmc'
-wb, --without_build 不强制源码构建组件自身
[07:20:03 root(1110):/home/workspace/codehome/iam]#
```
根据上面的返回结果，需要使用的参数只有其中几个，以具体实例来讲解
```shell
# -b Board_A: 指定单板名，某些组件和单板名挂钩，需要指定单板名来打入某些文件，如果组件和单板无关，不带此参数
# -bt debug: 构建类型，调试包
# --stage rc: 预发布包
bingo build -b Board_A -bt debug --stage rc
# 截取部分日志放在这里
Downloading conanmanifest.txt completed [17.89k]
Downloading conaninfo.txt completed [2.97k]
Downloading conan_package.tgz completed [543.98k]
Decompressing conan_package.tgz completed [0.00k]
iam/1.20.31@openUBMC.release/rc: Package installed cb9794cb17b2f104bdddb1803a0104b29d12d75c
iam/1.20.31@openUBMC.release/rc: Downloaded package revision 35401b8fc57f5024055b6203bbd5abfe
Build successfully
[07:28:19 root(1110):/home/workspace/codehome/iam]#
```
在Build successfully上方，能看到编译完成的版本号，这个版本号就是生成的组件版本
## 组件测试
`test`命令用来执行组件的集成测试，单元测试，压力测试，使用`help`命令来看下`test`命令的帮助文档
```shell
[07:25:33 root(1110):/home/workspace/codehome/iam]# bingo test --help
>> whoami
root
conan版本: 2.13.0
usage: bingo [-h] [-bt BUILD_TYPE] [--stage STAGE] [-r REMOTE] [--conan2] [-s] [-nc] [-o OPTIONS] [--user USER] [-as] [-wb] [-pr PROFILE] [-jit] [-ut] [-it] [-ft]
[-fg] [-mt] [-mg] [-lf LOG_FILE] [-cnt FUZZ_COUNT] [-f TEST_FILTER] [-a APP] [--coverage_exclude COVERAGE_EXCLUDE] [--minimum]
[--package_info PACKAGE_INFO]
Test component
options:
-h, --help show this help message and exit
-bt BUILD_TYPE, --build_type BUILD_TYPE
构建类型，可选：debug, release 默认：debug
--stage STAGE 组件包发布阶段, 可选: ['dev', 'pre', 'rc', 'stable'] 默认：dev
-r REMOTE, --remote REMOTE
conan仓别名，请检查conan remote list查看已配置的conan仓
--conan2 强制使用conan2构建组件，此参数仅用于临时兼容组件conan1和conan2构建场景
-s, --from_source Build from source, include dependency component
-nc, --no_cache 不使用~/.conan/data目录下的缓存包(构建前删除缓存)
-o OPTIONS, --options OPTIONS
Define options values (host machine), e.g.: -o Pkg/*:with_qt=True
--user USER 指定conan包的user字段，未指定时依次尝试读取mds/service.json的user字段，都未指定时使用'openubmc'
-as, --asan Enable address sanitizer
-wb, --without_build 不强制源码构建组件自身
-pr PROFILE, --profile PROFILE
显式指定conan构建使用的profile文件 (~/.conan/profiles目录下)别名, 默认为: 空 可选值: profile.ini, profile.dt.ini, profile.luajit.ini, armv8_release, default
-jit, --enable_luajit
Enable luajit
-ut, --unit_test Enable unit test
-it, --integration_test
Enable integration test
-ft, --fuzz_test Enable fuzz test
-fg, --fuzz_gen Generate fuzz case
-mt, --mock_test Enable mock test
-mg, --mock_gen Generate mock case
-lf LOG_FILE, --log_file LOG_FILE
Monitor log file directory path
-cnt FUZZ_COUNT, --fuzz_count FUZZ_COUNT
Fuzz count
-f TEST_FILTER, --test_filter TEST_FILTER
Run unit test with a filter
-a APP, --app APP App in hica
--coverage_exclude COVERAGE_EXCLUDE
Specify coverage exclude file path of whitelist
--minimum, -m 获取dt构建的最小版本
--package_info PACKAGE_INFO, -pi PACKAGE_INFO
package_info 文件路径, 使用manifest配套版本dt构建, 此文件在manifest构建时会在inner目录生成
```
从返回结果，可以看到这个参数结构相对比较简单，使用如下命令即可执行组件测试
```shell
# 集成测试
bingo test -it
# 单元测试
bingo test -ut
# 日志截取，没有发生报错，则表示测试通过
================ 开发者测试开始 ================
================ 测试 bmc_time 开始 ================
1..1
# Started on Thu Dec 12 10:24:16 2024
# Starting class: TestTimeCfg
ok 1 TestTimeCfg.test_time_intf
# Ran 1 tests in 0.005 seconds, 1 success, 0 failures
Dt 报告结果输出到 /root/bmc_time/temp/coverage/dt_result.json
================================ 构建菜单 ================================
单元测试(ut): True
集成测试(it): False
自动测试(rt): False
覆盖率: False
地址消毒: False
============================================================================
===>>>> 测试: bmc_time/1.60.1@openubmc.dev/dev 完成
```
---
# openUBMC Studio常见问题
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bmc_studio/bmc_studio.html
> Language: zh
# 2026版本openUBMC Studio FAQ
## Q1：登录到社区时提示无法识别OS keyring，登录保持功能无法正常生效
**问题现象：**
登录到社区时，右下角弹窗提示`An OS keyring couldn't be identified for storing the encryption related data in your current desktop environment.`，登录保持功能无法正常生效，开启新页面或重启openUBMC Studio时仍为未登录状态
**问题原因：**
该问题可能与主机的凭证管理服务无法正常工作有关，请确认当前使用的主机是否支持凭证管理
首先确保Windows凭据管理器服务正在运行：
1. 按下`Win + R`，输入`services.msc`并回车。
2. 在服务列表中找到`Credential Manager`（凭据管理器），确保其状态为“正在运行”，启动类型建议为“手动”或“自动”。
3. 如果服务未运行，右键单击选择“启动”。
如果服务是启动的，则有可能当前主机没有权限管理凭证，请确认是否能够管理凭据：
1. 打开“控制面板”>“用户账户”>“凭据管理器”>“Windows 凭据”。
2. 确认是否能够正常打开，少数场景下，打开会报错，此时当前用户无权限管理凭据，请尝试提升用户权限
---
# 2025版本BMC Studio FAQ
## Q1：通过apt源安装仓颉工具链时，执行apt install cangjie-runtime命令报错trying to overwrite '/usr/share/bmc_studio/server/libsecurec.so', which is also in package bmc-studio 1.1.95.250628
**问题现象：**运行`apt install cangjie-runtime`安装仓颉工具链时报错，报错信息如下
```bash
dpkg: error processing archive /var/cache/apt/archives/cangjie-runtime_1.0.0_amd64.deb (--unpack):
trying to overwrite '/usr/share/bmc_studio/server/libsecurec.so', which is also in package bmc-studio 1.1.95.250628
Errors were encountered during processing:
/var/cache/apt/archives/cangjie-runtime_1.0.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
**可能原因：**安装仓颉工具时，旧版本 BMC Studio （1.1.95.250628版本）未卸载。
**处理建议：**请先运行代码
```bash
apt update
apt install bmc-studio
```
安装最新BMC Studio，然后再执行
```bash
apt install cangjie-runtime
```
## Q2：安装完成后，运行提示error while loading shared libraries: libcangjie-std-ast\.so: cannot open shared object file: No such file or directory
**问题现象：**安装完成后，提示 error while loading shared libraries: libcangjie-std-ast\.so: cannot open shared object file: No such file or directory
**可能原因：**未安装 cangjie-runtime
**处理建议：**参考[安装方式3](./installation_guide/bmc_studio_installation.md)配置 apt 源，然后在命令行输入命令：
```bash
apt install cangjie-runtime
```
然后重新启动 BMC Studio 即可。
## Q3：安装完成后，使用`bingo studio`命令无法正常拉起BMC Studio窗口
**问题现象1：**安装完成后，使用`bingo studio`命令，但是没有界面被唤起。
**可能原因1：**您使用的 linux 环境并非 wsl
**处理建议：**非 wsl 环境需要手动输入地址打开。
在 windows 中的 web 浏览器中（edge、Internet Explorer、chrome 任意均可）输入图中所示位置的地址，即可打开 BMC Studio 前端页面。
**问题现象2：**日志无异常，有浏览器窗口被打开，但窗口白屏，一段时间后显示无连接。
**可能原因2：**您曾经在配置过 netsh 转发规则
**处理建议：**打开管理员权限的 powershell ，输入命令
```bash
netsh interface portproxy show all
```
如果发现有您的端口号相关的设置，请清除它。
```powershell
netsh interface portproxy delete v4tov4 listenport=10000 listenaddress=x.x.x.x
```
请自行替换命令中的listenaddresss
**问题现象3：**现象同问题现象2，但`netsh interface portproxy show all`没有发现回显
**可能原因3：**有进程在占用您的端口号
**处理建议：**
```bash
# 在wsl终端里输入以下命令查找是否有进程在占用10000端口
sudo netstat -tlnp | grep :10000
# 如果发现占用进程，结束它
sudo kill -9
```
请自行替换命令中的端口号和 pid
此外，windows 端中也有可能有进程占用 10000 端口。
您可以使用命令：
```powershell
netstat -ano | findstr :10000
```
如果看到如下回显：
请在任务管理器中使用回显中最后的数字查找该进程，如果您认识且认为不重要，您可以在任务管理器中右键点击这个进程并点击"结束进程"
如果该应用对您很重要，可以修改我们的脚本，将/usr/share/bmc_studio/load_nginx.sh中的第46行从
```bash
FRONTEND_PORT=$((10000 + USER_ID % 10000))
```
修改为
```bash
FRONTEND_PORT=$((10001 + USER_ID % 10000))
```
**问题现象4：**日志报错"Failed to auto-open in WSL"
**可能原因4：**您在 `/etc/wsl.conf` 这个文件中配置了 `default=root` ，wslu 的 bug 会将这个配置误识别为 windows 挂载点配置，导致无法获取到正确的 windows 目录地址。
**处理建议：**打开文件 `/usr/bin/wslview`，删除114~119行内容：
```bash
if [ -f /etc/wsl.conf ]; then
tmp="$(awk -F '=' '/root/ {print $2}' /etc/wsl.conf | awk '{$1=$1;print}')"
[ "$tmp" == "" ] || win_location="$tmp"
[[ "$win_location" =~ ^.*/$ ]] || win_location="$win_location/" # make sure it always end with slash
unset tmp
fi
```
删除完成后，重新打开 BMC Studio 。
## Q4：BMC Studio 上传文件/文件夹报错 fail to post /studio-tool/csr/folder
**问题现象：**
在 csr 页面选择导入代码仓或导入单个 csr 报错，信息为
```bash
fail to post /studio-tool/csr/folder
```
**可能原因：**
您的系统磁盘剩余空间不足
**处理建议：**
清理您的系统，获得更多的磁盘剩余空间。
## Q5：BMC Studio 一键仓库部署超时
**问题现象：**
使用 manifest 创建完工作空间后，按照文档流程在仓库管理页面点击一键仓库部署，然而超时失败
**可能原因：**
您没有登录 conan 账号
**处理建议：**
在命令行输入命令
```bash
conan remote login openubmc_dev 您的账号 -p 您的密码
```
登录 conan 账号后，重新一键仓库部署即可。
## Q6：BMC Studio 的 QEMU 在线调试过程中，资源协作接口获取不全
**问题现象：**
拉起 QEMU 后，使用 BMC Studio 连接上 QEMU ，点开在线调试的资源协作接口窗口后，接口显示很少。
**可能原因：**
QEMU 性能较慢，获取全量接口需要时间。
**处理建议：**
请耐心等待，并通过刷新按钮查看新增接口。
## Q7：BMC Studio 连接真机后，无法进行在线调试
**问题现象：**
BMC Studio 连接真机后，无法进行在线调试。
**可能原因：**
BMC Studio 的在线调试能力尚未支持真机，存在破坏环境的风险，目前暂时仅支持基于 QEMU 的调试。
**处理建议：**
建议使用 QEMU 进行替代。QEMU 每次启动都会重置，调试导致环境出现问题后只需要重启 QEMU 即可。
## Q8：无法使用插件进行调试文件
**问题现象：**
使用 VsCode 修改文件后，无法进行调试或右上角没有调试图标
**可能原因：**
不是所有文件都支持调试，支持的文件主要是 `/opt/bmc/apps/` 组件名路径下的 lua 文件、北向接口配置文件以及 `/opt/bmc/sr` 路径下的内置CSR文件。且 mdb_interface 这种模型定义仓暂时也不支持直接通过 VsCode 调试。
**处理建议：**
使用出整包的方式调试。
## Q9：运行 BMC Studio 时闪退
**问题现象：**
运行 BMC Studio 时闪退，报错信息为
```bash
xxxxxx E Thread "bmc_studio_serv" catched unhandled SIGILL /(Illegal instruction) from managed frame. signal pc: 0xxxxxxxxxxxxx
/usr/share/bmc_studio/bmc_studio.sh: line 96: xxxxxx Segmentation fault ./bmc_studio_server "$1"
Failed to start foreground service
```
**可能原因：**
BMC Studio 使用仓颉语言开发，目前仓颉语言依赖 avx2 指令集。您使用的电脑 CPU 可能不支持 avx2 指令集。可以通过在 linux 命令行中执行命令
```bash
lscpu | grep avx2
```
来进行判断。如果没有出现结果，那么您的 cpu 可能就不支持 avx2 指令集。
**解决方案：**
如果您的 cpu 不支持 avx2 指令集，可能暂时无法使用 BMC Studio。请期待未来仓颉更新后解除对 avx2 指令集的依赖。
## Q10：运行 BMC Studio 的终端被关闭了，如何查看日志？
**问题现象：**
在命令行唤起 BMC Studio 后，终端被误关闭，导致没法看日志。
**解决方案：**
BMC Studio 的日志会保存在 `~/bmc_studio/var/log/debug.log` 中，可以手动打开这个文件进行查看。
---
# openUBMC Studio 安装指南
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bmc_studio/installation_guide/bmc_studio_installation.html
> Language: zh
# openUBMC Studio 开发平台
openUBMC Studio 是 openUBMC 社区推出的集成化开发平台，专为 BMC 固件开发打造，提供代码编辑、项目构建、设备仿真、自动化检查等一站式开发体验。**推荐**所有开发者安装使用；首次体验时，可以暂不安装。
本文档主要介绍 openUBMC Studio 的环境搭建以及安装指导。
openUBMC Studio可以通过[openUBMC应用市场](https://www.openubmc.cn/marketplace)获取
# 安装openUBMC Studio
## 下载安装包
1. 访问openUBMC Studio下载链接
2. 下载安装包到本地
> **说明**：
> 建议从官方渠道下载安装包，以确保软件的安全性和完整性。
## 执行安装程序
1. 双击打开下载的exe安装包
2. 根据安装向导提示进行操作：
- 同意许可协议
- 选择是否从vscode迁移插件（如果之前安装过VSCode，可选择迁移已有插件）
3. 点击“安装”按钮，等待安装完成
4. 安装完成后，点击"完成"退出安装向导
> **说明**：
> 安装过程中如果遇到杀毒软件拦截，请选择允许或添加到信任列表。
## 环境初始化配置
首次启动 openUBMC Studio 时，需要完成社区登录、BMC 开发环境部署和规则集配置。您可以使用 AI Agent 按当前环境状态自动引导，也可以按照引导页面手动完成配置。
### 使用 AI 引导初始化
如果已安装并能正常使用 AI Agent（例如 opencode、Claude Code 或 Cursor），建议使用 AI 引导完成初始化：
1. 启动 openUBMC Studio，在欢迎页面中单击“配置引导”。
2. 在配置引导窗口中找到“AI 引导初始化”卡片。
3. 单击“复制指令”，再单击“复制到 AI Agent”。
4. 将复制的 Prompt 粘贴到 AI Agent 并发送。AI Agent 会查询当前配置进度，依次引导完成 GitCode 登录认证、开发环境部署和规则集配置；已经完成的步骤会自动跳过。
5. AI Agent 执行完成后，确认配置引导窗口显示初始化已完成，并检查状态栏中的登录状态、机型和规则集信息。
初始化中断后，可以重新发送 Prompt 继续执行。完整操作和问题排查请参见[AI 引导环境初始化](#使用-ai-引导初始化)。
### 手动完成初始化配置
如果暂不使用 AI Agent，可以按照以下步骤手动完成初始化：
1. 首次启动openUBMC Studio，界面将显示初始化引导页面。
2. 根据引导页面的提示，逐步完成以下配置。
- 登录到社区
1. 点击IDE右下角状态栏中的登录图标
2. 在弹出的登录页面中输入您的openUBMC社区账号和密码
3. 点击“登录”按钮完成登录
- 配置BMC开发环境
1. 关闭新功能展示页面
2. 根据[环境准备](../../../getting_started/quick_start/env_introduction.md)配置环境
- 配置conan
在 Linux 中运行 manifest 仓库中的初始化脚本 `init.py`，脚本会自动完成配置。
如果在 Windows 中，则需前往 [Conan 官方下载页面](https://conan.org.cn/downloads)下载安装包，手动安装 Conan 后通过 openUBMC Studio 登录到社区。
- 配置检查规则集
点击Web版Studio状态栏中的"未选择机型"按钮，按以下步骤操作：
1. 在模型配置页面中，选择对应的产品和规则集。
2. 确认产品信息后，选择需要配置的模型文件。
3. 配置模型文件对应的代码仓和分支信息。
4. 完成配置后，点击"确定"保存配置。模型配置完成后，规则检查、拓扑配置等功能即可正常使用。
3. 点击“完成”按钮，完成初始化配置。
> **说明**：
> 初始化配置完成后，如果完成过一次完整配置则不再弹出，可随时通过欢迎页面重新触发。
> 环境初始化完成后，一般不需要频繁配置。
---
# openUBMC Studio适配指南
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bmc_studio/user_guide/bmc_studio_adapt_guide.html
> Language: zh
openUBMC 采用组件化架构，需与板卡、传感器、电源、RAID/GPU/NPU 网卡等部件完成适配后方能在产品中落地。openUBMC Studio 适配指南包括板卡适配与部件驱动适配，介绍如何借助 Studio 的可视化拓扑配置、参数配置等能力，以拖拽替代手工编写配置文件，降低适配门槛、减少出错概率，帮助开发者快速交付可运行的 BMC 固件。
[**openUBMC Studio整机适配指南**](../../../hardware/system_adapt/quick_start/board_integration_guide.md)
介绍如何使用 BMC Studio 的可视化能力完成板卡 CSR 拓扑配置与器件参数适配。
---
# openUBMC Studio 用户指南
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bmc_studio/user_guide/bmc_studio_tool.html
> Language: zh
# 一、简介
openUBMC Studio 是一款基于 Code - OSS 的 openUBMC 集成开发环境，面向 openUBMC 开发、调试和构建场景。
## 最近版本新增功能
下表按发布时间倒序汇总 openUBMC Studio 最近三个版本的新增功能，单击功能名称可跳转到对应章节。当前收录 2026 年 8 月和 9 月发布的版本；后续发布新版本时，仅保留最近三个版本。
| 版本 | 新增功能 |
| --- | --- |
| **2.1.1（2026 年 9 月 1 日）** | [AI 引导环境初始化](#ai-env-init)：通过预置 Prompt 引导 AI Agent 完成 GitCode 登录、开发环境部署和规则集配置。
[CSR 拓扑插件 0.3.7](#bmc-csr-topo)：提供本地、日志和远程三种整机拓扑模式，支持总线异常检测、单板卡配置、日志包离线还原和真机在位调试。
[事件管理](#event-management)：可视化管理事件字典、描述模板和 CSR 事件绑定，并导出事件字典及机型支持清单。
[日志诊断、Agent 日志体检与告警链条分析](#log-diagnosis)：导入 BMC 一键日志压缩包或 dump 目录，结合本地证据和 openUBMC RAG 生成问题清单、导出 PDF 报告，并分析指定告警的触发链条。
[C/C++、Lua 与北向接口快速调试](#quick-debug)：根据组件 Git 变更生成调试计划，直接部署 Lua 和运行时配置，按需构建 C/C++ 与生成型北向配置，并完成服务重启、结果校验和环境恢复。
[BMC 远程 GDB 调试](#remote-gdb-debug)：支持附加板端 systemd 服务，或部署并启动独立程序进行源码级调试。
[出包签名配置](#sign-config)：可视化管理 HPM 和 EEPROM 签名档案，生成本地自签名证书并吊销签名者证书。 |
| **2026 年 8 月 1 日版本** | [BMC 环境管理插件](#bmc-env-management)：集中管理多台 BMC，支持连接与分组、命令宏、SFTP/HPM 升级、日志监控和 MCP 工具。
[白牌包定制](#white-brand)：可视化定制 Web 风格、Logo、图片和产品信息，并构建白牌包或清白牌包。
[Manifest 配置与一键出包](#manifest-package)：可视化编辑 `manifest.yml` 出包配置，并按机型和包型构建固件包。
[组件与固件联合构建](#joint-build)：从业务组件仓构建本地组件包，在隔离 Manifest 中验证选包并转入固件出包。 |
## 主要特性
openUBMC Studio 的主要特性包括：
- **智能代码辅助**：提供代码跳转、定义预览和引用查找等功能。
- **实时错误检查**：基于规则集检测代码错误和潜在问题。
- **表达式计算器**：支持 CSR 表达式的编写、调试和批量测试。
- **SMC 命令字配置**：提供可视化的 SMC 命令字解析和配置工具。
- **模型配置**：支持产品和规则集的选择与配置。
- **CSR 拓扑可视化与调试**：支持本地、日志和远程三种整机拓扑模式，提供总线异常检测、单板卡配置、日志包离线还原和真机在位调试。
- **事件管理**：支持查看和编辑事件字典、描述模板及 CSR 事件绑定。
- **能效调速配置**：支持通过 Excel 导入热设计表格并生成 CSR 调速曲线代码。
- **Manifest 可视化配置**：支持配置构建变体、组件依赖、默认特性和组件特性，并提供配置诊断。
- **组件与固件联合构建**：支持从业务组件仓构建本地组件包，在隔离 Manifest 中验证选包并转入固件出包。
- **一键出包**：支持选择机型和包型，完成出包预检、固件构建、日志查看和产物下载。
- **签名配置**：支持管理 HPM 和 EEPROM 签名档案，并生成或吊销本地自签名证书。
- **AI 引导环境初始化**：支持通过 AI Agent 完成社区开发环境初始化。
- **日志诊断与告警链条分析**：支持导入 BMC 一键日志进行可视化诊断、Agent 日志体检和告警链条分析。
- **C/C++、Lua 与北向接口快速调试**：支持按照 Git 变更规划直接部署或隔离构建，将最小替换集部署到 BMC 并验证结果。
- **BMC 远程 GDB 调试**：支持附加板端服务，或部署独立程序进行源码级调试。
- **BMC 环境管理插件**：集中管理多台 BMC，支持连接与分组、命令宏、SFTP/HPM 升级和日志监控。
- **白牌包定制**：支持可视化定制 Web 风格、Logo、图片和产品信息，并构建白牌包或清白牌包。
- **社区集成**：对接 openUBMC 社区资源和服务。
# 二、AI 引导环境初始化
openUBMC Studio 提供 AI 引导环境初始化能力。将预置 Prompt 发送给 AI Agent（例如 opencode、Claude Code 或 Cursor）后，AI Agent 会检测当前状态、诊断问题，并按顺序引导用户完成社区开发环境初始化。
## 使用前准备
- 已安装并能正常使用 AI Agent，例如 opencode、Claude Code 或 Cursor。
## 打开配置引导
1. 在欢迎页面中单击“配置引导”入口。
2. 在打开的配置引导窗口中找到“AI 引导初始化”卡片。
## 复制引导指令
1. 单击“复制指令”卡片，打开 Prompt 对话框。
2. 单击“复制到 AI Agent”，将 Prompt 复制到剪贴板。
3. 切换到 AI Agent，粘贴并发送 Prompt。
## 了解 AI 引导流程
AI Agent 接收到 Prompt 后，会按以下流程引导用户完成环境初始化：
1. **GitCode 登录认证**：AI Agent 打开 OAuth 登录窗口，并在用户授权后检测登录状态。
2. **环境检测与部署**：AI Agent 检测操作系统。Windows 用户可以选择 Docker（约 5 分钟）或 WSL（约 30 分钟）部署方式，Linux 用户直接进入环境配置。
3. **规则集配置**：AI Agent 引导用户在 openUBMC Studio 界面中选择机型和规则集，并通过 `localview_get_data_source` 验证配置是否生效。
4. **状态写回**：每个步骤完成后，AI Agent 会回写向导状态；全部步骤完成后，向导状态变为“已完成”。
> [!NOTE]说明：
> AI Agent 在每个步骤开始前会查询当前配置进度，并自动跳过已完成的步骤。初始化中断后，可以重新发送 Prompt 继续执行。
## 验证初始化结果
1. 确认配置引导窗口显示初始化已完成。
2. 返回欢迎页面，确认状态栏中的登录状态、机型和规则集信息已更新。
## 常见问题
- **Docker SSH 连接失败**：检查容器内 `sshd` 是否启动、`10022` 端口是否开放，以及密钥认证是否配置正确。
- **Conan 鉴权失败**：检查 GitCode 登录状态是否有效，重新登录后重试。
- **规则集未生效**：在 openUBMC Studio 状态栏中确认是否已选择机型和规则集，必要时重新配置。
# 三、登录到社区
openUBMC Studio提供了便捷的社区登录功能，通过社区登录可以获取更多资源和服务支持。
## 登录步骤
1. 点击IDE右下角状态栏中的登录图标
2. 在弹出的登录页面中输入您的openUBMC社区账号和密码
3. 点击“登录”按钮完成登录
## 登录状态保持
登录成功后，IDE会自动保持和刷新登录状态：
- **自动刷新**：IDE会定期刷新登录状态，确保持续有效
- **状态保持**：退出IDE后，登录状态会继续保持一段时间
- **自动重连**：重新打开IDE时，会自动尝试使用上一次的登录状态重新登录
## Conan中心仓集成
登录社区后，IDE会自动同步登录到Conan中心仓：
- 登录状态自动保持并刷新
- 只要IDE处于登录状态，Conan就处于登录状态
- 在执行出包等操作时不会因为认证问题而超时
> [!NOTE]说明：
> 建议在开始开发工作前先完成社区登录，以确保能够正常访问所有资源和服务。
# 四、openUBMC 远程连接
openUBMC 远程连接插件用于在 openUBMC Studio 中接入远程开发环境。通过该插件，用户可以在 IDE 内管理本地 Docker 镜像并一键连接容器开发环境，也可以直接打开 SSH 远程主机或 WSL 发行版中的目标工作目录，无需在多个工具之间切换。
插件提供以下两类核心能力：
| 能力 | 说明 | 典型场景 |
| --- | --- | --- |
| 管理与连接 Docker 镜像 | 查看本地 Docker 镜像，基于镜像启动、停止、删除容器，并一键连接容器内的开发环境 | 在 Windows 下使用 openUBMC 开发镜像快速搭建开发环境 |
| 打开 SSH 或 WSL 目标工作目录 | 通过 SSH 连接远程主机，或打开本机 WSL 发行版中的目录作为工作空间 | 代码位于远程服务器或 WSL 中，需要在 IDE 内直接编辑和调试 |
## 管理与连接 Docker 镜像
1. 在远程连接插件视图中查看本地已有镜像，包括镜像名称、标签、大小等信息。
2. 通过镜像条目上的操作按钮管理镜像：
- **连接到该镜像**：基于选中的镜像创建并启动容器。
- **拉取镜像文件**：将选中的镜像文件拉取到本地用于后续的容器创建与连接。
- **创建容器**：为选中的镜像选取工作目录并以该目录创建容器。
### 连接容器开发环境
1. 在镜像中点击连接到该镜像，或者找到镜像列表下的已创建容器，选择“连接到容器”。
2. 连接成功后，左下角状态栏显示当前连接的容器名称，后续的编码辅助、构建和调试功能均在该容器内执行。
## 打开 SSH/WSL 目标工作目录
1. 通过远程连接插件最上方的选项选择SSH Targets或者WSL Targets。
2. 在当前已检测到的WSL目标或已创建的SSH目标中，选择要打开的目标WSL distro或SSH。
3. 选择WSL目录或SSH中的特定文件夹作为目标工作目录打开。
4. 等待连接建立后，WSL/SSH 目录会作为工作空间打开，左下角状态栏显示当前发行版名称。
> [!NOTE]说明：
> 通过 Docker、SSH 或 WSL 方式打开工作空间后，CSR 编码辅助、组件构建、一键出包等功能均可正常使用。组件构建与一键出包要求使用 Linux 本地、WSL 或 SSH Remote 工作空间。
## 常见问题
- **Docker 连接失败**：确认 Docker 服务已启动，Docker Desktop 处于运行状态。
# 五、CSR 编码辅助
openUBMC Studio提供了强大的CSR编码辅助功能，包括引用跳转、规则检查、表达式计算器和SMC计算器等，帮助开发者快速定位代码、发现问题并提高开发效率。
## 模型配置
使用CSR编码辅助功能前，需要先完成模型配置。登录IDE后，点击Web版Studio状态栏中的"未选择机型"按钮，按以下步骤操作：
1. 在模型配置页面中，选择对应的产品和规则集。
2. 确认产品信息后，选择需要配置的模型文件。
3. 配置模型文件对应的代码仓和分支信息。
4. 完成配置后，点击"确定"保存配置。模型配置完成后，规则检查、拓扑配置等功能即可正常使用。
> [!NOTE]说明：
> 模型配置完成后即可使用以下CSR编码辅助功能。后续如需切换产品或规则集，可重新进行模型配置。
## 引用跳转功能
引用跳转功能可以帮助开发者快速定位代码定义和引用位置，支持多种跳转方式，大幅提高代码阅读和导航效率。
### 转到定义
1. 在代码编辑器中，将光标定位到需要查看定义的符号上。
2. 使用以下任一方式跳转到定义：
- 右键点击符号，选择“转到定义”
- 按住 `Ctrl` 键，点击符号
3. 编辑器将自动跳转到符号的定义位置。
### 转到引用
1. 在代码编辑器中，将光标定位到需要查看引用的符号上。
2. 使用以下任一方式查看引用：
- 按下 `Shift + F12` 键
- 右键点击符号，选择“转到引用”
3. 在侧边栏将显示所有引用该符号的位置列表。
4. 点击列表中的项可跳转到对应的引用位置。
### 鼠标悬停预览定义
1. 在代码编辑器中，将鼠标悬停在符号上。
2. 等待片刻，将显示符号的定义预览窗口。
## 基本规则错误检查功能
openUBMC Studio内置了CSR规则检查功能，模型配置完成后即可支持CSR语法与配置约束的实时检查。该功能支持错误位置高亮和规则自动更新，帮助开发者在编码阶段就发现潜在问题。
### 实时检查
模型配置后，在openUBMC Studio中打开任意CSR文件，检查自动生效：
页面中的类型错误和格式错误都会被实时拦截：
表达式中的语法错误也可以被实时拦截：
### 查看检查结果
1. 错误和警告会以波浪线形式标注在代码中：
- 红色波浪线：表示错误（Error）
- 黄色波浪线：表示警告（Warning）
2. 查看"问题"面板：
- 点击底部"问题"标签页
- 查看所有错误和警告列表
- 点击列表项可快速定位到对应代码位置
### 复杂规则校验
openUBMC Studio已建立复杂规则校验能力，可以在社区代码仓 [openubmc_dsl_rulepack](https://gitcode.com/openUBMC/openubmc_dsl_rulepack) 中开发业务相关的检查规则，自定义规则同样支持实时检查功能。
## 表达式计算器功能
表达式计算器是openUBMC Studio提供的强大工具，用于编写、调试和测试CSR表达式，帮助开发者快速验证表达式的正确性。
### 打开表达式计算器
1. 打开CSR文件，在表达式上方将显示“计算表达式”按钮
2. 点击“计算表达式”按钮，表达式计算器窗口将在右侧打开
### 表达式计算器界面
表达式计算器界面包含以下部分：
- **表达式编辑区**：显示和编辑当前选中的表达式
- **模式切换按钮**：可以在“调试模式”和“用例模式”之间切换
- **变量面板**：显示当前表达式中可用的变量及其值
- **结果面板**：显示表达式计算结果和各级管道的计算过程
### 修改表达式
1. 在表达式编辑区查看或修改表达式
2. 修改完成后，点击“保存到文件”按钮保存修改
3. 保存后，表达式计算器会自动重新加载表达式
4. 源文件中的表达式修改并保存后，表达式编辑页面也会自动重新加载
### 调试表达式
1. 在表达式编辑区查看表达式内容
2. 在变量面板中输入或修改变量值
3. 完成输入后，系统将自动计算：
- 各级管道的中间结果
- 最终表达式结果
> [!NOTE]说明：
> 调试功能可以帮助您逐步查看表达式的计算过程，快速定位问题。
### 表达式批量用例测试
1. 在表达式计算器中，
点击“用例模式”按钮切换到批量测试模式
2. 创建测试用例：
- 按照要求输入测试用例名称和参数值以及结果值
3. 执行批量测试：
- 点击“加载用例”加载所有测试用例
- 点击“Execute all”执行所有测试用例
- 查看验证报告，显示每个用例的执行结果
> [!NOTE]说明：
> 测试用例可以导出为文件，方便团队共享和版本管理。
> 建议为复杂表达式编写多个测试用例，确保表达式在各种情况下都能正确工作。
## SMC计算器功能
SMC计算器用于解析和配置SMC命令字，帮助开发者快速理解和生成SMC命令，简化SMC相关的开发工作。
### 打开SMC计算器
1. 打开CSR文件，定位到Scanner或Accessor的offset字段
2. 点击offset字段上方显示的"计算偏移量"按钮
3. SMC计算器窗口将在右侧打开
### SMC命令字解析
SMC计算器提供了强大的命令字解析功能：
1. **自动解析**：当前偏移量会被自动解析，显示各字段的含义
2. **实时计算**：修改下方输入框的数据内容将自动更新和计算偏移量
3. **应用到文件**：点击“应用”按钮可以将计算结果写入到CSR文件
4. **字段提示**：鼠标悬停在字段上方可以显示具体的字段含义和说明
### SMC命令字可视化辅助
openUBMC Studio提供了直观的SMC命令字可视化功能：
1. **水印显示**：SMC命令字将在CSR中以水印形式显示字段内容，方便查看
2. **悬停详情**：鼠标悬停在offset字段上将显示偏移量的详细信息，包括：
- 各字段的值
- 字段的含义
- 完整的偏移量计算结果
> [!NOTE]说明：
> 可视化辅助功能可以帮助您快速理解复杂的SMC命令字结构，减少配置错误。
# 六、拓扑与 CSR 可视化配置
CSR 拓扑插件提供整机和单板卡两个维度的总线及器件拓扑可视化。0.3.7 版本新增本地、日志和远程三种整机拓扑模式，并支持总线异常检测、日志包离线还原、真机在位调试以及单板卡可视化配置。
## 创建拓扑配置
1. 单击 openUBMC Studio 左侧的拓扑十字形侧边栏图标。
2. 单击“创建配置”。
3. 单击“添加仓库”，选择 CSR 文件夹，即可在该机型配置中使用来自该文件夹的 CSR。可以添加多个 CSR 代码仓，单击右下角的“确定”即可创建项目。
4. 创建完成后，拓扑起点为 `root.sr`。
## CSR 整机拓扑
CSR 整机拓扑图提供整机维度与单 CSR 维度的总线及器件拓扑可视化：以板卡为节点展示整机的层级结构、Connector 连接关系与总线连线，支持双击板卡下钻到单板视图、从器件库拖拽器件完成配置。根据数据来源不同，拓扑图分为三种使用模式：**本地模式**、**日志模式**与**远程模式**。
### 三种模式对比与选择
| 对比项 | 本地模式 | 日志模式 | 远程模式 |
|--------|---------|---------|---------|
| 数据来源 | 模型配置的本地 CSR 代码仓 | 日志压缩包（`connectors.txt` + `.sr`） | 真机运行时（`mdbctl` + `framework.log`） |
| 依赖模型配置 | 是 | 否 | 否 |
| 在位状态 | 静态配置，可切换（在位/不在位/天池加载/动态加载） | 收集时刻快照，只读 | 运行时实际值，可切换开关模拟拔插 |
| 典型场景 | 日常开发、搭建整机拓扑、板卡适配 | 现场日志离线分析、问题回溯 | 真机调试、在位异常定位 |
根据手头资源选择：
- 有整机 CSR 代码仓，需要搭建或修改拓扑配置 → **本地模式**（见下文「本地模式」）。
- 只有现场日志压缩包，需要还原收集时刻的整机拓扑 → **日志模式**（完整指南见[导入 BMC 日志压缩包查看 CSR 拓扑](#bmc-log-import)）。
- 有可达真机 BMC，需要查看实时在位或调试板卡加载 → **远程模式**（完整指南见[远程模式连接 BMC 环境](#remote-csr-debug)）。
模式切换：日志模式与远程模式均为临时查看模式，重新从侧边栏加载本地拓扑（如切换机型或点击侧边栏文件节点）即恢复本地模式，导入日志产生的临时解压目录会自动清理。
### 界面说明
拓扑图中的主要元素如下：
- **板卡节点**：每个节点代表一块板卡，显示板卡类型、SR 文件名与对应的板型示意图；根节点为 `root.sr`（BMC 主板）。
- **在位状态**：节点左上角显示在位标签或开关，含义与可操作性随模式不同，详见各模式说明。
- **板卡选择器**：本地模式下，尚未确定 SR 的节点提供候选板卡列表与数量选择器，用于配置下游板卡。
- **总线连线与连接桩**：连线表示**上游 Connector 传入的总线**，由上游板卡的连接桩连向下游板卡；总线配置不一致时会出现红色连线或异常标志。
- **单板下钻**：双击整机拓扑页面的任意板卡，或点击左侧 CSR 列表中的文件，即可打开单 CSR 配置页面，查看该板卡 SR 的板内拓扑与详情。
- **工具栏**：配置选择框与「导出配置」按钮用于整机拓扑的多配置管理，仅本地模式可用。
### 本地模式
本地模式是默认模式，数据来自模型配置的本地 CSR 代码仓，用于日常开发中搭建与修改整机拓扑。
#### 查看整机拓扑
点击侧边栏拓扑插件图标，进入整机拓扑图页面，显示如下：
1. **总线连线**：板卡之间的连线为上游 Connector 传入的总线，将鼠标悬停在总线上可显示总线名称。
2. **总线异常检测**：自动检测上游 Connector 传入总线与下游板卡 Anchor 中定义总线的一致性。
1. 总线类型不匹配
当上游 Connector 的 Buses 和下游板卡 Anchor 的 Buses 同一索引位置的总线类型不一致时，总线显示为红色，将鼠标悬停在图标上可查看具体信息。
总线类型判断逻辑：取总线名称前缀，若前缀相同，则认为类型匹配。
2. 上游多传入总线
当上游 Connector 的 Buses 数量大于下游板卡 Anchor 的 Buses 数量时，Connector 的 Buses 数组中多出的总线会被识别为上游多传入总线。板卡左下角会显示红色异常标志，将鼠标悬停在标志上可查看具体信息。
3. 下游板卡多出总线
当上游 Connector 的 Buses 数量小于下游板卡 Anchor 的 Buses 数量时，下游板卡 Anchor 的 Buses 数组中多出的总线会被识别为下游多定义总线。板卡左下角会显示红色异常标志，将鼠标悬停在标志上可查看具体信息。
3. **板卡合并**：SR 文件中的不同 Connector 加载同一个文件时，拓扑图会将其合并为一张板卡。
#### 配置整机拓扑
1. 可通过板卡上方选项在整机拓扑中选择对应板卡，各板卡可选下游板卡数量和类型由该板卡的 Connector 配置决定；尚未确定 SR 的节点通过板卡选择器从候选列表中指定 SR 文件。所有配置信息会自动在本地持久化。
2. 双击整机拓扑页面的任意板卡，或点击左侧 CSR 列表中的文件，即可打开单 CSR 配置页面。
3. 通过工具栏的配置选择框可在多套整机配置之间切换，点击「导出配置」可导出当前配置。
#### 在位状态
本地模式根据 SR 文件中上游 Connector 的 `IdentifyMode` 和 `Presence` 值显示在位状态，单击开关可切换：
| 显示 | 含义 |
|------|------|
| 天池加载 | `IdentifyMode` 为 3，由天池配置加载 |
| 在位 / 不在位 | `IdentifyMode` 为 2，`Presence` 为固定值 1 / 0 |
| 动态加载 | `IdentifyMode` 为 2，`Presence` 为表达式，按表达式动态计算 |
1. 板卡在位状态
2. 切换在位状态：单击开关可同步修改上游 Connector 中 `Presence` 的值。
### CSR 单板卡配置
双击整机拓扑页面的任意板卡，或单击左侧 CSR 列表中的文件，即可打开单 CSR 配置页面。单板卡视图支持新增、删除总线或器件，以及修改 Mux 总线的 `ChannelId`。也可以按 `Ctrl + Z` 撤销、按 `Ctrl + Y` 恢复。
#### 定位器件
单击器件，右侧 SR 文件会自动定位到该器件对象所在的位置。
#### 修改 ChannelId
单击器件上方的 `ChannelId` 数字方块，可修改其值。
#### 新增总线
单击 `+` 图标，选择总线类型并填写总线后缀，然后单击“确定”新增总线。
#### 删除器件、总线
将鼠标悬停在器件或总线上，单击鼠标右键并选择“删除”。
#### 拖拽器件
打开器件库，将器件拖拽到总线上即可将器件挂载到总线，同时自动修改对应 CSR 文件内容。也可以拖拽器件到可下连的器件卡片上进行挂载。
## 导入 BMC 日志压缩包查看 CSR 拓扑
openUBMC Studio 支持导入 BMC 一键收集的日志压缩包，在离线环境下还原当前整机加载的 CSR 及其拓扑关系。适用于现场问题定位与离线日志分析：拿到日志包即可查看板卡层级结构、连接关系与在位情况，无需连接真机。
### 使用前准备
- 已安装 openUBMC Studio 并启用 CSR 拓扑插件（随主插件提供）。
- 准备 BMC 一键收集的日志压缩包，支持 `zip`、`tar`、`tgz`、`gz`（含 `.tar.gz`）格式。
- 本机需可执行 `tar` 命令（日志包解压依赖系统 tar）。
> [!NOTE]说明：
> 导入日志模式不依赖模型配置，也无需预先创建拓扑项目，可直接使用。
### 导入日志压缩包
1. 在 openUBMC Studio 左侧 CSR 拓扑侧边栏视图标题栏，点击「导入日志包」按钮。
2. 在弹出的文件选择框中，选择 BMC 日志压缩包并点击「选择日志压缩包」确认。
3. 工具自动解压并解析日志包中的 `connectors.txt`，随后在主编辑区渲染整机 CSR 拓扑图。导入成功后右下角提示「成功导入: 文件路径」。
### 查看导入的拓扑
- **板卡层级与连接关系**：拓扑图展示整机各板卡的层级结构与总线连接，查看能力与本地整机拓扑页面一致，但不支持切换板卡配置（配置选择框与导出配置按钮为禁用状态）。
- **在位状态**：每块板卡以只读标签显示在位状态（在位/不在位），状态取自日志包记录。
### 实现原理
#### 数据来源
导入模式的拓扑数据全部来自日志压缩包内部，不访问真机，各数据项来源如下：
| 数据项 | 来源 | 用途 |
|--------|------|------|
| 板卡层级结构 | `connectors.txt` 的树形拓扑部分 | 构建整机拓扑树（板卡父子关系） |
| Connector 详情（`Buses`、`Type`、`Presence`、`IdentifyMode` 等） | `connectors.txt` 的 Connector 详情段 | 总线连线、连接器类型、在位状态 |
| 板卡类型与名称（`Unit.Type` / `Unit.Name`） | 日志包内的 `.sr` 文件 | 拓扑节点显示的板卡类型与名称 |
| 下游总线（`ManagementTopology.Anchor.Buses`） | 日志包内的 `.sr` 文件 | 总线一致性检测的下游锚点 |
| 板卡 SR 详情 | 日志包内的 `.sr` 文件 | 双击板卡下钻查看的自描述内容 |
`connectors.txt` 通常位于日志包的 `dump_info/AppDump/hwdiscovery/` 目录下；工具同时支持在解压根目录及任意子目录中递归查找。`.sr` 文件从 `connectors.txt` 所在目录及其子目录中递归收集。
#### connectors.txt 格式示例
`connectors.txt` 由 BMC 硬件自发现流程生成，前半部分是板卡树形结构，后半部分是每个 Connector 的属性详情：
```text
root
├─Connector_BMC
│├─Connector_PCPU_1
│└─Connector_PCPU_2
└─Connector_PSU_1
Connector_BMC:
.Buses: ["I2c_1","I2c_2"]
.Type: BMC
.Presence: 1
.IdentifyMode: 2
Connector_PSU_1:
.Buses: ["I2c_3"]
.Type: PSU
.Presence: 0
.IdentifyMode: 2
```
- **树形部分**：通过行首的 `├─`、`└─`、`│` 符号表达层级，每个节点即一块板卡的 Connector，对应 SR 文件名为 `节点名.sr`（如 `Connector_PCPU_1.sr`）。
- **详情部分**：`Connector_XXX:` 开启一个 Connector 段，其下以 `.属性: 值` 逐行列出属性。其中 `Presence` 决定在位标签（1=在位，0=不在位），`Buses` 决定上游总线连线。
#### 处理流程
1. **解压**：调用系统 `tar`（zip 在 Linux 下用 `unzip`）将日志包解压到固定临时目录。
2. **查找 connectors.txt**：按「解压根目录 → `dump_info/AppDump/hwdiscovery/` → 递归子目录」的顺序查找。
3. **解析**：拆分树形结构与 Connector 详情段，得到拓扑树骨架与各 Connector 属性。
4. **收集 SR 文件**：递归收集同目录下全部 `.sr` 文件并解析缓存到内存。
5. **构建拓扑**：将 Connector 属性与 SR 文件按名称（去除末尾 `_序号` 后缀）匹配，生成前端拓扑树并渲染。
> [!NOTE]说明：
> 在位状态反映的是**收集日志时刻**的整机状态，非实时数据。
### 功能验证
导入完成后，可按以下检查项验证功能是否正常：
| 验证项 | 操作步骤 | 预期结果 |
|--------|----------|----------|
| 导入解析 | 选择 BMC 一键收集日志压缩包导入 | 右下角提示「成功导入: 文件路径」，主编辑区渲染整机拓扑 |
| 板卡层级 | 对比拓扑树与日志包 `connectors.txt` 的树形结构 | 板卡父子层级一致，无遗漏板卡 |
| 在位状态 | 查看板卡节点标签，与 `connectors.txt` 中对应 Connector 的 `Presence` 值比对 | 标签显示与记录一致（1=在位，0=不在位） |
| 板卡详情下钻 | 双击拓扑中的板卡节点 | 编辑器第二列打开该板卡 SR 文件内容 |
### 常见问题
| 现象 | 处理建议 |
|------|----------|
| 提示「未找到 connectors.txt 文件」 | 请确认导入的是 BMC 一键收集日志压缩包（内含 `connectors.txt`） |
| 导入会占用/残留磁盘空间吗 | 日志包解压到固定临时目录（`系统临时目录/bmc-log-import`），每次导入前自动清理旧数据，无需手动维护 |
| 能否修改在位状态或板卡配置 | 导入模式为只读查看，不支持修改在位状态与 CSR 配置；配置选择与导出按钮为禁用状态 |
## 远程模式连接 BMC 环境
远程模式支持连接真机 BMC 环境，自动从运行时数据（`mdbctl` 调试命令 + 框架日志）构建整机 CSR 拓扑，实时展示板卡实际在位情况。无需从 BMC 手动导出数据再导入，选择环境即可出图，适用于真机调试、板卡适配验证与在位异常定位。
### 使用前准备
- 已安装并启用 **BMC环境管理** 插件（`openubmc.bmcstudio-bmc-remote`），并添加至少一条 BMC 连接。连接的添加方法参见 [BMC环境管理插件](#bmc-env-management) 章节。
- 目标 BMC 运行 openUBMC 固件，开放 Telnet 调试通道（23 端口免认证调试 shell），且板上具备 `mdbctl` 调试命令。
- 开发机无需安装 telnet 客户端，扩展使用内置连接直连。
> [!NOTE]说明：
> 远程模式不依赖模型配置，选中环境后自动跳过机型配置流程，直接加载拓扑。
### 连接 BMC 环境
1. 在 CSR 拓扑侧边栏视图标题栏，点击「远程调试」按钮。
2. 在顶部弹出的环境选择框中，选择目标 BMC 环境。列表展示全部已配置连接，并实时探测在线状态（在线/离线图标 + 账号信息）。
3. 选择后显示「正在加载 xx 环境的 CSR 拓扑」进度通知，工具自动读取真机运行时的 Connector 对象与 SR 加载记录并构建拓扑。
4. 加载完成后，拓扑图工具栏显示当前连接的环境名称与 IP，主编辑区渲染整机实时拓扑。
### 查看实时拓扑
- **真实在位状态**：拓扑以真机运行时数据为准（而非静态 root.sr 配置），每块板卡显示实际在位/不在位状态。
- **EEPROM 板卡**：CSR 烧录在 EEPROM（而非 .sr 文件）的板卡会被自动解码，与文件板卡同等展示，双击同样可查看内容。
- **板卡 SR 下钻**：双击板卡即可进入单板视图查看该板卡的 SR 内容。
- **在位调试**：板卡节点上的在位开关可点击切换，模拟板卡拔插，详见下文「在位调试」。
### 在位调试
远程模式下，点击板卡节点上的在位开关即可**模拟板卡拔插**，验证下级板卡的加载逻辑，无需物理操作真机。
> [!NOTE]说明：
> 切换在位状态**不是卸载板卡**：该板卡已加载的 SR 不受影响，只影响**下级板卡的加载判断**——下级板卡检测到上游 Connector 的 Presence 为 0 时不会加载。
#### 普通在位属性
Presence 为固定值（1/0）的板卡，节点上显示单个在位开关。点击开关后：
1. 工具通过 `mdbctl setprop` 向真机下发修改，更新该 Connector 的 Presence 值；
2. 重新读取运行时在位状态并重建拓扑（不重新读取 SR 文件）；
3. 下级板卡的加载状态随 Presence 变化体现在拓扑上。
#### 同步属性（多开关）
Presence 为表达式（引用其他对象属性，如多个物理在位开关共用一个 Connector）时，节点上会按同步源渲染**多个开关**，每个开关对应一个同步源对象的属性。点击单个开关只修改对应同步源对象的属性值，适用于逐个验证各物理开关对板卡加载的影响。
> [!WARNING]注意：
> 在位调试通过 `setprop` 真实修改真机运行时属性，直接影响下级板卡的加载判断。请确认影响范围后再操作，调试完成后建议将开关切回原状态。
### 实现原理
#### 数据来源
远程模式的拓扑数据来自真机运行时，全部通过 Telnet 调试通道（23 端口）自动采集，各数据项来源如下：
| 数据项 | 来源 | 用途 |
|--------|------|------|
| Connector 对象清单 | 真机运行时（`mdbctl lsobj connector`） | 拓扑节点唯一来源，以实际加载为准（非静态 root.sr） |
| Connector 实际在位值 | 真机运行时（`mdbctl lsprop` 读取 `Presence`） | 板卡在位/不在位状态 |
| SR 文件加载记录 | 真机 `/var/log/framework.log` 中框架打印的加载日志 | 确定每个 Connector 实际加载的 SR 文件路径（含根节点） |
| SR 文件内容 | 真机 `/opt/bmc/sr/*.sr` | 板卡类型/名称（`Unit` 字段）、下游总线、双击下钻内容 |
| EEPROM 板卡 CSR | 板上 EEPROM（CDR 容器格式） | CSR 烧录在 EEPROM（无 .sr 文件）板卡的解码展示 |
| 拓扑层级关系 | Connector 的 `GroupPosition` 属性 | 按 GroupPosition 建树（去末两位即父节点） |
#### 通过日志查看 Connector 加载的文件
每个 Connector 实际加载的 SR 文件记录在 BMC 的框架日志 `/var/log/framework.log` 中，由硬件自发现流程打印，共两类记录：
**记录一（init.lua，板卡加载主源）**——每个 Connector 加载 SR 时打印，`position` 即该 Connector 的 `GroupPosition`：
```text
2026-08-20 10:15:32 hwdiscovery NOTICE: init.lua(152): position: 0101011A, get csr data from /opt/bmc/sr/14100513_pcie_card.sr, ...
```
**记录二（dump.lua，根节点主源）**——根板卡的加载只出现在此类记录中：
```text
2026-08-20 10:15:30 hwdiscovery NOTICE: dump.lua(88): start to dump connector: root loading file: /opt/bmc/sr/root.sr
```
工具解析后的对应关系示例：
| 日志记录 | 解析结果 |
|----------|----------|
| `position: 0101011A, get csr data from /opt/bmc/sr/14100513_pcie_card.sr` | GroupPosition 为 `0101011A` 的 Connector 加载了 `14100513_pcie_card.sr` |
| `start to dump connector: root loading file: /opt/bmc/sr/root.sr` | 根节点加载 `root.sr`（拓扑根板卡） |
| `start to dump connector: Connector_EXU_1 loading file: Eeprom/...`（`loading file` 为 EEPROM 对象路径） | 该板卡 CSR 烧录在 EEPROM，工具改走 EEPROM 解码 |
也可以在 BMC 上手动执行以下命令核对（与工具解析使用同一数据源）：
```bash
grep -E "get csr data from|start to dump connector" /var/log/framework.log
```
> [!NOTE]说明：
> 同一 Connector 多次加载时取**最新一条**记录（日志按最新文件优先解析）；加载失败的记录（如占位文件）会被过滤，不会体现在拓扑中。
#### 处理流程
1. **连通性自检**：通过 Telnet 23 端口连接目标 BMC，探测调试 shell 可用性。
2. **发现 Connector**：执行 `mdbctl lsobj connector` 获取运行时全量 Connector 对象，再批量 `mdbctl lsprop` 读取每个 Connector 的 `Presence` 实际值。
3. **解析加载记录**：读取 `/var/log/framework.log`（含历史 `.gz` 轮转文件），解析「position → SR 文件」与「运行时名 → 文件」两组映射。
4. **建树**：按 Connector 的 `GroupPosition` 属性构建整机层级（去掉末两位十六进制即父节点位置）。
5. **读取 SR 内容**：按映射从 `/opt/bmc/sr/` 读取 `.sr` 文件；EEPROM 板卡读取 EEPROM 二进制（CDR 容器）并本地解码出 CSR。
6. **渲染**：组装拓扑树、在位状态与 SR 数据，发送到拓扑图视图渲染。
> [!NOTE]说明：
> 在位状态以**真机运行时数据**为准（mdbctl 实时读取），而非 CSR 静态配置中的 `Presence` 表达式，可避免静态配置与实际加载不一致造成的误判。
> 所有数据仅在加载拓扑和切换在位开关时读取，不在本地持久化。
### 功能验证
连接环境并加载拓扑后，可按以下检查项验证功能是否正常：
| 验证项 | 操作步骤 | 预期结果 |
|--------|----------|----------|
| 环境列表 | 点击「远程调试」按钮 | 列出全部已配置 BMC 连接，并标注在线/离线状态与账号信息 |
| 拓扑加载 | 选择一个在线环境 | 显示「正在加载 xx 环境的 CSR 拓扑」进度，完成后工具栏显示环境名与 IP，渲染整机拓扑 |
| 在位一致性 | 将拓扑中板卡在位状态与真机实际在位比对（可对照 BMC Web 页面或板上 `mdbctl` 查询结果） | 与真机实际加载一致（以运行时数据为准） |
| 加载文件一致性 | 在 BMC 上执行上文 grep 命令，比对拓扑中板卡对应的 SR 文件 | 双击下钻打开的 SR 文件与日志记录的 `get csr data from` 路径一致 |
| 板卡详情下钻 | 双击拓扑中的板卡节点 | 打开单板视图，可查看该板卡 SR 内容 |
| EEPROM 板卡 | 查看拓扑中无 .sr 文件的板卡 | EEPROM 板卡正常解码展示，双击同样可查看 CSR 内容 |
| 在位开关切换 | 点击某板卡节点的在位开关 | 切换后拓扑自动刷新，下级板卡加载状态随之变化 |
| 同步属性切换 | 点击同步属性板卡上的单个开关 | 仅对应同步源对象的属性变化，其余开关状态不变，拓扑刷新 |
### 常见问题
| 现象 | 处理建议 |
|------|----------|
| 提示「未配置 BMC 环境，请先添加连接」 | 先在 BMC环境管理插件中添加连接，参见 [BMC环境管理插件](#bmc-env-management) 章节 |
| 提示「远程拓扑加载失败」 | 检查环境是否在线、BMC 23 端口是否开放、板上 `mdbctl` 是否可用；详细原因可查看输出通道中 RemoteTopologyLoader 的日志 |
| 环境列表显示「探测中」 | 连接健康探测最长 3 秒，离线环境会标注离线状态，不影响选择其他环境 |
> [!NOTE]说明：
> 远程模式下配置选择与导出配置不可用（禁用），与导入日志模式一致。
> 此外，远程拓扑支持通过 MCP 工具 `csr_topo_get_remote_topology` 供 AI Agent 查询整机 Connector 在位清单与 SR 来源。
## 能效调速配置
能效调速配置功能提供能效调速对象的配置入口，支持通过Excel导入热设计表格解析调速曲线配置，支持对象自动关联及配置检查、CSR片段自动生成。
### 打开配置页面
点击CSR拓扑侧边栏中的温度计图标即可开启能效调速配置页面。
### 配置能效调速对象
1. 通过该页面配置能效调速对象，以及配置对象间的关联关系。
2. 点击右上角的"导入Excel"即可导入热设计表格，当前仅支持xlsx格式，若为其他格式请通过Excel另存为xlsx格式文件。完成导入后，温度点与调速曲线等配置可以自动解析。
3. 点击右上角"生成CSR"即可根据当前配置产生CSR代码片段，可以自行填入CSR文件中。生成CSR过程支持配置语法检查，禁止出现ID冲突等问题。
# 七、事件管理
本章节介绍 openUBMC Studio 的事件管理功能。用户可以在 IDE 中查看和编辑 `event_def.json` 中的事件信息与描述模板，也可以查看、新增和保存事件与 CSR `Event_` 对象的绑定关系。
> [!NOTE]说明：
> 事件管理依赖模型配置生成的事件字典基线。如尚未配置模型，请先完成[模型配置](#模型配置)中的产品和规则集选择。
## 功能说明
BMC 事件字典定义了整机事件的事件标识、严重级别、事件编码和描述模板等标准信息。事件管理提供以下能力：
- **事件字典管理**：查看、筛选和搜索全部事件，编辑基础字段与中英文描述模板，新建自定义事件模板，以及还原或导出差量。
- **CSR 绑定管理**：查看事件在 SR 文件中绑定的 `Event_` 对象，可视化新增、编辑和删除绑定，并批量保存到 SR 文件。
根据打开入口，事件管理提供以下两种视图：
| 视图 | 入口 | CSR 绑定聚合范围 |
| --- | --- | --- |
| 单板卡视图 | 单 SR 拓扑视图中的“事件管理” | 当前 SR 文件及其拆分文件中的 `Event_` 对象 |
| 整机视图 | 总拓扑页面工具栏中的“事件管理” | 总拓扑下所有 SR 文件中的 `Event_` 对象 |
两种视图共用同一套事件字典与编辑能力，仅 CSR 绑定的聚合范围不同。
## 使用前准备
- **模型配置**：已完成产品和规则集选择，事件字典基线来自 Conan 规则包中的 `event_def.json`。
- **拓扑项目**：已通过拓扑侧边栏创建配置并添加 CSR 仓库，当前工作区存在可用的 SR 上下文。
> [!NOTE]说明：
> 字段修改、描述模板修改和自定义事件模板会以差量形式保存在本地缓存中。编辑停止约 1 秒后，差量会自动写入缓存；关闭事件管理面板时，差量会自动落盘。原始字典文件不会被直接修改。
## 打开事件管理
- **打开整机视图**：进入总拓扑页面，单击工具栏中的“事件管理”。
- **打开单板卡视图**：进入单 SR 拓扑视图，单击“事件管理”。此时 CSR 绑定范围限定为当前 SR 文件。
事件管理会在独立面板中打开，不影响原拓扑页面。
## 查看事件管理界面
事件管理界面由工具栏、事件列表、编辑横幅、分页栏和详情面板组成。
- **工具栏**：提供新建事件模板、重新拉取、导出、清除全部筛选和搜索功能。
- **事件列表**：展示全部事件，支持列头筛选和分页。
- **编辑横幅**：存在未导出的编辑时，以黄色或绿色横幅提示导出。
- **详情面板**：单击事件行后显示在界面右侧。拖动面板左边缘可以在约 `280～700px` 范围内调整宽度，单击“×”可以关闭面板。
## 筛选和搜索事件
### 查看列表字段
| 列 | 说明 |
| --- | --- |
| 事件（`EventKeyId`/`EventName`） | 事件唯一标识与名称，内容过长时自动省略，悬停后显示全文 |
| 级别 | 严重程度：提示（蓝灰）、一般（蓝）、重要（橙）或紧急（红） |
| CSR 绑定 | 当前视图范围内绑定的 `Event_` 对象数量 |
| 分类 | 根据事件标识推导的业务分类 |
| 机型支持 | 当前机型是否支持该事件 |
| `EventCode` | 事件的十六进制唯一编码 |
| 恢复上报 | 是否上报恢复事件 |
| `EventType` | 事件类型 |
| `LifeCycleId` | 生命周期标识 |
### 设置筛选条件
1. 单击“级别”“CSR 绑定”“分类”“机型支持”或“恢复上报”列头中的筛选按钮。
2. 勾选需要保留的选项。每个选项会显示对应的事件数量。
3. 如需清空当前列的条件，再次打开筛选菜单并单击“清空筛选”。
右上角搜索框支持按 `EventKeyId`、事件名称或事件编码进行模糊搜索。存在筛选或搜索条件时，工具栏会显示“清除全部筛选（N）”，单击后可以恢复完整列表。
### 设置分页
底部分页栏支持将每页数量设置为 20、40、80 或 100 条，也支持按页码跳转。没有事件数据时，可以通过空状态入口新建事件模板；存在数据但被过滤时，可以通过空状态入口清除筛选。
## 新建和编辑事件
### 新建事件模板
1. 单击工具栏中的“新建事件模板”。
2. 在右侧详情面板中编辑新模板。
新建的自定义事件会置于列表顶部并自动选中。详情面板底部提供“删除该自定义事件模板”按钮。
### 编辑基础字段
1. 在事件列表中单击目标事件。
2. 在右侧详情面板中打开“基础信息”页签。
基础字段说明如下：
| 字段 | 说明 |
| --- | --- |
| 事件名称 `EventName` | 事件短名称，通常与 `EventKeyId` 的最后一段一致 |
| `SeverityId` | 严重级别：`0` 表示提示、`1` 表示一般、`2` 表示重要、`3` 表示紧急 |
| 机型支持 | 标记当前机型是否支持该事件，是导出 `eventDefList.txt` 的依据 |
| 恢复上报 `DeassertFlag` | 是否上报恢复事件，与 `LifeCycleId` 共同决定事件是否可恢复 |
| 事件编码 `EventCode` | 十六进制唯一编码，例如 `0x0200001F` |
| 旧版事件编码 `OldEventCode` | 跨版本兼容映射，没有对应关系时留空 |
| 上报通道 `ReportChannel` | 目标通道位掩码，`65535` 表示向全部通道上报 |
| 事件类型 `EventType` | BMC 固件定义的编号，当前字典中的常见取值为 `0` 或 `1` |
| 生命周期标识 `LifeCycleId` | BMC 固件定义的编号，当前字典中的常见取值为 `0` 或 `1` |
| 动作标识 `ActionId` | BMC 固件定义的编号，当前字典中的常见取值为 `0` 或 `1` |
### 编辑描述模板
“描述模板”区域提供以下四类内容的中英文编辑，单击右上角的“中”或“EN”可以切换语言：
- `Description`：描述。
- `Cause`：可能原因。
- `Influence`：影响。
- `Suggestion`：处理建议。
> [!NOTE]说明：
>
> - 描述支持 `%Component`、`%DescArg1`～`%DescArg5` 占位符，依次引用 CSR 事件绑定中的 `Component` 和 `DescArg` 字段。输入占位符后，界面会显示提示。
> - 可能原因与处理建议支持多条内容，多条内容之间使用 `@#AB;` 分隔。
### 还原事件数据
- **还原单个事件**：单击详情面板标题行中的“还原”，丢弃该事件的全部本地编辑并恢复为字典基线值。
- **重新拉取全部事件**：单击工具栏中的“重新拉取”，在确认窗口中继续操作。完成后，事件管理会丢弃全部编辑，从 Conan 包重新读取事件字典，并将筛选、搜索和分页恢复为初始状态。
> [!WARNING]注意：
> “重新拉取”会丢弃当前所有本地编辑。首次打开事件管理时，系统优先读取本地缓存；仅在需要放弃全部差量或重新获取 Conan 包中的最新数据时执行此操作。
## 查看并导出修改
存在未同步的编辑时，列表上方会显示编辑横幅。
| 横幅 | 含义 | 导出文件 |
| --- | --- | --- |
| 黄色 | 事件字段、描述模板或自定义模板发生变化 | `event_def.json` |
| 绿色 | 机型支持字段发生变化 | `eventDefList.txt` |
- **查看修改**：打开变化清单后，可以单击事件标识定位到对应事件，也可以单独还原某个事件。
- **导出事件字典**：导出的 `event_def.json` 包含全部事件定义与描述模板，文件版本号末段自动加一，例如从 `1.0.0` 更新为 `1.0.1`。导出后，请将文件提交到 VPD 仓库进行同步。
- **导出机型事件清单**：导出的 `eventDefList.txt` 仅包含“机型支持”为“是”的事件标识。
> [!NOTE]说明：
> 两类横幅会根据修改内容独立显示和导出。两类内容均发生变化时，需要分别导出对应文件。
## 管理 CSR 绑定
CSR 绑定描述事件与 SR 文件中 `Event_` 对象的对应关系。在详情面板中打开“CSR 绑定”页签，可以查看和编辑绑定。
### 查看 CSR 绑定
页签顶部显示当前视图类型和事件的绑定总数。绑定以卡片形式展示，每张卡片会标注所属 SR 文件，悬停后可以查看完整路径。
### 新增 CSR 绑定
1. 单击详情面板底部的“CSR 绑定”。
2. 在新增卡片中填写绑定字段。
3. 如果当前处于整机视图，选择“目标 SR 文件”。整机根文件 `root.sr` 不在候选范围内；单板卡视图会自动使用当前 SR 文件。
4. 单击“确定”，批量保存本次绑定修改。
### 查看绑定字段
| 字段 | 说明 |
| --- | --- |
| 事件对象名 | 必须以 `Event_` 开头且不能只有前缀；同一拆分文件组内不得重名，不同组之间允许同名 |
| 目标 SR 文件 | 仅在整机视图新增绑定时显示，用于指定绑定写入的 SR 文件 |
| `Condition` | 绑定条件；清空后删除该键，纯数字内容会自动转换为数值 |
| `Component` | 事件关联的器件组件，候选项按照目标 SR 文件分为“推荐”和“其他”两组 |
| `OperatorId` | 操作符编号，可以留空 |
| `Enabled` | 是否启用绑定，可以留空以删除该键 |
### 验证保存结果
- “确定”仅在存在修改且表单校验通过时可用；单击“取消”会放弃本次全部修改。
- 对象名为空、未以 `Event_` 开头或在组内重名时，对应输入框会显示错误。
- 保存成功后，绑定列表和绑定数量会自动刷新，事件列表会定位到当前事件。
- 在编辑器中直接保存 SR 文件后，绑定列表和绑定数量也会自动刷新。
## 常见问题
- **事件字段是否需要手动保存？** 不需要。字段与描述模板编辑会在停止输入约 1 秒后写入本地缓存，并在关闭面板时落盘；CSR 绑定修改需要单击“确定”保存到 SR 文件。
- **重新拉取后编辑全部消失**：此行为符合预期。“重新拉取”会丢弃全部本地差量并恢复到字典基线。
- **CSR 绑定提示对象名必须以 `Event_` 开头**：事件对象名必须带有固定前缀，并且不能只有 `Event_` 前缀。
- **整机视图与单板卡视图的绑定数量不一致**：两种视图的聚合范围分别为全部 SR 文件和当前 SR 文件，因此数量可能不同。
- **还原事件后列表中的绑定数量未变化**：“还原”仅丢弃事件字典的本地差量，不修改 CSR 绑定。
- **导出的文件应提交到哪里？** `event_def.json` 与 `eventDefList.txt` 均用于提交到 VPD 仓库，具体流程遵循团队的字典变更管理规范。
- **新建的模板在筛选结果中不可见**：新建模板时会自动清空筛选。如模板仍不可见，请检查搜索词和列头筛选条件。
# 八、日志诊断与告警链条分析
一键日志解析插件（扩展 ID：`openubmc.bmcstudio-log-reviewer`）用于导入 BMC 一键日志包或 dump 目录，并通过可视化页面和 AI Agent 分析设备状态。用户可以浏览硬件、告警、传感器、性能及原始日志，也可以结合 openUBMC RAG 进行日志体检，或通过告警证据工具分析指定事件的触发链条。
## 功能说明
日志诊断提供以下使用方式：
| 使用方式 | 主要能力 | 适用场景 |
| --- | --- | --- |
| 一键日志解析页面 | 自动解压日志包，通过概览、硬件、告警、传感器、性能、调速、线缆和日志等视图展示 dump 日志 | 人工浏览现场、筛选日志和快速确认异常范围 |
| Agent 日志体检 | 结合本地日志证据和 openUBMC RAG 生成问题清单，实时回写结果并导出 PDF 报告 | 对日志进行批量体检和问题优先级排序 |
| 定向诊断与告警链条分析 | 关联事件记录、运行日志、数据库及 `CSR Event` 定义，输出告警状态、触发链、恢复或复发情况和证据位置 | 聚焦指定问题、还原告警链条和形成可复核结论 |
> [!NOTE]说明：
> 可视化页面中的“智能检测”用于 Agent 日志体检。指定问题的深入诊断和告警链条分析可以在已配置 openUBMC Studio MCP 服务的 AI Agent 对话中发起。
## 使用前准备
如果活动栏中没有“一键日志解析”图标，请先执行以下操作：
1. 在 openUBMC Studio 中打开插件市场，搜索“一键日志解析”。
2. 安装插件，并按照提示重新加载窗口。
3. 确认活动栏中出现“一键日志解析”图标。
使用 Agent 日志体检前，还需要满足以下条件：
- 已登录 openUBMC 社区。
- `openubmc-rag` 扩展已启用。
- 当前网络可以访问配置的 LightRAG 服务。
- AI Agent 可以访问 openUBMC Studio MCP 工具。
AI Agent 会在读取日志前检查 RAG 状态。未登录、RAG 工具未启用、网络异常或状态响应无法解析时，日志体检会停止并显示处理建议。
> [!NOTE]说明：
> 如果所有 MCP 工具均提示网络错误，请将 `localhost`、`127.0.0.0/8` 和 `::1` 加入代理直连列表或 `NO_PROXY`，然后完全重启 openUBMC Studio 和 AI Agent。
## 打开一键日志
一键日志解析支持 Windows、Linux、WSL、SSH 远程工作区和容器工作区。
支持导入以下内容：
- `.tar.gz`、`.tgz`、`.tar` 或 `.zip` 格式的 BMC 一键日志压缩包。
- 已解压且包含 `AppDump` 子目录的 dump 文件夹。
操作步骤如下：
1. 单击活动栏中的“一键日志解析”图标。
2. 根据日志形态，选择“打开 BMC 一键日志压缩包”或“打开 dump 目录”。
3. 选择日志压缩包或 dump 根目录。选择目录时，应选中包含 `AppDump` 子目录的 dump 根目录。
4. 等待解压和解析完成，确认日志页面已在编辑器区域打开。
也可以通过以下入口打开日志：
- 在资源管理器中右键单击日志压缩包或 dump 文件夹，选择对应的一键日志解析命令。
- 单击“最近打开”中的历史记录，重新打开对应日志。
“最近打开”最多保存 30 条记录。同一日志已经打开时，再次打开只会定位到原页面。删除一条最近记录时，对应的日志页面也会关闭。
### 查看日志包要求
日志包中必须存在名称完全匹配的 `AppDump` 目录，典型结构如下：
```text
dump_info/
├── AppDump/
├── LogDump/
├── RTOSDump/
└── OSDump/
```
插件最多向下查找 6 层目录。`AppDump` 是导入日志时的必需目录；缺少 `LogDump`、`RTOSDump` 或 `OSDump` 时，日志包仍可能打开，但对应页面会显示无数据或目录缺失。
| 项目 | 限制 |
| --- | --- |
| 单次选择 | 1 个日志包，可以重复导入不同日志包 |
| 支持格式 | `.tar.gz`、`.tgz`、`.tar`、`.zip` |
| `tar` 系列解压后总内容 | 不超过 8GiB |
| `tar` 系列归档条目 | 不超过 200000 项 |
| ZIP 解压 | 依赖系统中的 `tar` 或 `unzip`，单次命令最长执行 300 秒 |
| `AppDump` 查找深度 | 最多递归 6 层 |
> [!WARNING]注意：
> 插件不单独限制压缩文件本身的大小。处理大型日志包时，需要为远程暂存文件、中间 `.tar` 文件和解压目录预留足够空间，建议可用空间至少为解压后内容大小的两倍。
## 查看诊断信息
日志面板按照不同领域组织现场信息，常用视图包括：
- **现场概览**：查看机型、健康状态、FRU、板卡和软件版本。
- **告警与传感器**：查看告警记录、活动状态、传感器读值和门限信息。
- **运行状态**：查看性能、功率、进风温度、调速策略和 PID 配置。
- **硬件关联**：查看线缆检测、同步属性、CSR 和丝印信息。
- **日志与诊断**：查看操作日志、应用日志、框架日志、维护日志、驱动日志、串口日志、`journalctl`、一键日志原始文件和故障诊断文件。
- **智能检测**：使用 AI Agent 和 openUBMC RAG 进行日志体检。
不同页面按需解析日志文件，不会在导入时将所有文件一次性加载到内存。日志视图支持筛选、大小写匹配、全字匹配、正则表达式、匹配项跳转和保存搜索，具体可用项以当前视图为准。
## 使用 Agent 进行日志体检
日志体检会将本地日志证据与 openUBMC RAG 检索结果关联，并按照严重程度、紧急度和置信度排列问题。故障案例库是可信度最高的知识来源，但不是唯一可用来源。
> [!NOTE]说明：
> 流程图中的问题数量和内容仅用于说明操作过程。实际问题数量、严重程度和诊断结论以导入日志中的证据及 RAG 检索结果为准。
### 复制分析 Prompt
1. 打开日志页面顶部的“智能检测”。
2. 单击“复制 Prompt 模板”。
3. 将 Prompt 粘贴到能够访问 openUBMC Studio MCP 工具的 AI Agent 中。
4. 发送 Prompt，等待 AI Agent 完成 RAG 状态检查并开始分析。
Prompt 已包含以下约束，无需手动填写日志路径：
- 包含当前日志包的显示名称、分析任务标识和回调地址。
- 只允许读取当前分析任务绑定的日志包。
- 必须先检查 RAG 连接和社区登录状态。
- 必须保留 RAG 引用的真实来源，其中故障案例库来源具有最高可信度。
- 每个问题必须同时提供 RAG 匹配内容和本地日志证据。
- 分析完成后，按照用户配置的 TopN 返回结果。
### 查看实时问题
AI Agent 分析期间，每个已确认的问题会实时显示在“Agent 日志问题”区域。问题卡片包含以下内容：
- 严重程度：`CRITICAL`、`HIGH`、`MEDIUM` 或 `LOW`。
- 紧急度：综合故障影响、恶化可能、冗余能力和修复窗口计算的 0～100 分。
- 置信度：本地多源证据与 RAG 知识的一致程度。
- 可能原因和处理建议。
- RAG 匹配内容、来源及可信度。
- 日志片段、日志包内相对路径和定位信息。
> [!NOTE]说明：
> 截图中的故障名称和日志内容仅用于演示界面结构，不代表产品预置的诊断结论。
同一根因产生的重复现象应合并为一个问题。分析完成后，插件会依次按照严重程度、紧急度和置信度排序，并展示最紧急的 TopN 问题。
### 配置 TopN
TopN 默认值为 10，可以设置为 1～50：
1. 单击“一键日志解析”侧边栏标题栏中的齿轮图标。
2. 在设置页面中修改 `bmcstudio.logReviewer.analysisTopN`。
3. 创建新的分析会话，使新设置生效。
TopN 只限制分析完成后页面和 PDF 报告中展示的问题数量。AI Agent 可以在分析过程中回写更多候选问题，插件会在完成时统一排序和截取。已经打开的分析会话继续使用创建会话时的 TopN 值；如需让同一日志使用新的 TopN，请先从“最近打开”中删除该日志，再重新导入并发起分析。
### 导出 PDF 报告
“导出为 PDF 报告”仅在分析状态变为“已完成”后可用：
1. 确认页面显示“Agent 智能分析：已完成”。
2. 单击“导出为 PDF 报告”。
3. 选择保存路径和文件名。
4. 使用 PDF 阅读器打开报告，核对摘要、问题排序、RAG 内容、日志证据和处理建议。
报告在当前 openUBMC Studio 扩展宿主运行期间可以持续导出。完全关闭或重启 openUBMC Studio 后，内存中的分析会话不会保留，需要重新发起分析。
### 处理会话异常
| 场景 | 预期行为 |
| --- | --- |
| 分析期间关闭日志页面 | AI Agent 回调可以继续写入后台会话，重新打开同一日志后恢复状态 |
| 页面关闭较长时间后重新打开 | 运行中的会话按照空闲策略管理，重新打开并操作后刷新活跃状态 |
| 从“最近打开”中删除日志 | 对应页面关闭，关联分析会话被清理 |
| 清空“最近打开” | 所有日志页面关闭，关联分析会话被清理 |
| RAG 不可用 | 分析停止并显示登录、网络或配置建议，不生成主观问题 |
| 日志中没有诊断内容 | 日志包格式有效时，分析完成并显示 0 个问题，PDF 报告可以导出 |
| 缺少 `AppDump` | 导入失败，并提示文件可能不是 openUBMC 一键日志包 |
| 缺少 `AppDump/fault_diagnosis` | 结构化诊断失败，AI Agent 将分析任务标记为失败 |
## 使用 AI Agent 定向诊断日志
在 AI Agent 对话中提供日志路径和分析目标，例如：
```text
请打开并诊断 /path/to/bmc-log.tar.gz，先给出设备健康概览、关键异常和对应证据位置。
```
openUBMC Studio 会打开同一份日志的可视化面板，同时将机型、健康状态、硬件清单、告警、传感器、性能、调速、线缆和 CSR 等结构化数据提供给 AI Agent。后续可以继续要求 AI Agent 聚焦某个领域，例如：
```text
继续分析当前日志中的散热异常，关联传感器、调速策略、功率和相关运行日志。
```
## 分析告警链条
分析单条告警时，建议提供以下任一组定位信息：
- 事件码和发生时间。事件码格式为 `0x` 后接 8 位十六进制数字，时间格式为 `YYYY-MM-DD HH:mm:ss`。
- `sel.txt` 中的事件记录 ID。openUBMC Studio 可以据此解析事件码和发生时间。
- 需要区分多个告警实例时，再补充组件或实例名称。
示例：
```text
基于当前打开的一键日志，分析事件码 0x12345678、时间 2026-08-28 14:23:16 的完整告警触发链。
请说明当前告警状态、已观察到和缺失的阶段、恢复与复发情况，并在每个节点标注证据文件及行号或数据库记录位置。
```
AI Agent 会根据日志中的实际证据按需给出以下内容：
- 唯一告警锚点及其匹配方式，避免混淆相同事件码的不同告警实例。
- 告警当前状态，包括 `active`、`inactive`、`conflicted` 或 `unknown`，并分别列出状态依据。
- 已观察到的触发流程，例如采样、数值转换、门限或事件规则求值、事件存储和北向上报；未采集到的阶段会标记为缺失。
- 运行期事件与 dump 内 `.sr` 文件中 `CSR Event`/`PowerEvent` 定义、属性和直接引用关系的关联结果。
- `Assert`/`Deassert` 恢复配对、复发次数下界、历史覆盖范围和可能的时钟跳变。
- 每个关键事实对应的 dump 相对路径、行号、列号、JSON Pointer 或数据库定位信息。
> [!WARNING]注意：
> 告警链条分析仅关联 dump 中可观察到的事实，不会自动将时间相邻的事件视为因果，也不会使用静态 CSR 定义证明规则在告警时刻一定执行。日志缺失或状态冲突时，结论会保留为“证据不足”或“存在冲突”，需要结合现场信息和业务知识继续判断。
## 了解数据范围和安全边界
- AI Agent 日志工具只能访问分析任务绑定的日志包，不会自动选择其他历史日志。
- 日志证据使用日志包内相对路径，不会向页面回写宿主绝对路径。
- 日志体检唯一允许访问的外部知识是 openUBMC RAG 状态和知识检索结果。
- `tar` 系列导入会拒绝路径逃逸、绝对路径和解压炸弹，并忽略符号链接、硬链接及设备文件。
- PDF 报告只包含当前分析会话中的摘要、TopN 问题、RAG 依据和日志证据。
# 九、BMC 环境管理
本章介绍 openUBMC Studio 的 **BMC环境管理** 插件（扩展 ID：`openubmc.bmcstudio-bmc-remote`）的功能与使用方法。该插件用于在 IDE 内集中管理多台 BMC 环境、批量下发命令、上传文件、一键升级固件、实时监控日志、自动调试组件以及远程 GDB 调试。
BMC环境管理插件在活动栏注册一个「BMC环境管理」容器，下设两个视图：
- **BMC Environments**：BMC 环境连接树，按分组组织，管理连接的元数据与凭据。
- **Command Macros**：命令宏树，维护可批量下发的命令序列。
插件的核心能力包括：
- **连接管理**：以分组方式管理多台 BMC，单条连接可任选 SSH、Telnet 或 WebView 方式接入。
- **连通性管理**：手动或周期性探测 BMC 可达性，并在状态变化时播报。
- **命令宏**：预定义命令序列与变量，按「全部可达 / 分组 / 手动多选」批量下发，回收结构化结果。
- **SFTP 上传**：从资源管理器右键将本地文件或目录上传到 BMC。
- **HPM 一键升级**：右键 `.hpm` 固件包，并发升级多台 BMC，全程进度可视。
- **实时日志监控**：实时 `tail` 远端 `/var/log` 日志，支持日志轮转衔接、时间回绕校准与原始文件下载。
- **组件自动调试**：根据 Git 变更自动部署 Lua、C/C++ 和北向接口调试内容，详见 [C/C++、Lua 与北向接口快速调试](#quick-debug)。
- **远程 GDB 调试**：附加板端服务或部署独立程序进行源码级调试，详见 [BMC 远程 GDB 调试](#remote-gdb-debug)。
- **MCP 工具**：对外暴露 27 个 MCP 工具，供 AI Agent 调用，实现自然语言驱动的批量运维与告警证据分析。
## 使用前准备
### 环境要求
- **运行平台**：推荐 Linux（Ubuntu）。连接管理以 Linux 为目标平台；HPM 升级与日志监控仅依赖 Node 内置模块，三平台行为一致。
- **系统依赖**：建议预装以下工具：
- `openssh-client`：SSH 接入与 SFTP 上传。
- `telnet`：Telnet 接入与实时日志监控。
- `tar`（支持 `-z`）：目录上传与日志下载解压。
- `libsecret-1-0` / `gnome-keyring`：Linux 下用于安全存储密码。
### 安装插件
1. 在 openUBMC Studio 中打开插件市场（活动栏的「扩展」图标，或按 `Ctrl+Shift+X`），搜索「BMC环境管理」，点击「安装」。
2. 安装完成后重启 IDE 生效。活动栏出现「BMC环境管理」图标即表示安装成功。
> [!NOTE]说明：
> 若已安装 openUBMC Studio 主插件，BMC环境管理作为配套扩展随其一同提供，具体获取方式请参考 [openUBMC Studio安装指南](../installation_guide/bmc_studio_installation.md)。
## BMC 环境管理
### 新增分组
连接以「分组」为单位组织，系统默认创建一个分组。
1. 在 **BMC Environments** 视图标题栏单击「Add Group」按钮。
2. 输入分组名称并确认。
分组的右键菜单支持「Add」「Rename Group」「Delete Group」。**分组非空时拒绝删除**（保护数据），需先清空或迁移其下连接。
### 新增连接
1. 单击 **BMC Environments** 视图标题栏「Add BMC Environment」按钮，或在某个分组上右键选择「Add」。
2. 在弹出的表单中填写连接信息并保存。
连接字段说明：
| 字段 | 说明 | 备注 |
| --- | --- | --- |
| 名称 `name` | 连接显示名称 | 必填 |
| IP 地址 `host` | BMC 的 IPv4 地址 | 必填，仅接受 IPv4，非法地址会被拒绝 |
| 用户名 `username` | 登录用户名 | 必填 |
| 密码 `password` | 登录密码 | 必填（新增时）；密码存于操作系统级安全存储，不落配置文件、不进日志 |
| 分组 `group` | 所属分组 | 不选则落入首个分组 |
| 标签 `tags` | 标签数组 | 可选，用于归类 |
| 描述 `description` | 连接描述 | 可选 |
### 接入 BMC
在连接上右键，选择接入方式：
- **Connect via SSH**：使用进程内 SSH 客户端登录（兼容老款 BMC 的弱算法与 keyboard-interactive 交互），以伪终端呈现。默认在编辑器区（接近全屏）打开，由配置项 `bmc.autoMaximizeTerminal` 控制，关闭后回到底部面板。
- **Connect via Telnet**：调用系统 `telnet` 命令接入，需本机已安装 telnet。Telnet 不会自动发送密码，需手动输入。
- **Open in WebView**：使用系统浏览器打开 BMC Web UI（`https://{host}`）。
SSH 握手超时由 `bmc.connectionTimeout`（默认 30 秒）控制。
### 编辑与删除
- **Edit Configuration / Change Password**：修改连接信息。编辑密码时留空表示保留原密码。
- **Disconnect**：发送 `exit`、关闭终端并注销会话。
- **Delete**：删除前会弹出模态确认；删除会先关闭相关终端并清理该连接的凭据。
> [!NOTE]说明：
> 删除连接会连带删除其凭据；删除分组前需先清空连接或迁移。
## 连通性管理
插件通过 TCP 探测 SSH 22 端口判断 BMC 可达性，连接树图标实时反映状态（不可达时变红），分组徽章显示「X/Y 可达」。
- **手动探测单个**：右键连接 → 「Check Connection Health」，提示可达 / 不可达。
- **全量刷新**：单击视图标题栏「Refresh」，先把全部连接置为检测中再统一探测。
- **周期检测**：右键连接 → 「开启自动检测连通状态」/「关闭自动检测连通状态」。开启后每 **10 秒** 探测一轮，仅对开启该项的连接生效。
- **状态播报**：右键连接 → 「开启连通性变更播报」/「关闭连通性变更播报」。上线提示「{分组}/{名称} 已上电」，掉线提示「{名称} 已下电」。
探测超时由 `bmc.pingTimeout`（默认 3000 毫秒）控制。可达性 = 「TCP 22 端口通 + 已配置凭据」；运行宏、上传、升级前均以此作为就绪判据。
## 命令宏
命令宏用于预定义「一组有序 shell 命令 + 变量 + 失败策略」，运行时按目标范围批量下发到 BMC，每台环境复用一条 SSH 连接执行完整命令集，并回收结构化的「环境 × 命令」结果矩阵。
### 新建宏
1. 单击 **Command Macros** 视图标题栏「Add Command Macro」按钮。
2. 在表单中填写宏内容并保存。
宏字段说明：
| 字段 | 说明 | 默认值 / 范围 |
| --- | --- | --- |
| 名称 `name` | 宏名称 | 必填 |
| 描述 `description` | 宏描述 | 可选 |
| 命令 `commands` | 有序命令列表 | 至少 1 条；每条可单独设置 `description`、`timeoutMs`、`abortOnFailure`（遇错：默认 / 中断 / 继续） |
| 变量 `variables` | 自定义变量（键名不含 $） | 与内置变量合并；同名时**内置优先** |
| 失败策略 `onError` | 宏级策略 | `continue`（继续）/ `abort`（中断该环境后续命令）；默认 `continue` |
| 命令超时 `timeoutMs` | 单条命令超时（毫秒） | 默认 30000；单条命令可覆盖 |
| 并发度 `concurrency` | 环境间并发度 | 1–8，默认 1 |
| 标签 `tags` | 标签（表单中逗号分隔） | 可选 |
### 变量替换
命令模板支持变量占位：
- 语法：`$VAR` 或 `${VAR}`；$$ 转义为字面 $。
- 内置变量（按每台环境各自替换，优先级高于自定义）：
| 变量 | 含义 |
| --- | --- |
| `$HOST` | BMC IP 地址 |
| `$USER` | 登录用户名 |
| `$NAME` | 连接名称 |
| `$CONN_ID` | 连接 ID |
| `$GROUP` | 分组名称 |
> [!NOTE]说明：
> 未定义的变量**保留原样**（不会被置空），以避免因拼写错误导致类似 `rm -rf /tmp/$UNDEF/*` 的危险展开。
### 运行宏
- **Run Macro...**：右键宏 → 选择目标范围（「所有可达且有凭据的环境」/「按分组」/「手动多选」）→ 模态确认后执行。
- **Run on Group...** / **Run on All Reachable**：右键宏快速按分组或全部可达执行；后者也可用视图标题栏的火箭图标。
运行前会弹出确认：「命令可能对 BMC 造成不可逆影响，是否继续？」。
每台环境内的命令**严格串行**（后一条常依赖前一条结果）；环境间并发受 `concurrency` 限制（上限 8）。不可达或无凭据的环境自动跳过并标注，**不阻断其他环境**。每台环境的结果状态包括：
| 状态 | 含义 |
| --- | --- |
| `ok` | 全部命令成功 |
| `partial` | 部分命令失败 |
| `aborted` | 该环境被中断（如命令超时） |
| `unreachable` | 不可达 |
| `error` | 无凭据或连接失败 |
### 注入终端
除批量执行外，宏还支持把命令注入到已打开的终端：
- **Run Macro in Terminal...**：右键某连接 → 选择宏 → 命令注入该连接已打开的 SSH/Telnet 终端，复用连接与终端上下文，输出保留在终端中。
- **双击宏**：注入当前活动终端（任意终端；若该终端属于某 BMC 连接，则解析其内置变量）。
注入模式无法读回退出码，因此失败判断交由远端 shell：全部「继续」时按换行拼接逐条执行；存在「中断」时用 `&&` 串联，并把「继续」型命令包成不阻断链路的形式。
### 筛选与结果
- **Filter by Tag**：视图标题栏按标签筛选宏（含「无 tag」选项）。
- 结果写入 **BMC Remote** 输出通道（OutputChannel），包含每条命令的退出码、stdout、stderr 与汇总。
## SFTP 上传
1. 在资源管理器中右键本地文件或目录 → 「上传到 BMC 环境」。
2. QuickPick 列出全部连接并实时探测连通性，**仅可达环境可选**。
3. 选择目标 BMC 后，进度通知显示上传过程，完成后默认上传到远端 `/tmp`。
单文件使用 SFTP 直传；目录上传采用「本地 tar.gz 打包 → 传输 → 远端 `tar -xzf` 解压」流程。
> [!NOTE]说明：
> 目录上传需本机与远端均安装 `tar`（支持 `-z`），缺失会提示安装方式。无凭据或不可达的环境不可选。
## HPM 一键升级
1. 在资源管理器中右键 `.hpm` 固件包 → 「一键升级到 BMC 环境」（仅 `.hpm` 文件出现该菜单项）。
2. 多选目标 BMC（实时探测连通性，不可达项自动忽略），仅保留可达且有凭据的环境。
3. 模态危险确认：「将对 N 个环境升级固件 xxx.hpm，升级期间 BMC 可能重启且不可中断，是否继续？」。
4. 进度通知显示整体进度，完成后给出成功 / 失败汇总；失败环境的右下角通知可一键打开输出查看原因。
升级按 BMC HTTPS REST 协议执行「登录 → 上传 → 触发 → 轮询 → 登出」，使用 443 端口，自签名证书自动放行。
相关配置项：
| 配置项 | 默认值 | 说明 |
| --- | --- | --- |
| `bmc.upgradeConcurrency` | 3（1–8） | 多 BMC 并发度，重操作建议保守 |
| `bmc.upgradePollDeadlineMs` | 600000 | 单台轮询整体硬超时（默认 10 分钟） |
| `bmc.upgradePollErrorTolerance` | 5 | 轮询连续失败容错次数，兼容升级中途 BMC 重启 |
| `bmc.upgradeUploadTimeoutMs` | 300000 | REST 上传 HTTP 超时（超时自动转 SFTP 兜底） |
**BMC 重启期间**，进度条数值暂停在最后已知值，提示信息切换为「设备异常不通，正在尝试重新查询升级状态」，避免被误判为卡死或误报成功。常见失败原因：登录失败（检查账号密码与 443 端口）、触发失败、状态异常、轮询连续失败、上传失败、网络错误。
> [!WARNING]注意：
> 升级为**破坏性、不可逆**操作，一旦开始**不可取消**。请确认固件版本与目标环境正确后再执行。
## 实时日志监控
1. 在连接树右键某连接 → 「实时日志监控」。
2. 插件通过 Telnet 列出 `/var/log`，归并出日志基名，QuickPick 选择目标日志。
3. 打开日志监控 Webview（标题「{连接名} 日志监控」），实时追加日志。
4. 顶部按钮：「日志信息下载」（可选「下载当前窗口内容」/「下载远程原始文件」）、「清空」、「停止」；滚动离开底部时出现「回到底部」。
核心能力：
- **日志轮转无缝衔接**：跟随文件名 `tail`，在日志压缩切换瞬间自动重开新文件，流不中断。
- **时间回绕校准**：当系统时间回绕（年份小于 `rewindMinYear`，典型如 1970）时，自动估算并标注 `[估算]`，时间恢复后线性插值回填 `[校准]`。
- **断线自动重连**：默认开启，退避重连且不重置状态机。
- **下载双通道**：优先 SFTP 取回原始文件（含 `.gz`）；SSH/SFTP 不可用时自动回退 Telnet 八进制传输。
- **下载后自动拼接**：解压所有 `.gz` 并按时间顺序拼接为完整日志。
相关配置项：
| 配置项 | 默认值 | 说明 |
| --- | --- | --- |
| `bmc.logMonitor.maxBufferedLines` | 5000 | 后端缓冲日志行数上限（超出丢最旧） |
| `bmc.logMonitor.tailInitialLines` | 200 | 启动时初始输出行数 |
| `bmc.logMonitor.rewindMinYear` | 2000 | 年份小于该值视为回绕 |
| `bmc.logMonitor.autoReconnect` | true | 断线是否自动重连 |
| `bmc.logMonitor.reconnectAttempts` | 3 | 自动重连尝试次数 |
| `bmc.logMonitor.downloadGzip` | true | 下载原始文件是否包含 `.gz` |
> [!NOTE]说明：
> 仅开放 SSH（23 端口不通）的 BMC 无法使用日志监控。下载原始文件时密码可选（仅 SFTP 下载需要，缺失时自动回退 Telnet 传输）。
## 配置项总览
除上述章节提到的配置外，所有配置集中在 `bmc.*` 命名空间。可通过侧栏视图标题栏的齿轮按钮（「Open Settings」）直接打开本扩展配置页。
| 配置项 | 类型 | 默认值 | 用途 |
| --- | --- | --- | --- |
| `bmc.connectionTimeout` | number | 30000 | SSH 连接超时（毫秒） |
| `bmc.pingTimeout` | number | 3000 | 可达性 TCP 探测超时（毫秒） |
| `bmc.autoMaximizeTerminal` | boolean | true | BMC 终端在编辑器区（而非底部面板）打开 |
| `bmc.upgradeConcurrency` | number | 3 | HPM 升级并发度（1–8） |
| `bmc.upgradePollDeadlineMs` | number | 600000 | 单台升级轮询整体硬超时 |
| `bmc.upgradePollErrorTolerance` | number | 5 | 轮询连续失败容错次数 |
| `bmc.upgradeUploadTimeoutMs` | number | 300000 | HPM 上传 HTTP 超时 |
| `bmc.logMonitor.*` | — | — | 日志监控相关参数，见「实时日志监控」章节 |
## 与 AI 协作：MCP 工具
插件对外暴露 **27 个 MCP 工具**，可由 openUBMC Studio 的 MCP 宿主以鸭子类型发现，供 AI Agent 调用，实现自然语言驱动的批量运维与告警证据分析。凭据由安全存储服务端读取，**绝不进入工具的输入参数或返回结果**；连接、分组、宏均可用 ID 或名称（大小写不敏感）引用。
主要工具分类：
- **查询与探测**：列出连接 / 分组、健康探测。
- **SSH 执行 / SFTP 上传**：单命令执行、单文件 / 目录上传。
- **连接与分组管理**：增删改、自动检测与播报开关。
- **命令宏**：列出（可按标签过滤）、运行、新增、删除。
- **HPM 升级**：指定固件与目标范围，返回逐环境结果与汇总。
- **告警证据分析**：按事件码/时间或记录 ID 编译告警证据、定点读取报告，并生成有界的告警链条分析流程。
连接、宏、上传和升级等运维类 UI 命令与对应 MCP 工具共用同一套执行核心；告警证据分析只读 dump，不会修改日志或目标 BMC。
## 常见问题与注意事项
- **密码安全**：所有密码存于操作系统级安全存储，不落配置文件、不进日志、不在 MCP 输入输出中回显。
- **平台支持**：连接管理以 Linux 为目标平台；Windows / macOS 未纳入连接管理的测试范围。
- **可达性判据**：宏、上传、升级在执行前均以「TCP 22 通 + 有凭据」作为就绪判据，不可达环境自动跳过。
- **HPM 升级不可逆**：一旦开始不可取消，BMC 可能中途重启，请确认无误后再执行。
- **Telnet 依赖**：Telnet 接入与日志监控依赖系统 `telnet` 命令；目录上传与日志下载依赖 `tar`。
# 十、快速调试 C/C++、Lua 与北向接口
快速调试功能由“BMC 环境管理”插件提供。它根据组件中已保存到磁盘的 Git 变更自动生成调试计划，将必要文件部署到目标 BMC，重启受影响的服务并验证是否生效，适用于开发和自测阶段的快速迭代。
> [!NOTE]说明：
> 界面中的功能名称为“自动调试当前组件”。该功能用于快速部署和运行验证，不启动 GDB。如需使用断点、单步和变量查看，请执行“GDB 调试: 选择 BMC 连接并启动”，并参考[使用 openUBMC Studio 远程调试 BMC](#remote-gdb-debug)。
## 支持的变更类型
| 变更类型 | 处理方式 | 是否构建 |
| --- | --- | --- |
| 普通组件或北向接口中的运行时 Lua | 使用已保存源码直接部署到运行时目标 | 否 |
| 可证明为直接运行时文件的 JSON | 完成 JSON 语法和目标映射检查后直接部署 | 否 |
| 北向接口映射 JSON 等生成型输入 | 隔离构建当前组件，仅部署该输入影响的运行时生成结果 | 是，一轮最多一次 |
| C/C++ 源文件、头文件和 DMC 等编译型输入 | 隔离构建当前组件，部署本次构建产生的 ELF 或 Lua C 模块 | 是，一轮最多一次 |
| Lua、北向配置和 C/C++ 混合变更 | 合并为同一调试计划，直接部署项与构建产物一并生效 | 按需构建一次 |
README、设计文档和测试文件等无运行时影响的变更会被忽略；文件新增、删除、重命名、冲突或无法可靠映射的变更会被阻断，并在连接 BMC 前给出原因。
## 使用前准备
1. 使用 openUBMC Studio 打开组件仓或 rackmount 仓。仓库中应包含 `mds/service.json`。
2. 将工作区标记为受信任，并确保组件代码由 Git 管理。自动调试可以采集已暂存、未暂存和未跟踪的修改。
3. 单击活动栏中的“BMC 环境管理”图标。
4. 在“BMC 环境管理”中添加目标 BMC，并确认连接地址和凭据可用。
5. 仅包含可直接部署的 Lua/JSON 修改时，不依赖本地构建环境；C/C++ 和生成型北向配置的修改需要在支持 Bingo/Conan 的构建环境中调试。
6. 仅在已授权、可通过 Telnet 连接到具有 root 权限的 Shell 环境的开发板或调试环境中使用此功能。自动调试会临时替换运行时文件并重启受影响的 systemd 服务，不应直接用于生产设备。
## 执行自动调试
1. 保存本次需要验证的修改。若组件内仍有未保存文件，openUBMC Studio 会要求保存后再继续。
2. 通过以下任一入口执行“自动调试当前组件”：
- 在业务仓列表中选择组件仓的快捷操作“自动调试当前组件”或“按 Git 提交基线自动调试”。
- 在“BMC 环境管理”的连接上右键单击，选择“自动调试当前组件”。
- 按 `Ctrl + Shift + P` 打开命令面板，执行“BMC 调试: 自动调试当前组件”。
3. 根据入口选择或确认目标 BMC。openUBMC Studio 会采集当前组件的 Git 变更并生成初步计划。
4. 检查修改文件数、处理策略、预估替换文件数和是否需要构建。若需要构建，单击“开始构建”；直接部署场景单击“继续”。
5. 构建和最终映射完成后，再次检查替换文件数及影响的逻辑应用，单击“确认自动调试”。
6. 等待 openUBMC Studio 完成文件上传、完整性校验、服务归并、运行时激活、服务重启和结果验证。
> [!NOTE]说明：
> 需要验证一段连续提交中的最终差异时，可以使用“按 Git 提交基线自动调试”，选择一个提交、标签或分支作为基线。普通“自动调试当前组件”只处理当前 Git 工作树修改。
## 验证调试结果
自动调试完成后，按以下步骤验证结果：
1. 确认 openUBMC Studio 显示调试成功，并核对替换文件数和受影响服务数。
2. 打开“BMC GDB”输出通道，检查详细计划、构建输出、运行时目标、服务名称和校验结果。
3. 执行本次修改对应的业务操作，确认功能行为符合预期。
## 切换默认调试目标
如需切换默认调试目标，执行以下操作：
1. 单击状态栏中的“BMC：当前环境名称”。
2. 在环境列表中选择目标 BMC。
状态栏显示所选环境名称时，表示默认调试目标已切换。
## 调试生效与连续迭代
自动调试不会覆盖 BMC 的只读系统分区，而是在 `/data/bmc-debug` 下准备会话私有的最小替换集，通过临时挂载或服务配置让目标进程使用调试版本。openUBMC Studio 会进行以下校验：
- Lua、JSON 和可执行文件的运行时目标必须来自本轮调试目录，且内容摘要一致。
- 共享库必须在服务重启后由目标进程从本轮调试目录加载。
- 多个逻辑应用属于同一个 systemd 服务时，会合并替换内容，该服务只重启和验证一次。
- 任一服务组激活失败时，后续服务停止执行，已经生效的服务组按逆序恢复。
修改代码并再次执行自动调试时，新版本会直接接管同一服务的上一轮 openUBMC Studio 调试会话，不需要每轮都先恢复环境，也不会叠加多层调试挂载。
> [!NOTE]说明：
> 自动调试仅支持替换目标环境中已存在的组件和文件。涉及文件新增或删除时，请构建并升级固件包进行验证。
## 恢复调试环境
完成验证后，通过以下任一入口恢复目标 BMC：
- 在“BMC 环境管理”的目标连接上右键单击，选择“恢复调试环境”。
- 在业务仓快捷操作中选择“恢复调试环境”。
- 打开命令面板，执行“BMC 调试: 恢复调试环境”。
openUBMC Studio 会根据板侧会话清单和实际挂载、临时服务配置及进程状态，仅清理能够证明属于 openUBMC Studio 的调试资源，并将服务恢复到首轮调试前的状态。若提示恢复不完整，请保留“BMC GDB”输出中的会话和路径信息，修复连接后再次执行恢复，不要直接批量删除 `/data/bmc-debug`。
## 配置项
| 配置项 | 默认值 | 说明 |
| --- | --- | --- |
| `bmc.quickRestart.enabled` | `true` | 是否在组件工作区启用自动调试 |
| `bmc.quickRestart.buildToolPath` | `bingo` | 构建型修改使用的构建工具 |
| `bmc.quickRestart.buildArgs` | `["build", "-bt", "debug"]` | 隔离构建参数 |
| `bmc.quickRestart.buildTimeoutMs` | `1800000` | 单次构建超时，默认 30 分钟 |
| `bmc.quickRestart.maxChangedFiles` | `2000` | 单次自动调试允许采集的最大修改文件数 |
> [!WARNING]注意：
> 自动调试用于临时验证，不能替代正式组件包、固件构建和升级流程。最终交付前仍需执行项目规定的构建、测试和发布检查。
# 十一、远程调试 BMC
openUBMC Studio 通过 BMC 环境管理扩展（`openubmc.bmcstudio-bmc-remote`）提供远程 GDB 调试能力，用于对板端 C/C++ 组件进行源码级调试。扩展可以完成板端部署、`gdbserver` 启动、符号与源码路径解析和会话清理。
> [!WARNING]注意：
> 仅在已授权的隔离调试板上使用远程调试，不要对生产环境中的 BMC 执行调试操作。
## 选择调试方式
| 场景 | 调试方式 | 是否进入 GDB |
| --- | --- | :---: |
| 调试板上正在运行的 systemd 业务服务 | Attach（附加）调试 | 是 |
| 调试独立测试程序、工具或 carrier | Standalone（独立程序）调试 | 是 |
| 仅验证新产物能否运行或查看日志 | Deploy & Restart（快速部署并重启） | 否 |
| 组件仅输出 `.so` 库 | 编写 carrier 后使用 Standalone 调试 | 是 |
在“运行和调试（Run and Debug）”下拉列表中选择 `launch.json` 配置。`request` 为 `attach` 的配置使用 Attach 调试，`request` 为 `launch` 的配置使用 Standalone 调试。
## 使用前准备
- **调试版产物**：执行 `bingo build -bt debug`，构建包含 DWARF 调试信息的产物。推荐使用 `-g -O0` 编译选项。
- **本机交叉 GDB**：安装 `gdb-multiarch` 或 `aarch64-linux-gnu-gdb`。
- **BMC 连接**：在“BMC 环境管理”中配置管理 IP 地址、SSH 端口和 Administrator 账号凭据。
- **板端 gdbserver**：通常无需手动安装，扩展会探测板端 `gdbserver` 或使用内置版本。
> [!NOTE]说明：
> 首次调试时，openUBMC Studio 会自动安装 Eclipse CDT GDB Adapter 扩展。离线环境需要提前安装该扩展。生产网络或非隔离网络建议将 `bmc.gdb.rspTransport` 设置为 `tunnel`，使 RSP 流量通过 SSH 隧道传输。
## 使用 Attach 调试板上服务
Attach 调试会根据构建产物的二进制名称发现板端服务。以下 `launch.json` 配置将 `artifact` 指向构建产物目录或 ELF 文件：
```jsonc
{
"version": "0.2.0",
"configurations": [
{
"type": "bmc-gdb",
"request": "attach",
"name": "BMC 调试：附加板上服务",
"bmcConnection": "lab-bmc-03",
"artifact": "/home/dev/.conan2/p/b/xxxx/p", // 构建产物目录或 ELF 文件
"stopAtEntry": true,
"buildIdCheck": "warn"
}
]
}
```
操作步骤如下：
1. 执行 `bingo build -bt debug`，确认构建产物包含调试信息。
2. 确认板端目标服务处于 `active` 状态。
3. 在“运行和调试”下拉列表中选择 Attach 配置。
4. 按 `F5` 启动调试。
5. 在“BMC 调试会话”视图中确认各准备阶段均已通过。
扩展会根据 Build ID 比对结果选择执行策略：
- **Build ID 匹配**：不部署、不替换且不重启服务，仅使用 `gdbserver --attach` 附加到当前进程。
- **Build ID 不匹配**：选择“准备调试版本并附加”可以部署调试产物、临时替换并重启服务，会话结束后自动恢复；也可以选择“继续仅汇编调试”或“选择其他 Artifact”。替换和重启前，openUBMC Studio 会显示影响确认窗口。
## 使用 Standalone 调试独立程序
Standalone 调试适用于独立工具、测试程序、尚未安装的新服务，以及为纯库组件编写的 carrier。以下配置将 `artifact` 指向构建输出目录：
```jsonc
{
"version": "0.2.0",
"configurations": [
{
"type": "bmc-gdb",
"request": "launch",
"name": "BMC 调试：部署并启动程序",
"bmcConnection": "lab-bmc-03",
"artifact": "/home/dev/build/output", // 推荐使用目录，也可以直接指定 ELF 文件
"stopAtEntry": true,
"buildIdCheck": "warn"
}
]
}
```
使用 Standalone 调试时，请注意以下事项：
- `artifact` 指向目录时，扩展会扫描其中的 AArch64 可执行 ELF。只有一个候选文件时自动选用，存在多个候选文件时需要手动选择。
- 产物包含共享库时，通过 `artifactRoots` 指定本次构建对应的 Conan package 目录，避免混用不同版本的同名库。
- 启动程序前，扩展会执行 ABI 预检，并报告缺少共享库或符号未定义等问题。
- 调试纯 `.so` 库时，需要编写调用目标库函数的最小 carrier，并在库函数中设置断点。
配置完成后，在“运行和调试”下拉列表中选择 Standalone 配置，按 `F5` 启动调试，并在“BMC 调试会话”视图中确认部署和启动阶段均已通过。
## 快速部署并重启组件
Deploy & Restart 不进入 GDB。该功能会将产物部署到板端影子目录、重启服务，并通过 `/proc//maps` 验证目标进程是否加载新产物，适用于修改静态库后快速确认服务能否启动。
1. 按 `Ctrl + Shift + P` 打开命令面板。
2. 执行“BMC调试: 快速重拉组件(部署+重启,不调试)”。
3. 在“BMC GDB”输出通道中确认部署、服务重启和加载路径校验均已完成。
## 执行日常调试操作
断点、条件断点、日志断点、单步、变量监视和调用栈等操作均使用 openUBMC Studio 原生调试界面。常用 GDB 控制台命令如下：
| 命令 | 作用 |
| --- | --- |
| `bt`、`bt full` | 查看当前线程的调用栈，或包含局部变量的调用栈 |
| `thread apply all bt` | 查看所有线程的调用栈，用于排查卡死或死锁 |
| `info sharedlibrary` | 查看共享库加载和符号读取情况 |
| `print <变量>`、`ptype <类型>` | 打印变量或查看类型定义 |
| `info breakpoints` | 查看断点是否已验证或处于 pending 状态 |
> [!WARNING]注意：
> Attach 会话中的进程由 systemd 和扩展管理，不要在 GDB 控制台中执行 `run`，请使用 `continue`、`next` 或 `step`。服务在断点处暂停过久可能触发上游超时或 watchdog，请控制暂停时间。
## 排查常见问题
| 现象 | 原因与处理方法 |
| --- | --- |
| 提示“无 DWARF 调试信息” | 当前文件可能是 strip 后的 package 文件；使用 `bingo build -bt debug` 重新构建，并选择 build 目录中未 strip 的副本 |
| 断点显示为灰色或未命中 | 检查源码映射和 Build ID，并使用 `info sharedlibrary` 确认目标库已加载 |
| GDB 连接立即断开 | 检查“BMC GDB”输出中最早出现的错误，确认 `gdbserver` 能够启动且运行依赖完整 |
| `libX.so => not found` | 将本次构建对应的精确 package 目录加入 `artifactRoots` |
| 变量显示 `` | 使用 `-O0 -g` 重新构建调试产物 |
| 服务重启后立即退出 | 查看 ABI 预检报告和 `journalctl -u `，排查缺少共享库或 ABI 不兼容问题 |
| 调试结束后服务仍使用调试版本 | 执行“GDB调试: 清理板侧调试残留” |
## 结束调试并清理环境
- **正常结束**：单击调试工具栏中的“停止”。扩展会停止 `gdbserver`、撤销板端替换、恢复服务并删除调试产物。
- **异常退出后恢复**：重新启动扩展，等待扩展自动对账和恢复。如果仍有残留，在命令面板中执行“GDB调试: 清理板侧调试残留(崩溃会话对账)”。
完成远程调试时，请遵循以下原则：
1. 符号文件、运行文件和依赖库应来自同一次构建。
2. 排查故障时，优先查看“BMC 调试会话”视图中最早失败的阶段。
3. 使用 openUBMC Studio 的停止按钮或清理命令结束会话，确保扩展能够执行恢复流程。
# 十二、白牌包定制
本章介绍 openUBMC Studio 的 **白牌包定制** 能力：在 IDE 内通过可视化编辑器定制 BMC 白牌包的 Web 界面风格、Logo/图片、产品信息等，并一键调用 `bingo wbd_build` 构建出白牌固件包。
> [!NOTE]说明：
> 本能力由 openUBMC Studio CSR 拓扑插件（`bmcstudio_csr_topolopy`）提供。关于白牌包定制的官方概念与字段含义，另见 [白牌包定制官方指南](https://www.openubmc.cn/docs/zh/development/develop_guide/product_development/white_branding_customization_guide.html)。
白牌包定制用于把 BMC 从默认外观/信息改造为某品牌或客户专属形态，涵盖三类定制：
- **配置定制**：产品联系信息、SSL 证书字段、软件名称、主机名、客户名等，写入 `web_custom.xml`。
- **风格定制**：Web 主界面风格（精美/简约/标准），写入 `style_config.json`。
- **图片定制**：浏览器图标、登录页 Logo、技术支持二维码、Web 界面图片等，写入 `filelist.conf` 声明并随包发布。
白牌包定制分两种模式：
| 模式 | 作用 |
|---|---|
| **白牌包**（普通） | 把 BMC 定制为目标品牌/客户形态 |
| **清白牌包** | 一种特殊白牌包，把已定制的 BMC **恢复为默认配置** |
两类模式共用同一套可视化编辑器与构建流程。
## 使用前准备
- **构建工具**：需安装 `bmcgo` 或 `bingo`，且支持 `wbd_build` 子命令。插件会优先尝试 `bmcgo`，不可用时回退 `bingo`。
- **工作目录**：准备一个用作白牌目录的文件夹（可为空）。白牌定制涉及的核心文件会生成在该目录下，构建产物 `wbd-crypt-image-signed.hpm` 也会落回该目录。
## 打开白牌定制编辑器
在资源管理器中**右键单击任意文件夹**，选择 **「定制白牌文件」** 即可打开白牌定制编辑器（webview）。
打开时的行为遵循「缺哪个补哪个」：
- 若目录下尚无白牌文件，会自动创建默认的 `filelist.conf`、`web_custom.xml`、`style_config.json`（默认风格 `beautiful`、版本 `2.00`）；同时**扫描目录里已存在的图片**自动加入 `filelist.conf` 声明，避免「图片在但 filelist 没声明」的不一致。
- 若目录下已有白牌文件，则按现有配置加载到编辑器中。
> 编辑器为单例面板：同一文件夹重复右键打开会回到已打开的面板；不同文件夹各自打开独立面板，互不干扰。
## 编辑器界面
编辑器顶部为模式切换与版本号，下方分为「配置定制」「风格定制」「图片定制」三个区域，底部为「保存」「构建」按钮。
### 模式与版本号
- **模式**：`白牌包` / `清白牌包` 单选。切换到清白牌模式时，会隐藏「风格定制」段、图片按 BMC 路径分组展示、构建按钮文案变为「清白牌包构建」。图片在两种模式间共享，切换不重置。
- **版本号**：格式 `x.y`（`y` 最多两位，如 `1.0`、`2.0`、`1.10`），保存后写入 `web_custom.xml` 的 `` 头部。加载时从 XML 头部解析回填。必填且需通过正则校验，否则保存/构建按钮禁用。
### 配置定制（web_custom.xml）
可视化表单对应 `web_custom.xml` 的 17 个属性，每项带 tooltip 说明，只需填写需要的项：
| 字段 | 说明 |
|---|---|
| `sysContact` | 维护联系人 |
| `dBannerContent` | 默认横幅内容 |
| `PreSSLSeverCommonName` / `PreSSLSeverOrgName` / `PreSSLSeverCountry` | 预置 SSL 证书通用名/组织/国家 |
| `OfficalWeb` / `SupportWeb` | 官网 / 技术支持网址 |
| `Copyright` | 版权信息 |
| `Email` / `Phone` | 邮箱 / 电话 |
| `DownloadKVMLink` | KVM 下载链接 |
| `DocSupportFlag` | 文档支持标记（取值 `0`/`1`） |
| `SoftwareName` | 软件名称 |
| `CustomAlarmName` | 自定义告警名称 |
| `CustomManufacturer` | 自定义厂商 |
| `HostName` | 主机名 |
| `Customer` | 客户名 |
保存时只输出非空字段；`DocSupportFlag` 取值必须为 `0` 或 `1`。
### 风格定制（style_config.json）
选择 Web 主界面风格 `pageStyle`：
- `beautiful`（精美，默认）
- `simple`（简约）
- `standard`（标准）
`pageStyle` 在白牌模式下必填（不选会校验失败，保存/构建禁用）；清白牌模式下该段隐藏，`style_config.json` 强制写空对象 `{}`。
### 图片定制（filelist.conf）
可定制 8 张图片，每张对应固定的 BMC 路径与文件名，已按类型限制只能选择对应类型图片：
| 分组 | 文件名 | BMC 路径 |
|---|---|---|
| 浏览器图标 | `favicon.ico` | `/data/opt/pme/web/htdocs` |
| 技术支持二维码 | `code1.png` | `/data/opt/pme/web/htdocs/theme/custom/img` |
| Web 界面图片 | `login.png`、`login_logo.png`、`img_01.png`、`img_02.png`、`img_03.png`、`header_logo.png` | `/data/opt/pme/web/custom` |
每张图卡片支持「选择图片 / 更换 / 删除」；保存时所选图片会被复制到白牌目录（文件名与 `filelist.conf` 的声明一致）。
## 保存
点击「保存」执行两步：
1. **同步图片**：把所选图片复制到白牌目录，文件名改为与 `filelist.conf` 声明一致；
2. **生成文件**：按当前配置写出 `filelist.conf`、`web_custom.xml`、`style_config.json`。
保存成功后右下角提示「白牌配置已保存」。
## 构建白牌包
点击「白牌包构建」（清白牌模式为「清白牌包构建」），流程如下：
1. **校验**：`pageStyle` 必填、`DocSupportFlag` 合法、版本号格式正确（实时校验，通过后才允许构建）；
2. **自动保存**：有未保存改动时先自动保存，保存成功后再构建；
3. **前置文件检查**：核对 `filelist.conf` 声明的文件是否都实际存在；
- 仅图片缺失 → 自动清理 `filelist` 中缺失声明并提示重新构建；
- 核心文件（`web_custom.xml`/`style_config.json`）缺失 → 报错，需手动处理；
4. **临时目录构建**：把白名单文件（`filelist.conf`、其声明的文件、可选 `beforeaction.sh`/`afteraction.sh`）复制到临时目录，在其中执行 `bingo wbd_build`，终端面板实时输出进度（可手动终止）；
5. **产物落回**：构建成功后产物 `wbd-crypt-image-signed.hpm` 自动复制回原白牌目录（同名覆盖），右下角提示带完整路径；
6. **按钮状态**：构建期间按钮变为「构建中...」并禁用，结束后无论成功/失败/终止都恢复。
> [!NOTE]说明：
> 为什么要切到临时目录：`bingo` 命令清单对当前工作目录敏感，在 manifest 项目根或组件目录下会过滤掉 `wbd_build`。因此构建一律先切到脱离任何 manifest 树的临时目录执行，跑完再把产物复制回来。
**工具回退**：优先 `bmcgo`，不可用回退 `bingo`；执行中若返回退出码 `127`（命令不存在）会自动换另一个工具重试一次，其他业务错误不重试。
**常见失败提示**：
| 场景 | 提示 |
|---|---|
| 缺图片（可自动清理） | 已自动清理 filelist 中缺失的图片声明：xxx，请重新构建 |
| 缺核心文件 | 白牌目录缺少必要文件：xxx，请重新保存完整配置 |
| bingo 退出码非 0 | 白牌包构建失败（退出码 N），请查看终端输出 |
| 用户 Ctrl+C | 白牌包构建已终止 |
| 工具未找到 | 未找到打包工具，请先安装 |
## 清白牌包定制（恢复默认）
清白牌包用于把 BMC 从已定制状态恢复为默认配置，三类恢复默认规则：
- **配置定制**：`web_custom.xml` 写默认值；
- **风格定制**：`style_config.json` 写空对象 `{}`；
- **图片定制**：要恢复默认的图片在 `filelist.conf` 中将 `Name=` 改为 `CLEAR_ALL`（BMC 路径不变），并在白牌目录创建一个空 `CLEAR_ALL` 文件。
切到清白牌模式后，8 张图按 BMC 路径分 3 组展示（浏览器图标 / 技术支持二维码 / Web 界面图片），每组有组级复选框可整组恢复默认。
> [!NOTE]说明：
> **CLEAR_ALL 按路径去重**：BMC 检测到某路径下有 `CLEAR_ALL` 文件就清空整个目录，与 filelist 中声明数量无关。因此同一 BMC 路径下多张图标记恢复默认时，`filelist.conf` 只生成一条 `Name=CLEAR_ALL`（例如 Web 界面图片组 6 张共用一个路径 → 只写 1 条）。
清白牌构建链路与白牌包完全一致（临时目录 + 白名单复制 + `bingo wbd_build` + HPM 落回原目录）；`filelist.conf` 的 `Version` 为 `2.02`（白牌模式为 `2.00`）。
## 常见问题与注意事项
- **按钮一直禁用**：检查 `pageStyle` 是否已选（白牌模式必填）、`DocSupportFlag` 是否为 `0`/`1`、版本号是否符合 `x.y`（`y` 最多两位）。
- **图片显示但构建报缺失**：以文件实际存在为准；缺图片会被自动清理，按提示重新构建即可。
- **找不到 `wbd_build` 命令**：不要在 manifest 项目根或组件目录下手动执行；编辑器的临时目录构建已规避此问题。若仍报工具未找到，请确认 `bmcgo`/`bingo` 已安装并在 PATH。
- **产物位置**：`wbd-crypt-image-signed.hpm` 总是生成并覆盖回右键打开的白牌目录，不会留在临时目录。
- **清白牌模式风格段消失**：属预期，清白牌会把 `style_config.json` 强制写为 `{}`。
# 十三、Manifest 配置与一键出包
## Manifest 配置
Manifest 配置功能用于可视化查看和修改 `manifest.yml` 中的出包配置，包括构建变体、默认特性、组件依赖和组件特性。配置面板会结合 lockfile 显示组件的实际版本和生效配置，并在写回文件时尽量保留原有注释、缩进和其他未修改内容。
> [!NOTE]说明：
> Manifest 配置功能当前支持 Linux 环境，完整解析组件版本和特性需要安装 Conan 2.x。
> 建议将 manifest 仓根目录作为受信任的工作空间打开，并确认目标产品的配置文件位于 `build/product/<产品线>/<机型>/manifest.yml`。
### 打开出包配置
1. 在 openUBMC Studio 中打开需要配置的 `manifest.yml` 文件。
2. 点击依赖配置上方的“打开出包配置”。也可以打开命令面板，执行“Manifest: 打开出包配置面板（变体/依赖/默认特性）”。
3. 在“出包配置”页面查看 schema 类型、平台包和 lockfile 状态，以及构建变体、默认特性、组件依赖和诊断结果。
### 配置构建变体和默认特性
1. 在“构建变体”区域选择需要配置的 `manufacture` 或 `tosupporte` 变体。未选择变体时，页面展示并修改基线配置。
2. 查看当前变体的 `build_type`、`signature_type` 和 `platform.package` 信息。选择变体后，依赖列表展示该变体与基线合并后的生效结果。
3. 在“默认特性 default_options”区域修改已有特性，或点击“新增一项”添加特性。
4. 点击“保存默认特性”，将配置写回当前基线或变体。
> [!NOTE]说明：
> 切换变体或清空默认特性前，如果存在未保存的修改，openUBMC Studio 会提示是否丢弃修改。
### 配置组件依赖和特性
1. 在“依赖 dependencies”区域查看基础组件，`dt_dependencies`（gcov）、`debug_dependencies`（dev）、`qemu_dependencies`（qemu）分别以独立卡片展示。
2. 根据需要执行以下操作：
- 点击“插入”，从候选列表中向当前依赖类型添加组件。
- 点击“特性”，展开组件的 `options` 和 `tool_options`。特性值会标识为“显式”、“继承默认”或“recipe 默认”。
- 配置变体时，点击“删除”或“取消删除”，设置或取消组件的 `action: delete` 状态。
- 点击“移除”，删除当前基线或变体中直接声明的组件。
3. 修改组件特性后，点击“保存到 manifest”。
> [!NOTE]说明：
> 当 `platform.package` 已配置时，平台整包中的组件会显示“锁”标识，其版本和特性不可在产品 Manifest 中定制。
> 变体中继承自基线的组件不能直接从变体中移除，如需删除其声明，请切换到基线操作。
### 查看 SDK 组件
1. 在 `platform.conan` 配置上方点击“查看 ibmc_sdk 组件”，或在 `openubmc_sdk.conan` 配置上方点击“查看 openubmc_sdk 组件”。
2. 在“SDK 组件”页面查看组件名称、版本或 Conan 引用，以及组件清单的来源。
3. 在搜索框中输入组件名称，可以筛选当前 SDK 中的组件。
## 组件与固件联合构建
组件与固件联合构建功能用于在业务组件仓中构建本地 Conan 包，并将该组件集成到目标产品的调试固件中。本章节适用于需要验证组件改动或生成联调固件的组件开发人员。
### 准备构建环境
执行组件构建前，请准备以下环境：
- 受信任的 Linux 本地、WSL 或 SSH Remote 工作空间
- 包含有效 `mds/service.json` 的业务组件仓
- 安装在 Extension Host 中的 Conan 2.x
- 登录 Shell 可以执行 `bmcgo` 或 `bingo`
执行组件与固件联合构建时，还需要满足以下要求：
- Extension Host 中已安装 Git
- 目标 Manifest 可以从同一 Extension Host 访问
- 目标 Manifest 位于 `build/product/<产品线>/<机型>/manifest.yml`
- 目标 Manifest 所在仓库具有有效的 Git HEAD
- 目标 Manifest 的修改已经保存
- 目标 Manifest 未配置非空的 `include`
> [!NOTE]说明：
> 如果同时检测到 `bmcgo` 和 `bingo`，openUBMC Studio 默认使用 `bmcgo`，并允许用户切换构建工具。组件构建面板与固件出包页面共用此设置。仅检测到 `bingo` 时，openUBMC Studio 直接使用 `bingo`。
### 打开组件构建面板
1. 将包含 `mds/service.json` 的业务组件仓作为工作空间打开。
2. 在资源管理器中展开“业务组件仓快捷入口”。
3. 展开“openUBMC Studio Local View”。
4. 单击“组件构建”。
5. 等待构建计划解析完成。
通过资源管理器中的快捷入口打开组件构建面板。
组件构建面板默认进入“仅组件模式 · 不关联 Manifest”，并显示组件包、组件 options、阻断项和诊断信息。
展开“运行环境与命令详情”，可以查看登录 Shell、工具路径、命令预览和目标 profile。展开“查证与会话技术详情”，可以查看组件包身份、依赖图和沙箱覆盖的证据位置。
### 仅构建组件
仅构建组件适用于只需要生成本地组件包、不需要生成固件的场景。此模式不创建 Manifest 沙箱，也不执行 `install_sdk`、`app` 或 `publish`。
1. 确认页面处于“仅组件模式”。
2. 如果已经选择固件目标，单击“返回仅组件模式”。
3. 在“组件 options”区域选择需要的值。
4. 确认“阻断项”为空。
5. 根据需要展开“运行环境与命令详情”，检查命令预览。
6. 单击“仅构建组件”。
7. 在 Task 终端中查看构建输出。
8. 构建完成后，确认“执行状态”为“成功”。
9. 展开“查证与会话技术详情”，查看“组件独立构建包身份证明”。
只能选择当前 `mds/service.json` 中声明且类型一致的 option 值。openUBMC Studio 使用 debug build type 和 stable channel 构建组件。Task 终端会显示组件构建过程和最终结果。
Task 退出码为 0 后，openUBMC Studio 会从本地 Conan cache 验证本次组件包的 reference、RREV、package ID、PREV、settings 和 options。如果无法唯一确定本次组件包，构建结果仍会标记为失败。
> [!WARNING]注意：
> 组件 Task 在源码仓根目录中执行，可能创建或刷新 `conanbase.py`、`temp/`、`gen/` 以及 `mds/service.json` 中声明的代码生成目录。如果其他受保护文件发生变化，openUBMC Studio 会停止后续流程，但不会自动回滚文件。执行构建前，请保存重要修改。
### 构建组件并转到固件出包
组件与固件联合构建适用于生成包含当前组件改动的调试固件。openUBMC Studio 会在隔离的 Manifest 沙箱中应用组件包，不会修改源 Manifest、SDK 或 subsystem 文件。
#### 选择固件目标
1. 单击“选择固件目标”（已选择目标时显示为“更换固件目标”）。
2. 选择需要构建的 `tosupporte` 或 `manufacture` 包型。
3. 如果列表中没有目标文件，单击“选择其他 manifest.yml…”。
4. 选择当前 Extension Host 可以访问的 `manifest.yml`。
5. 等待构建计划刷新完成。
6. 确认页面标题下方显示正确的产品线、机型和包型。
固件目标列表显示已发现的产品、包型和 Manifest 路径。选择结果会自动缓存。
选择固件目标后，组件 options 由目标 Manifest 的生效配置锁定，不能在面板中修改。如果源码版本不满足目标版本约束，页面会显示非阻断提示；`app` 和 `publish` 仍会验证实际选中的组件包。无法安全解析配置或 option 时，页面会阻止构建。
#### 执行联合构建
1. 确认“阻断项”为空。
2. 展开“运行环境与命令详情”。
3. 检查 `install_sdk`、组件构建、`app` 预检和 `publish` 命令。
4. 单击“构建组件并转到固件出包”。
5. 在 Task 终端中查看构建输出。
openUBMC Studio 按以下顺序执行联合构建：
1. 复制 Manifest 的 Git 源输入并创建临时沙箱。
2. 在沙箱中将所选包型的 `build_type` 设置为 `debug`。
3. 使用 stable channel 执行 `install_sdk`。
4. 使用目标 profile 构建并验证当前组件包。
5. 在沙箱当前包型的 `dependencies` 中写入组件的精确 reference、RREV 和业务 options。
6. 使用 stable channel 执行 `app` 依赖图预检。
7. 验证依赖图选择的组件 recipe、目标 profile 和业务 options。
8. 打开“固件出包”页面并自动启动 stable channel 的 `publish` 任务。
#### 验证联合构建结果
1. 在组件构建面板中确认“执行状态”为“成功”。
2. 确认“组件包证明”和“app 目标包证明”均已通过。
3. 在自动打开的“固件出包”页面中查看计划组件和本次实际组件。
4. 确认固件任务退出码为 0。
5. 在“自动发现的本次产物”区域下载需要的固件产物。
在“固件出包”页面中核对计划组件和本次实际组件，确认固件使用了本次构建的组件包。
在“自动发现的本次产物”区域下载需要的固件文件。
组件会话、固件出包交接和固件任务分别记录结果。组件页面显示成功，表示组件包身份和 `app` 选包已经验证；固件是否成功以固件出包页面中 `bmcgo` 或 `bingo` 的退出码为准。未自动发现 HPM、ZIP 或 QEMU 文件不会改变固件任务的结果，需要结合 `output` 目录和完整的 `task.log` 确认实际文件。
选择合法的 `tosupporte/qemu` 目标时，`app` 和 `publish` 会自动启用 QEMU 构建参数。固件出包页面会尝试发现 `.data.gz` 和 `.cpio.gz` 产物并提供下载入口。后续操作请参见[一键出包](#一键出包)。
### 停止构建任务
关闭组件构建页面不会停止正在运行的任务。重新打开同一组件仓，可以继续查看当前会话。
- 组件构建阶段：单击“取消”
- 固件构建阶段：在“固件出包”页面中单击“终止任务”
### 清理构建沙箱
1. 等待固件任务进入成功、失败或取消状态。
2. 下载需要保留的固件产物。
3. 返回组件构建页面。
4. 单击“清理本次沙箱”。
5. 在确认窗口中单击“清理本次沙箱”。
开始下一轮构建时，也可以在提示窗口中单击“清理并继续”。
> [!WARNING]注意：
> 清理沙箱会永久删除本次联合构建生成的临时 Manifest、日志和固件产物，且无法恢复。openUBMC Studio 重启后也不保证能够访问旧会话产物。执行清理前，请下载需要保留的产物。
### 处理常见问题
| 诊断码或现象 | 处理建议 |
|--------------|----------|
| `WORKSPACE_UNTRUSTED`、`UNSUPPORTED_PLATFORM` | 在受信任的 Linux 本地、WSL 或 SSH Remote 工作空间中重新打开组件仓。 |
| `BUILD_TOOL_NOT_FOUND`、`SHELL_ENV_RESOLVE_FAILED` | 确认登录 Shell 可以执行 `bmcgo` 或 `bingo`，并可以执行 Conan 2.x；也可以单击“配置工具路径”。 |
| `TARGET_MANIFEST_INVALID`、`MANIFEST_GIT_CONTEXT_UNAVAILABLE` | 保存并检查目标 Manifest；确认已安装 Git，目标仓具有有效 HEAD，且没有非空 `include`。 |
| `PLAN_STALE` | 组件源码、`mds/service.json`、Manifest 或相关 SDK 输入在计划生成后发生变化；保存文件并单击“刷新计划”。 |
| `PROFILE_DRIFT`、共享构建资源等待 | 避免在其他 Studio 窗口或外部终端中同时修改同一 Conan profile 或 cache，等待当前任务结束后刷新计划。 |
| `COMPONENT_VERSION_OUT_OF_RANGE` | 此提示不会阻止构建。确认源码版本符合本次调试目的后继续，实际选包仍由沙箱中的 `app` 和 `publish` 依赖图验证。 |
| `INTEGRATION_MISMATCH` | 展开“查证与会话技术详情”，检查独立组件包、整包目标组件包、`app` 依赖图和 options 差异。 |
| `MANIFEST_INPUT_LIMIT_EXCEEDED`、`INSUFFICIENT_DISK_SPACE` | 清理 Manifest 仓中未忽略的大文件或释放沙箱所在卷空间；确有需要时在“组件构建”设置中调整输入上限或最低可用空间。 |
| `DEBUG_PACKAGE_SIGNING_UNAVAILABLE` | 此提示不会阻止构建。固件签名或占位行为由 `bmcgo` 或 `bingo` 决定，请以固件任务退出码和产物为准。 |
| `FIRMWARE_PACKAGE_HANDOFF_FAILED` | 组件包和 `app` 预检可能已经成功；根据提示中的沙箱 Manifest 和覆盖报告，在固件出包页面检查阻断项并重试。 |
## 一键出包
一键出包功能可以根据产品 `manifest.yml` 中的 `tosupporte` 和 `manufacture` 包型生成构建命令，完成环境预检并启动固件构建。构建过程中可以查看计划组件、实际组件、构建进度和日志，构建完成后可以下载本次生成的固件产物。
> [!NOTE]说明：
> 执行一键出包需要使用受信任的 Linux 本地、WSL 或 SSH Remote 工作空间，manifest 仓及其 `output` 目录需要具备写权限。
> 用户登录 Shell 环境中需要存在 `bmcgo` 或 `bingo` 命令。检测到 `bmcgo` 时默认使用 `bmcgo` 并支持切换到 `bingo`；仅检测到 `bingo` 时直接使用 `bingo`。
### 选择机型和包型
可以通过以下任一方式进入出包流程：
- 在资源管理器的“快捷入口”中展开“openUBMC Studio Local View”，点击对应机型的出包入口，例如 `BMC/openUBMC 出包`。
- 打开产品 `manifest.yml`，点击目标 `tosupporte` 或 `manufacture` 包型上方的入口，例如 `default 出包入口`，直接进入该包型的出包页面。
通过“出包配置”页面或“快捷入口”进入时，按以下步骤选择包型：
1. 在“固件包类型选择”页面查看当前机型的所有包型。页面按照“To Support E”和“Manufacture”分组，显示包型名称、构建类型、包名和签名类型。
2. 可以在搜索框中按照包型名称、分类或包名筛选。
3. 在目标包型右侧点击“进入出包页”。无效包型会显示具体的配置错误，需要修改 `manifest.yml` 并刷新后再选择。
### 执行出包预检
1. 进入“固件出包”页面后，等待 openUBMC Studio 读取 Manifest、组件清单和构建环境。
2. 在“构建选择”区域选择构建类型。若 `manifest.yml` 已配置 `build_type`，构建类型不可修改。
3. 查看出包信息、构建命令预览和计划组件。组件来源默认折叠，可按需展开查看。
4. 如果“组件来源”中存在支持获取的缺失 SDK 制品，点击“从 Conan 获取”，完成后页面会自动重新加载出包信息。
5. 点击“一键预检”重新检查当前配置和环境。如果页面显示“预检阻断”，请根据提示保存 Manifest、信任工作空间、修复配置或补齐构建工具后再次预检。
### 执行出包任务
1. 预检通过后，点击页面顶部的“开始出包”。openUBMC Studio 会根据包型自动生成参数，并通过 Task 终端启动构建。
2. 任务启动后，页面会自动定位到“构建阶段”，依次展示“计划就绪”、“有效 manifest”、“依赖图就绪”和“产物就绪”状态。
3. 构建期间可以在 Task 终端查看实时输出，也可以在页面查看本次实际组件以及计划和实际配置之间的差异。
4. 如需停止构建，点击“终止任务”。关闭出包页面不会自动终止正在执行的任务，重新打开同一包型的出包入口可以继续查看当前会话。
### 查看日志和下载产物
1. 构建成功、失败或取消后，页面会自动定位到“构建日志”，并显示 `temp/log/task.log` 末尾最多 128KiB 的内容。
2. 构建失败时，可以点击“只看异常上下文”或“跳到最近异常”辅助定位问题；点击“打开完整 task.log”可以查看完整日志。
3. 构建成功后，在“本次新产物”区域根据包型查看本次构建生成的 HPM、发布 ZIP 等文件，点击“下载”并选择保存位置。Remote 工作空间中的产物也可以下载到本机。
4. 在“最近记录”区域查看当前工作区近期出包任务的状态、执行时间和产物数量。
> [!NOTE]说明：
> 日志中的异常高亮仅用于提供排查线索，不代表 openUBMC Studio 已经确定失败根因，请结合完整日志确认。
> “本次新产物”仅展示当前构建会话中新生成且校验通过的文件，不会将历史 `output` 目录中的文件作为本次结果。
# 十四、出包签名配置
openUBMC Studio 签名配置扩展（`bmcstudio_sign_config`）提供可视化的 HPM 签名档案管理、本地自签名证书生成和 EEPROM 签名配置。开发者可以在 CSR 出包和白牌包构建时复用签名档案，无需手动编辑 `.bmcgo/config` 中的 INI 配置。
## 选择出包签名档案
CSR 出包和白牌包构建页面均支持选择已有签名档案：
- **单 CSR 出包**：在出包窗口的签名档案下拉列表中选择档案。如果工作目录的 `.bmcgo/config` 中存在同名 INI 节，界面会显示配置冲突提示。
- **多 CSR 出包**：通过 QuickPick 选择签名档案。
- **白牌包构建**：在白牌定制编辑器的构建流程中选择签名档案。
如果没有可用档案，单击签名档案下拉列表旁的“新增签名档案”，进入签名配置界面。
## 管理 HPM 签名档案
HPM 签名档案用于保存签名方式、密钥路径和服务端参数，可以在多次出包任务之间复用。签名配置界面包含以下页签：
| 页签 | 说明 |
| --- | --- |
| 签名管理 | 新增、编辑和删除签名档案 |
| 证书生成 | 生成本地自签名所需的证书文件 |
| 证书吊销 | 吊销签名者证书并更新 CRL |
### 新增 HPM 签名档案
支持以下签名方式：
| 签名方式 | 说明 | 适用场景 |
| --- | --- | --- |
| 本地自签名 | 使用本地 OpenSSL 密钥签名 | 开发调试 |
| 简易签名服务器 | 通过 HTTP 请求签名服务器 | 内部 CI |
| 远程签名 | 通过 SignServer 远程签名 | 正式发布 |
不同签名方式需要配置以下字段：
| 签名方式 | 配置字段 |
| --- | --- |
| 本地自签名 | 根证书（DER）、吊销列表（CRL）、签名证书、时间戳证书、时间戳配置 |
| 简易签名服务器 | 根证书（DER）、证书标识符、签名服务器地址、TLS 验证方式 |
| 远程签名 | SignServer 地址、时间戳服务器地址、根证书（DER）、吊销列表（CRL）、Worker 路由标识、签名哈希算法、TLS 验证方式、Keyfactory 模式 |
1. 打开“签名管理”页签。
2. 单击“新增签名档案”。
3. 选择签名方式。
4. 填写对应的证书路径、密钥路径或服务端参数。
5. 单击“保存”。
> [!NOTE]说明：
> 保存时会自动检查密钥和证书文件是否存在。路径无效时，界面会显示错误并阻止保存。
### 编辑或删除 HPM 签名档案
- **编辑档案**：在档案列表中单击目标档案，修改配置后单击“保存”。
- **删除档案**：单击档案旁的“删除”，在确认窗口中继续操作。
## 创建本地自签名证书
首次使用本地自签名方式时，可以在“证书生成”页签中生成所需文件。该功能依赖 OpenSSL，请先执行 `openssl version`，确认系统已安装 OpenSSL。
需要填写以下信息：
| 字段 | 说明 |
| --- | --- |
| 输出目录 | 证书文件的生成目录 |
| 组织名（O） | 证书中的组织名称 |
| 根私钥保护密码 | PFX 根私钥的加密密码，不少于 12 个字符，可以通过“随机生成”创建 |
操作步骤如下：
1. 打开“证书生成”页签。
2. 填写输出目录、组织名和根私钥保护密码。
3. 根据需要填写国家、证书通用名称和各证书有效期。RSA 密钥长度固定为 4096 位。
4. 单击“一键生成全套证书”。
生成的文件如下：
| 文件 | 说明 |
| --- | --- |
| `rootca.pfx` | 包含私钥的根 CA 证书，采用 PKCS#12 格式 |
| `rootca.der` | DER 格式的根 CA 证书 |
| `rootca.crl` | 证书吊销列表 |
| `signer.pem` | 包含私钥的签名者证书 |
| `ts_signer.pem` | 时间戳签名者证书 |
| `tsa.cnf` | 时间戳配置文件 |
5. 将所需文件路径填写到本地自签名档案中。
> [!NOTE]说明：
> 签名档案使用 `rootca.der`、`rootca.crl`、`signer.pem`、`ts_signer.pem` 和 `tsa.cnf`。`rootca.pfx` 包含根 CA 私钥，仅在证书吊销时使用，不需要填写到签名档案中。
## 吊销签名者证书
签名私钥泄露时，可以在“证书吊销”页签中吊销签名者证书并更新 CRL。
| 字段 | 说明 |
| --- | --- |
| 证书目录 | 包含 `rootca.pfx` 和 `rootca.crl` 的目录 |
| 根私钥保护密码 | 生成证书时设置的 PFX 密码 |
| 签名者证书 | 需要吊销的 `signer.pem` 文件路径 |
1. 打开“证书吊销”页签。
2. 填写证书目录、根私钥保护密码和签名者证书路径。
3. 单击“吊销并更新 CRL”。
> [!WARNING]注意：
> 证书吊销不可逆。吊销后，签名者证书会写入 CRL，继续使用该证书签名 HPM 包将失败。如需继续签名，请创建新的签名者证书。
## 管理 EEPROM 签名档案
EEPROM 签名与 HPM 签名是两条独立链路。HPM 签名使用 CMS 对固件包外层进行签名，EEPROM 签名使用 ECDSA P-256/SHA-256 对写入 EEPROM 的原始二进制内容进行签名。CSR 出包时可以分别配置两类签名。
CSR 出包页面中的 HPM 签名和 EEPROM 签名分别使用独立的下拉列表。选择“使用现有配置”可以保留当前配置；单击 EEPROM 下拉列表旁的“新增签名档案”可以打开 EEPROM 签名配置页面。
EEPROM 签名档案支持以下签名方式：
| 签名方式 | 说明 |
| --- | --- |
| 本地自签名 | 使用本地 ECC 密钥签名 |
| 简易签名服务器 | 通过 HTTP 请求签名服务器 |
| 远程 ECC 签名 | 通过 SignServer 远程签名 |
> [!NOTE]说明：
> EEPROM 签名档案与 HPM 签名档案独立管理，互不影响。
## 常见问题
- **保存时提示路径不存在**：检查密钥和证书文件路径。签名配置界面会在保存时验证文件是否存在。
- **出包时提示全局配置冲突**：工作目录的 `.bmcgo/config` 中存在同名 INI 节。请确认是否使用签名档案覆盖已有配置。
- **证书生成失败**：执行 `openssl version`，确认 OpenSSL 已安装并已加入 `PATH`。
# 十五、常用操作
## 快捷键参考
openUBMC Studio提供了丰富的快捷键支持，帮助开发者提高工作效率：
| 功能 | 快捷键 | 说明 |
|------|--------|------|
| 转到定义 | `Ctrl + 点击` 或 `F12` | 跳转到符号的定义位置 |
| 转到引用 | `Shift + F12` | 查看符号的所有引用位置 |
| 查找 | `Ctrl + F` | 在当前文件中查找 |
| 全局搜索 | `Ctrl + Shift + F` | 在整个项目中搜索 |
| 保存 | `Ctrl + S` | 保存当前文件 |
| 全部保存 | `Ctrl + Shift + S` | 保存所有打开的文件 |
| 撤销 | `Ctrl + Z` | 撤销上一步操作 |
| 重做 | `Ctrl + Y` | 重做上一步操作 |
| 快速打开文件 | `Ctrl + P` | 快速打开项目中的文件 |
| 命令面板 | `Ctrl + Shift + P` | 打开命令面板，执行各种命令 |
| 切换侧边栏 | `Ctrl + B` | 显示/隐藏侧边栏 |
> [!NOTE]说明：
> 可以在“文件”>“首选项”>“键盘快捷方式”中查看和自定义所有快捷键。
## 设置与配置
### 修改用户设置
1. 点击菜单栏“文件”>“首选项”>“设置”，或使用快捷键 `Ctrl + ,`
2. 在设置页面中，可以修改各类配置：
- 编辑器设置（字体、主题、缩进等）
- CSR规则检查设置
- 快捷键配置
- 扩展设置
# 十六、卸载 openUBMC Studio
如果您不再需要使用openUBMC Studio，可以通过以下步骤卸载。
## Windows系统卸载
1. 打开“控制面板”>“程序”>“程序和功能”
2. 在程序列表中找到“openUBMC Studio”
3. 右键点击，选择“卸载”
4. 按照卸载向导提示完成卸载
## 卸载后清理
> [!NOTE]说明：
> 卸载程序不会删除用户配置文件和工作空间数据，如需完全清理，请手动删除以下目录：
>
> - 用户数据目录：`%APPDATA%\.bmc-Studio`
> - 远程连接服务目录：`~/.bmcstudio-server`
>
> **注意**：
> 删除配置目录和工作空间数据是不可逆操作，请确保已备份重要数据后再执行删除。
---
# openUBMC Studio使用指导
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bmc_studio/user_guide/bmc_studio_usage_instructions.html
> Language: zh
BMC Studio 是一款可视化的配置工具，用于辅助 BMC 进行灵活定制。支持配置 CSR、资源协作接口、MDS、接口映射，同时也支持在线调试、板卡定制、原生开发、接口定制以及一键出包等功能。
# 简介
BMC Studio分为“开发任务”和“操作模块”两个板块，您可以在首页单击“切换视图”进行切换。
- 操作模块
- **CSR配置**：CSR描述了板卡上的具体组成结构，包括链路拓扑和器件描述信息，记录板卡的静态硬件信息。
- **资源协作接口配置**：支持从系统视角对BMC软件管理功能的抽象定义，包含接口和路径的定义，先定义接口，再使用路径实现这个接口。
- **MDS配置**：APP的模型描述文件，定义APP如何管理资源协作接口和具体存在的私有属性。
- **接口映射配置**：支持定义接口请求与资源协作接口的对应关系、接口及属性的校验信息、属性执行映射的前置与后置处理等。
- 开发任务
- **板卡定制**：支持对新增的板卡器件进行定义以及对已有板卡的器件适配。
- **原生开发**：支持开发新的APP功能。
- **接口定制**：支持定制北向接口和对Redfish、WebREST、CLI、SNMP接口映射配置的新增、修改和删除。
- **编译构建**：上传工具生成的CSR文件，对接编译服务器，实现一键编译出包。
- **仿真验证**：支持管理Qemu设备和BMC设备，并提供了在线调试接口和查询数据库的功能。
# 安装与启用 BMC Studio
## 环境准备
- BMC Studio 需要在 Ubuntu24 环境上运行，使用前须先搭建环境，请用户根据使用的操作系统，参考“环境准备”对应章节进行环境搭建。例如：本地使用 Windows 开发环境，请参考“Windows 开发环境搭建”。
> [!NOTE]说明：
> 如果本地环境已搭建完成，可跳过此操作。
- 操作过程中需要使用 git 和 bingo 工具，请确保本地已安装。
## 运行环境
操作系统：Ubuntu 24.04。
## 安装方式
本文提供三种安装 BMC Studio 的方式：“自动升级与安装”、“通过 apt 源手动安装仓颉工具链和 BMC Studio”、“通过应用市场安装”。
### 自动升级与安装
目前通过 manifest 初始化工作环境时，会自动安装 BMC Studio。
如果本地已存在 BMC Studio 工具，可执行以下命令将工具升级到最新版本。
```bash
bingo upgrade
```
### 通过 apt 源手动安装仓颉工具链和 BMC Studio
1. 执行以下命令检查本地是否已配置 apt 源：
```bash
sudo apt update
apt policy openubmc-bingo
```
- 如果出现以下输出，表示 apt 源已配置完成，可直接执行步骤 5。
- 如果未出现以下输出，表示未配置 apt 源，请执行步骤 2-步骤 5。
```bash
openubmc-bingo:
Installed: 0.0.1
Candidate: 0.0.1
Version table:
0.0.1 500
500 https://openubmc-apt-repo.obs.cn-north-4.myhuaweicloud.com/Ubuntu noble/main amd64 Packages
```
2. 下载 GPG 公钥
1. 安装 gnupg。
```bash
sudo apt update && sudo apt install gnupg
```
2. 安装 GPG 公钥。
- （方式一）直接下载 GPG 文件安装
1. 指定下载公钥的位置。
```bash
sudo mkdir -p /etc/apt/keyrings
```
2. 下载 GPG 文件。
```bash
wget -O- https://openubmc-apt-repo.obs.cn-north-4.myhuaweicloud.com/Ubuntu/gpg_key.public | sudo gpg --dearmor -o /etc/apt/keyrings/openubmc.gpg
```
- （方式二）通过公钥服务器下载
1. 指定下载公钥的位置。
```bash
sudo mkdir -p /etc/apt/keyrings
```
2. 下载 GPG 文件。
```bash
gpg --keyserver keyserver.ubuntu.com --recv-keys BF3B2D407FDEDEA0DC91CC9412640FBCB175287A
gpg --export BF3B2D407FDEDEA0DC91CC9412640FBCB175287A | sudo tee /etc/apt/keyrings/openubmc.gpg >/dev/null
```
3. 配置 apt 源。
```bash
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/openubmc.gpg] https://openubmc-apt-repo.obs.cn-north-4.myhuaweicloud.com/Ubuntu/ noble main" | sudo tee /etc/apt/sources.list.d/openubmc.list
```
4. 验证APT配置。
```bash
sudo apt update
apt policy bmc-studio
```
5. 安装仓颉依赖包和 BMC-Studio deb 包。
```bash
apt remove bmc-studio
apt install cangjie-runtime
apt install bmc-studio
```
### 通过应用市场安装
1. 进入 [openUBMC应用市场](https://openubmc.cn/marketplace)，在“开发工具”模块下。选择“BMC Studio”。
2. 在 BMC Studio 下载页面，单击右侧“立即下载”按钮，将 BMC Studio 软件包下载到本地。
3. 根据该页面的安装指引安装 BMC Studio 即可。
## 启动 BMC Studio
- 如果您有 BMC Studio 插件，直接点击插件即可在 VS Code 中启动 BMC Studio。
- 如果您有 bingo，执行以下命令，即可启动 BMC Studio。（此方法需要 bingo 版本大于等于0.5.238）
```bash
bingo studio
```
- 如果您使用的是 wsl 系统，可以直接在浏览器中看到 BMC Studio 的前端页面。
- 如果您使用的不是 wsl 系统，需要在浏览器中手动输入后端日志显示的该地址（视您的系统环境而定）
- 如果您想使用 BMC Studio 本身的启动方式，请参考以下命令。
```bash
/usr/share/bmc_studio/bmc_studio.sh start
/usr/share/bmc_studio/bmc_studio.sh start backend（后台启动）
```
## 常用命令
- 通过 bingo 执行的常用命令：
- 启动 BMC Studio：
```bash
bingo studio
```
- 停止 BMC Studio：
```bash
bingo studio -stop
```
- 重启 BMC Studio：
```bash
bingo studio -restart
```
- 通过 BMC Studio 执行的常用命令：
- 启动 BMC Studio：
```bash
/usr/share/bmc_studio/bmc_studio.sh start
/usr/share/bmc_studio/bmc_studio.sh start backend（后台启动）
```
- 停止 BMC Studio：
```bash
/usr/share/bmc_studio/bmc_studio.sh stop
```
- 重启 BMC Studio：
```bash
/usr/share/bmc_studio/bmc_studio.sh restart
```
# 安装与使用BMC Studio 插件
## 使用前准备
- 进入[openUBMC应用市场](https://openubmc.cn/marketplace)，在“开发工具”模块中下载 BMC Studio 安装包（`.zip`格式），并将下载的安装包解压，获得`.vsix`文件。
- 确保本地已安装 VS Code(全称：Visual Studio Code，以下简称：VS Code)，且已经通过 Remote 插件连接到开发使用的 Ubuntu/docker 环境。
## 环境要求
BMC Studio 需要在 Ubuntu24 环境上运行，使用前须先搭建环境，请用户根据使用的操作系统，参考“环境准备”对应章节进行环境搭建。例如：本地使用 Windows 开发环境，请参考“Windows开发环境搭建”。
## 安装插件
- 通过 VS Code 安装插件。
1. 打开 VS Code，参考下图步骤操作。
2. 选择`.vsix`文件存放路径，安装插件。
> [!NOTE]说明：
> 选择前，请先确定`.vsix`文件存放的操作系统，Windows 或 wsl。
3. 安装完成后重启 VS Code 生效。
- 在 WLS 开发环境中安装插件。
根据实际情况在 Ubuntu 或 Linux 环境下，执行以下命令进行安装（“xxxxxx”表示`.vsix`文件的存放路径）。
```bash
code --install-extension xxxxxx
```
## 安装和使用工具
1. 在 VS Code 打开已安装的 BMC Studio 的插件。
2. 插件将会自动对环境进行检测，查询是否安装 BMC Studio 和 Qemu。
- 如果检测到环境中未安装工具，请执行以下步骤3~步骤7安装和启动。
- 如果检测到环境中已安装工具，插件将会自动启动 BMC Studio。
> [!NOTE]说明：
> 如果当前安装的工具非最新版本，您可以单击界面上的“一键更新”升级工具版本，也可以直接使用当前的旧版本。
3. 单击“一键安装工具”，弹出“使用协议”相关弹框。
4. 勾选“同意《BMC软件许可协议》协议”，单击“继续安装”。插件将开始下载并安装您缺失的工具和依赖。安装时间根据网络情况，预计在1~10分钟不等。
5. （可选）如果下载时间过长，您可以在 VS Code 上方导航栏中选择“终端 > 新建终端”，在新建的终端中选择“输出”，右侧下拉框选择“Debug Logs”，打开日志查看是否报错，如果存在报错，请根据日志的实际情况处理。
6. 安装成功后“一键安装工具”的按钮变为“开始使用”。
7. 单击“开始使用”，即可启动 BMC Studio。
## 插件实时模型检查
BMC Studio 启动后，在 VS Code 中编辑 CSR 文件或任意 BMC Studio 工作空间内的 MDS、资源协作接口、映射接口文件，保存后会触发插件进行模型检查。检查完成后，在控制台窗口会显示检查结果，查看检查结果操作如下：
## 插件双屏显示
BMC Studio 插件支持双屏查看文件的能力。在打开一个 .sr 或 .json文件后，vscode 右上角会出现这个图标。点击该图标，即可启动 BMC Studio 双屏模式。
双屏模式中，插件会使用 BMC Studio 打开该 .sr 或 .json 文件，然后展示在插件页面里。
## 插件在线调试
前置条件：
- BMC Studio 版本不低于1.2.0。
- BMC Studio 插件版本不低于0.0.5。
- Qemu 已安装。
开发环境初始化过程会安装 Qemu，无需手动安装。
在线调试：
在线调试的具体流程，请参考Qemu设备管理使用指南。
## 卸载插件
安装了插件后，可以在 vscode 的扩展页面的“已安装”一栏中看到 BMC Studio 插件。按图中顺序点击。
点击图中的“卸载”按钮即可完成卸载。
# 仓库部署
以下视频介绍了BMC Studio 仓库部署操作指导，通过该视频您可以详细了解仓库部署的具体步骤，从而有效提升BMC Studio的部署效率。
# 配置工作空间
首次使用BMC Studio，必须配置默认空间，如果未配置则无法进入系统。
## 默认空间配置
> **说明**：
> 默认工作空间配置完成后，暂不支持删除，支持切换。
1. 首次登录BMC Studio，界面提示配置默认空间。
2. 根据实际需求配置默认空间。
- 空间名称：填写工作空间的名称，要求如下：
- 支持数字、字母、下划线和点号（.），且必须包含数字或字母。
- 工作空间名称设定后不支持修改。
- 工作空间的名称不能重复，建议用产品名称命名。
- 数据导入方式：请根据实际情况，选择数据导入的方式。
- 如果选择“导入Manifest”：则通过Manifest来初始化空间数据。
- 如果选择“指定文件路径”：则导入本地开发环境的数据作为空间数据进行管理。
- 如果选择“自定义”：则需要手动上传一个文件夹或 zip 压缩包作为初始化的工作空间数据。
- Git地址：请输入Manifest的git仓库地址。
- 远端分支名称：请选择待开发产品对应的Manifest分支。
- 指定文件路径：“数据导入方式”选择“指定文件路径”时必填。请输入本地开发环境的数据所在的路径。例如：`/usr/share/bmc_studio/server/users/xxxxx/oem_files`。
- 一键迁移：数据导入方式”选择“指定文件路径”时支持此勾选项。如果勾选，则表示将指定路径下的工作数据无损迁移到BMC Studio工作空间进行管理。
3. 填写完毕后，单击“确认”，完成配置。
## 新建工作空间
新建的工作空间可用于管理不同系列化产品，空间之间的数据相互独立。最多支持创建10个（包含默认工作空间）。
1. 在BMC Studio首页，单击右上角工作空间按钮。
2. 选择“新建工作空间”。
3. 根据实际需求配置空间信息，详细参数可参考“配置默认空间”中的参数说明。
4. 填写完毕后，单击“确认”。
5. 根据弹框提示，选择跳转到新的工作空间。
6. 单击右上角“仓库管理”按钮进入仓库。
7. 选择产品名称，为新的工作空间指定产品。
8. 单击“一键仓库部署”拉取对应产品的代码仓库到创建的工作空间内。
> **说明**：
> 新建的工作空间如果未执行“一键仓库部署”，模型文件将显示不存在。
> 执行一键仓库部署需要有仓库权限。
## 切换工作空间
支持工作空间相互切换。
> **说明**：
切换工作空间不会删除工作空间内的数据。
工具拉取代码和执行模型检查时，不支持切换工作空间。
切换工作空间成功后，工具的所有操作都是基于新工作空间的数据。
切换工作空间不会删除切换前和切换后工作空间的数据。
1. 在BMC Studio首页，单击右上角工作空间名称。
2. 选择需要切换的工作空间。
3. 单击“切换到此空间”。提示“操作成功”表示空间切换成功。
## 删除工作空间
最多支持创建10个工作空间，如果达到创建上限，则需要删除已有的工作空间，才可继续创建。
> **说明**：
默认工作空间不支持删除。
工具拉取代码和执行模型检查时，不支持删除工作空间。
删除工作空间会解除工具与工作目录的关系。
如果删除正在使用的工作空间，删除成功后将自动切换到默认工作空间。
1. 在BMC Studio首页，单击右上角工作空间名称。
2. 选择需要删除的工作空间。
3. 单击“删除此空间”，弹出删除确认的提示框，请确认后操作。
- 确认删除操作，请单击“确认”。如果勾选“同步删除工作空间数据”，删除成功后数据无法恢复，请谨慎操作。
- 取消删除操作，请单击“取消”。
4. 确认后，完成删除工作空间操作。
# 操作模块
## 配置CSR模块
CSR描述了硬件板卡的物理组成结构，包括链路拓扑和器件描述信息。将一个可独立更换的Fru抽象为板卡（组件和部件），为每一个板卡都定义一个CSR描述文件，在运行过程中由BMC系统自动发现和解析。
> **说明**：
> 支持查看文件代码和比对代码修改前后数据，具体操作方法请参考[代码预览](#代码预览)和[查看修改](#查看修改)章节。
### 修改模型
1. 在BMC Studio选择操作模块的首页，选择CSR。
2. 进入CSR模型界面，工具会自动识别产品空间中的CSR仓库。
3. 在CSR列表中，选择需要操作的模型。
4. 搭建模型。
5. 修改完毕后，单击“保存”。
### 新增组件仓
1. 在BMC Studio选择操作模块的首页，选择CSR。
2. 点击图中所示的加号按钮。
3. 选择需要上传的文件夹，然后点击右下角的“打开”。
### 新增文件夹
1. 在BMC Studio选择操作模块的首页，选择CSR。
2. 在CSR列表中，选择需要新增文件夹的目标文件夹。
3. 单击目标文件夹后的“操作”。例如：需要在vpd文件夹下新增文件夹，请单击vpd后的“操作”按钮。
4. 选择“新增文件夹”。
5. 输入文件夹名称，完成新建操作。
> **说明**：
> 名称仅支持数字、字母和下划线。
### 新增组件
目前提供三种方式新增组件。
#### 手动新增
1. 在BMC Studio选择操作模块的首页，选择CSR。
2. 在CSR列表中，选择需要新增组件的目标文件夹。
3. 单击目标文件夹后的“操作”。例如：需要在src文件夹下新增组件，请单击src后的“操作”按钮。
4. 选择“新增组件”。
5. 填写组件名称、格式版本和数据版本。数据版本和格式版本要求为A.BC的格式校验，A、B、C均为0-255的数字（不能有前导零）。
6. 填写完毕后，单击“保存”。
#### 上传组件
1. 在BMC Studio选择操作模块的首页，选择CSR。
2. 在CSR列表中，选择需要新增组件的目标文件。
3. 单击目标文件夹后的“操作”。例如：需要在src文件夹下新增组件，请单击src后的“导入本地sr文件”按钮。
4. 选择需要上传的sr文件，并点击“打开”
#### 复制CSR
1. 在BMC Studio选择操作模块的首页，选择CSR。
2. 在CSR列表中，选择需要复制的目标文件。
3. 单击目标文件后的“操作”，然后点击复制按钮。
4. 选择您要将 CSR 复制过去的文件夹，点击文件名后的“操作”，然后点击粘贴按钮。
### 删除组件
支持撤销删除操作，具体操作方法方法请参考“常用操作”章节中的[撤销删除文件和撤销修改](#撤销删除文件和撤销修改)。
1. 在CSR列表中，选择需要删除的文件、模型或组件，单击“操作”。
2. 选择“删除”。
3. 工具弹出确认删除的提示框，请根据情况选择。
- 确认删除，请单击“确认”。
- 取消删除，请单击“取消”。
### CSR页面检查
以下视频介绍了 BMC Studio 的 CSR 页面模型检查操作指导，通过该视频您可以详细了解 CSR 模型检查的具体步骤，模型检查可以检查出模型之间不一致的错误，并给出告警提示。
### 同步代码
通过Git命令，将CSR配置提交到代码仓。
1. 选择要同步代码的主文件夹，单击“操作”。
2. 选择“同步代码”。
3. 如果提示“代码同步成功”，表示同步代码操作成功。
> **说明**：
> 如果弹出“代码同步失败”，提示“检测到待同步数据与工具本地数据存在冲突，请通过其它工具解决冲突。
> 您也可以执行强制覆盖操作，此操作不可逆，存在数据丢失的风险”。建议先通过其他工具解决冲突，再执行代码同步。
### 适配板卡
适配板卡具体操作流程，请参见[板卡适配指南](#板卡适配指南)。
### CSR出包
支持单个和批量打包CSR。
> **说明**：
> 批量生成时仅支持下载为HPM包格式。
> 选择的CSR文件中，必须包含UID，且批量出包中的UID不能重复。
#### 单个CSR打包
1. 模型配置完成后，单击页面右上角“CSR出包”。
2. 参考以下内容，填写出包信息。
- **FormatVersion**：填写Format的版本。
- **DataVersion**：填写Data的版本。
- **EEPROM大小限制**：选择16k或32k。
- **OEM定制信息**：选填项，请根据情况选择是否上传 OEM 定制信息。上传要求格式为.bin 和 .ini，大小不超过4KB。
- **下载选项**：勾选下载生成的格式，可同时勾选多个。支持hpm、二进制bin、json文件。
3. 单击“CSR出包”。生成的CSR将自动下载到本地。如果通过SSH连接了BMC 真机，则还可以选择“出包并升级到BMC”将出的包直接生效到真机环境。
#### 批量CSR打包
批量生成时仅支持下载为HPM包格式。
1. 在CSR列表右上方单击“批量CSR出包”。
2. 勾选需要出包的文件，单击CSR出包。
3. 参考以下内容，填写出包信息。
- **OEM共享文件**：上传的OEM文件可用于全部CSR出包使用。
- **EEPROM大小限制**：选择16k或32k。
- **OEM文件**：为对应的CSR上传OEM文件，上传要求格式为.bin 和 .ini，大小不超过4KB。
- **使用共享文件**：如果勾选，表示携带“OEM共享文件”中上传的文件。如果不勾选，表示不携带“OEM共享文件”中上传的文件直接携带本文件选择的对应“OEM文件”。
- **删除**：删除对应的CSR文件。
4. 单击“批量CSR出包”。
> **说明**：
> “出包并升级到BMC”功能需要您有真实服务器，并且通过BMC Studio连接到这台机器才能使用，可以将出完的包直接生效到环境中。
### 生效到 QEMU
在连接到 Qemu 后，可以将文件直接生成到 Qemu 环境。
在点击了按钮后，可以选择生效方式。
BMC Studio 会把该文件以对应的方式生效到 Qemu。
## 配置资源协作接口
资源协作接口即为从系统视角对BMC软件管理功能的抽象定义。资源协作接口包含对象和接口的定义，接口以bmc.kepler开头。
> **说明**：
> 支持查看文件代码和比对代码修改前后数据，具体操作方法请参考[代码预览](#代码预览)和[查看修改](#查看修改)章节。
### 修改资源协作接口/路径信息
> **说明**：
> 配置资源协作接口的基本信息时，属性、方法和信号要求至少配置一个。
1. 选择需要操作的资源协作接口/路径。
2. 修改资源协作接口的配置。
3. 修改资源协作接口路径的配置。
4. 修改完毕后，单击“保存”，完成修改。
### 新增文件夹
1. 选择需要新增文件夹类型，路径或接口。
2. 在资源协作接口列表中，选择需要新增文件夹的目标文件。
3. 单击目标文件夹后的“操作”。以新增路径文件举例，例如：需要在Accessor文件夹下新增文件夹，请单击Accessor后的“操作”按钮。
4. 选择“新增文件夹”。
5. 输入文件夹名称，完成新建操作。
> **说明**：
> 名称仅支持数字、字母和下划线，且要求不能以数字开头。
### 新增资源协作接口/路径
1. 在资源协作接口列表中选择新增的类型：接口/路径。
2. 在资源协作接口的列表中，选择需要新增接口或路径的目标文件。
3. 单击目标文件夹后的“操作”。例如：需要在kepler文件夹下新增资源协作接口，请单击kepler后的“操作”按钮。
4. 选择“新增资源协作接口”。
5. 参考“修改资源协作接口/路径信息”中的参数列表。配置资源协作接口/路径。
6. 配置完成后，单击“保存”。
### 检查
1. 在资源协作接口/路径列表中，选择需要检查的文件，单击“操作”。
2. 选择“检查”，工具开始检查所选文件的模型一致性。
3. 检查完成后，单击“检查结果”可查看详情。界面展示“错误提示”、“错误影响”和“修复建议”。
### 删除资源协作接口/路径
支持撤销删除操作，具体操作方法请参考[撤销删除文件和撤销修改](#撤销删除文件和撤销修改)。
1. 在资源协作接口/路径列表中，选择需要删除的文件，单击“操作”。
2. 选择“删除”。
3. 工具弹出确认删除的提示框，请根据情况选择。
- 确认删除，请单击“确认”。
- 取消删除，请单击“取消”。
## 配置MDS
MDS是APP的模型描述文件，定义了该APP管理的资源协作接口和私有属性。
> **说明**：
> 支持查看文件代码和比对代码修改前后数据，具体操作方法请参考[代码预览](#代码预览)和[查看修改](#查看修改)章节。
### 修改MDS信息
> **说明**：
> 信息填写完毕后，未保存当前页面信息，切换页面时会清空当前页面编辑的全部内容，请谨慎操作。
1. 选择需要操作的文件。
2. 修改配置信息。
3. 修改完毕后，单击“保存”，完成修改。
### 检查
1. 在MDS列表中，选择需要检查的文件，单击“操作”。
2. 选择“检查”，工具开始检查所选文件的模型一致性。
3. 检查完成后，单击“检查结果”可查看详情，界面展示“错误提示”、“错误影响”和“修复建议”。
### 同步代码
通过Git命令，将MDS配置提交到代码仓。
1. 选择要同步代码的主文件夹，单击“操作”。
2. 选择“同步代码”。
3. 如果提示“代码同步成功”，表示同步代码操作成功。
> **说明**：
> 如果弹出“代码同步失败”，提示“检测到待同步数据与工具本地数据存在冲突，请通过其它工具解决冲突。
> 您也可以执行强制覆盖操作，此操作不可逆，存在数据丢失的风险”。建议先通过其他工具解决冲突，再执行代码同步。
### 删除MDS文件
1. 在MDS列表中，选择需要删除的文件，单击“操作”。
2. 选择“删除”。
3. 工具弹出确认删除的提示框，请根据情况选择。
## 配置接口映射
使用Redfish/WebREST/SNMP/CLI的设计，引入数据映射器机制，框架解析数据映射配置，将接口请求转发到资源协作接口，拼装返回对应格式的数据。
映射配置定义了如下内容：
* 接口请求与资源协作接口的对应关系。
* 接口及属性的校验信息。
* 属性执行映射的前置与后置处理等。
### 新增文件夹
1. 选择需要新增的接口类型：Redfish、WebREST、CLI或SNMP。
2. 在文件列表中，选择需要新增文件的目标文件夹。
3. 单击目标文件后的“操作”。例如：需要在Accounts文件夹下新增文件夹，请单击Accounts后的“操作”按钮。
4. 输入文件夹名称，完成新建操作。名称仅支持数字、字母、下划线和中划线，且要求不能以数字开头。
### 新增接口映射
1. 选择需要新增的接口类型：Redfish、WebREST、CLI或SNMP。
2. 在文件列表中，选择需要新增接口映射的目标文件夹。
3. 单击目标文件后的“操作”。例如：需要在Accounts文件夹下新增接口映射，请单击Accounts后的“操作”按钮。
4. 选择“新增接口映射”。
5. 输入接口名称。名称仅支持数字、字母、下划线和中划线，且要求不能以数字开头。
6. 单击“新增资源”，输入URI资源。
7. 单击“确认”接口新增成功。
8. 配置接口信息。
### 检查
1. 在接口文件或文件夹中，选择需要检查的文件，单击“操作”。
2. 选择“检查”，工具开始检查所选文件的模型一致性。
3. 检查完成后，单击“检查结果”可查看详情。界面展示“错误提示”、“错误影响”和“修复建议”。
### 删除接口文件
支持撤销删除操作，具体操作方法请参考撤销删除文件和撤销修改。
1. 在接口文件列表中，选择需要删除的文件，单击“操作”。
2. 选择“删除”。
3. 工具弹出确认删除的提示框，请根据情况选择。
# 开发任务
## 板卡定制
板卡定制，分为以下两种情况。
- 板卡新增：定制新的板卡时，对新的器件进行定义，对新增板卡定制前，请先执行以下操作。
1. 在原生开发定义资源协作接口和路径，操作方法请参考：操作模块 >资源协作接口配置。
2. MDS里进行管理定义的资源协作接口。
3. 打开对应的CSR开关。
- 板卡适配：基于已有器件库，对硬件组件进行定制，包含对组件上器件类型、数量的编排等操作。
### 定义新器件操作流程（板卡新增）
1. 在BMC Studio首页，单击“板卡定制”，进入定制板卡操作界面。
2. 请按照如下流程新增器件，操作方法参见[配置CSR模型](#配置csr模块)章节。
1. （可选）新增CSR模型文件夹。
2. 新增CSR组件。
3. 配置模型数据。
4. 保存配置。
3. 单击“保存”完成配置。
### 定制硬件组件（板卡适配）
板卡适配详细操作可参见BMC Studio板卡适配指南，也就是[板卡适配指南](#板卡适配指南)。
## 原生开发
使用原生开发功能开发新的APP。
1. 在BMC Studio首页，单击“原生开发”，进入原生开发操作界面。
2. 为板卡定义资源协作接口信息。请按照如下流程配置，具体操作方法参见[配置资源协作接口](#配置资源协作接口)章节。
1. （可选）新增资源协作接口文件夹。
2. 新增资源协作接口。
3. 新增资源协作接口路径。
4. 保存配置。
3. 在原生开发的导航条上，单击“MDS”。
4. 为板卡配置MDS信息。具体操作方法参见[配置MDS](#配置mds)。
5. 配置完成后，单击“保存”。
## 接口定制
可使用BMC Studio定制北向接口，包含对Redfish、WebREST、CLI、SNMP接口映射配置的新增、修改和删除，具体操作方法，请参考[配置接口映射](#配置接口映射)。
## 编译构建
BMC Studio的工作空间包含多个代码仓，这些代码仓可能被本地管理或被设置为Git工作空间。用户可通过页面配置Git仓地址，将代码同步到工作空间。工具也会自动扫描工作空间，识别出Git仓，并在仓库管理页面展示。
> **说明**：
> 选择Manifest产品后，才可进行仓库初始化操作。仓库完成初始化操作后，才可获取代码。
1. 参考以下内容选择出包信息。
- **一键出包**：基于该产品空间的本地代码一键出包。仅root用户支持一键出包。
- **Git仓库地址**：工作空间中的Git代码仓。
- **本地分支名称**：默认取值为导入Manifest时选择的远端分支，可手动切换分支。
- **同步远端最新配置**：本地分支选择后，单击此按钮进行切换。说明：切换本地分支时将同步最新的远端代码。切换分支时，要求本地代码和Manifest的库上最新代码不能存在冲突，如果存在冲突，请手动解决冲突后再切换分支。
- **产品名称**：选择分支对应的产品名称，切换产品后需重新进行仓库部署。如果该产品已执行过一键仓库部署，则无须再重新进行仓库部署。
- **一键仓库部署**：根据Manifest中产品的配置信息，动态获取仓库配置并完成全量仓库代码的获取。
- 如果有代码变动，会弹框提示是否覆盖代码，
- 如果代码未变动，不会提示覆盖代码，但会做代码检查。
- **获取全量代码**：一键拉取全量仓库代码到对应的分支。支持编辑个人远端地址和个人远端分支。
2. 单击“一键出包”，选择对应产品。
3. 在组件列表勾选需要出包的组件。
4. 单击“下一步：出包”，出包会显示进度条，出包成功之前请勿执行其他操作。
> **说明**：
> 一键仓库部署和获取全量代码只能拉取有权限的仓库，只要有一个组件仓库拉取成功，则表示操作成功，未能成功拉取的仓库可查看“仓库日志”确认原因。
> 如果出包失败，仓库管理右侧的“构建日志”列会展示出包失败的日志，可下载全量日志到本地进行分析。
> 如果出包成功，仓库管理右侧的“固件信息”列会展示出包信息，单击“下载”将固件包下载到本地。
> 固件包仅保留三天，失效后将无法下载。
> “一键仓库部署”和“获取全量代码”的日志将展示在仓库日志中。
# BMC Studio SSH 连接功能操作
本章节主要介绍如何使用BMC Studio SSH的连接功能。
## 使用前准备
- 软件：请安装最新版本的BMC Studio工具。
- 硬件：请准备一台可远程访问的服务器，并提前获取服务器的IP地址、端口号、用户名和登录密码。
## 使用须知
- BMC Studio仅支持保持一个活跃连接，如果新建SSH连接或重新连接另一个设备，之前的会话将会被断开。
- 为确保设备信息安全，离开设备时，请主动断开连接。
## 创建SSH连接
1. 在BMC Studio首页，单击右上角第一个图标“仿真管理”按钮，进入“接入设备管理”界面。
2. 在“BMC设备管理”区域单击“+新建设备”。
3. 填写设备的IP地址、端口、用户名和密码。
4. 单击“确定”，完成设备认证。认证成功后，新建的设备会展示在BMC设备管理区域下。
## 连接管理
### 重新连接会话
1. 在“BMC设备管理”区域下的设备列表中，选择需要重新连接的会话。
2. 确认设备处于未连接状态，操作列将展示“连接”和“删除”。
3. 单击“连接”按钮，输入对应设备的密码。
> **说明**：
> 基于安全考虑，BMC Studio不会自动保存设备密码，涉及密码处均须手动输入确认。
### 断开当前连接
1. 在“BMC设备管理”区域下的设备列表中，选择需要断开连接的会话。
2. 确认设备处于连接状态，操作列将展示“取消连接”和“删除”。
3. 单击“取消连接”按钮，等待“取消连接”按钮变为“连接”时，断开成功。
### 删除设备配置
1. 在“BMC设备管理”区域下的设备列表中，选择需要删除的会话。
2. 单击“删除”按钮，删除成功后会清除当前设备的全部缓存信息。
## 连接状态说明
- **绿灯**：表示设备已连接，可执行断开或发送命令操作。
- **灰标**：表示设备未连接，可执行新建连接或重新连接操作。
# 板卡适配指南
本章节主要介绍如何适配板卡。
## 使用前准备
- 已安装bingo工具。
- BMC Studio工具能正常启动。
- 已创建工作空间并进行一键仓库部署或手动导入业务组件的`MDS`文件、`vpd`、`mdb_interface`和`rackmount`代码仓到工作空间。
## 拓扑视图化
当前将CSR页面划分为“管理视图”，“业务视图”和“告警事件”三大板块，大大提升了配置页面的易用性。
## 板卡适配
1. 在BMC Studio首页，选择CSR，进入CSR配置界面。
2. 在vpd仓库进入`vendor/Huawei/Server/Kunpeng/openUBMC`路径，选择`root.sr`文件。
3. 将LM75芯片拖拽到I2c_8上。
4. 拖拽完成后，单击M75芯片上方的扳手图标，配置参数，鼠标停在对应字段的"?"图标上即可查看字段类型和描述。
- 配置基本信息：填写“器件别名”,并自定义`properties`中的`Address`、`AddrWidth`、`OffsetWidth`参数。
- 配置传感器读数：按照属性进行配置，选择`Scanner`，配置“名称”、“偏移”、“长度”、“掩码”、“扫描周期”，配置完成后，单击“操作”列下的“保存”按钮。
5. 选择业务视图，进入软件对象配置页面。
6. 单击左上角“+新增”按钮，弹出“新增功能器件”窗口。
7. 搜索`Entity`，并进行配置。
8. 新增`ThresholdSensor`进行配置。
- 对于需要使用动态应用的场景，在下拉框中选择动态引用，并关联到对应的对象。
- 对于需要使用数据同步的场景，在下拉框中选择数据同步，并关联到对应`Scanner`的`value`值。
9. 配置完成后，在管理视图中单击“查看代码”，即可查看新增CSR配置的内容。
## CSR拓扑配置
以下视频介绍了 BMC Studio 的 CSR 拓扑配置操作指导，通过该视频您可以详细了解 CSR 拓扑配置的具体步骤，从而快速和准确配置CSR文件。
## CSR可视化配置
1. 在BMC Studio首页，选择CSR，进入CSR配置界面。
2. 新增组件，模板选择"RiserCard"，具体操作方法可参考“配置CSR模块”章节。[配置CSR模块](#操作模块)
3. 添加“I2c总线”。
4. 将器件和连接器拖拽到总线上或9545芯片的不同`channel`上，创建拓扑并进行配置，配置完成后，拓扑和Riser卡拓扑图一致。
> **说明**：
> 如果需要将总线传到`Connector`中，可以拖拽总线连接到`Connector`。
> 将光标移动到总线上，并单击红色叉号，可以删除这条传入的总线。
> 单击右侧“查看代码”可查看生成的CSR内容。
5. 双击框图的空白处配置板卡对象`RiserCard_1`。
6. 在页面上方选择“业务视图”配置`Chip_MCU`和`MCU`升级的对象。
7. 配置`Eeprom_IEU`并在业务视图中配置`SRUpgrade_1`对象，由于`SRUpgrade_1`对象的`WriteProtect`需要从`Pca9555`芯片获取，因此需要在`pca9555`芯片上配置读取器`Scanner`类型对象。
## 事件定制
以板卡适配中配置Riser卡电源失效事件为例：
配置事件前，需先配置要关联的组件，当前组件为Riser卡，如果配置Riser卡的电子标签信息和部件信息，需要在业务视图中完成`Fru_IEU`对象和`FruDate_IEU`对象的配置。
> **说明**：
> `Fru_IEU`对象的每个属性的配置描述可以参考板卡适配中“对象配置 > fru类”中的`Fur`。
> `FruData_IEU`对象的每个属性的配置描述可参考板卡适配中的“对象配置 > fru类”中的`FruData`。
1. 在CSR配置页面选择“告警事件”，并选择需要配置的告警项。
2. 对内容进行配置，Reading字段取值可以从Scanner对象获取。
3. 创建事件需要关联`Component`，在事件配置中选择`Component`配置关联。
4. 如果需要配置新的事件告警，可以在页面右上角选择自定义添加，手动配置告警。`EvenKeyld`需要手动配置，告警信息和修复信息分别支持10个参数。
## CSR事件告警配置
以下视频介绍了 BMC Studio 的 CSR 事件告警配置操作指导，通过该视频您可以详细了解 CSR 事件告警配置的具体步骤，从而快速配置一个事件精细化告警。
## 告警可视化配置
告警事件页面支持查看现有告警定义及告警描述信息，同时也可以直观查看当前板卡中已配置的告警内容。
> **说明**：
> 特性需要较高版本的社区vpd仓，对于历史版本的工作空间，可以手动下载社区[vpd仓库](https://gitcode.com/openUBMC/vpd)中`vendor`路径下的`event_def.json`文件，放在工作空间中的`vpd/vendor`路径下。
> 支持从预定义模板添加现有事件，添加事件自动关联事件ID和类型。
# Qemu设备管理使用指南
本章节主要介绍如何管理 Qemu 虚拟机。
## 使用前准备
- 安装 Qemu
- 使用 VS Code 插件安装。具体操作方法请参考BMC Studio插件使用说明。
- 准备镜像文件
- 通过 openUBMC 应用市场下载预制镜像：在“Qemu设备管理”配置虚拟机参数时，仿真镜像来源选择“应用市场”。
- 本地下载：单击[Qemu镜像](https://www.openubmc.cn/marketplace/QEMU)，下载对应版本的镜像文件到本地（镜像文件通常以`.cpio.gz`为后缀）。
## 配置 Qemu 虚拟机
1. 在 BMC Studio 首页，单击右上角“仿真管理”按钮，进入“接入设备管理”界面。
2. 在“Qemu设备管理”区域单击“配置”。
3. 参考以下内容设置虚拟机参数。
| 参数 | 参数说明 |
| ----------------- | ---------------------------------------------------------- |
| 机型 | 自定义标识名称，例如：`MyUbuntuVM` | `> |
| 模拟环境CPU核心数 | 分配的计算核心（建议 ≤ 物理核心数），例如：`2` | `> |
| 模拟环境内存 | 分配的内存（单位：GB），例如：`4` | `> |
| 仿真镜像来源 | 选“应用市场/Ubuntu镜像/本地文件”，例如：`ubuntu-22.04.iso` | `> |
| 网络端口 | 设置 SSH/HTTPS/IPMI/SNMP 访问端口，例如：`SSH:2222` | `> |
> [!NOTE]说明：
> 仿真镜像来源：
> - 应用市场：连接 openUBMC 应用市场自动预装系统的官方镜像。
> - 本地镜像：需要提前上传至 BMC Studio 的镜像目录。
> - Ubuntu镜像：如果您已经通过“应用市场”预装了镜像或通过“本地镜像”方式上传了镜像，可选择此项。
## 启动和使用虚拟机
启动虚拟机的操作方法如下：
1. 在 BMC Studio 首页，单击右上角第一个图标“仿真管理”按钮，进入“接入设备管理”界面。
2. 在“Qemu设备管理”区域选择虚拟机，单击“启动”，启动时间预计需要3~5分钟左右。
3. 等待状态显示为蓝色时，表示启动成功。启动完成后，相关参数含义请参考以下内容：
| 参数 | 参数说明 |
| -------- | ---------------------------------------------------------------- |
| 重新启动 | 重启虚拟机 | `> |
| 停止 | 强制关闭虚拟机。长时间不使用虚拟机时，可以使用此功能释放CUP/内存 | `> |
| 连接 | 通过 SSH 终端访问（需配置端口） | `> |
| BMC登录 | 通过浏览器访问仿真 BMC 设备 Web 图形界面 | `> |
> [!NOTE]说明：
> 删除虚拟机的配置不会清除镜像文件。
## 虚拟机仿真文件配置
本功能在 QEMU 未启动时，只能进行修改操作，无法生效到 QEMU。如果要生效到 QEMU，请在 QEMU 启动时保存修改。
1. 在BMC Studio首页，单击右上角第一个图标“仿真管理”按钮，点击上方“仿真文件”进入界面。在此页面，可以对文件进行任意修改。
2. 修改好文件后，点击下方“保存”和“取消”分别可以将修改的配置保存并生效到 QEMU 或放弃。
3. 可以通过点击下方“修改对比”按钮检查修改的部分。如果确认无误，可以点击“确定修改”保存并生效到 QEMU。也可以点击“退出对比”继续修改。
## 在线调试接口
前置要求：
- BMC Studio 版本不低于1.2.0
- BMC Studio 插件版本不低于0.0.5
- Qemu 已安装
### 通过 BMC Studio 结合 Qemu 进行代码调试
在已经建立 Qemu 连接的情况下，可以配合 BMC Studio 的 Vs Code 插件实现代码调试功能。请确保 BMC Studio 插件已安装，且 BMC Studio 已连接到 Qemu，否则调试按钮不会在 Vs Code 页面出现。
1. 通过 VsCode 在 openUBMC 的组件代码仓下打开新窗口。
以北向接口定制开发为例：
1. 打开 rackmount 文件夹。
2. 打开任意北向接口定制文件，即可在右上角看到两个图标，分别是文件级调试和组件级调试。
2. 单击“文件调试”按钮，文件会自动生效到 Qemu，并重启对应子系统进程。等待进程重启完成后即可连接 Qemu 查看调试结果。
3. 单击“组件调试：按钮，BMC Studio 会自动进行一次 bingo build 操作，并将 conan 制品中的文件替换到 Qemu 环境中，重启对应子系统，该方式适合代码修改涉及多个文件，或者修改C语言代码的情形。
4. 修改 web_backend 的接口，并启动调试。以 Login 接口的版权信息为例，修改后点击单文件生效。
5. 等待 interface 进程重启完毕。
6. 重启后，接口信息会发生更改。
7. 选择组件调试，由于需要编译组件，时间会稍微长。
8. 等待子系统重新拉起，此时耗时可能更长。
9. 组件调试完成，页面发生变化。
### 通过 BMC Studio 进行 Qemu 或者真机环境的资源协作接口和数据库调试
除了代码调试能力外，BMC Studio 的 Web 页面支持对资源协作接口进行可视化查看和调试，以及对数据库信息进行查询，具体如下：
#### 连接到任意 Qemu 环境或者真机环境
1. 连接到 BMC 环境后，选择右上角的仿真调试。
2. 资源协作接口查看与调试。
由于组件数量较多，资源协作接口会在后台持续按照组件更新，可以点击刷新按钮刷新。
3. 以资源`/bmc/kepler/Managers/1/BMC`为例，根据路径找到对应资源，点击后即可展开资源详情，内容按照接口进行折叠。
#### 资源协作接口属性实时修改
BMC Studio 基于 mdbctl 命令封装了属性设置功能。
1. 单击属性框即可修改属性，修改完成后点击其他任意处，属性修改会自动生效，例如：将 openUBMC 改为 MyBMC。
2. 修改完成后，即可进入命令行或者页面查看资源协作接口的修改结果。页面变化如下：
> [!NOTE]说明：
> 部分不在 mdbctl 命令支持范围内的对象不支持修改属性，修改后不会生效。
#### RPC一键调用
BMC Studio 简化了 RPC 调用过程，开发者只需要关注调用参数即可，无需关心完整命令的拼接，我们会帮您自动完成。调用参数操作方法如下：
1. 展开接口。
2. 单击选择需要调用的 RPC。
3. 在参数框中输入参数信息。
4. 单击右侧调试按钮，将会自动将下方拼接好的命令在 BMC 环境上执行，并返回结果，结果内容与命令行调用一致。
### 通过 BMC Studio 插件进行仿真调试
1. 使用 VS Code 打开一个代码仓，页面右上角会出现“仿真调试”按钮。
2. 单击“仿真调试”的按钮就可以进行和 BMC Studio 相同的仿真调试功能。
### 数据库信息查看
1. 单击仿真调试窗口上方的数据库页签即可查看全部组件的数据库信息。每个组件下的数据库按照不同的持久化类型分类。
2. 单击对应的表即可查看数据表内容。
# 代码预览
使用代码预览功能，可在工具界面预览各文件的代码，同时支持在预览界面直接修改并保存代码。
1. 选择需要查看代码的文件。
2. 单击页面右侧的“代码预览”按钮。
3. 界面右侧展示对应文件的代码。
> **说明**：
> 如需搜索代码内的关键字，请将鼠标选中代码框内的任意位置，使用Ctrl+F，输入关键字搜索。代码内存在多个相同的关键字时，可使用Ctrl+G跳转。
> DDS文件不支持编辑保存。
# 模型检查
BMC Studio支持模型的可视化配置，模型与模型之间存在配套关系，通过此功能可以检查出模型之间不一致的错误，并给出告警提示。
> **说明**：
> 工具根据默认的检查规则，检查指定的模型。
> 如果错误级别未定义或取值不符合规范要求，无法勾选“CSR扩展规则检查样例”。
1. 在工具首页单击右上角“模型检查”按钮。
2. 进入“模型检查”界面。
3. 选择想要检查的规则。
4. 单击右上角“开始检查”按钮。
5. 工具将根据已有的检查规则，检查各模型一致性。
6. 检查结束后，可在“检查结果”页签查看检查详情。参数说明请参考如下：
- **规则ID**：检查规则的ID。
- **所属模型**：可筛选需要展示的报错模块。
- **错误提示**：具体错误原因。
- **错误影响**：错误的影响。
- **修复建议**：具体的修复建议。
- **告警等级**：可筛选展示的高级等级。“严重”，“一般”，“提示”。
- **产生时间**：最后一次检查结果的时间。
7. 单击右上角“导出”可将检查结果导出至本地。
# 常用操作
## 查看修改
使用“查看修改”功能，可将修改前和修改后的数据进行比对，同时支持在预览界面直接修改并保存代码。
> **说明**：
> 仅支持比对最近一次保存前后的数据。
1. 选择操作模块。
2. 单击左上角“查看修改”的按钮。
3. 选择目标文件，比对修改前后的数据。
- 如需搜索代码内的关键字，请将鼠标选中需要搜索的代码框内任意位置，使用Ctrl+F，输入关键字搜索。代码内存在多个相同的关键字时，可使用Ctrl+G跳转。
- 勾选“统一缩进查看”，可统一缩进格式，便于查看。
- 如需编辑数据，请单击右上角“编辑”按钮，编辑完成后，单击“保存”。
## 撤销删除文件和撤销修改
CSR配置、资源协作接口、接口映射均支持撤销删除文件和撤销修改，MDS仅支持撤销修改。
> **注意**：
> 撤销不会有弹框再次确认，单击”撤销“后，工具将直接执行撤销操作。
> 撤销修改后，代码将变为初始拉取的状态。
撤销修改和撤销删除的方法一致，以下以CSR中的文件已被删除，需要撤销删除的操作。
1. 进入CSR操作模块。
2. 在CSR列表上方单击蓝色字体“查看修改"。
3. 选择需要撤销删除的文件，单击后方的“撤销”按钮。如果需要批量撤销，可勾选需要操作的文件，单击最上方的“撤销”按钮进行操作。
## 侧边栏
BMC Studio 目前有侧边栏，可以实现 openubmc.cn 常用链接的跳转。
五个图标从上到下分别是：
- [代码仓](https://gitcode.com/openUBMC)
- [文档中心](https://www.openubmc.cn/docs)
- [社区论坛](https://discuss.openubmc.cn)
- [sig中心](https://www.openubmc.cn/sig)
- [应用市场](https://www.openubmc.cn/marketplace)
## 卸载BMC Studio
在 linux 命令行中执行以下命令可卸载BMC Studio。
```bash
dpkg -P bmc-studio
```
---
# openUBMC Studio插件使用指南
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bmc_studio/user_guide/plugin_usage.html
> Language: zh
本文档主要介绍如何使用 BMC Studio 插件。
# 一键安装
欢迎使用 BMC Studio 一键安装视频操作指导，本视频将为您介绍自动安装步骤，助您轻松完成 BMC Studio 的安装。
# 使用前准备
- 进入[openUBMC应用市场](https://openubmc.cn/marketplace)，在“开发工具”模块中下载 BMC Studio 安装包（`.zip`格式），并将下载的安装包解压，获得`.vsix`文件。
- 确保本地已安装 VS Code(全称：Visual Studio Code，以下简称：VS Code)， 且已经通过 Remote 插件连接到开发使用的 Ubuntu/docker 环境。
# 环境要求
BMC Studio 需要在 Ubuntu24 环境上运行，使用前须先搭建环境，具体的搭建方法请参见[环境准备](../../../installation/env_prepare.md)，请用户根据使用的操作系统，参考“环境准备”对应章节进行环境搭建。例如：本地使用 Windows 开发环境，请参考“Windows开发环境搭建”。
# 安装插件
- 通过 VS Code 安装插件。
1. 打开 VS Code，参考下图步骤操作。
2. 选择`.vsix`文件存放路径，安装插件。
> [!NOTE]说明：
> 选择前，请先确定`.vsix`文件存放的操作系统，Windows 或 wsl。
3. 安装完成后重启 VS Code 生效。
- 在 WLS 开发环境中安装插件。
根据实际情况在 Ubuntu 或 Linux 环境下，执行以下命令进行安装（“xxxxxx”表示`.vsix`文件的存放路径）。
```bash
code --install-extension xxxxxx
```
# 安装和使用工具
1. 在 VS Code 打开已安装的 BMC Studio 的插件。
2. 插件将会自动对环境进行检测，查询是否安装 BMC Studio 和 Qemu。
- 如果检测到环境中未安装工具，请执行以下步骤3~步骤7安装和启动。
- 如果检测到环境中已安装工具，插件将会自动启动 BMC Studio。
> [!NOTE]说明：
> 如果当前安装的工具非最新版本，您可以单击界面上的“一键更新”升级工具版本，也可以直接使用当前的旧版本。
3. 单击“一键安装工具”，弹出“使用协议”相关弹框。
4. 勾选“同意《BMC软件许可协议》协议”，单击“继续安装”。插件将开始下载并安装您缺失的工具和依赖。安装时间根据网络情况，预计在1~10分钟不等。
5. （可选）如果下载时间过长，您可以在 VS Code 上方导航栏中选择“终端 > 新建终端”，在新建的终端中选择“输出”，右侧下拉框选择“Debug Logs”，打开日志查看是否报错，如果存在报错，请根据日志的实际情况处理。
6. 安装成功后“一键安装工具”的按钮变为“开始使用”。
7. 单击“开始使用”，即可启动 BMC Studio。
# 插件实时模型检查
BMC Studio 启动后，在 VS Code 中编辑 CSR 文件或任意 BMC Studio 工作空间内的 MDS、资源协作接口、映射接口文件，保存后会触发插件进行模型检查。检查完成后，在控制台窗口会显示检查结果，查看检查结果操作如下：
# 插件双屏显示
BMC Studio 插件支持双屏查看文件的能力。在打开一个 .sr 或 .json文件后，vscode 右上角会出现这个图标。点击该图标，即可启动 BMC Studio 双屏模式。
双屏模式中，插件会使用 BMC Studio 打开该 .sr 或 .json 文件，然后展示在插件页面里。
# 插件在线调试
前置条件：
- BMC Studio 版本不低于1.2.0。
BMC Studio 最新版本获取方法请参考[BMC Studio安装指南](../installation_guide/bmc_studio_installation.md)。
- BMC Studio 插件版本不低于0.0.5。
插件安装方法请参考[安装插件](#安装插件)。
- Qemu 已安装。
开发环境初始化过程会安装 Qemu，无需手动安装。
在线调试：
在线调试的具体流程，请参考[Qemu文档](./qemu_device_management.md)。
# 卸载插件
安装了插件后，可以在 vscode 的扩展页面的“已安装”一栏中看到 BMC Studio 插件。按图中顺序点击。
点击图中的“卸载”按钮即可完成卸载。
---
# openUBMC Studio Qemu设备管理使用指南
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bmc_studio/user_guide/qemu_device_management.html
> Language: zh
本文档主要介绍如何管理 Qemu 虚拟机。
# 使用前准备
- 安装 Qemu
- 使用 VS Code 插件安装。具体操作方法请参考[BMC Studio插件使用说明](plugin_usage.md)。
- 准备镜像文件
- 通过 openUBMC 应用市场下载预制镜像：在“Qemu设备管理”配置虚拟机参数时，仿真镜像来源选择“应用市场”。
- 本地下载：单击[Qemu镜像](https://www.openubmc.cn/marketplace/QEMU)，下载对应版本的镜像文件到本地（镜像文件通常以`.cpio.gz`为后缀）。
# 配置 Qemu 虚拟机
1. 在 BMC Studio 首页，单击右上角“设备管理”按钮，进入“接入设备管理”界面。
2. 在“Qemu设备管理”区域单击“配置”。
3. 参考以下内容设置虚拟机参数。
| 参数 | 参数说明 |
|------|----------------------------------------------------------------|
| 机型 | 自定义标识名称，例如：`MyUbuntuVM` | `>
| 模拟环境CPU核心数 | 分配的计算核心（建议 ≤ 物理核心数），例如：`2` | `>
| 模拟环境内存 | 分配的内存（单位：GB），例如：`4` | `>
| 仿真镜像来源 | 选“应用市场/Ubuntu镜像/本地文件”，例如：`ubuntu-22.04.iso` | `>
| 网络端口 | 设置 SSH/HTTPS/IPMI/SNMP 访问端口，例如：`SSH:2222` | `>
> [!NOTE]说明：
> 仿真镜像来源：
> - 应用市场：连接 openUBMC 应用市场自动预装系统的官方镜像。
> - 本地镜像：需要提前上传至 BMC Studio 的镜像目录。
> - Ubuntu镜像：如果您已经通过“应用市场”预装了镜像或通过“本地镜像”方式上传了镜像，可选择此项。
# 启动和使用虚拟机
启动虚拟机的操作方法如下：
1. 在 BMC Studio 首页，单击右上角第一个图标“设备管理”按钮，进入“接入设备管理”界面。
2. 在“Qemu设备管理”区域选择虚拟机，单击“启动”，启动时间预计需要3~5分钟左右。
3. 等待状态显示为蓝色时，表示启动成功。启动完成后，相关参数含义请参考以下内容：
| 参数 | 参数说明 |
|------|----------------------------------------------------------------|
| 重新启动 | 重启虚拟机 | `>
| 停止 | 强制关闭虚拟机。长时间不使用虚拟机时，可以使用此功能释放CUP/内存 | `>
| 连接 | 通过 SSH 终端访问（需配置端口） | `>
| BMC登录 | 通过浏览器访问仿真 BMC 设备 Web 图形界面 | `>
> [!NOTE]说明：
> 删除虚拟机的配置不会清除镜像文件。
# 虚拟机仿真文件配置
本功能在 QEMU 未启动时，只能进行修改操作，无法生效到 QEMU。如果要生效到 QEMU，请在 QEMU 启动时保存修改。
1. 在BMC Studio首页，单击右上角第一个图标“设备管理”按钮，点击上方“仿真文件”进入界面。在此页面，可以对文件进行任意修改。
2. 修改好文件后，点击下方“保存”和“取消”分别可以将修改的配置保存并生效到 QEMU 或放弃。
3. 可以通过点击下方“修改对比”按钮检查修改的部分。如果确认无误，可以点击“确定修改”保存并生效到 QEMU。也可以点击“退出对比”继续修改。
# 在线调试接口
前置要求：
- BMC Studio 版本不低于1.2.0
BMC Studio 最新版本获取方法请参考[BMC Studio安装指南](../installation_guide/bmc_studio_installation.md)。
- BMC Studio 插件版本不低于0.0.5
BMC Studio 插件目前需要以文件方式安装，安装过程参考[插件文档](./plugin_usage.md)。
- Qemu 已安装
开发环境初始化过程会安装 Qemu，无需手动安装。
## 通过 BMC Studio 结合 Qemu 进行代码调试
在已经建立 Qemu 连接的情况下，可以配合 BMC Studio 的 Vs Code 插件实现代码调试功能。请确保 BMC Studio 插件已安装，且 BMC Studio 已连接到 Qemu，否则调试按钮不会在 Vs Code 页面出现。
1. 通过 VsCode 在 openUBMC 的组件代码仓下打开新窗口。
以北向接口定制开发为例：
1. 打开 rackmount 文件夹。
2. 打开任意北向接口定制文件，即可在右上角看到两个图标，分别是文件级调试和组件级调试。
2. 单击“文件调试”按钮，文件会自动生效到 Qemu，并重启对应子系统进程。等待进程重启完成后即可连接 Qemu 查看调试结果。
3. 单击“组件调试：按钮，BMC Studio 会自动进行一次 bingo build 操作，并将 conan 制品中的文件替换到 Qemu 环境中，重启对应子系统，该方式适合代码修改涉及多个文件，或者修改C语言代码的情形。
4. 修改 web_backend 的接口，并启动调试。以 Login 接口的版权信息为例，修改后点击单文件生效。
5. 等待 interface 进程重启完毕。
6. 重启后，接口信息会发生更改。
7. 选择组件调试，由于需要编译组件，时间会稍微长。
8. 等待子系统重新拉起，此时耗时可能更长。
9. 组件调试完成，页面发生变化。
## 通过 BMC Studio 进行 Qemu 或者真机环境的资源协作接口和数据库调试
除了代码调试能力外，BMC Studio 的 Web 页面支持对资源协作接口进行可视化查看和调试，以及对数据库信息进行查询，具体如下：
### 连接到任意 Qemu 环境或者真机环境
1. 连接到 BMC 环境后，选择右上角的仿真调试。
2. 资源协作接口查看与调试。
由于组件数量较多，资源协作接口会在后台持续按照组件更新，可以点击刷新按钮刷新。
3. 以资源`/bmc/kepler/Managers/1/BMC`为例，根据路径找到对应资源，点击后即可展开资源详情，内容按照接口进行折叠。
### 资源协作接口属性实时修改
BMC Studio 基于 mdbctl 命令封装了属性设置功能。
1. 单击属性框即可修改属性，修改完成后点击其他任意处，属性修改会自动生效，例如：将 openUBMC 改为 MyBMC。
2. 修改完成后，即可进入命令行或者页面查看资源协作接口的修改结果。页面变化如下：
> [!NOTE]说明：
> 部分不在 mdbctl 命令支持范围内的对象不支持修改属性，修改后不会生效。
### RPC一键调用
BMC Studio 简化了 RPC 调用过程，开发者只需要关注调用参数即可，无需关心完整命令的拼接，我们会帮您自动完成。调用参数操作方法如下：
1. 展开接口。
2. 单击选择需要调用的 RPC。
3. 在参数框中输入参数信息。
4. 单击右侧调试按钮，将会自动将下方拼接好的命令在 BMC 环境上执行，并返回结果，结果内容与命令行调用一致。
## 通过 BMC Studio 插件进行仿真调试
1. 使用 VS Code 打开一个代码仓，页面右上角会出现“仿真调试”按钮。
2. 单击“仿真调试”的按钮就可以进行和 BMC Studio 相同的仿真调试功能。具体操作和[通过 BMC Studio 进行 Qemu 或者真机环境的资源协作接口和数据库调试](#通过-bmc-studio-进行-qemu-或者真机环境的资源协作接口和数据库调试)。
## 数据库信息查看
1. 单击仿真调试窗口上方的数据库页签即可查看全部组件的数据库信息。每个组件下的数据库按照不同的持久化类型分类。
2. 单击对应的表即可查看数据表内容。
---
# BMC Studio SSH连接功能操作指南
> URL: https://openubmc.cn/docs/zh/latest/common_tools/bmc_studio/user_guide/ssh_connection.html
> Language: zh
本文档主要介绍如何使用BMC Studio SSH的连接功能。
# 使用前准备
- 软件：请安装最新版本的BMC Studio工具。
进入[openUBMC应用市场](https://www.openubmc.cn/marketplace/BMC%20Studio)，在BMC Studio下载页面，单击右侧“立即下载”按钮，将BMC Studio软件包下载到本地。
- 硬件：请准备一台可远程访问的服务器，并提前获取服务器的IP地址、端口号、用户名和登录密码。
# 使用须知
- BMC Studio仅支持保持一个活跃连接，如果新建SSH连接或重新连接另一个设备，之前的会话将会被断开。
- 为确保设备信息安全，离开设备时，请主动断开连接。
# 创建SSH连接
1. 在BMC Studio首页，单击右上角第一个图标“设备管理”按钮，进入“接入设备管理”界面。
2. 在“BMC设备管理”区域单击“+新建设备”。
3. 填写设备的IP地址、端口、用户名和密码。
4. 单击“连接”，完成设备认证。认证成功后，新建的设备会展示在BMC设备管理区域下。
# 连接管理
## 重新连接会话
1. 在“BMC设备管理”区域下的设备列表中，选择需要重新连接的会话。
2. 确认设备处于未连接状态，操作列将展示“连接”和“删除”。
3. 单击“连接”按钮，输入对应设备的密码。
> **说明**：
> 基于安全考虑，BMC Studio不会自动保存设备密码，涉及密码处均须手动输入确认。
## 断开当前连接
1. 在“BMC设备管理”区域下的设备列表中，选择需要断开连接的会话。
2. 确认设备处于连接状态，操作列将展示“取消连接”和“删除”。
3. 单击“取消连接”按钮，等待“取消连接”按钮变为“连接”时，断开成功。
## 删除设备配置
1. 在“BMC设备管理”区域下的设备列表中，选择需要删除的会话。
2. 单击“删除”按钮，删除成功后会清除当前设备的全部缓存信息。
# 连接状态说明
- **绿灯**：表示设备已连接，可执行断开或发送命令操作。
- **灰标**：表示设备未连接，可执行新建连接或重新连接操作。
---
# QEMU常见问题
> URL: https://openubmc.cn/docs/zh/latest/common_tools/qemu/qemu.html
> Language: zh
# Qemu启动
## 【Q】按照官方的最新的manifest以及指导文档运行Qemu后 SSH能访问Ipmi命令能通，但是web不通，端口号也都反复检查了。这时候的固件是跑脚本的时候下载的固件
1. ssh和ipmi启动时间会比web的启动时间要快，web连接不通可能在于nginx还没拉起，可以稍等几秒再重新拉起，此时可以：
- 登录ssh：`ssh Administrator@localhost -p 10022`
- 进入telnet：`/data/home/busybox_x telnet localhost`
- 查看nginx服务是否启动：`netstat -ntlpa`
2. 如果还不行，请保持默认config文件内容，删除manifest temp目录和output目录重试拉起qemu，此时能够顺利拉起qemu。
## 【Q】25.06源码构建的qemu，启动后存在互锁和web网页无法打开的问题：`ERROR：../hw/infc/arm_drcv3_cpuif.c:784:gicv3_cpuif_update:assertion failed: {qemu_mutex_iothread_locked()}`
/hw/infc/arm_drcv3_cpuif.c断言失败导致的问题，可能是您本地缓存的qemu二进制文件和现在不匹配问题，您可以进行如下流程进行恢复：
- 删除conan缓存：`rm -rf ~/.conan2/p/*` (conan2)；`rm -rf ~/.conan/data/*` (conan1)
- 重新出包：`bingo build -sc qemu`
- 删除qemu本地缓存的二进制工具：manifest仓的temp目录
- 重新拉起qemu：`python3 build/works/packet/qemu_shells/vemake_1711.py`
## 【Q】Qemu启动后存在RTOS版本不一致问题，导致ssh无法连接：x_tables: disagrees about version of symbol module_layout
这个是RTOS版本不一致导致驱动起不来的问题：
先看查看环境的RTOS版本和qemu远程的RTOS版本一致了，查看方法：`ls -l /opt/RTOS`，将会由显示RTOS版本号，然后Qemu的使用的RTOS版本号会在manifest.yml里面存在qemu_rtos_version，将两者进行比较
如果不是的话，请进行以下步骤：
1. 拉最新的[manifest组件仓](https://gitcode.com/openUBMC/manifest.git)
2. 删除conan缓存：`rm -rf ~/.conan2/p/*`
3. 重新初始化环境：执行`python3 init.py xxx`
4. 重新出包：`bingo build -sc qemu`
5. 重新启动qemu：`python3 build/works/packet/qemu_shells/vemake_1711.py`
## 【Q】Qemu仿真环境启动时卡住：Authorized uses only. All activity may be monitored and reported.pe (err -2)localhost login
这种情况有可能是两种因素引起：
1. 修改的内容导致BMC有问题，这种遇到卡顿可以等一下，过了一段时间，可以telnet进去查看日志：`cat /var/log/framework.log`，查看报错，一般都是基础框架没有起来的问题；然后根据日志报错修改自己的代码
2. 由于本地的conan缓存的生命周期失效，可以清除conan缓存
可以尝试这样解决：
- 拉最新manifest
- 执行`python3 init.py xxx`
- 升级bingo：`bingo upgrade`
- 清除conan缓存：`rm -rf ~./conan2/p/*`
- 出包：`bingo build -sc qemu`
- 启动qemu: `python3 build/works/packet/qemu_shells/vemake_1711.py`
## 【Q】执行仿真环境qemu后，有报错但不影响登录openUBMC，请问账号密码是什么？
账号/密码：`Administrator/Admin@90000`
## 【Q】web一直不响应，可以看看nginx服务是否存在
终端登录ssh: `ssh Administrator@localhost -p 10022`
进入telnet: `/data/home/busybox_x telnet localhost`
查看nginx服务是否启动：`netstat -ntlpa`
如果nginx服务启动了，web还登录不了，此时可以查看日志：`cat /var/log/app.log`, 或者`killall interface`
如果nginx服务还没启动，需要通过日志来定位问题了：`cat /var/log/app.log`, 来观察是不是本身代码做了其他修改导致的问题
## 【Q】仿真环境启动后，登进去，缺少ipmcget命令：仿真环境初始化完毕后，用户名Administrator密码Admin@90000，登录到openUBMC里面，没有ipmcget命令，也没有ifconfig命令，如何添加?
在manifest的output/data被异常修改导致的问题：
- 停止正在运行的qemu
- 删除output/data目录
- 重新运行qemu：`python3 build/works/packet/qemu_shells/vemake_1711.py`
目前openUBMC暂时不支持ifconfig命令
# Qemu构建
## 【Q】bingo build -sc qemu 报错为啥，用的是普通用户，必须要用root用户嘛？
目前Qemu的二进制工具构建和openUBMC的仿真镜像包仅支持root用户
## 【Q】25.06源码构建qemu固件包失败，存在组件全量源码构建失败问题：CMake Error: The source directory “/root/.conan/data/bmc_network/1.70.42/openUBMC.release/rc/build/a8cc6717e1ce1e0d9c59af89eaae6d6122f062e6” does not appear to contain CMakeLists.txt
1. 因为触发了bmc_network组件的全量源码构建，但bmc_network组件在社区只有conan包导致的，可以直接`conan download bmc_network/1.70.42@openUBMC.release/stable -r openubmc_dev`验证conan有没有问题
2. `conan download bmc_network/1.70.42@openUBMC.release/stable -r openubmc_dev`成功之后，拉最新的manifest，重新`python3 init.py xxx`, 然后清除缓存`rm -rf ~/.conan2/p/*`, 然后重新再来：`bingo build -sc qemu`.
## 【Q】基于修改代码出自己的qemu cpio包，会提示某个组件download失败
首先去查看本地manifest仓的temp/log/task.log，看看有没有说是要输入account和密码，如果有的话：
- 杀死正在运行的qemu构建出包进程
- 然后在终端输入命令：`conan search help -r openubmc_dev`，会提示输入账号和密码
- 重新`bingo build -sc qemu`出包即可
---
# QEMU仿真与BMC业务开发指南
> URL: https://openubmc.cn/docs/zh/latest/common_tools/qemu/qemu_tool_guide.html
> Language: zh
本文档主要介绍如何启动并在BMC业务中使用QEMU。
## 1. 🛠️ QEMU 环境搭建
### 什么是 QEMU？
QEMU 是一个开源的硬件仿真器，可以在你的电脑上模拟出一台完整的服务器。对于 BMC（基板管理控制器）开发来说，这是一个非常实用的工具——你不需要准备真实的硬件单板，就可以在虚拟环境中验证大部分功能。
想象一下，传统的开发流程是这样的：修改代码 → 编译 → 烧录到硬件 → 启动服务器 → 测试功能 → 发现问题 → 重复上述过程。每次测试都需要硬件配合，而且烧录固件也需要时间。
有了 QEMU，流程就变成了：修改代码 → 编译 → 重启 QEMU → 测试功能。整个过程在本地就可以完成，大大缩短了开发周期。
### 为什么使用 openUBMC 的 QEMU？
openUBMC 社区针对 BMC 开发的特点，对 QEMU 做了专门的优化和配置。主要优势包括：
- **预配置好的硬件拓扑**：模拟了真实服务器的硬件结构，不用自己从头搭建
- **完整的北向接口支持**：CLI、Redfish、Web、IPMI 等接口开箱即用
- **便捷的启动方式**：提供脚本和 deb 包两种启动方式，适应不同使用场景
- **活跃的社区支持**：遇到问题可以在论坛上交流讨论
**关于 manifest 仓库**
你可能会问：为什么总是提到 manifest 仓库？这是因为 manifest 是 openUBMC 社区维护的配置管理中心，里面包含了：
- **启动脚本**：用于拉起 QEMU 虚拟机
- **配置文件**：定义了硬件拓扑、端口映射、PCIe 卡等
- **初始化工具**：自动下载和配置 BMC 运行所需的各种文件
后续的环境初始化、QEMU 启动、PCIe 卡配置等操作都需要通过 manifest 仓库来完成。简单来说，它是你使用 openUBMC QEMU 的"控制中心"。
**manifest 仓库地址**：[https://gitcode.com/openUBMC/manifest](https://gitcode.com/openUBMC/manifest)
每次都需要保持本地的 manifest 仓库是最新的，可以执行下面的指令：
```bash
# 如果第一次 git clone manifest 仓库
git clone https://gitcode.com/openUBMC/manifest.git
cd manifest
git pull
```
---
### 环境初始化
第一次使用前，需要先初始化环境。这一步会下载必要的文件和配置。
```bash
cd manifest
python3 init.py -path -user -psw
```
**参数说明**：
- `-path`：bmc_sdk.zip 文件的路径，这个 zip 包包含了 BMC 固件运行所需的基础文件（获取路径：[https://www.openubmc.cn/zh/marketplace/bmcsdk](https://www.openubmc.cn/zh/marketplace/bmcsdk)）
- `-user`：你的 openUBMC 社区用户名
- `-psw`：你的 openUBMC 社区密码
---
### 1.1 方式一：通过脚本启动
这是最直接、最常用的启动方式，特别适合日常的开发调试。
#### 为什么推荐这种方式？
脚本启动方式的优点：
- **简单直接**：一条命令就能启动，不需要额外配置
- **调试友好**：QEMU 的输出会直接显示在终端，方便查看日志
- **灵活可控**：可以通过修改脚本参数调整 QEMU 的配置
- **更新及时**：脚本总是和 manifest 仓库同步，第一时间获得最新功能
#### 启动 QEMU
```bash
cd manifest
python3 build/works/packet/qemu_shells/vemake_1711.py
```
执行后，你会看到 QEMU 的启动日志滚动显示。等待一段时间后，BMC 固件就会启动完成，你可以通过 SSH 或者 Web 界面连接进去。
```bash
Uncompressing... done, booting...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[ 0.000000] Linux version 5.10.0 (oe-user@oe-host) (aarch64-euler-linux-gcc (BiSheng Embedded CPU 302.1.0.B016) 7.3.0, GNU ld (BiSheng Embedded CPU 302.1.0.B016) 2.41) #1 SMP PREEMPT Tue Nov 26 22:03:48 CST 2024
```
#### 如何停止 QEMU？
有时候你需要停止 QEMU，比如要修改配置或者结束今天的工作。
**方法 1：优雅退出（推荐）**
在 QEMU 启动的终端窗口中，直接按 `Ctrl + C`，脚本会自动清理相关进程。
**方法 2：强制结束**
如果 `Ctrl + C` 没有响应，可以用 kill 命令强制结束：
```bash
# 先查看 QEMU 进程的 PID
ps aux | grep qemu
# 然后结束进程， 对应 QEMU 进程的 PID
# 一般情况下查找 qemu-system-aarch64 所对应的 PID 号
kill -9
```
---
### 1.2 方式二：通过 .deb 软件包启动
如果你习惯了使用 Linux 的包管理工具，或者需要在自动化测试、CI/CD 流程中使用，deb 包方式会更方便。在最开始环境初始化的过程中，就已经将 deb 包安装好了，剩下的事情就只需要一键启动即可。
#### 什么时候选择这种方式？
- **CI/CD 环境**：在持续集成流程中，使用 deb 包更容易集成
- **多台机器部署**：安装一次 deb 包，之后可以快速启动
- **命令行偏好**：习惯了 `apt install` 的操作方式
#### deb 包相关命令
```bash
# 查询版本命令
openubmc-qemu version
# 查询接口状态命令（当接口 up 时，用户就可以连接）
openubmc-qemu status
# 关闭 QEMU 命令
openubmc-qemu close
```
#### 启动 QEMU
```bash
# 初始化环境（第一次使用时需要）
openubmc-qemu init
# 启动 QEMU
openubmc-qemu run --remote
```
`--remote` 参数表示使用远程模式，这样 QEMU 的服务端口会映射到宿主机上，你可以通过网络访问。
---
### 1.3 连接到 QEMU 中的 BMC
QEMU 启动后，BMC 固件就开始运行了。但是你还没有办法直接操作它，因为 BMC 运行在 QEMU 虚拟出来的"服务器"里，而不是你的物理电脑。
为了解决这个问题，QEMU 使用了**端口映射**技术。简单来说，就是把虚拟机里的端口"转发"到你的物理电脑上。
| BMC 内部端口 | 宿主机映射端口 | 说明 |
|:-----------:|:-------------:|:-----|
| 22 | 10022 | SSH 服务 |
| 23 | 10023 | Telnet 服务 |
| 443 | 10443 | HTTPS（Web + Redfish） |
| 623 | 10623 | IPMI 服务 |
举个例子，当你连接 `127.0.0.1:10022` 时，实际上连接的是虚拟机里的 `22` 端口（SSH）。
#### SSH 连接
SSH 是最常用的连接方式，可以执行各种管理命令。在登录 SSH 之前需要知晓宿主机的 IP，在 Linux 中执行 `ifconfig` 查看 IP，找到 eth0 的 IP，然后在宿主机中执行：
```bash
# 此处默认的 IP 地址是 localhost 也就是 127.0.0.1
ssh -p 10022 Administrator@127.0.0.1
```
输入密码 `Admin@90000` 后，你就进入了 BMC 的命令行界面，可以像操作真实服务器一样执行各种命令。
> **默认账号信息**：
>
> - 用户名：`Administrator`
> - 密码：`Admin@90000`
>
> **安全提示**：在生产环境中，请务必修改默认密码！
#### Telnet 连接
Telnet 是一个更简单的协议，主要用于调试。
```bash
telnet 127.0.0.1 10023
```
### 1.4 卸载 deb 包
```bash
apt purge -y openubmc-qemu
```
---
## 2. 🌐 BMC 北向接口在 QEMU 中的应用
### 什么是北向接口？
BMC（基板管理控制器）是服务器上的一个小型独立计算机，负责监控和管理服务器的各种状态。但是 BMC 自己不会主动去"管理"什么——它需要和外部管理系统配合工作。
**北向接口**就是 BMC 对外提供的"沟通渠道"。通过这些接口，外部的管理系统（比如数据中心管理平台、监控软件）可以：
- 查询服务器的硬件状态（温度、电压、风扇转速等）
- 控制服务器的电源（开机、关机、重启）
- 管理固件版本
- 配置各种参数
- 接收告警通知
openUBMC 支持以下北向接口：CLI、Redfish、Web、IPMI。每个接口都有自己的特点和适用场景。
### QEMU 如何暴露这些接口？
在真实的服务器上，BMC 的北向接口通过网络对外提供服务。在 QEMU 虚拟环境中，我们使用**端口转发**技术，把虚拟机里的端口映射到宿主机上。
这样，你就可以在宿主机上直接访问 BMC 的各种服务，就像访问一台真实服务器的 BMC 一样。
---
### ⌨️ a) CLI 接口（命令行接口）
CLI（Command Line Interface）是最直接、最原始的管理方式。通过命令行，你可以执行几乎所有的 BMC 管理操作。
#### CLI 的特点
- **响应快速**：没有图形界面的开销，命令执行速度快
- **适合脚本**：可以编写脚本批量执行操作
- **调试利器**：开发者最常用的接口，可以快速定位问题
- **功能完整**：几乎所有功能都可以通过 CLI 访问
#### 步骤 1：查看版本信息
连接上 BMC 后，第一件事通常是查看版本信息，确认 BMC 固件是否正确加载。BMC 提供丰富的 CLI 命令，如下图所示，可以看到 ipmcget 命令支持查询固件版本信息、查询时间等操作。
```bash
ipmcget -d v
```
执行后会输出 BMC 的版本信息，包括：
- BMC 固件版本号
- BIOS/UEFI 版本
- CPLD 版本
- 各种子卡固件版本
#### 步骤 2：使用 D-Bus 接口
D-Bus 是 Linux 系统中用于进程间通信的机制。在 openUBMC 中，各个功能模块之间通过 D-Bus 互相调用，协同工作。
通过 `busctl` 命令，你可以：
- 查看 BMC 的组件结构
- 查看每个组件提供的接口
- 调用组件的方法
- 监听组件的事件
**查看组件资源协作接口**：
```bash
# 命令可以依赖 bmc.kepler.<组件名> 来拼接
# 以固件管理 firmware_mgmt 为例
busctl --user tree bmc.kepler.firmware_mgmt
```
这个命令会显示 `bmc.kepler` 服务的对象树结构，像文件系统的目录树一样，展示了各个子组件的层级关系。
**查看接口定义**：
```bash
busctl --user introspect bmc.kepler.firmware_mgmt /bmc/kepler/UpdateService/FirmwareInventory/ActiveBMC
```
`introspect` 命令会详细列出某个对象的所有接口、方法、属性和信号，包括它们的参数类型和返回值类型。这对于开发者来说是非常有用的调试工具。
---
### 🦊 b) Redfish 接口
Redfish 是 DMTF（分布式管理任务组）制定的现代数据中心管理标准。相比传统的 IPMI 协议，Redfish 具有以下优势：
#### Redfish 的优势
- **基于 HTTP/HTTPS**：使用标准的 Web 协议，易于集成
- **JSON 格式**：数据格式简洁，解析方便
- **RESTful 风格**：API 设计符合 REST 规范，直观易懂
- **安全性更好**：支持 HTTPS 和现代认证机制
- **扩展性强**：可以方便地添加新的资源和功能
#### 认证信息
- **访问地址**：`https://127.0.0.1:10443`
- **用户名**：`Administrator`
- **密码**：`Admin@90000`
#### 步骤 1：使用 Postman 测试
Postman 是一个流行的 API 测试工具，提供图形化界面，支持保存请求历史，非常适合用来调试 Redfish 接口。
**操作步骤**：
1. 打开 Postman，新建一个请求
2. 选择请求方法（GET 用于查询数据，POST 用于创建资源，PATCH 用于修改资源）
3. 输入 URL：`https://127.0.0.1:10443/redfish/v1/`
4. 配置认证：
- 切换到 **Authorization** 标签
- Type 选择 **Basic Auth**
- Username 输入 `Administrator`
- Password 输入 `Admin@90000`
5. 关闭 SSL 验证：Settings → SSL certificate verification → Off（因为 QEMU 使用的是自签名证书）
6. 点击 **Send** 发送请求
#### 步骤 2：查询系统信息
Redfish 使用树状结构组织资源，`/redfish/v1/` 是根路径，从这里可以访问所有子资源。
查询系统信息：
```bash
curl -k -u Administrator:Admin@90000 \
https://127.0.0.1:10443/redfish/v1/Systems/1
```
返回的 JSON 数据包含了服务器的各种信息：
- `SerialNumber`：序列号
- `Model`：型号
- `Status`：健康状态
- `PowerState`：电源状态
- `Boot`：启动配置
---
### 💻 c) Web 接口（Web UI）
Web UI 是最直观、最易用的管理方式。你不需要记忆任何命令，也不需要编写代码，通过浏览器就可以完成大部分管理操作。
#### Web UI 的特点
- **图形化界面**：直观易用，不需要培训
- **实时监控**：可以查看传感器的实时读数
- **功能全面**：支持固件管理、用户配置、网络设置等
- **跨平台**：只要有浏览器就可以使用
#### 访问方式
在浏览器中打开：`https://127.0.0.1:10443`
输入用户名和密码登录即可。
#### 步骤 1：访问 Web UI
登录后，你会看到 BMC 的主界面，这里显示了服务器的整体状态概览。
主界面通常包括：
- **系统信息**：型号、序列号、健康状态
- **传感器读数**：温度、电压、风扇转速
- **电源状态**：开机/关机状态
- **告警信息**：最近的告警事件
#### 步骤 2：固件管理
固件管理页面可以查看和升级各个组件的固件版本。
这里可以管理：
- **BMC 固件**：BMC 本身的固件
- **BIOS/UEFI**：主板的 BIOS 固件
- **CPLD/FPGA**：各种可编程逻辑器件的固件
- **子卡固件**：网卡、RAID 卡等扩展卡的固件
#### 步骤 3：服务管理
服务管理页面可以配置 BMC 提供的各种网络服务。
可配置的服务包括：
- **SSH 服务**：命令行接口
- **Web 服务**：Web UI 和 Redfish
- **IPMI 服务**：IPMI over LAN
- **虚拟控制台**：KVM/VNC 重定向
你可以启用或禁用某个服务，修改监听端口，配置访问白名单等。
---
### 🛠️ d) IPMI 接口
IPMI（Intelligent Platform Management Interface，智能平台管理接口）是 BMC 的传统协议。虽然 Redfish 已经成为新的标准，但 IPMI 在许多存量系统中仍然被广泛使用。
#### IPMI 的特点
- **历史悠久**：从上世纪 90 年代就开始使用
- **兼容性好**：几乎所有的服务器都支持
- **工具成熟**：有大量的管理工具可以使用
- **安全性较低**：相比 Redfish，IPMI 的安全性较弱
#### 认证信息
- **端口**：`10623`
- **用户名**：`Administrator`
- **密码**：`Admin@90000`
#### 步骤 1：查询 FRU 信息
FRU（Field Replaceable Unit，现场可替换单元）信息记录了硬件的各种标识数据，包括制造商、型号、序列号等。这些信息对于资产管理和故障追踪非常重要。
```bash
ipmitool -I lanplus -H 127.0.0.1 -p 10623 -U Administrator -P Admin@90000 fru
```
FRU 信息通常包括：
- **Product Info**：产品制造商、型号、序列号
- **Board Info**：主板信息、生产日期
- **Chassis Info**：机箱类型、机箱序列号
#### 步骤 2：读取电子标签
电子标签（E-label）存储在组件的 EEPROM 中，是一种更灵活的存储格式。和 FRU 相比，电子标签可以存储更多信息，并且更容易更新。
```bash
ipmitool -I lanplus -H 127.0.0.1 -p 10623 -U Administrator -P Admin@90000 raw 0x30 0x90 0x05 0x01 0x2 0x03 0x00 0x3
```
这条命令使用 IPMI 的 raw 命令直接发送底层指令。参数的含义：
- `0x30 0x90`：读取电子标签的命令码
- `0x05`：FRU ID
- `0x01`：区域（Board/Product/Chassis）
- `0x2`：字段类型
- `0x03`：偏移量
- `0x00`：读取起始位置
- `0x3`：读取长度
---
## 3. 🏗️ QEMU 进阶应用
前面的章节介绍了基本的接口使用，这一节我们会进入更高级的主题：模拟复杂的硬件场景。
### 为什么需要进阶应用？
在真实的运维环境中，服务器会遇到各种突发情况：温度过高、电源故障、设备损坏等。BMC 需要能够及时发现这些异常，并采取相应的措施（发出告警、自动关机、调整风扇转速等）。
如何验证 BMC 的异常处理逻辑是否正确？你不可能真的去破坏硬件来测试。QEMU 提供了一种安全的方式：在虚拟环境中模拟各种异常场景。
本节介绍两个实用场景：
1. **PCIe 卡热插拔**：模拟在线更换 PCIe 设备
2. **事件模拟**：模拟各种硬件告警事件
---
### ⏰ 3.1 PCIe 卡热插拔
#### 什么是热插拔？
热插拔（Hotplug）是指在系统运行状态下，在线添加或移除硬件设备，而不需要关机。
在数据中心运维中，这是一个非常实用的功能。比如：
- 服务器的网卡坏了，需要更换新的网卡
- 需要增加一块 NVMe 硬盘来扩容
- RAID 卡故障，需要紧急更换
传统做法是关机 → 更换硬件 → 开机，这会导致服务中断。有了热插拔，你可以在不影响服务的情况下完成硬件更换。
#### BMC 在热插拔中的作用
当 PCIe 设备插入或拔出时，硬件会触发中断信号。BMC 需要能够：
1. 检测到设备变化
2. 识别新设备的类型和信息
3. 更新资产记录
4. 发送告警通知给管理系统
通过 QEMU，我们可以模拟整个热插拔流程，验证 BMC 的响应是否正确。
#### 默认支持的 PCIe 卡
openUBMC 的 QEMU 环境目前支持以下 PCIe 卡的仿真：
| 卡型号 | 类型 | BMC 支持情况 |
|:------|:-----|:------------|
| **SP680** | 网卡 | 大部分功能已支持，包括端口状态查询、MAC 地址获取、VLAN 配置等 |
| **SAS 3152** | RAID 卡 | 基础仿真，支持设备识别和基本信息查询 |
---
#### 步骤 1：查看 pcie_card.json 配置
PCIe 卡的配置信息存储在 manifest 仓库的 `pcie_card.json` 文件中。这个文件控制着哪些 PCIe 卡"在位"（present）、每个卡的 CSR 数据是什么。
文件中每个 PCIe 卡都有一个 `present` 字段：
- `1` 表示该卡在位（BMC 会尝试识别它）
- `0` 表示该卡不在位（BMC 会忽略它）
#### 步骤 2：修改 CSR 名称并启用
CSR（Command Status Register）是一组记录 PCIe 卡信息的寄存器，包括设备 ID、厂商 ID、子系统 ID 等。
要将一张 PCIe 卡"插入"系统，需要：
1. 将 `present` 字段改为 `1`
2. 配置正确的 CSR 名称（这个名字对应 vpd 仓库中的 CSR 文件）
CSR 数据可以从 vpd 仓库获取，这里存放了各种 PCIe 卡的标准 CSR 定义：
#### 步骤 3：添加仿真数据
光有 CSR 名称还不够，BMC 还需要知道 PCIe 卡的详细属性，比如设备名称、功能类型、链路状态等。这些信息需要在配置文件中完整定义。
**配置示例（SP670 网卡）**：
```json
"PCIeDevice_1": {
"DeviceName": "PCIe Card $ (SP670)",
"FunctionClass": 2,
"DiagnosticFault": 0,
"PredictiveFault": 0,
"CorrectableError": 0,
"UncorrectableError": 0,
"FatalError": 0,
"DeviceType": 8,
"PCIeDeviceType": "MultiFunction",
"SlotType": "FullLength",
"FunctionProtocol": "PCIe",
"FunctionType": "Physical"
}
```
**字段说明**：
| 字段 | 说明 |
|:-----|:-----|
| `FunctionClass` | 功能类别（0=未指定，1=存储，2=网络） |
| `DiagnosticFault` | 诊断故障标志 |
| `PredictiveFault` | 预测性故障标志 |
| `CorrectableError` | 可纠正错误计数 |
| `UncorrectableError` | 不可纠正错误计数 |
| `FatalError` | 致命错误标志 |
| `DeviceType` | 设备类型 |
| `PCIeDeviceType` | PCIe 设备类型 |
| `SlotType` | 插槽类型 |
| `FunctionProtocol` | 功能协议 |
| `FunctionType` | 功能类型（物理/虚拟） |
这些字段会被 BMC 解析后展示在 Web UI 或通过 Redfish 接口对外提供。
#### 步骤 4：验证结果
配置完成后，可以在 BMC 中查看 PCIe 卡是否被正确识别。
```bash
# 查看 PCIe 卡信息
ipmcget -d v
```
如果一切正常，你应该能看到新添加的 PCIe 卡的信息，包括设备名称、厂商、型号等。
---
### 🔌 3.2 事件模拟
#### 什么是事件模拟？
BMC 的一个重要职责是监控服务器的各种状态，当出现异常时及时发出告警。常见的事件类型包括：
- **温度告警**：CPU 或环境温度过高
- **电压异常**：电源电压超出正常范围
- **风扇故障**：风扇转速过低或停止
- **设备故障**：硬盘、网卡等设备出现故障
每个事件都会触发 BMC 的响应流程：记录日志（SEL）、更新传感器状态、发送告警通知（SNMP Trap、Redfish Event）、执行预设动作（调整风扇、自动关机）。
通过 QEMU 模拟这些事件，你可以验证 BMC 的告警机制是否正常工作，不用真的去制造硬件故障。
#### 本节示例
我们以 **BCU1 VCC_12V0_2 电压传感器**为例，演示如何手动触发一个电压告警事件。
---
#### 步骤 1：查看 Web 告警列表
先看看 BMC 的当前告警界面长什么样，了解一下告警信息的展示方式。
告警列表通常显示：
- 告警级别（Info/Warning/Critical）
- 告警时间
- 告警描述
- 告警来源（哪个传感器触发）
#### 步骤 2：找到目标传感器的 UID
每个传感器在 BMC 系统中都有一个唯一的 UID（唯一标识符），用于精确定位该传感器。
通过 Web 界面导航到 BCU 板卡的传感器页面，找到 VCC_12V0_2 电压传感器的 UID。
这里的 UID 是该板卡的唯一标识符。
#### 步骤 3：查看传感器当前状态
使用 `mdbctl` 命令可以查看传感器的实时读数和配置信息。
```bash
# 查看电压传感器的当前值
mdbctl lsprop Scanner_12v2_010101
# 查看电源状态
mdbctl lsprop Scanner_PowerGood_010101
```
输出会显示传感器的各种属性，如上图中所示：
- `Value`：当前读数
- `ClassName`：名称
#### 步骤 4：修改传感器数值触发告警
现在到了关键步骤：手动修改传感器的数值，看看 BMC 是否会触发告警。
```bash
# 设置一个超出正常范围的值（触发告警）
mdbctl setprop set Scanner_12v2_010101 bmc.kepler.Scanner Value 3000
# 恢复正常值（清除告警）
mdbctl setprop set Scanner_12v2_010101 bmc.kepler.Scanner Value 2200
```
第一条命令将电压值设为 3000（单位通常是毫伏），这明显超出了 12V 电源的正常范围。BMC 检测到这个异常值后，应该会产生一条告警。
刷新 Web 界面的告警列表，你应该能看到新增的电压告警记录。
如果你想清除告警，执行第二条命令，将电压值恢复正常即可。
---
### 🔧 3.3 板卡适配
#### 什么是板卡适配？
板卡适配是将新的硬件板卡（如网卡、RAID 卡、GPU 卡等）集成到 BMC 管理系统中，使其能够被正确识别、监控和管理。
通过 QEMU，你可以在没有真实硬件的情况下完成大部分适配工作，硬件到位后只需做少量验证。
**核心原理**：通过 `mdbctl` 命令修改板卡的加载方式和 ID，实现板卡的在线替换适配。
---
#### 步骤 1：查看当前板卡信息
首先执行以下命令，查看系统中当前的板卡信息：
```bash
ipmcget -d v
```
记录下需要替换的板卡 UID，后续步骤会用到。
---
#### 步骤 2：执行板卡替换
本节以 UID 为 `00000001040302044504` 的 IEU 板卡为例，演示如何将其替换为 UID 为 `00000001040302044501` 的板卡。
**执行流程**：
```bash
# 1. 查看板卡当前属性信息
mdbctl lsprop Connertor_D7a_010101
# 2. 将板卡设置为不在位状态
mdbctl setprop set Scanner_D7a_010101 bmc.kepler.Scanner Value 0
# 3. 设置连接器识别模式
mdbctl setprop set Connertor_D7a_010101 bmc.kepler.Connector IdentifyMode 2
# 4. 修改板卡 ID（替换为新的 UID）
mdbctl setprop set Connertor_D7a_010101 bmc.kepler.Connector Id "00000001040302044501"
# 5. 将板卡恢复为在位状态
mdbctl setprop set Scanner_D7a_010101 bmc.kepler.Scanner Value 1
```
> **说明**：图中的内容是进入了 mdbctl 模式分开执行的命令，可以通过上述的命令直接执行，而不用进入 mdbctl 模式单独执行命令。
**命令说明**：
| 步骤 | 命令作用 | 说明 |
|:----:|:---------|:-----|
| 1 | `lsprop` | 查看板卡的当前属性配置 |
| 2 | `Value = 0` | 将板卡标记为"不在位"，相当于拔出板卡 |
| 3 | `IdentifyMode = 2` | 设置连接器识别模式 |
| 4 | `Id` | 修改板卡的 UID，替换为新板卡的标识 |
| 5 | `Value = 1` | 将板卡标记为"在位"，相当于插入新板卡 |
---
#### 步骤 3：验证替换结果
板卡替换完成后，再次执行以下命令验证结果：
```bash
ipmcget -d v
```
你应该能看到板卡的 UID 已经更新为新的值，板卡信息与目标板卡一致。
## 📚 附录：快速参考
### 认证信息汇总
所有接口使用统一的账号密码，方便记忆：
| 接口 | 用户名 | 密码 | 端口 |
|:----:|:------|:-----|:----:|
| **CLI / SSH** | `Administrator` | `Admin@90000` | 10022 |
| **Redfish** | `Administrator` | `Admin@90000` | 10443 |
| **Web UI** | `Administrator` | `Admin@90000` | 10443 |
| **IPMI** | `Administrator` | `Admin@90000` | 10623 |
### 常用命令速查
```bash
# SSH 连接
ssh -p 10022 Administrator@127.0.0.1
# 查看版本信息
ipmcget -d v
# 查看传感器
ipmcget -d sensorlist
# 查看 FRU 信息
ipmitool -I lanplus -H 127.0.0.1 -p 10623 -U Administrator -P Admin@90000 fru
# Redfish 查询系统信息
curl -k -u Administrator:Admin@90000 https://127.0.0.1:10443/redfish/v1/Systems/1
# D-Bus 查看资源协作接口
busctl --user tree bmc.kepler.<组件名>
# 修改传感器值
mdbctl setprop set bmc.kepler.Scanner Value <值>
```
---
# 部件驱动接入导读
> URL: https://openubmc.cn/docs/zh/latest/component_driver/comp_driver_overview.html
> Language: zh
# 简介
openUBMC 的部件驱动接入是基于南向部件接口规范，开发者通过编写设备描述文件和驱动代码，让 BMC 自动发现并纳管新硬件部件，实现即插即用的标准化接入能力。
本章主要介绍openUBMC部件类适配（部件驱动适配方案2.0）中各部件的适配方案。
关于openUBMC整机类适配和部件类适配（资源树适配方案1.0）中各部件的适配方案，请参考[硬件适配](../hardware/hw_adapt_overview.md)。
# 学习路径
openUBMC部件驱动接入的学习路径主要包括：
- 新手入门：帮助您实现快速上手实操，对部件驱动接入有整体的初步了解。
- 进阶开发：掌握深入原理，熟悉驱动接入操作，快速实现部件驱动接入定制开发。
| 新手入门 | 进阶开发 |
| -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| | [概念原理](./concept_principle/component_driver_discovery.md) |
| [快速上手](./comp_driver_quick_start.md) | [总体指导](./general_guide/bus_chip_driver_guide.md) |
| | [网卡适配](./nic_adapt/nic_driver_spec.md) |
| | [硬盘适配](./hdd_adapt/hdd_driver_adapt_guide.md) |
| | [xPU适配](./xpu_adapt/gpu_driver_spec.md) |
| | [风扇电源适配](./fan_power_adapt/fan_power_driver_adapt.md) |
---
# 部件驱动接入快速上手
> URL: https://openubmc.cn/docs/zh/latest/component_driver/comp_driver_quick_start.html
> Language: zh
# 1 环境搭建
可参考[openUBMC环境搭建](../getting_started/quick_start/env_introduction.html)。首先，您需要准备一个Linux编译服务器。
## 1.1 拉取源码
### 1.1.1 配置ssh公钥
```bash
ssh-keygen -t rsa -b 2048 -C 个人邮箱地址
```
不要输入，一路回车
```bash
cat ~/.ssh/id_rsa.pub
```
添加到gitcode上
### 1.1.2 拉取源码
```bash
git clone https://gitcode.com/openUBMC/devmon.git
git clone https://gitcode.com/openUBMC/component_drivers.git
git clone https://gitcode.com/openUBMC/libmcpp.git
```
## 1.2 编译构建
### 1.2.1 升级bingo工具
```bash
bingo upgrade
```
### 1.2.2 编译构建
在component_drivers根目录下执行，bingo会自动处理依赖拉取与编译
```bash
bingo build
```
### 1.3 运行测试
```bash
bingo test
```
打开另一个终端，登录到容器，设置环境变量
```bash
export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus_test_Y2SmMZ/dbus.socket
```
查看资源协作路径
```bash
busctl --usr tree bmc.kepler.devmon
busctl --user introspect bmc.kepler.devmon /bmc/dev/Systems/1/PCIeNicCard/hisi_1822
```
# 2 场景一：新增一款同代次的网卡驱动
首先，您需要安装Visual Studio Code
## 2.1 编辑器准备
### 2.1.1 方式一：下载安装Remote-SSH插件（连接远程容器）
### 2.1.2 Remote-SSH登录容器
```bash
ssh root@192.168.0.144 -p 40906
```
（1）输入容器的root密码
（2）打开component_drivers工程目录
### 2.1.3 方式二：使用WSL（连接本机容器）
适用于容器运行在WSL环境的情况，无需SSH：
（1）在Windows的WSL终端中启动docker容器并进入
```bash
docker start openubmc_hls
docker exec -it openubmc_hls /bin/bash
```
（2）编写并执行代码，直接访问`/root/workspace`下的工程目录
（3）在VSCode中全部重新加载，使用容器内已安装的工具进行开发调试
## 2.2 新增csr
同代次协议不需要变更，驱动复用现有的so，不需要修改，仅需要增加csr即可
### 2.2.1 拷贝一份同代次的网卡csr到csr目录
## 2.3 运行测试
（1）拉起devmon服务
```bash
meson test -C builddir -v --timeout=0
```
（2）加载csr配置：添加新的csr到devmon服务中
```bash
busctl --user call bmc.kepler.devmon /bmc/dev bmc.dev AddDevice sa{sv} “~/workspace/devmon/tests/tests_data/csr/14140130_19e50222_19e500a2.sr” 3 Position i 2 SystemId i 1 Slot i 2
```
（3）查看资源协作路径：
打开另一个终端，登录到容器，设置环境变量
```bash
export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus_test_Y2SmMZ/dbus.socket
```
查看资源协作信息
```bash
busctl --usr tree bmc.kepler.devmon
busctl --user introspect bmc.kepler.devmon /bmc/dev/Systems/1/PCIeNicCard/SP670
```
# 3 场景二：新增一款跨代次的网卡驱动
跨代次协议可能需要变更，需要新增驱动so和csr
## 3.1 新增驱动
### 3.1.1 拷贝一份上代次的驱动
### 3.1.2 修改编译脚本
（1）在drivers/pcie_nic_card/hisi/meson.build的subdir()中增加hi185x
（2）修改drivers/pcie_nic_card/hisi/hi185x/meson.build与实际源文件一致
### 3.1.3按需修改差异点
例如，需要单独修改bmc.dev.PCIeCard的Name字段，可以在start函数增加差异处理
## 3.2 新增csr
### 3.2.1 拷贝一份上代次的网卡csr到csr目录
Compatible需要修改为与drivers/pcie_nic_card/hisi/hi185x/meson.build中的配置一致
### 3.2.2按需修改差异点
例如，修改bmc.dev.PCIeDevice的DeviceName字段为“SP699”
## 3.3 运行测试
打开另一个终端，登录到容器，设置环境变量
```bash
export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus_test_Y2SmMZ/dbus.socket
```
查看资源协作路径
```bash
busctl --usr tree bmc.kepler.devmon
busctl --user introspect bmc.kepler.devmon /bmc/dev/Systems/1/PCIeNicCard/SP699
```
---
# 部件驱动项目概览
> URL: https://openubmc.cn/docs/zh/latest/component_driver/concept_principle/component_driver_adapt.html
> Language: zh
# 部件驱动项目概览
## 项目简介
Component Drivers 是一个基于 C++17 的硬件组件驱动程序项目，使用 Meson 构建系统管理。项目提供了多种硬件设备的驱动支持和通信协议库，主要面向服务器板卡组件管理场景。该项目与devmon(Device Monitor)设备监控框架深度集成，共同构成openUBMC的硬件管理解决方案。
## 与Devmon框架的关系
### 整体架构视图
Component Drivers项目作为devmon框架的驱动实现层，通过标准化的ABI接口和插件机制实现无缝集成：
```mermaid
flowchart TB
subgraph "应用层"
BMC["BMC管理应用"]
Monitor["监控服务"]
RestAPI["RESTful API"]
end
subgraph "Devmon框架层"
DevmonService["devmon_service
设备管理服务"]
CSRParser["CSR解析器
配置驱动"]
TopoMgr["拓扑管理器
设备树管理"]
DriverLoader["驱动加载器
dlopen动态加载"]
DeviceFactory["设备工厂
对象创建"]
end
subgraph "Component Drivers层"
direction LR
DriverABI["驱动ABI接口
标准C接口"]
DeviceObject["设备对象
MC_OBJECT定义"]
DeviceInterface["设备接口
gen/dev命名空间"]
Protocol["协议库
NCSI/MCTP/IMU"]
HAS["硬件访问服务
总线芯片抽象"]
end
subgraph "硬件层"
Hardware["物理硬件设备"]
end
BMC --> DevmonService
Monitor --> DevmonService
RestAPI --> DevmonService
DevmonService --> CSRParser
DevmonService --> TopoMgr
CSRParser --> DriverLoader
DriverLoader --> DeviceFactory
DeviceFactory --> DriverABI
DriverABI --> DeviceObject
DeviceObject --> DeviceInterface
DeviceInterface --> Protocol
Protocol --> HAS
HAS --> Hardware
TopoMgr -.维护设备树.-> DeviceObject
```
### 核心集成机制
#### 1. CSR配置驱动机制
**CSR (Component Self-Description)** 是设备配置的核心：
```shell
CSR配置文件
├── DDS (Device Description Schema) - 设备描述文件
│ ├── 设备类型定义 (DeviceType)
│ ├── 接口集合声明 (Interfaces)
│ └── 属性默认值 (Properties)
└── SR (Self-Descripition Record) - 自描述记录文件
├── 拓扑路径 (ManagementTopology)
├── 驱动匹配 (Compatible)
└── 连接器信息 (Connector)
```
**工作流程**：
1. devmon读取CSR配置文件
2. 解析设备描述和拓扑关系
3. 根据Compatible字段匹配驱动SO
4. 动态加载对应的驱动库
#### 2. 驱动ABI标准接口
驱动通过标准的C风格ABI接口与devmon交互：
```cpp
// 定义在 include/devmon/driver_abi.h
// 状态码
typedef enum status {
STATUS_OK = 0,
STATUS_ERROR = 1,
STATUS_NOT_FOUND = 2,
STATUS_INVALID_ARG = 3,
STATUS_NOT_IMPLEMENTED = 4,
STATUS_TIMEOUT = 5,
STATUS_BUSY = 6,
STATUS_NO_MEMORY = 7,
} status_t;
typedef void* driver_handle_t; // 每个设备对象一个驱动实例
typedef void* device_config_t; // CSR 共享内存数据对象
// 驱动生命周期函数类型
typedef driver_handle_t (*driver_ctor)(void* service, const char* object_name);
typedef status_t (*driver_init)(driver_handle_t, void* csr_object, void* connector);
typedef status_t (*driver_start)(driver_handle_t);
typedef status_t (*driver_stop)(driver_handle_t);
typedef const char* (*driver_dump)(driver_handle_t device);
typedef struct device_driver {
const char* device_name; // 设备名称
const driver_ctor ctor; // 创建函数
const driver_init init; // 初始化函数
const driver_start start; // 启动函数
const driver_stop stop; // 停止函数
driver_dump dump = nullptr;
} device_driver_t;
// 驱动SO导出符号
extern "C" {
status_t register_device_driver(device_driver_t** device_driver, uint8_t* count);
}
```
**设计优势**：
- **跨编译器兼容**: C接口避免C++名称修饰问题
- **动态加载友好**: 通过dlopen/dlsym机制加载
- **版本隔离**: 不同版本驱动可独立演进
- **调试便利**: 清晰的生命周期管理
#### 3. MC_REFLECT反射机制
MC_REFLECT是一个编译期反射系统，实现属性的自动序列化和动态访问：
**工作原理**：
```cpp
// 1. 定义接口类
class PCIeDevice {
public:
std::string DeviceName;
std::string VendorId;
std::string DeviceId;
uint8_t Bus;
uint8_t Device;
uint8_t Function;
};
// 2. 注册反射信息
MC_REFLECT(PCIeDevice, (),
((DeviceName, "DeviceName"))
((VendorId, "VendorId"))
((DeviceId, "DeviceId"))
((Bus, "Bus"))
((Device, "Device"))
((Function, "Function"))
)
// 3. 运行时动态访问
mc::dict properties;
mc::reflect::to_variant(pcie_device, properties); // 对象 -> JSON
mc::reflect::from_variant(properties, pcie_device); // JSON -> 对象
```
**核心特性**：
- **编译期元数据生成**: 零运行时开销
- **类型安全**: 编译期类型检查
- **双向映射**: C++对象 ↔ JSON/配置文件
- **属性查询**: 运行时枚举对象属性
- **序列化支持**: 自动生成序列化代码
#### 4. 插件化架构
Component Drivers采用分层插件架构：
```shell
drivers/
├── pcie_nic_card/ # PCIe网卡驱动
│ ├── hisi/ # 海思厂商实现
│ │ ├── hi182x/ # Hi182x系列驱动
│ │ │ ├── hi182x_card.h/cpp # 设备对象
│ │ │ ├── hi182x_port.h/cpp # 端口对象
│ │ │ ├── hi182x_om.h/cpp # 光模块对象
│ │ │ ├── hi182x_abi.cpp # ABI导出
│ │ │ └── meson.build # 构建配置
│ │ ├── hi182x_high/ # Hi182x-High系列驱动（同结构）
│ │ ├── hi1822_fc/ # Hi1822 FC系列驱动（同结构）
│ │ ├── hi1825_board/ # 1825大板驱动（同结构）
│ │ ├── interface/ # 接口实现
│ │ │ ├── board.h/cpp # Board接口
│ │ │ ├── cooling.h/cpp # Cooling接口
│ │ │ ├── fru.h/cpp # Fru接口
│ │ │ ├── network_adapter.h/cpp # 网络适配器接口
│ │ │ ├── network_port.h/cpp # 网络端口接口
│ │ │ ├── optical_module.h/cpp # 光模块接口
│ │ │ ├── pcie_card.h/cpp # PCIe卡接口
│ │ │ ├── pcie_device.h/cpp # PCIe设备接口
│ │ │ └── upgrade.h/cpp # 固件升级接口
│ │ └── meson.build
│ ├── wangxun/ # 网迅厂商实现（含 rp1000、ff50xx、sfx00ht 等型号，以及 interface/ 与 interface_pldm/）
│ ├── mellanox/ # 迈络思厂商实现
│ ├── boardcom/ # 博通厂商实现
│ ├── grt/ # grt厂商实现
│ └── mucse/ # mucse厂商实现
└── pcie_gpu_card/ # PCIe GPU驱动
├── innosilicon/ # 芯动科技（awm_m11p）
├── jingjia/ # 景嘉微（jm1100）
├── moorethreads/ # 摩尔线程（mtt_s4000）
├── nvidia/ # NVIDIA（nv_common）
└── vastai/ # 瀚博（vg1000）
```
**层次关系**：
| 层次 | 目录位置 | 职责 | 代码来源 |
|------|---------|------|---------|
| 接口定义层 | mds/ | JSON 模型契约定义 | 手工编写 |
| 生成接口层 | gen/device_tree/interface/ | C++接口基类（dev::gen 命名空间） | 代码生成 |
| 实现接口层 | drivers/.../interface/ | 厂商接口实现（dev 命名空间） | 手工编写 |
| 设备对象层 | drivers/.../{model}/ | 设备对象类 | 手工编写 |
| ABI导出层 | drivers/.../{model}/{model}_abi.cpp | 驱动导出 | 手工编写 |
## 板卡驱动与管理协议关系
### 🔗 驱动-协议绑定架构
板卡驱动与管理协议采用**分层协作**模式，实现硬件抽象与远程管理的完美结合：
```shell
📱 应用管理层: BMC管理应用、监控服务
↓ 标准化API调用
🎯 驱动接口层: PCIe板卡驱动、GPU驱动、传感器驱动
↓ 协议绑定
📡 协议通信层: NCSI over MCTP、MCTP、IMU协议栈
↓ 传输封装
🚌 物理传输层: PCIe传输、I2C传输、Socket通信
↓ 硬件访问
🔧 板卡硬件层: 网卡、GPU、传感器等物理设备
```
### 💡 协议与驱动映射关系
| 板卡类型 | 对应驱动 | 管理协议 | 厂商支持 |
|----------|----------|----------|----------|
| PCIe网卡 | `hi182x_card`, `rp1000_card`, `ff50xx_card` | NCSI over MCTP | hisi, wangxun, mellanox, boardcom, grt, mucse |
| PCIe GPU | `awm_m11p_card`, `jm1100_card` | MCTP | 芯动、景嘉微、摩尔线程、NVIDIA |
| I2C传感器 | 各 chip 驱动（lm75/ina 等） | SMBus/PMBus | 通用 |
| PCIe设备 | `accessor` 访问器 | 标准PCIe | 通用 |
### 🔄 协议栈工作流程
1. **驱动初始化**: 板卡驱动检测硬件BDF信息
2. **协议绑定**: 根据硬件类型绑定对应管理协议
3. **通道建立**: 创建MCTP传输通道和端点
4. **定时任务**: 启动周期性状态监控和数据采集
5. **事件响应**: 处理硬件事件和协议消息
### 设备对象模型
设备对象是Component Drivers的核心抽象，通过MC_OBJECT宏定义其特征：
**基本定义**：
```cpp
class hi182x_card : public mc::engine::object {
public:
// MC_OBJECT(对象类型宏名, 设备类型, 路径模式, 接口集合)
MC_OBJECT(
hi182x_card,
"PCIeNicCard",
"/bmc/dev/Systems/1/PCIeNicCard/${object_name}",
(PCIeDevice)(PCIeDevice_PCIeFunction)(PCIeDevice_Oem)(PCIeDevice_Status)(PCIeCard)(PCIeCard_Oem)(
PCIeCard_Metrics)(NetworkAdapter)(NetworkAdapter_FaultStatus)(Cooling)(NetworkAdapter_Oem)(Board)(
PCIeDevice_Bandwidth)(NetworkAdapter_LogCollection)(Fru)
)
// 协议对象成员
ncsi_over_mctp_hw_ptr m_ncsi_over_mctp_huawei;
imu_ptr m_imu_obj;
smbus_obj_ptr m_smbus_obj;
mc::shared_ptr m_mctp_object;
};
```
**关键特性**：
| 特性 | 说明 | 示例 |
|------|------|------|
| **路径模式** | 支持参数替换的层次化路径 | `/Systems/1/PCIeNicCard/hi182x` |
| **接口组合** | 通过组合多个接口实现功能 | PCIeDevice + NetworkAdapter |
| **属性反射** | MC_REFLECT实现动态属性访问 | 运行时枚举和修改属性 |
| **对象树** | 形成父子关系的设备层次 | Card -> Port -> OpticalModule |
| **D-Bus暴露** | 自动注册到D-Bus总线 | busctl查询设备对象 |
**对象层次示例**：
```shell
/bmc/dev/
└── Systems/
└── 1/
└── PCIeNicCard/
└── hi182x/ # 网卡对象
├── NetworkPort/
│ ├── 0/ # 端口0对象
│ │ └── OpticalModule/ # 光模块对象
│ └── 1/ # 端口1对象
│ └── OpticalModule/
└── properties # 设备属性
```
### 硬件访问服务(HAS)
HAS提供了对底层硬件总线和芯片的统一访问抽象：
**架构层次**：
```shell
应用层 (设备驱动)
↓
芯片驱动层 (Chip抽象)
├── drivers/chip/ # 通用芯片驱动（lm75/ina/pca9545/pca9555 等）
└── drivers/internal/chip/ # 内部芯片基类封装
↓
总线驱动层 (Bus抽象)
├── drivers/bus/ # I2C、I2C-Mux、Hisport 总线驱动
├── drivers/bus/i2c/ # I2C总线
└── drivers/internal/bus/ # 内部总线基类封装
↓
协议/物理层
├── libraries/smbus/ # SMBus协议实现
├── libraries/canbus/ # CAN总线协议
└── 物理硬件
```
**核心组件**：
| 组件 | 路径 | 功能 |
|------|------|------|
| I2C总线 | drivers/bus/i2c/ | I2C通信实现 |
| I2C-Mux总线 | drivers/bus/i2c_mux/ | I2C多路复用 |
| 芯片驱动 | drivers/chip/ | lm75/ina/pca9545 等芯片 |
| SMBus协议 | libraries/smbus/ | SMBus协议实现（smbus/std_smbus） |
| CAN总线协议 | libraries/canbus/ | CAN总线通信 |
| 总线/芯片基类 | drivers/internal/ | 内部基类封装 |
**使用示例**（以 SMBus 总线为例，协议库位于 libraries/smbus/，类在 dev 命名空间）：
```cpp
// SMBus对象需要父对象和显式构造函数
mc::shared_ptr smbus_obj = mc::make_shared(parent);
// 通过总线对象发起读写事务（使用请求构造/响应解包）
mc::mutable_dict req = {{"bus_id", 0x01}, {"slave_addr", 0x50}, {"cmd", "read"}};
auto [ok, rsp] = smbus_obj->send_and_receive(smbus_obj->construct_request_data(req), smbus_obj->get_max_frame_len());
```
### 协议库系统
Component Drivers集成了多种通信协议：
**协议架构**：
```mermaid
flowchart LR
subgraph "应用层"
Driver["设备驱动"]
end
subgraph "协议库层"
NCSI["NCSI协议
网络控制器侧带接口"]
MCTP["MCTP协议
管理组件传输"]
NOM["NCSI over MCTP
混合协议"]
IMU["IMU协议
惯性测量单元"]
end
subgraph "传输层"
PCIeTransport["PCIe传输"]
I2CTransport["I2C传输"]
SocketTransport["Socket传输"]
end
Driver --> NCSI
Driver --> MCTP
Driver --> NOM
Driver --> IMU
NCSI --> SocketTransport
MCTP --> PCIeTransport
MCTP --> I2CTransport
NOM --> MCTP
IMU --> I2CTransport
```
**协议详情**：
| 协议 | 标准 | 主要用途 | 支持厂商 |
|------|------|---------|---------|
| **NCSI** | DMTF标准 | 网卡带外管理 | Intel, 华为, 网迅 |
| **MCTP** | DMTF标准 | 组件间通信传输层 | 通用 |
| **NCSI over MCTP** | 华为扩展 | 扩展NCSI功能 | 华为海思 |
| **IMU** | 自定义 | IPMI获取设备信息 | 通用 |
**NCSI协议特性**：
- 标准命令支持：链路状态、MAC地址、VLAN配置
- OEM命令扩展：厂商特定功能
- 华为扩展命令：固件版本、日志收集、温度监控
**MCTP协议特性**：
- 多种消息类型：控制消息、PLDM、NCSI、NVME等
- 多种物理媒介：PCIe、SMBus、I2C
- 端点管理：路由、绑定、传输
**使用示例**：
```cpp
// NCSI over MCTP使用（dev 命名空间）
// 1. 根据BDF计算物理地址，创建MCTP对象（需要显式构造参数）
mc::shared_ptr mctp_obj = mc::make_shared(this,
mctp::init_phy_addr(pcie_function.BusNumber, pcie_function.DeviceNumber, pcie_function.FunctionNumber),
MCTP_MESSAGE_TYPE::MCTP_MESSAGE_TYPE_NCSI, "");
// 2. 创建并启动传输通道与端点
mctp_obj->create_transport_and_endpoint("mctp", nullptr);
// 3. 创建NCSI over MCTP华为扩展对象
dev::ncsi_over_mctp_huawei nom_hw(mctp_obj);
// 4. 调用OEM扩展接口
uint8_t mac[6] = {0};
nom_hw.get_mac_addr(package_id, channel_id, mac, sizeof(mac));
uint16_t chip_temp = 0;
nom_hw.get_chip_temp(package_id, channel_id, &chip_temp);
```
## 板卡驱动核心价值
### 🎯 1. 硬件抽象统一化
- **价值**: 为不同厂商硬件提供统一编程接口
- **实现**: 继承`PCIeCard`、`NetworkAdapter`等标准基类
- **收益**: 应用层代码与硬件解耦，提高代码复用性
### 🌐 2. 远程管理能力
- **价值**: 实现**带外管理**(Out-of-Band Management)
- **实现**: 集成NCSI/MCTP协议栈，支持远程监控配置
- **收益**: 无人值守数据中心管理，降低运维成本
### 📊 3. 实时状态监控
- **价值**: 提供硬件实时健康状态信息
- **功能**: 温度监控、链路状态、带宽使用、故障检测
- **收益**: 预防性维护，提高系统可靠性99.9%+
### 🔧 4. 多厂商兼容性
- **价值**: 避免硬件厂商锁定
- **支持**: 华为海思（hisi）、网迅（wangxun）、迈络思（mellanox）、芯动（innosilicon）、景嘉微（jingjia）、摩尔线程（moorethreads）、NVIDIA等主流厂商
- **收益**: 提高采购灵活性，降低硬件成本
### 🚨 5. 故障隔离与诊断
- **价值**: 快速故障定位和根因分析
- **实现**: 详细错误码、故障状态码、诊断信息
- **收益**: 故障响应时间缩短80%，减少停机损失
### ⚡ 6. 性能优化支持
- **价值**: 硬件性能调优和资源管理
- **功能**: 带宽管理、功耗控制、负载均衡
- **收益**: 系统性能提升15-30%
## 目录结构与关键功能
### 🔧 硬件驱动层 - component_drivers/drivers/
**核心作用**: 提供各类硬件设备的底层驱动程序实现
```shell
component_drivers/drivers/
├── scanner/ # 设备扫描驱动
│ └── scanner/ # 扫描器核心实现
├── pcie_nic_card/ # PCIe网络接口卡驱动
│ ├── wx/ # 网迅(WX)网卡驱动实现
│ └── hisi/ # 海思(HiSi)网卡驱动实现
├── pcie_gpu_card/ # PCIe图形处理卡驱动
│ └── innosilicon/ # 芯动科技GPU驱动实现
├── bus/ # 系统总线驱动
│ └── i2c/ # I2C总线通信驱动
└── accessor/ # 硬件访问器驱动
└── accessor/ # 统一硬件访问接口
```
**技术特点**:
- 支持多厂商硬件设备
- 统一的驱动接口设计
- PCIe设备专门优化
- 模块化驱动架构
**依赖关系**: 依赖 component_drivers/libraries/ 中的协议库，被 component_drivers/tests/ 测试调用
---
### 📚 协议通信层 - component_drivers/libraries/
**核心作用**: 实现标准化的硬件通信协议和功能库
```shell
component_drivers/libraries/
├── ncsi/ # 网络控制器侧带接口协议库
│ ├── ncsi_protocol.h # NCSI协议核心定义
│ ├── ncsi_socket.h # NCSI Socket通信
│ ├── ncsi_huawei.h # 华为NCSI实现
│ ├── ncsi_wangxun.h # 网迅NCSI实现
│ ├── ncsi_mellanox.h # 迈络思NCSI实现
│ ├── ncsi_mucse.h # mucse NCSI实现
│ ├── ncsi_grt.h # grt NCSI实现
│ └── adapter.h # 协议适配器
├── ncsi_over_mctp/ # NCSI over MCTP混合协议
│ ├── ncsi_over_mctp.h # 基础定义
│ ├── ncsi_over_mctp_standard.h/cpp # 标准实现
│ ├── ncsi_over_mctp_huawei.h/cpp # 华为扩展
│ ├── ncsi_over_mctp_wangxun.h/cpp # 网迅扩展
│ ├── ncsi_over_mctp_mellanox.h/cpp # 迈络思扩展
│ └── ncsi_over_mctp_mucse.h/cpp # mucse扩展
├── mctp/ # 管理组件传输协议库
│ ├── mctp.cpp/.h # MCTP核心功能实现
│ └── pcie_transport.cpp/.h # PCIe传输层实现
├── imu/ # IMU通信库
│ ├── imu.cpp/.h # IMU设备通信接口
│ └── 传感器数据处理
├── smbus/ # SMBus总线协议（smbus/std_smbus/xx）
├── pldm/ # PLDM协议（base/fru/monitor/update + 厂商扩展）
├── nvme/ # NVMe协议（nvme_mi_over_mctp 等）
├── pmbus/ # PMBus电源管理协议（含厂商变种）
├── lldp/ # LLDP链路发现协议
├── canbus/ # CAN总线协议
├── ipmb/ # IPMB协议
└── protocol/ # 通用协议抽象
```
**技术特点**:
- 实现业界标准协议(NCSI/MCTP)
- 支持多厂商协议变种
- 模块化协议栈设计
- 高性能通信优化
**依赖关系**: 被 drivers/ 调用，依赖 include/ 头文件
---
### 🎯 接口定义层 - component_drivers/include/
**核心作用**: 提供统一的头文件接口和API定义
```shell
component_drivers/include/
└── devmon/ # 设备监控接口定义
├── 设备状态监控API
├── 硬件事件回调接口
├── 错误处理机制定义
└── 设备管理接口
```
**技术特点**:
- 统一的API接口规范
- 设备无关的抽象层
- 标准化的错误处理
- 模块间通信接口
**依赖关系**: 被所有模块引用，定义系统接口规范
---
### 🧪 测试验证层 - component_drivers/tests/
**核心作用**: 提供完整的测试框架和验证用例
```shell
component_drivers/tests/
├── main.cpp # 测试主程序入口 (27行)
├── drivers/ # 驱动程序测试用例
│ ├── 单元测试
│ ├── 集成测试
│ └── 性能测试
└── meson.build # 测试构建配置
```
**技术特点**:
- 完整的测试覆盖
- 自动化测试流程
- 性能基准测试
- 持续集成支持
**依赖关系**: 测试 drivers/ 和 libraries/ 模块
---
### ⚙️ 代码生成层 - component_drivers/gen/
**核心作用**: 自动化代码生成和配置管理
```shell
component_drivers/gen/
└── device_tree/ # 设备树相关代码生成
├── 硬件配置自动生成
├── 设备驱动模板生成
└── 配置文件转换
```
**技术特点**:
- 自动化配置生成
- 设备树支持
- 模板化代码生成
- 配置一致性保证
**依赖关系**: 为 drivers/ 生成配置，依赖 mds/ 定义
---
### 📋 模型服务层 - component_drivers/mds/
**核心作用**: 定义数据模型和服务接口规范
```shell
component_drivers/mds/
├── model.json # 数据模型定义 (3行精简)
└── service.json # 服务接口定义 (31行)
```
**技术特点**:
- JSON格式的模型定义
- 标准化服务接口
- 版本化管理
- 接口文档自动生成
**依赖关系**: 为 gen/ 提供生成源，被 libraries/ 引用
---
### 🏗️ 构建输出层 - component_drivers/builddir/
**核心作用**: Meson构建系统的输出和中间文件
```shell
component_drivers/builddir/
├── build.ninja # Ninja构建脚本 (942行)
├── compile_commands.json # 编译命令数据库 (867行)
├── .ninja_log # 构建日志 (184条记录)
├── meson-info/ # Meson构建信息
├── meson-logs/ # 详细构建日志
├── drivers/ # 编译后的驱动模块
├── libraries/ # 编译后的库文件
└── tests/ # 编译后的测试程序
```
**技术特点**:
- 增量编译支持
- 并行构建优化
- 依赖关系管理
- 交叉编译支持
---
### 📦 依赖管理层 - component_drivers/subprojects/
**核心作用**: 管理外部依赖和子项目
```shell
component_drivers/subprojects/
├── libmcpp/ # C++核心库依赖
└── libmcpp.wrap # 依赖包装配置 (8行)
```
**技术特点**:
- Meson Wrap系统
- 版本化依赖管理
- 自动依赖解析
- 源码级依赖支持
---
### 📖 文档说明层 - component_drivers/docs/
**核心作用**: 项目技术文档和开发指南
```shell
component_drivers/docs/
├── 1-项目概览.md # 项目概览文档 (本文档)
├── 架构设计文档
├── API参考文档
└── 开发者指南
```
## 架构层次关系
### 🏗️ 整体分层架构
```shell
📱 应用管理层 [BMC应用] [监控服务] [管理工具] [测试程序]
↓ RESTful API / D-Bus调用
🎯 服务接口层 [设备监控服务] [模型服务] [配置服务] [事件服务]
↓ 对象模型调用
🔌 硬件驱动层 [网卡驱动] [GPU驱动] [总线驱动] [扫描器驱动]
↓ 协议绑定
📡 协议通信层 [NCSI] [MCTP] [IMU] [NCSI over MCTP]
↓ 传输封装
🚌 传输抽象层 [PCIe传输] [I2C传输] [Socket传输] [串口传输]
↓ 硬件访问
🔧 硬件设备层 [PCIe设备] [I2C设备] [传感器] [其他硬件]
```
### 🔄 驱动-协议交互流程
```mermaid
sequenceDiagram
participant App as 管理应用
participant Driver as 板卡驱动
participant Protocol as 管理协议
participant Hardware as 物理硬件
App->>Driver: 启动板卡驱动
Driver->>Protocol: 绑定管理协议
Protocol->>Hardware: 建立通信通道
Hardware-->>Protocol: 硬件信息响应
Protocol-->>Driver: 状态数据更新
Driver-->>App: 设备状态上报
loop 定时监控
Driver->>Protocol: 轮询硬件状态
Protocol->>Hardware: 发送查询命令
Hardware-->>Protocol: 返回状态数据
Protocol-->>Driver: 解析协议数据
Driver-->>App: 推送状态变化
end
```
## 构建配置
### 主要构建选项（meson_options.txt）
- `meson_build`: 是否在Meson环境中构建（默认：true）
- `tests`: 是否构建测试用例（默认：true）
- `install_inc_dir`: 头文件安装目录（默认：include）
- `enable_conan_compile`: 是否开启共享内存编译（默认：false）
- `enable_coverage`: 是否启用代码覆盖率统计（默认：false）
- `fast_debug_info`: 压缩调试信息以降低 g++ 内存占用（默认：true）
- `use_mold`: 使用 mold 链接器（默认：true）
- `use_icf`: 链接期相同代码折叠（默认：true）
- `use_pch`: 为高频模板头启用全局预编译头（默认：false）
- `inlines_hidden`: 隐藏内联成员/模板实例导出符号，缩减 .dynsym/.dynstr（默认：true）
- `unidev`: 启用 unidev 时编译 csr1/connector 相关驱动（默认：false）
- `chipv2_enable`: 启用 chipv2 时编译 hisport2 相关驱动（默认：false）
### 项目配置特性
- **编程语言**: C++17
- **构建系统**: Meson + Ninja
- **编译器标准**: GCC/Clang，支持交叉编译
- **依赖管理**: Conan + Meson混合模式
- **支持架构**: x86_64, armv8
### 编译特性
- 支持PIC（位置无关代码）
- 警告级别：level 3
- 特殊编译选项：
- `-fpermissive` - 允许一些非标准扩展
- `-Wno-deprecated-copy` - 忽略弃用的拷贝警告
- `-fno-strict-aliasing` - 禁用严格别名优化
## 快速开始
```bash
# 配置构建环境
meson setup builddir
# 编译项目
meson compile -C builddir
# 运行测试
meson test -C builddir
# 清理重新构建
rm -rf builddir; meson setup builddir; meson compile -C builddir
```
## 项目特点
### 🚀 技术特性
1. **模块化设计**: 驱动程序和库文件分离，便于维护和复用
2. **多厂商支持**: 支持华为海思、网迅、迈络思、芯动、景嘉微、摩尔线程等多家硬件厂商
3. **标准协议**: 实现NCSI、MCTP等标准化硬件管理协议
4. **灵活构建**: 支持本地和交叉编译，适配不同平台需求
5. **完整测试**: 提供完整的测试框架和用例
### 🎯 核心优势
- **统一抽象**: 不同厂商硬件通过统一接口访问
- **远程管理**: 支持带外管理，实现无人值守运维
- **实时监控**: 提供硬件健康状态实时监控
- **故障诊断**: 详细的错误码和诊断信息支持
- **性能优化**: 硬件资源管理和性能调优能力
## 主要应用场景
### 🏢 数据中心管理
- **服务器硬件管理**: PCIe板卡的生命周期管理
- **网络设备监控**: 网卡状态、链路质量、带宽使用
- **故障预警**: 温度异常、链路中断、性能下降告警
- **远程运维**: 带外管理通道的远程诊断和配置
### 🔧 嵌入式系统
- **嵌入式设备驱动**: ARM、x86平台的板卡驱动开发
- **传感器数据采集**: IMU、温度、电压等传感器管理
- **工业控制**: 工控板卡的实时监控和控制
### 🌐 网络通信
- **PCIe设备通信**: 高速PCIe通道的数据传输
- **网络设备侧带管理**: NCSI协议的网卡管理
- **协议栈集成**: MCTP、NCSI等标准协议的实现
### 📊 系统监控
- **硬件健康监控**: 实时温度、电压、功耗监控
- **性能分析**: 带宽使用、延迟统计、吞吐量分析
- **日志收集**: 硬件事件和错误日志的集中管理
---
**Component Drivers** - 为openUBMC提供强大的硬件管理能力 🚀
---
# 部件驱动自发现机制设计
> URL: https://openubmc.cn/docs/zh/latest/component_driver/concept_principle/component_driver_discovery.html
> Language: zh
部件驱动自发现是南向硬件管理中，根据槽位在位状态自动识别部件、选择 CSR 并加载对应驱动 SO 的机制。本文面向驱动适配者和南向框架维护者，说明发现触发、SR 选择、热插拔卸载与排障方法。
# 认识部件驱动自发现
运行时入口在 Connector，驱动匹配与 `dlopen` 在 devmon。代码以 component_drivers 仓的 Connector、Scanner、EEPROM 以及 `include/devmon/driver_abi.h` 为准。运行时不按 PCIe VID 或 DID 搜索 DDS 文件来加载驱动。
适配步骤见后续各部件驱动适配指南；总线与芯片接线见《[总线芯片驱动开发指南](../general_guide/bus_chip_driver_guide.md)》。
> [!NOTE]说明
>
> 本文只写发现触发、SR 选择与加载路径。DDS 代码生成与出包步骤见各品类适配指南。
## 目录
1. [范围与术语](#范围与术语)
2. [端到端时序](#端到端时序)
3. [触发条件](#触发条件)
4. [SR 选择](#sr-选择)
5. [EEPROM 与 LoadStatus](#eeprom-与-loadstatus)
6. [框架侧加载](#框架侧加载)
7. [适配检查清单](#适配检查清单)
8. [故障排查](#故障排查)
9. [附录（对照源码）](#附录对照源码)
---
## 范围与术语
底板或上级板的 CSR 先实例化槽位 Connector。Connector 在部件在位后交出一份 SR JSON，devmon 再按 SR 里的 `Unit.Compatible` 加载对应 SO，并执行 `ctor`、`init`、`start`。
### 仓边界
```mermaid
flowchart LR
subgraph 驱动仓["component_drivers"]
Conn["libConnector.so
在位开关 / 选 SR"]
Scan["libScanner.so
周期读在位脚"]
Acc["libAccessor.so
按需读寄存器"]
Eep["libEeprom.so
GetSRData"]
Card["业务驱动 SO"]
end
subgraph 框架["devmon"]
Disc["full_discovery
platform.sr / root.sr"]
Add["AddDeviceWithData
RemoveDevice"]
Match["Compatible 到 dlopen"]
Topo["ManagementTopology
内部 Bus 与 Chip"]
end
Disc --> Conn
Scan -->|"Presence 引用"| Conn
Eep -->|"BoardId 与 SR JSON"| Conn
Acc -->|"可选：Id 或 Presence"| Conn
Conn -->|"SR 与 Connector 字典"| Add
Add --> Match
Match --> Card
Add --> Topo
```
| 层 | 组件 | 职责 |
| ---- | ---- | ---- |
| 发现入口 | component_drivers 的 `libConnector.so` | 监听在位、选择 SR、调用 Devmon。 |
| 在位采集 | Scanner、Accessor | 把硬件在位或 BoardId 同步到属性。 |
| 身份与 SR 原文 | EEPROM | 提供 `GetSRData`、头解析与验签。 |
| 解析与加载 | devmon | 选择 CSR、执行 `dlopen`、建对象树、卸载对象。 |
| 业务驱动 | 各品类 SO | 被加载后实现网卡、GPU、电源等接口。 |
### 术语
| 术语 | 含义 |
| ---- | ---- |
| CSR | 部件自描述的总称。运行时加载的是 SR JSON（来自文件或 EEPROM）。 |
| SR | Service Record。扩展名为 `.sr`，或位于 EEPROM 内的 JSON，含 `Unit`、`Objects`，常含 `ManagementTopology`。 |
| DDS | Device Description Schema（`.dds`）。定义对象路径与接口，用于代码生成，不作为运行时驱动匹配键。 |
| Connector | 槽位对象。`Presence` 为 1 时加载下级 SR，为 0 时卸载。 |
| Presence | Connector 在位。取值为常量 1，或 `#/Scanner_xxx.Value` 等引用。 |
| IdentifyMode | 下级身份识别方式。代码里只有 3 走 EEPROM；1 与 2 走本地 `.sr`。 |
| Compatible | SR 的 `Unit.Compatible[]`。按序尝试 `lib${name}.so`，逗号会先换成下划线。 |
| CSR1 与 CSR2 | SR 顶层 `FormatVersion` 小于 5.0 走 CSR1 的 `device_loader`；大于或等于 5.0 走 CSR2 的 `device_manager`。 |
| LoadStatus | Connector 加载结果。0 表示成功，255 表示默认或已卸载，其余为错误码。 |
DDS 文件名规则（如 `14140130_[VID][DID]_[SVID][SSID].dds`）见各品类适配指南与《[部件驱动接口模型设计](../general_guide/interface_model_spec.md)》，本文不把它当成发现算法。
---
## 端到端时序
### 启动到首次加载
```mermaid
sequenceDiagram
participant HW as hwdiscovery
participant Root as root.sr
participant Eep as Eeprom
participant Scan as Scanner
participant Conn as Connector
participant Dev as Devmon
HW->>Root: full_discovery：先 platform.sr（00）再 root.sr（01）
Root->>Eep: ctor / init / start
Note over Eep: CSR2 的 start 会解析 EEPROM 头并预热 SR 缓存
CSR1 的 start 不访问硬件
Root->>Scan: ctor / init / start
Root->>Conn: ctor / init（订阅 Presence.changed）
Conn->>Conn: start：预热 SR 缓存
alt Presence 已是 1（常量或已被同步）
Conn->>Dev: 异步 try_load_device，再 AddDeviceWithData
else Presence 仍为 0（常见：CSR1 Scanner 尚未扫到）
Conn-->>Conn: 等待 Presence.changed
end
Scan->>Conn: Value 变为 1 后同步到 Presence
Conn->>Conn: resolve_sr_data
Conn->>Dev: AddDeviceWithData（sr，connector 字典）
Dev->>Dev: Compatible 到 dlopen，再 ctor、init、start
```
`discovery_service` 在 hwproxy 就绪后调用 `discovery::full_discovery`：先加载 `platform.sr`（position 为 `"00"`），再加载 `root.sr`（`"01"`，带 `SystemId=1`）。CSR 文件在镜像、`/data/opt/bmc/sr/gold`、`/data/opt/bmc/sr/temp` 之间按 `DataVersion` 择优。
root SR 描述底板拓扑，包括 I2C、MUX、EEPROM、Scanner、Accessor 与槽位 Connector。每个对象同样经 `Compatible` 加载对应 SO。Connector 的 `start()` 只做两件事：预热 SR 缓存、检查初始 Presence。
### 热插拔
```mermaid
stateDiagram-v2
[*] --> 未在位: Presence 为 0
未在位 --> 加载中: Presence 变为 1
加载中 --> 已加载: AddDeviceWithData 成功
LoadStatus 为 0
加载中 --> 失败: LoadStatus 为 1 到 7
失败 --> 加载中: Reload 或再次 Presence 为 1
已加载 --> 未在位: Presence 变为 0
RemoveDevice，LoadStatus 为 255
已加载 --> 加载中: Reload
```
- **插入**：`Presence.changed` 变为 1 后调用 `try_load_device()`。同一 `GroupPosition` 已存在时，devmon 跳过重复创建。
- **拔出**：变为 0 后调用 `RemoveDevice`，并置 `m_require_eeprom_refresh_on_next_load` 为 true。下次插入跳过 Connector 缓存，重新读 Chip。
- 拔出时不会 `dlclose` 业务 SO。工厂缓存驱动句柄；卸载的是设备对象，不是 `.so` 文件。
下级 SR 里可以再定义 Connector，形成主板到背板、再到硬盘或电源的递归发现。
---
## 触发条件
实现位于 component_drivers 仓的 `drivers/connector/connector/connector.cpp`（生命周期）与 `interface/i_connector.cpp`（信号与加载）。
### Connector 生命周期
| 阶段 | 做什么 | 不做什么 |
| ---- | ---- | ---- |
| `init` | 用 `from_variant` 灌入 CSR，并订阅 `Presence.property_changed()`。 | 不读 EEPROM，不调用 AddDevice。 |
| `start` | 调用 `preload_sr_cache()`；若 `Presence` 为 1，则 `mc::runtime::post(try_load_device)`。 | preload 失败不改 `LoadStatus`。 |
| `stop` | 清 SR 缓存；下次必须重读 EEPROM。 | 无。 |
对象表中必须有名为 Devmon 的对象，否则 `try_load_device` 与 `RemoveDevice` 会打错误日志后返回。调用的方法是 `AddDeviceWithData(sr_data, connector_dict)` 与 `RemoveDevice(connector_dict)`。
Connector 对象层还有未出现在 `bmc.kepler.Connector` 接口上的属性：`Chip`（EEPROM 引用）、`Container`、`Position`、`IdChipAddr`、`CSRVersion`。IdentifyMode 为 3 时靠 `Chip` 调用 `GetSRData`。
### Presence 来源
CSR 示例：
```json
"Presence": "#/Scanner_BoardPresence.Value"
```
| 来源 | 行为 | 适用 |
| ---- | ---- | ---- |
| 常量 1 | `start()` 时就会异步加载。 | 永远在位的部件。 |
| `#/Scanner_xxx.Value` | Scanner 周期读 Chip 的 BitIO 或 BlockIO，防抖后执行 `Value.set_value`。 | 热插拔（推荐）。 |
| Accessor 的 `Value` | 读属性才访问硬件，无定时器。 | 更适合绑定 `Id`，不适合作为热插拔 Presence。 |
CSR2 Scanner（`drivers/scanner/`）按 `Period` 毫秒扫描。CSR1 Scanner（`drivers/csr1/scanner/`）额外有：
- 默认约 30s 启动延迟（环境变量 `SCANNER_PERIOD_DELAY_TIME`）；
- `SuccessDebounceCount` 与 `FailureDebounceCount`（默认 10）满足后才改 `Value`；
- 同芯片偏移可合并，只让一个 master 读硬件。
> [!NOTE]说明
>
> 把 Presence 绑到 CSR1 Scanner 时，Connector 的 `start()` 那一刻 Presence 常常仍为 0。真正加载发生在 Scanner 第一次把 `Value` 写成 1 之后。
### Reload 接口
接口为 `bmc.kepler.Connector.Reload(Bom, Id, AuxId, IdentifyMode)`。
1. 若当前 `LoadStatus` 为 SUCCESS，先 `RemoveDevice`；
2. 写入非空的 Bom、Id、AuxId 和新的 IdentifyMode；
3. 清 Connector 缓存与本地 `csr_version.json` 缓存，并置 refresh；
4. 最多两次 `try_load_device`。
用于改识别方式或强制换一份 SR，而不依赖拔插。
---
## SR 选择
实现为 `IConnector::resolve_sr_data`。单测见 `tests/drivers/connector/test_connector.cpp`。
### 本地文件名
目录默认 `/opt/bmc/sr`，可用环境变量 `CONNECTOR_SR_DIR` 覆盖。
```text
{dir}/{Bom}_{Id}_{AuxId}.sr
```
缺 Bom 或缺 AuxId 则少对应段。版本表 `{dir}/csr_version.json` 用去掉扩展名的文件名作 key，读取 `DataVersion`。
### IdentifyMode
| 值 | 规格含义 | 代码行为 |
| ---- | ---- | ---- |
| 1 | BoardId 可读 | 不读 EEPROM。用 CSR 里的 Bom、Id、AuxId 拼本地 `.sr`。Id 常由 `#/Accessor_xxx.Value` 注入。 |
| 2 | BoardId 不可读（由配置上报） | 同上，走本地文件。 |
| 3 | EEPROM 自描述 | 读 Chip 的 BoardId 与 SR，再和本地比版本。 |
常量为 `identify_mode::EEPROM = 3`。其它值全部走本地文件。
### IdentifyMode 为 3 时的决策
```mermaid
flowchart TD
Start[IdentifyMode 为 3] --> Fast{CSR2 SelfDescriptionRecord.BoardId 非空}
Fast -->|是| Id1[用该 BoardId 与 DataVersion 作身份
尚不调用 GetSRData]
Fast -->|否| E2P[get_e2p_csr_data]
E2P --> CSR1{bmc.kepler.EepromData.GetSRData 成功且 UID 非空}
CSR1 -->|是| Id2[身份为 UID]
CSR1 -->|否| CSR2[bmc.dev.Chip.SelfDescriptionRecord.GetSRData]
CSR2 --> Id3[身份为 BoardId]
E2P --> Fail{芯片返回非 SUCCESS}
Fail -->|是| Err[LoadStatus 等于芯片完成码
禁止降级本地]
Fail -->|SUCCESS 但身份空| LocalId[用 CSR 配置的 Id 拼本地路径]
Id1 --> Cmp[比较 DataVersion]
Id2 --> Cmp
Id3 --> Cmp
Cmp --> Pick{EEPROM 版本非空 且 本地空或 EEPROM 不低于本地}
Pick -->|是| UseEep[源为 EEPROM]
Pick -->|否| UseLoc[源为本地]
UseLoc --> Stamp{仍有 EEPROM 版本}
Stamp -->|是| StampY[把 payload.DataVersion 改写成 EEPROM 版本]
Stamp -->|否| File[读本地 sr]
UseEep --> Soft{FormatVersion 在 3.0 到 5.0 之间}
Soft -->|是| Merge[与同名_soft.sr 合并 Objects 与 Topology]
Soft -->|否| Done[得到 SR]
Merge --> Done
StampY --> File
File --> Done
LocalId --> File
```
- **快路径**：CSR2 的 `eeprom_object::start()` 已解析 128 Byte头并填好 `BoardId` 与 `DataVersion` 时，Connector 先用属性做身份和版本比较，需要 payload 时再 `GetSRData`（通常打中芯片缓存）。
- **慢路径**：CSR1 EEPROM 的 `start()` 不读硬件，BoardId 为空，必然走到 `GetSRData`。先走 CSR1 接口，失败再走 CSR2。
- `version_compare(a, b)` 表示 a 大于或等于 b（`major.minor`）。相等也选 EEPROM。本地严格更新则用本地内容，但对外 `DataVersion` 写成 EEPROM 的版本。
- soft 合并仅针对 EEPROM 源，且 `FormatVersion` 在 3.0（含）到 5.0（不含）之间。同名子字典以 soft 为底、EEPROM 覆盖。合并失败仍返回未合并的 EEPROM 数据。大于或等于 5.0 视为设备树 CSR，不再拆 soft。
> [!WARNING]注意
>
> 芯片返回硬件访问失败、验签失败或格式错误时，禁止降级到可能属于另一块板的本地文件。仅当完成码为成功但身份为空时，才使用 CSR 里配置的 Id。
### 三层缓存
| 层 | 位置 | 命中条件 | 失效 |
| ---- | ---- | ---- | ---- |
| 芯片内存 | `chip_eeprom::m_sr_cache` | 签名区一致，且 BoardId 与版本一致。 | 头解析失败，或调用 `invalidate_sdr_cache`。 |
| 芯片磁盘 | `/data/opt/bmc/sr/backup/{uid}.bin` | 文件尾部签名与当前签名区一致。 | 签名变化。 |
| Connector | `IConnector::m_sr_cache` | 来源、board_id、两个版本与文件路径一致。 | Presence 为 0、Reload，或 refresh 标志。 |
`m_require_eeprom_refresh_on_next_load` 初始为 true；preload 成功置 false；拔出或 Reload 再置 true。为 true 时跳过 Connector 缓存。缓存命中且 IdentifyMode 为 3 时，正式 load 可以零次访问 Chip。
---
## EEPROM 与 LoadStatus
设备树入口：
- CSR2：`bmc.dev.Chip.SelfDescriptionRecord.GetSRData` 返回 `(uint8_t status, string json)`，同时刷新 `FormatVersion`、`DataVersion`、`BoardId`。
- CSR1：`bmc.kepler.EepromData.GetSRData` 返回 `(status, json, uid)`。
内部均落到 `chip_eeprom::get_sdr_data`（`drivers/internal/chip/chip_eeprom/eeprom.cpp`）。访问前锁 host_bus。
### 头与流水线
EEPROM 偏移以 8 Byte步长计。开头 128 Byte含 UID、`sign_offset`、`csr_offset`、CRC32。由此得到：
- `BoardId` 与 CSR1 的 uid 等于头内 24 Byte UID 字符串；
- `FormatVersion` 等于 `{ver}.00`；
- `DataVersion` 等于 `{sr_version_high}.{sr_version_low:02}`。
`get_sdr_data` 顺序：解析头，读签名区，查内存或磁盘缓存，读被签名区。签名区非全 0 则做 ECDSA-SHA256 验签（先内置 P-256 公钥，失败再读 `/opt/bmc/trust/partner/device_desc_pubkey.bin`），再从 `csr_offset` 解 gzip JSON。签名全 0 视为老硬件无签名。部分遗留 UID 在白名单内，签名参数非法或验签失败也可放行（不备份）。
解压失败返回完成码 4（获取 SR 失败），此时 Connector 才允许转本地 CSR。页读写与 CRC 实现细节见 EEPROM 源码，本文不展开。
### LoadStatus
与 EEPROM 完成码对齐，由 Connector 在正式 load 时写入（preload 失败不改）：
| 值 | 名称 | 典型原因 |
| ---- | ---- | ---- |
| 0 | SUCCESS | `AddDeviceWithData` 成功。 |
| 1 | HARDWARE_ACCESS_FAIL | I2C、总线或前级 MUX 失败。 |
| 2 | SIGNATURE_VERIFY_ERROR | 验签失败且不在白名单。 |
| 3 | DATA_FORMAT_ERROR | 头 CRC 失败、非 JSON 或 gzip，或本地 JSON 损坏。 |
| 4 | LOCAL_FILE_ERROR | `.sr` 不存在或读失败。 |
| 5 | OBJECT_PARSE_ERROR | 预留。 |
| 6 | INTEGRITY_VERIFY_ERROR | 预留。 |
| 7 | FORMAT_VERSION_ERROR | 预留。 |
| 255 | DEFAULT | 初始、已 Remove，或 Reload 清状态。 |
`try_load_device` 在拿到 SR 后调用 AddDevice；invoke 抛异常时打错误日志，不一定改写 `LoadStatus`（成功路径才置 0）。拿不到 SR 时把上述错误码写到 `LoadStatus`。
---
## 框架侧加载
Connector 交出 SR 之后的工作在 devmon。`FormatVersion` 小于 5.0 走 CSR1 的 `device_loader`；否则走 CSR2 的 `device_manager::add_device`。
### 从 Compatible 到 SO
```mermaid
flowchart LR
SR["SR 的 Unit.Compatible"] --> Loop["按列表依次尝试"]
Loop --> Name["逗号换成下划线"]
Name --> File["lib 加 name 加 .so"]
File --> Flash["image、gold、temp 按版本择优"]
Flash --> ABI["dlsym register_device_driver"]
ABI --> Type["device_name 等于 Unit.Type"]
```
- `Compatible: ["hisi_182x"]` 对应 `libhisi_182x.so`。
- `Compatible: ["Mellanox,CX5"]` 对应 `libMellanox_CX5.so`。
- CSR1 还会尝试 `libCsr1${name}.so`。
- 列表从前到后，第一个加载成功的即停；全部失败则解析失败，设备不会 start。
- SO 候选来自驱动安装目录与 `/data/opt/bmc/drivers/gold`、`temp`（`flash_driver_store`）。实现细节以 devmon 为准。
`Unit.Type` 必须等于该 SO 注册的某个 `device_name`（如 `PCIeNicCard`）。对象实例名来自 `Unit.Name`，并可按 Connector 的 position 重命名以保证全局唯一。
### ManagementTopology
SR 的 `ManagementTopology` 把模板总线名映射到 Connector 字典里的 `Buses`（字符串数组，元素是底板已有总线对象名）。devmon 抽出可达的 Bus 与 Chip，在 `device_manager`（component_drivers 的 `libInternal.so`）里创建内部对象并接线 `left_bus`、`host_bus`、`left_chip`。设备树 SO 的 `init()` 不创建内部芯片，只按 `object_name` 执行 `find_object`。EEPROM 能 `GetSRData` 的前提是这条拓扑已经接好。详见《[总线芯片驱动开发指南](../general_guide/bus_chip_driver_guide.md)》。
### ABI
以 component_drivers 仓的 `include/devmon/driver_abi.h` 为准。每个 SO 必须用 `extern "C"` 导出 `register_device_driver`。
```cpp
typedef enum status {
STATUS_OK = 0,
STATUS_ERROR = 1,
STATUS_NOT_FOUND = 2,
STATUS_INVALID_ARG = 3,
STATUS_NOT_IMPLEMENTED = 4,
STATUS_TIMEOUT = 5,
STATUS_BUSY = 6,
STATUS_NO_MEMORY = 7,
} status_t;
struct device_driver {
const char* device_name;
const driver_ctor ctor; // (service, object_name) -> handle
const driver_init init; // (handle, csr_object, connector)
const driver_start start;
const driver_stop stop;
driver_dump dump; // 可为 nullptr
};
```
一个 SO 可注册多种 `device_name`。以 `drivers/pcie_nic_card/hisi/hi182x/hi182x_abi.cpp` 为例，同一库导出 `PCIeNicCard`、`NicPort`、`OpticalTransceiver`。空指针参数返回 `STATUS_ERROR`，不要使用已不存在的 `STATUS_INVALID_PARAM`。
`ctor` 只创建对象并设置 service 与 object_name。`init` 灌入 CSR、建子对象关系，不开定时器和协议。`start` 才启动业务。`stop` 停业务并清理。Connector 自身就是这个模型：`init` 订阅信号，`start` 才检查 Presence。
热插拔 `RemoveDevice` 对主对象调 `stop`，并尝试 stop 同 position 下的子类型对象，不会因此卸载 `.so`。若调用 `device_driver::unload()`，必须先清空 `m_devices` 再 `dlclose`，因为函数指针在库内。
### 属性注入
CSR 的 `Objects` 按接口名组织，经 `MC_REFLECT` 与 `from_variant` 映射到对象属性。占位符（`${Slot}`、`#/Scanner.Value` 等）由 devmon 的 CSR 解析与引擎引用机制处理，不是 Connector 里的独立函数。Connector 传给框架的字典字段包括：`ObjectName`、`Bom`、`Slot`、`GroupId`、`GroupPosition`、`Presence`、`Id`、`AuxId`、`Buses`、`SystemId`、`ManagerId`、`SilkText`、`Type`、`IdentifyMode`、`ChassisId`、`LoadStatus`、`Container`、`Chip`。缺省时用默认值，避免类型转换失败。
---
## 适配检查清单
驱动写完却加载不上时按此核对，不必先怀疑 VID 或 DID 扫描。
底板或上级 CSR：
- [ ] 有对应槽位的 Connector 对象，且 `Compatible` 能加载到 `libConnector.so`。
- [ ] `Presence` 有来源：常量 1，或指向已创建的 Scanner 的 `Value`。
- [ ] `IdentifyMode` 与板类型一致：EEPROM 自描述用 3；否则保证本地 `.sr` 的 Bom、Id、AuxId 能拼出文件。
- [ ] IdentifyMode 为 3 时，`Chip` 指向已接线的 EEPROM 对象（`host_bus` 与 `left_bus` 非空）。
- [ ] `Buses` 列出下级 SR 拓扑要用到的底板总线名。
- [ ] `GroupPosition` 在同一 CSR 内不重复。
下级 SR 与驱动 SO：
- [ ] 文件在 `/opt/bmc/sr/`（或 gold、temp、EEPROM）；IdentifyMode 不是 3 时，`csr_version.json` 有对应条目。
- [ ] `Unit.Type` 等于 SO 里某个 `device_name`。
- [ ] `Unit.Compatible` 能落到已安装的 `libxxx.so`（注意逗号转下划线）。
- [ ] `Objects` 接口名与 `MC_REFLECT`、DDS 生成的 `gen::` 接口一致。
- [ ] 需要热插拔时，不要把 Presence 只绑在无定时器的 Accessor 上。
品类目录、DDS 命名与出包步骤仍以《[网卡驱动适配指南](../nic_adapt/south_nic_driver_adapt.md)》至《[风扇电源驱动适配指南](../fan_power_adapt/fan_power_driver_adapt.md)》为准。
---
## 故障排查
### 按 LoadStatus
| LoadStatus | 先查 |
| ---- | ---- |
| 255 且部件已在位 | Presence 是否从未变成 1（Scanner 延迟或防抖）；对象表有无 Devmon。 |
| 1 | I2C、MUX、EEPROM 总线；Chip 引用是否为空。 |
| 2 | 验签公钥、是否老 UID 白名单、签名区是否损坏。 |
| 3 | EEPROM 头 CRC、gzip 或 JSON；或本地 `.sr` 不是合法 JSON。 |
| 4 | `/opt/bmc/sr/{Bom}_{Id}_{AuxId}.sr` 是否存在；Id 是否已从 EEPROM 改写导致文件名变化。 |
| 0 但业务对象没有 | AddDevice 后 Compatible 与 `Unit.Type` 是否匹配；查看 devmon 侧加载日志。 |
### 日志关键字
- `[self-discovery]` 与 `[self-release]`：Presence 边沿。
- `SR source=EEPROM` 与 `SR source=LOCAL`：最终选用哪份数据。
- `merge soft data`：soft 合并是否成功。
- `Devmon.AddDeviceWithData failed`：框架解析或建对象失败（此时 SR 已选出）。
### Connector dump
`LoadStatus` 为 SUCCESS 时，`Connector::dump()` 在标准属性（`.` 前缀）之外输出 `-` 前缀字段，包括 `SourcePath`、`SoftSourcePath`、`DataSource`（`EEPROM`、`LOCAL` 或 `NA`），以及有效、EEPROM、本地的 FormatVersion 与 DataVersion。hwdiscovery 的 discovery dump 会汇总各 Connector，并补 flash 副本完整性字段。
> [!WARNING]注意
>
> 不要用主机上的 `lspci` 或 `i2cdetect` 作为 BMC 南向自发现的诊断手段。
---
## 附录（对照源码）
路径相对于对应 Git 仓根目录。component_drivers 见 [GitCode 仓库](https://gitcode.com/openUBMC/component_drivers)；devmon 见 [GitCode 仓库](https://gitcode.com/openUBMC/devmon)。
| 主题 | 路径 |
| ---- | ---- |
| Connector 状态机、SR 选择 | `drivers/connector/connector/interface/i_connector.cpp` |
| Connector ABI 与 dump | `drivers/connector/connector/connector.cpp`、`connector_abi.cpp` |
| CSR2 EEPROM 的 GetSRData | `drivers/chip/interface/i_self_description_record.cpp` |
| 头解析、验签、backup | `drivers/internal/chip/chip_eeprom/eeprom.cpp` |
| CSR1 GetSRData（start 不读硬件） | `drivers/csr1/chip/common/interface/i_eeprom_data.cpp`、`drivers/csr1/chip/eeprom/eeprom.cpp` |
| CSR2 与 CSR1 Scanner | `drivers/scanner/scanner/`、`drivers/csr1/scanner/scanner/` |
| Accessor | `drivers/accessor/accessor/` |
| ABI 头文件 | `include/devmon/driver_abi.h` |
| 启动发现 | `libs/hwdiscovery/src/discovery/discovery.cpp`（devmon） |
| Add 与 Remove | `libs/hwdiscovery/src/discovery/hwdiscovery_root_interface.cpp`（devmon） |
| Compatible 与拓扑 | `libs/common/src/device/csr.cpp`、`manager.cpp`（devmon） |
| SO 加载与 flash 择优 | `libs/common/src/device_driver.cpp`、`flash_driver_store.cpp`（devmon） |
| Connector 行为单测 | `tests/drivers/connector/test_connector.cpp` |
---
# 南向风扇电源驱动适配指南
> URL: https://openubmc.cn/docs/zh/latest/component_driver/fan_power_adapt/fan_power_driver_adapt.html
> Language: zh
# 南向风扇电源驱动适配指南
> 南向驱动是基于硬件组件驱动程序框架，采用分层架构设计，支持多种设备类型和通信协议。本文档面向风扇和电源适配的设备驱动开发者，提供从设计到实现的完整开发流程，并基于现有代码实例分析，提供一篇快速适配的开发指南。
>
> 章节总览与分册选型见《[部件驱动适配指南](https://gitcode.com/openUBMC/component_drivers/blob/main/docs/4-部件驱动适配指南.md)》。电源接口契约见 `dmc/intf/bmc/dev/PowerSupply*`（含 `Control/Metrics/Status/Oem/LogCollection/...` 子接口）；电源对象路径与接口组合见 `dmc/path/bmc/dev/PowerSupply/PowerSupply.json`；风扇部件对象见 `dmc/path/bmc/dev/Fan/{Fan,Fans,FanType}.json`（Fan 对象可选 `bmc.dev.Fru` / `bmc.dev.PCB` / `bmc.dev.Temperature`，CESA 表 58）；总览：《[Device Management Contract](https://gitcode.com/openUBMC/component_drivers/blob/main/docs/3-DeviceMgmtContract.md)》。
## 1. 概述
### 1.1 什么是南向风扇电源驱动适配
南向风扇电源驱动适配是指在 BMC 系统中，为不同厂商的电源（PSU）设备提供统一的驱动程序接入方案，使 BMC 能够管理和监控电源设备。电源设备通常包含内置风扇，因此本文档同时涵盖电源和风扇的管理。
**风扇与电源的关系：**
- **内置风扇**：电源设备通常内置 1-4个风扇，用于散热
- **统一管理**：风扇作为电源的一部分，通过电源驱动统一管理
- **PMBus 协议**：通过 PMBus 协议的风扇相关命令监控和控制风扇
### 1.2 适配后可以实现什么功能
**电源功能：**
- 获取电源基本信息（厂商、型号、序列号、固件版本等）
- 监控电源状态（输入/输出电压、电流、功率、温度等）
- 管理电源模式（主用/备用、正常/休眠模式）
- 故障诊断和健康状态监控
- 电源复位操作
**风扇功能：**
- 监控风扇转速（RPM - 每分钟转数）
- 监控风扇状态（运行状态、故障状态）
- 控制风扇转速（设置目标转速或 PWM 占空比）
- 风扇告警和故障诊断
- 支持多风扇管理（1-4个风扇）
### 1.3 需要了解的关键概念
#### 契约与代码分层
在开始之前先厘清四个易混淆的概念：`dmc/`、`gen/`、`dev` 命名空间、以及厂商驱动目录。它们之间的关系见 [1.4](#14-驱动分层架构)。
| 概念 | 位置 | 说明 |
|------|------|------|
| **接口契约（dmc）** | `dmc/intf/bmc/dev/*.json` | 定义 `bmc.dev.*` 接口的属性、方法、类型与描述（如 `PowerSupply.json`、`PowerSupply/Metrics.json`、`Fan/Control.json`），是南向接口契约的单一事实源 |
| **对象路径（dmc）** | `dmc/path/bmc/dev/**` | 定义设备树对象挂载路径与接口组合，如 `PowerSupply/PowerSupply.json`、`Fan/{Fan,Fans,FanType}.json` |
| **接口基类（gen）** | `gen/include/device_tree/interface/` | 与契约对应的 C++ 接口基类，位于 `dev::gen` 命名空间，如 `gen::PowerSupply`、`gen::PowerSupply_Control`、`gen::Fan`；当前仓库没有自动重新生成的工具链，改动接口时需要人工同步维护 |
| **驱动实现（dev）** | `drivers/` 下各驱动目录 | 厂商/协议实现，位于 `dev` 命名空间，如 `dev::OnePowerPmbus`、`dev::IPowerSupply` |
| **设备描述（CSR）** | 驱动目录内 `csr/*.dds` / `*.sr` | `.dds` 声明设备对象到 D-Bus 路径的映射与接口列表，`.sr` 是型号级实例配置（总线拓扑、静态属性、`Compatible` 等） |
#### 设备对象
| 对象类型 | 说明 | 代码示例 |
|---------|------|------|
| **电源主对象** | 代表整个电源设备，承载 `OnePowerBase` 公共逻辑并组合各接口 | `dev::OnePowerPmbus`（`drivers/psu/pmbus/`） |
| **电源公共基类** | 协议无关的电源对象基类：协议管理、属性采集、更新回调、升级、BMC 主从带外管理等 | `dev::OnePowerBase`（`drivers/psu/common/`） |
| **风扇框/风扇对象** | 风扇部件对象（非 PSU 内置风扇） | `dev::Fans` / `dev::Fan` / `dev::FanType`（`drivers/fan/huawei/`） |
#### 接口
- **gen 命名空间（`dev::gen`）**：与 dmc 契约对应的接口基类，只声明属性与虚方法，用 `MC_INTERFACE("bmc.dev.Xxx")` 声明接口名；改动契约时需要人工同步修改
- **dev 命名空间**：驱动实现类。接口实现类通过 `mc::engine::interface` 双模板参数继承对应 gen 基类
- **接口组合**：一个设备可实现多个接口（`PowerSupply`、`PowerSupply.Control`、`PowerSupply.Metrics`、`PowerSupply.Status`、`PowerSupply.Oem` 等），组合关系在 `.dds/.sr` 与 `MC_OBJECT` 中声明
#### 协议库
- **`libraries/protocol`**：`power_supply_protocol_base` 电源协议抽象基类（`ps_protocol_t`）
- **`libraries/pmbus`**：PMBus 电源管理总线协议（业界标准），含厂商变种实现（如 `pmbus_FP1420`、`pmbus_qb900` 等）
- **`libraries/smbus`、`libraries/canbus` 等**：底层通信协议封装；不同协议族（PMBus/CANbus/SMC）使用不同的驱动目录
- 电源驱动按“通信协议”组织而非按厂商，公共部分下沉到 `drivers/psu/common`
---
### 1.4 驱动分层架构
1. **分层架构**：从契约定义到硬件交互的完整体系：契约层（`dmc`）→ 基类层（`gen`，`dev::gen` 接口基类，需随 dmc 人工同步）→ 实现层（`dev`，厂商/协议实现）→ 部署层（`.so` + `csr` 配置由 devmon 加载并实例化到 D-Bus 设备树）；
2. **设计理念**：接口与实现分离。“改契约先改 `dmc`”（`dmc/intf` 定义接口、`dmc/path` 定义对象路径与接口组合），与契约对应的 C++ 接口基类维护在 `gen/`（当前仓库无自动生成工具，需人工同步），具体部件驱动在 `drivers/` 下实现；驱动只对 `devmon` 导出统一的 ABI（`register_device_driver`），设备实例由型号级 CSR（`.dds`/`.sr`）描述并按需加载。
```mermaid
flowchart TD
subgraph dmc["契约层(dmc)"]
direction TB
INTF["dmc/intf JSON 契约
PowerSupply.json / PowerSupply.Control.json /
PowerSupply.Metrics.json / Fan.json ..."]
PATH["dmc/path 对象路径+接口组合
PowerSupply/PowerSupply.json
Fan/Fan.json / Fans.json / FanType.json"]
end
subgraph gen["基类层(gen)"]
GEN_IF["gen/include/device_tree/interface/
dev::gen::PowerSupply / gen::PowerSupply_Metrics / gen::Fan ..."]
end
subgraph dev["实现层(drivers)"]
direction TB
subgraph psu_common["drivers/psu/common"]
BASE["OnePowerBase（协议管理/采集/回调/升级/主从带外管理）"]
DIF["IPowerSupply / IPowerSupply_Control /
IPowerSupply_Metrics / IPowerSupply_Status ..."]
end
subgraph psu_proto["drivers/psu/pmbus 等协议目录"]
OBJ["OnePowerPmbus : mc::app::object + OnePowerBase"]
ABI["psu_abi.cpp（register_device_driver）"]
end
subgraph fan_dev["drivers/fan/huawei"]
FOBJ["Fans / Fan / FanType 对象"]
FABI["fan_abi.cpp"]
end
BASE --> DIF
end
subgraph csr["型号配置(CSR)"]
SR["14191046_PSU_pmbus.dds / .sr
（Unit/Compatible/Objects/接口静态属性）"]
end
subgraph runtime["运行时(devmon)"]
TREE["D-Bus 设备树
/bmc/dev/Chassis/:SystemId/PowerSubsystem/PowerSupplies/:Id"]
end
INTF -->|契约对应/同步维护| GEN_IF
PATH -->|对象定义参考| SR
GEN_IF -->|继承实现 mc::engine::interface<Impl, gen::Base>| DIF
DIF -->|组合为设备对象| OBJ
OBJ -->|ABI 导出| ABI
ABI -->|devmon 按 CSR 加载 .so| TREE
SR -->|声明对象实例| TREE
DIF -->|同一套接口实现也可被风扇侧复用思路| FOBJ
FOBJ -->|ABI 导出| FABI
```
## 2. 前置准备
### 2.1 明确电源信息
#### 必需信息
| 信息项 | 说明 | 示例 |
|-------|------|------|
| **I2C 地址** | 电源的 I2C 从设备地址 | `0x58` |
| **协议类型** | 支持的协议 | `pmbus` |
| **槽位信息** | 电源槽位编号 | `1`, `2` |
#### 协议信息
- 支持的 PMBus 命令集（标准命令、厂商扩展命令）
- 数据格式（LINEAR11、LINEAR16 等格式）
- 特殊功能（休眠模式、N+R 支持等）
#### 硬件信息
- 额定功率
- 输入电压范围（AC/DC）
- 输出电压/电流规格
- 风扇数量和控制方式
### 2.2 驱动代码结构熟悉
Component Driver 采用分层架构设计，代码组织清晰，各个目录职责明确。理解这些目录的结构和作用是快速适配驱动的基础。
---
#### 2.2.1 整体目录结构
```shell
component_drivers/
├── dmc/ # Device Management Contract（接口契约与对象路径，单一事实源）
│ ├── intf/bmc/dev/ # 接口契约 JSON（bmc.dev.* 的属性/方法）
│ │ ├── PowerSupply.json + PowerSupply/ # 电源接口契约及子接口
│ │ ├── Fan.json + Fan/、Fans.json、FanType.json # 风扇接口契约
│ │ ├── Cooling.json / Upgrade.json / SharedManagement.json / Fru.json ...
│ │ └── ...
│ └── path/bmc/dev/ # 对象路径与接口组合 JSON
│ ├── PowerSupply/PowerSupply.json
│ ├── Fan/{Fan,Fans,FanType}.json
│ └── ...
├── drivers/ # 设备驱动实现目录（按部件类型组织）
├── gen/ # 与 dmc 契约对应的接口/对象 C++ 基类（dev::gen 命名空间，需随 dmc 人工同步）
├── libraries/ # 协议库目录（通信协议封装）
├── include/devmon/ # 公共头文件（含 driver_abi.h，定义统一驱动 ABI）
├── tests/ # 测试代码目录
├── docs/ # 文档目录（分册规范与适配指南）
├── mds/ # 模型/服务描述文件
└── meson.build # 构建配置文件
```
> [!NOTE]说明
> `dmc/` 是接口契约与对象路径的**单一事实源**：`dmc/intf` 定义“能提供什么属性/方法”，`dmc/path` 定义“对象挂在设备树哪个路径、组合哪些接口”。电源/风扇驱动需要实现的接口都以这两个目录中的 JSON 为准，细节见《[Device Management Contract](https://gitcode.com/openUBMC/component_drivers/blob/main/docs/3-DeviceMgmtContract.md)》。
---
#### 2.2.2 drivers 目录 - 设备驱动实现
`drivers/` 目录包含所有硬件设备的具体驱动实现，第一层按部件类型组织（如 `psu`、`fan`、`bus`、`chip`、`pcie_nic_card` 等），第二层电源按“通信协议”组织（公共实现统一放在 `common/`），风扇部件按厂商组织。
##### 目录结构
```shell
drivers/
├── psu/ # 电源驱动（本指南重点）
│ ├── common/ # 电源公共实现（协议无关，多协议复用）
│ │ ├── one_power_base.h/.cpp # OnePowerBase 电源公共基类
│ │ ├── interface/ # 电源接口实现（继承 dev::gen 基类）
│ │ │ ├── i_power_supply.h/cpp # PowerSupply 接口实现
│ │ │ ├── power_supply/ # 电源子接口实现
│ │ │ │ ├── i_control.h/cpp # Control
│ │ │ │ ├── i_metrics.h/cpp # Metrics
│ │ │ │ ├── i_status.h/cpp # Status
│ │ │ │ ├── i_log_collection.h/cpp / i_oem.h/cpp / i_upgrade.h/cpp
│ │ │ │ ├── i_capacitor.h/cpp (+ Capacitor/i_capacitor_metric.h/cpp)
│ │ │ │ ├── i_dual_inputs.h/cpp / i_dual_channel.h/cpp
│ │ │ ├── shared_management.h/cpp # SharedManagement 接口实现
│ │ │ └── meson.build
│ │ └── meson.build
│ ├── csr/ # 电源设备描述配置（各协议型号的 .dds/.sr）
│ │ ├── 14191046_PSU_pmbus.dds/.sr
│ │ ├── 14191046_PSU_pmbus_qb900.dds/.sr
│ │ ├── 14191046_PSU_canbus.dds/.sr
│ │ ├── 14191046_PSU_canbus_tpsu.dds/.sr
│ │ └── 14191046_PSU_smc.dds/.sr
│ ├── pmbus/ # PMBus 协议电源驱动
│ │ ├── one_power.h/.cpp # OnePowerPmbus 电源主对象
│ │ ├── psu_abi.cpp # ABI 导出接口（register_device_driver）
│ │ └── meson.build
│ ├── pmbus_qb900/ # PMBus QB900 变种（OnePowerPmbusQb900）
│ ├── canbus/ # CANbus 协议电源（OnePowerCanbus）
│ ├── canbus_tpsu/ # CANbus-TPSU 协议电源
│ ├── smc/ # SMC 协议电源
│ └── meson.build
│
├── fan/ # 风扇部件驱动
│ └── huawei/ # 华为风扇框驱动（Fans/Fan/FanType 对象）
│ ├── smc/ # fan_object / fans_object / fantype_object + fan_abi.cpp
│ ├── interface/ # i_fan / i_fans / i_fantype / i_shared_management 及子接口
│ └── csr/ # 14100363_*.dds/.sr
│
├── bus/ # 总线驱动（i2c、i2c_mux、i2c_over_hisport、localbus ...）
├── chip/ # 芯片驱动（eeprom、lm75、pca9555、cpld_register ...）
├── pcie_nic_card/ # 网卡驱动（hisi、wangxun、mellanox ...）
├── pcie_gpu_card/ # GPU 卡驱动（nvidia、innosilicon、moorethreads ...）
├── internal/ # 内部实现（驱动框架基础类）
└── meson.build
```
##### 关键目录说明
| 目录 | 说明 | 用途 |
|------|------|------|
| **psu/common/** | 电源公共实现 | `OnePowerBase` 提供协议无关的公共能力；`interface/` 下是所有协议电源共享的接口实现（`IPowerSupply_*`） |
| **psu/csr/** | 电源设备描述配置 | 集中存放各协议的 `.dds`/`.sr` 型号配置，定义设备接口、路径与实例化参数 |
| **psu/pmbus/ 等协议目录** | 各协议电源驱动 | 每个协议目录一个电源主对象（如 `OnePowerPmbus`）+ `psu_abi.cpp`，通过协议工厂表把 `协议名` 映射到 `libraries/pmbus` 中的具体实现类 |
| **fan/huawei/** | 风扇部件驱动 | 提供 `Fans`/`Fan`/`FanType` 三类对象（风扇框/风扇/风扇类型）及其接口实现、CSR 配置 |
| **internal/** | 内部基础框架 | 提供驱动框架的基础类 |
---
#### 2.2.3 gen 目录 - 接口/对象 C++ 基类
`gen/` 目录存放与 `dmc/` 契约对应的接口/对象 C++ 基类（`dev::gen` 命名空间），驱动代码继承这些基类实现功能。代码随仓库提交，meson 只负责编译。
> [!WARNING]注意
> 当前仓库内没有随构建执行的代码生成/重新生成工具链，`gen/` 下的代码需要**人工维护**：新增/修改接口属性时，除同步修改 `dmc/` 契约 JSON 外，还需人工同步修改 `gen/include/device_tree/interface/` 下的头文件（及其 `gen/src/` 实现），否则接口实现类将无法通过编译或属性缺失。仓库中 dmc/CSR 与 gen/驱动实现存在的不一致（如 `.dds`/`.sr` 仍引用 `bmc.dev.Cooling`、接口实现类与 `MC_OBJECT` 声明不齐等）多数与未做到同步有关。
##### 目录结构
```shell
gen/
├── include/ # 头文件目录
│ ├── device_tree/
│ │ ├── base.h # 基础类定义
│ │ ├── runtime_registrar.h # 运行时注册
│ │ ├── interface/ # 接口基类定义（namespace dev::gen）
│ │ │ ├── PowerSupply.h # 电源接口基类 gen::PowerSupply
│ │ │ ├── PowerSupply/ # 电源子接口基类
│ │ │ │ ├── Control.h # gen::PowerSupply_Control
│ │ │ │ ├── Metrics.h # gen::PowerSupply_Metrics
│ │ │ │ ├── Status.h # gen::PowerSupply_Status
│ │ │ │ ├── Oem.h / LogCollection.h / Capacitor.h / DualInputs.h / DualChannel.h ...
│ │ │ ├── Cooling.h / Upgrade.h / SharedManagement.h
│ │ │ ├── Fan.h + Fan/ # gen::Fan 及子接口（Control/Status/Metrics/PWMChannel/Oem/LogCollection）
│ │ │ ├── Fans.h + Fans/、FanType.h
│ │ │ └── ...
│ │ └── object/ # 对象组合定义（部分部件类型）
│ └── resource_tree/ # 资源树（总线/芯片/扫描器等）接口基类
├── src/ # 源文件目录（与 include 结构对应）
└── meson.build # 编成 libdevice_tree.so / libresource_tree.so
```
##### 关键概念
| 概念 | 说明 | 示例 |
|------|------|------|
| **接口基类** | 定义接口的属性与虚方法，用 `MC_INTERFACE("bmc.dev.Xxx")` 声明接口名 | `gen::PowerSupply`（即 `dev::gen::PowerSupply`）定义了 `Model`、`Manufacturer`、`SerialNumber` 等属性 |
| **接口实现类** | 用双模板参数继承接口基类，实现具体逻辑 | `class IPowerSupply : public mc::engine::interface` |
| **命名空间** | 接口基类位于 `dev::gen`，驱动实现位于 `dev` | 驱动代码中写 `gen::PowerSupply` 即 `dev::gen::PowerSupply` |
| **同步维护** | 以 `dmc/` 契约为准，`gen/` 基类需人工同步 | 在 `dmc/intf/bmc/dev/PowerSupply.json` 新增属性后，同步在 `gen/include/device_tree/interface/PowerSupply.h` 增加对应 `property<>`（当前仓库无自动生成工具） |
| **对象基类** | 部分部件类型提供对象基类（`mc::app::object` 派生） | `gen/include/device_tree/object/...` |
##### 使用方式
接口基类的风格如下（以电源接口为例，摘自仓库实际代码）：
```cpp
// gen/include/device_tree/interface/PowerSupply.h（namespace dev::gen）
class MC_API PowerSupply : public mc::engine::interface {
public:
MC_INTERFACE("bmc.dev.PowerSupply")
property FirmwareVersion; // 电源固件版本
property Manufacturer; // 厂商
property Model; // 电源型号
property SerialNumber; // 序列号
property SlotNumber; // 槽位号
// ...
};
```
驱动中实现接口时，不要直接继承 gen 基类，而是用**双模板参数**形式，并在 `.cpp` 中通过单参数 `MC_REFLECT` 完成反射注册：
```cpp
// 厂商接口实现类（dev 命名空间）
class IPowerSupply : public mc::engine::interface {
public:
void init(OnePowerBase* base_ptr);
void start(); // 内部注册更新回调
void stop();
bool update_power_supply(std::string_view property, const mc::variant& info);
private:
OnePowerBase* m_base;
};
// .cpp 文件末尾：反射注册（单参数，无需列出 gen 基类）
MC_REFLECT(dev::IPowerSupply)
```
---
#### 2.2.4 libraries 目录 - 通信协议库
`libraries/` 目录包含各种通信协议的封装实现，为驱动提供标准化的协议接口。除电源/风扇相关的 `protocol`/`pmbus`/`smbus` 外，还包含网卡/硬盘等部件使用的 `mctp`、`pldm`、`ncsi`、`nvme` 等协议库。
##### 目录结构
```shell
libraries/
├── protocol/ # 电源协议抽象基类
│ ├── power_supply_protocol.h/.cpp # power_supply_protocol_base（ps_protocol_t）
│ ├── protocol.h/.cpp # 协议公共定义
│ └── meson.build
│
├── pmbus/ # PMBus 协议库（含厂商/型号变种）
│ ├── pmbus.h/.cpp # PMBus 协议实现（继承 power_supply_protocol_base）
│ ├── pmbus_FP1420.h/.cpp / pmbus_qb900.h/.cpp / pmbus_eb1000_1.h/.cpp ...
│ ├── powerconverter_pmbus.h/.cpp
│ └── meson.build
│
├── smbus/ # SMBus/I2C 协议库
│ ├── smbus.h/.cpp、std_smbus.h/.cpp、smbus_postbox.h/.cpp
│ └── meson.build
│
├── canbus/ # CANbus 协议（电源/机框等使用）
├── mctp/ ncsi/ ncsi_over_mctp/ pldm/ pldm_over_mctp/ nvme/ # 带外管理/板卡协议
├── ipmb/ lldp/ imu/ ssu_oob/ # 其他协议
└── meson.build
```
##### 协议库说明
| 协议库 | 说明 | 传输方式 | 应用场景 |
|--------|------|---------|---------|
| **protocol** | 电源协议抽象基类 `power_supply_protocol_base` | - | 定义电源协议的通用接口（读取/控制/状态/升级），所有电源协议类的基类 |
| **pmbus** | PMBus 电源管理总线协议 | I2C/SMBus | 电源管理的主要协议；厂商变种（`pmbus_FP1420`、`pmbus_qb900`、`pmbus_eb1000_1` 等）以子类形式扩展 |
| **smbus** | 系统管理总线协议 | I2C | 底层总线通信，PMBus 的物理承载 |
| **canbus** | CANbus 协议（含 TPSU 变种） | CAN | 采用 CANbus 的电源/机框场景 |
##### 协议分层关系（以 PMBus 电源为例）
```shell
应用层： 电源驱动代码（OnePowerBase → OnePowerPmbus）
↓
协议层： libraries/protocol（power_supply_protocol_base）
↓
libraries/pmbus（pmbus 及厂商变种）
↓
传输层： libraries/smbus（smbus）
↓
物理层： I2C 硬件
```
##### 使用示例
协议库与驱动之间通过“协议工厂表”解耦：`drivers/psu/pmbus/one_power.cpp` 中把协议名字符串映射到具体的协议实现类，运行时由 `OnePowerBase::init_protocol()` 按名创建：
```cpp
// drivers/psu/pmbus/one_power.cpp：PMBus 协议工厂表（节选）
#define DEFINE_PS_PROTOCOL(name, ClassType) \
{name, [](mc::dict& data) -> std::unique_ptr { \
return std::make_unique(data); \
}}
static const ps_protocol_map_t pmbus_protocol_map = {
DEFINE_PS_PROTOCOL("pmbus", pmbus),
DEFINE_PS_PROTOCOL("pmbus_qb900", pmbus_qb900),
DEFINE_PS_PROTOCOL("pmbus_FP1420", pmbus_FP1420),
DEFINE_PS_PROTOCOL("psu_pmbus", pmbus_FP1420),
// ...
};
// 读取属性（接口方法大多返回 std::optional，便于判空/重试）
auto voltage = m_ps_protocol->get_input_voltage(); // 输入电压(V)
auto current = m_ps_protocol->get_output_current_amps(); // 输出电流(A)
auto power = m_ps_protocol->get_input_power_watts(); // 输入功率(W)
auto temp = m_ps_protocol->get_env_temperature_celsius(); // 环境温度(℃)
auto rpm = m_ps_protocol->get_psu_fan_speed_rpm(); // 风扇转速(RPM)
// 控制（如设置风扇 PWM 占空比，0-100）
m_ps_protocol->set_fan_speed_percent(30);
```
---
#### 2.2.5 目录之间的关系
```mermaid
flowchart TB
subgraph "契约层"
DMC["dmc/intf + dmc/path
接口契约与对象路径 JSON"]
end
subgraph "应用/驱动层"
Driver["drivers/psu/pmbus + drivers/psu/common
OnePowerPmbus / OnePowerBase"]
Interface["drivers/psu/common/interface
IPowerSupply / IPowerSupply_* 接口实现"]
end
subgraph "基类层"
GenInterface["gen/include/device_tree/interface
dev::gen 接口基类"]
end
subgraph "协议层"
ProtoBase["libraries/protocol
power_supply_protocol_base"]
PMBus["libraries/pmbus
pmbus 及厂商变种"]
SMBus["libraries/smbus
SMBus 协议实现"]
end
DMC -->|契约对应/人工同步| GenInterface
GenInterface -->|mc::engine::interface<Impl, gen::Base>| Interface
Interface -->|组合进对象| Driver
Driver -->|调用| PMBus
PMBus -->|继承| ProtoBase
PMBus -->|使用| SMBus
style Driver fill:#e1f5ff
style GenInterface fill:#fff4e1
style PMBus fill:#ffe1f5
```
##### 工作流程
1. **契约定义**：在 `dmc/` 中维护接口（`intf`）与对象路径/接口组合（`path`）
2. **基类维护**：`gen/` 下与契约对应的 C++ 接口/对象基类（`dev::gen`）需人工同步维护（当前仓库无自动生成工具链）
3. **接口实现**：在 `drivers/*/common/interface` 等位置用 `mc::engine::interface` 实现接口
4. **驱动组装**：在协议驱动目录（如 `drivers/psu/pmbus`）组合接口、继承公共基类（`OnePowerBase`），创建完整驱动对象并导出 ABI
5. **协议调用**：驱动通过 `libraries/` 中的协议库与硬件通信
6. **部署加载**：配套 `csr` 下的 `.dds/.sr`，由 devmon 在设备树中实例化设备对象
### 2.3 驱动协议架构
以 PMBus 电源为例，驱动、协议库与物理总线的分层关系如下（其他协议族如 CANbus、SMC 结构相同，只是中间协议库不同）：
```mermaid
flowchart LR
subgraph "设备驱动层"
Driver["设备驱动
OnePowerBase + OnePowerPmbus"]
end
subgraph "协议库层"
Proto["libraries/protocol
power_supply_protocol_base"]
PMBus["libraries/pmbus
pmbus + 厂商变种"]
SMBus["libraries/smbus
SMBus协议"]
end
subgraph "传输层"
I2C["I2C/SMBus"]
end
Driver -->|电源管理| PMBus
PMBus -->|继承协议接口| Proto
PMBus --> SMBus
SMBus --> I2C
```
### 2.4 底层协议确定
仓库中电源驱动按协议族组织：`drivers/psu/` 下有 `pmbus`、`pmbus_qb900`、`canbus`、`canbus_tpsu`、`smc` 五个协议目录，公共能力（`OnePowerBase` 与 `IPowerSupply_*` 接口实现）统一在 `common/`。
#### 协议类型
| 协议 | 驱动目录 | 说明 | 适用场景 |
|------|---------|------|---------|
| **PMBus** | `drivers/psu/pmbus` | 业界标准电源管理协议（SMBus/I2C），同一驱动内通过协议工厂表支持 `pmbus`、`pmbus_qb900`、`pmbus_FP1420`、`pmbus_eb1000_1` 等具体实现 | 标准 PMBus 电源 |
| **CANbus / CANbus-TPSU** | `drivers/psu/canbus`、`drivers/psu/canbus_tpsu` | CANbus 通信的电源 | 使用 CANbus 的电源 |
| **SMC** | `drivers/psu/smc` | 通过 SMC 通道访问电源 | 带 SMC 通道的整机电源 |
#### 协议实现关系
| 协议库（libraries） | 关系 | 说明 |
|------|------|------|
| `protocol/power_supply_protocol.h` | 抽象基类 | 定义 `power_supply_protocol_base`，统一读取/控制/状态/升级等虚方法 |
| `pmbus/pmbus.h` | 具体实现 | `pmbus` 实现标准 PMBus 命令 |
| `pmbus/pmbus_*.h` | 厂商/型号变种 | 在标准 `pmbus` 之上扩展厂商私有命令（如 `pmbus_FP1420`、`pmbus_qb900`、`pmbus_PDC3KD5412_LC` 等），由 `drivers/psu/pmbus/one_power.cpp` 的协议工厂表注册 |
---
### 2.5 电源与风扇支持的能力
本节以 `drivers/psu/pmbus` 的 `OnePowerPmbus`（PMBus 电源主对象）为例，说明当前驱动已具备的能力，帮助开发者明确适配时需要实现/复用哪些接口。
> [!NOTE]说明
> 电源主对象的能力由两部分决定：接口实现类（`drivers/psu/common/interface`，各协议共享）和对象上实际组合的接口列表（`MC_OBJECT` 宏 + 型号 `.sr/.dds` 声明）。可按型号裁剪，也可随 `dmc` 契约演进补充新接口。
#### 电源级能力
`OnePowerPmbus` 通过 `MC_OBJECT` 组合了以下 8 个接口（接口实现均在 `drivers/psu/common/interface`，各协议电源复用）：
| 能力类别 | 接口名称 | 说明 | 可获取/可设置的信息 |
|---------|---------|------|-------------|
| **电源基本信息** | `PowerSupply` | 电源设备基础信息 | 厂商、型号、序列号、部件号、固件版本、硬件版本、生产日期、槽位、协议类型、供电类型、是否参与整机功率计算等 |
| **指标接口** | `PowerSupply.Metrics` | 电源电气与温度指标 | 输入/输出电压、电流、功率、输入频率、额定功率/额定电流、环境/入口/内部/原边芯片/副边芯片温度、风扇转速 `FanSpeedRPM`、累计运行时长等 |
| **控制接口** | `PowerSupply.Control` | 电源控制功能 | `SetFanMinPWM`（风扇最小 PWM）、`SetWorkMode`（工作模式）、`SetSleepMode`（休眠）、`Reset`（复位）、`SetAlarmLatch`/`SetPowerLatch`（锁存）、`SetOutputPowerLimitWatts`（输出功率限值） |
| **状态接口** | `PowerSupply.Status` | 电源状态信息 | 在位 `Presence`、`Vout/Iout/Temperature/Input/CML/Mfr_Specific/Other` 告警状态、风扇状态 `Fans_1_2`/`Fans_3_4`、通信状态 `CommunicationStatus`、设备模式、输入/输出状态 |
| **日志接口** | `PowerSupply.LogCollection` | 电源故障日志 | 黑匣子信息导出 |
| **OEM 接口** | `PowerSupply.Oem` | 厂商私有能力 | 私有寄存器读写（`get_register_value`）等 |
| **升级接口** | `Upgrade`（`bmc.dev.Upgrade`） | 固件升级/激活 | 升级触发、进度/状态上报、激活（PMBus 升级接口 `pmbus_upgrade`） |
| **共享管理** | `SharedManagement`（`bmc.dev.SharedManagement`） | 多 BMC/共享电源场景 | 电源控制权（`ControlOwner`）、BMC 主从（Active/Standby）下带外管理启停 |
**可选增强接口**（按电源型号能力在 `.sr/.dds` 与对象上按需启用）：`PowerSupply.Capacitor`/`PowerSupply.Capacitor.Metrics`（超级电容）、`PowerSupply.DualInputs`（双路输入）、`PowerSupply.DualChannel`（双通道/轮询）。对应实现同样位于 `drivers/psu/common/interface/power_supply/`。
---
#### 风扇管理能力
电源内置的风扇通过以下方式进行管理：
##### 风扇状态监控
通过`PowerSupply.Status`接口获取风扇状态：
| 状态属性 | 说明 | 可能的值 |
|---------|------|---------|
| **Fans_1_2** | 风扇 1 和风扇 2 的状态字节 | PMBus `STATUS_FANS_1_2`（0x81）寄存器值 |
| **Fans_3_4** | 风扇 3 和风扇 4 的状态字节 | PMBus `STATUS_FANS_3_4`（0x82）寄存器值 |
> [!NOTE]注意
> 状态字节为寄存器原始值。驱动解析 `health_event` 时主要关注高位置位（如 bit7 风扇故障 `fan_fault`、bit6 风扇转速超控等），其余位的具体含义需以电源厂商的 PMBus 规格书为准，不同型号存在差异。
##### 风扇转速监控
电源内置风扇转速通过协议库读取（对应 Metrics 接口的 `FanSpeedRPM` 属性）：
| 监控项 | 协议接口（libraries/pmbus） | 说明 | 单位 |
|-------|---------------------------|------|-----|
| **风扇转速** | `get_psu_fan_speed_rpm()` | 读取电源当前风扇转速（返回 `std::optional`） | RPM |
| **风扇占空比** | `get_fan_speed_percent()` | 读取风扇 PWM 占空比（0-100） | % |
##### 风扇转速控制
通过 `PowerSupply.Control` 接口及协议库控制风扇：
| 控制项 | 接口/方法 | 说明 |
|-------|----------|------|
| **风扇最小 PWM** | `IPowerSupply_Control::SetFanMinPWM()`（属性 `Control.FanMinPWM`） | 设置风扇最小 PWM 占空比；取值范围/含义以 `dmc` 契约与厂商规格书为准 |
| **直接调速** | 协议库 `set_fan_speed_percent()` | 直接按占空比控制风扇 |
| **自动调速** | 电源固件自动控制 | 固件根据温度自动调节风扇转速 |
> [!NOTE]说明
>
> 1. 电源内置风扇通常由电源固件按温度自动调速，BMC 侧一般只设置**下限（最小 PWM）**；
> 2. 风扇部件（风扇框/风扇模块）的调速不在电源驱动内，而是由 `drivers/fan/huawei` 的 `Fans`/`Fan` 对象提供（PWM 通道、`Fan.Control` 等接口），见 [2.2.2](#222-drivers-目录---设备驱动实现)。
**控制示例：**
```cpp
// 通过 Control 接口设置风扇最小 PWM（示例：40%）
m_power_supply_control.SetFanMinPWM(40);
// 通过协议直接控制风扇占空比
m_ps_protocol->set_fan_speed_percent(40);
```
##### 风扇管理流程
```mermaid
flowchart LR
subgraph "应用层"
App["Redfish/应用"]
end
subgraph "驱动层"
Control["PowerSupply.Control接口"]
Status["PowerSupply.Status接口"]
OnePower["OnePowerPmbus（含 OnePowerBase）"]
end
subgraph "协议层"
PMBus["PMBus协议"]
end
subgraph "硬件层"
PSU["电源硬件"]
Fan1["风扇1"]
Fan2["风扇2"]
Fan3["风扇3"]
Fan4["风扇4"]
end
App -->|"设置风扇最小PWM"| Control
App -->|"查询风扇状态"| Status
Control -->|"SetFanMinPWM"| OnePower
Status -->|"读取 Fans_1_2/Fans_3_4"| OnePower
OnePower -->|"PMBus写(set_fan_speed_percent)"| PMBus
OnePower -->|"PMBus读(get_psu_fan_speed_rpm)"| PMBus
PMBus -->|"I2C通信"| PSU
PSU -->|"控制"| Fan1
PSU -->|"控制"| Fan2
PSU -->|"控制"| Fan3
PSU -->|"控制"| Fan4
```
---
#### 能力获取方式
以 `OnePowerPmbus`（PMBus）为例，数据获取分为“上电读取”与“周期采集”两个阶段：
| 阶段 | 获取方式 | 内容 | 说明 |
|-----|---------|------|------|
| **上电/带外启动** | 启动时带重试读取 | 厂商、型号、序列号、部件号、生产日期、固件版本、电源类型、输入电压类型、硬件版本、额定功率，以及输入/输出电压初始值 | 保证设备树尽早出现非零的关键值 |
| **周期采集（快）** | 500ms 定时器 | 输入功率、健康事件（`health_event`：`vout/iout/temperature/input/fans_1_2/cml/mfr_specific/other` 故障位）、通信状态 | `read_frequency_property()` |
| **周期采集（慢）** | 每约 3 秒 | 输出/输入电流、电压、功率、环境/原边芯片/副边芯片温度、风扇转速 | 在快采中分帧读取 |
| **周期采集（慢）** | 每约 5 秒 | 控制数据（休眠/工作模式、N+R 支持）、设备模式、额定功率、电源类型 | `read_slow_property()` |
> [!NOTE]说明
>
> - 实际周期与分帧策略见 `OnePowerPmbus::read_frequency_property()` / `read_slow_property()`（`drivers/psu/pmbus/one_power.cpp`）；CANbus/SMC 协议驱动的采集策略可能不同；
> - 产品信息（型号、序列号等）来自电源 FRU/寄存器数据，通常只在启动与低速周期读取，避免占用总线；
> - 监测任务统一由 `OnePowerBase` 的 `start_monitor()/restart_monitor()` 管理，500ms 是其基类默认值，子类可覆写。
---
## 3. 适配流程详解
> 场景假设：仓库需要支持一款新电源“XYZ”（PMBus 协议族），或使用全新通信协议的新电源。下面先判断适配形态，再按步骤落地。文中示例以 `drivers/psu/pmbus` 的 `OnePowerPmbus` 为蓝本。
### 3.1 确定适配形态与目录结构
与早期“按厂商在 `drivers/psu/huawei` 下新建驱动”不同，当前电源驱动已按协议组织，且公共能力全部抽到 `drivers/psu/common`。因此多数适配**不需要新建驱动目录**：
| 适配形态 | 场景 | 需要做的事 |
|--------|------|-----------|
| **新增电源型号（已有协议）** | 新电源使用 PMBus/CANbus/SMC 等仓库已覆盖的协议 | 在 `drivers/psu/csr/` 增加该型号的 `.dds/.sr`；若命令集差异较大，在 `libraries/pmbus` 增加厂商变种协议子类并注册到 `drivers/psu/pmbus/one_power.cpp` 的协议工厂表 |
| **新增协议/全新通道** | 电源使用仓库未覆盖的通信协议 | 参考 `drivers/psu/pmbus` 新建协议驱动目录 + 配套协议库与 CSR |
仅在“新增协议驱动”时才需要创建如下目录（目录名/类名与 `pmbus` 对齐，以 `xyz` 为例）：
```shell
psu/
├── common/ # 公共实现：直接复用，无需复制修改
│ ├── one_power_base.h/.cpp # OnePowerBase
│ └── interface/ # IPowerSupply_* 接口实现（所有协议电源共享）
├── csr/ # 型号配置：增加 14191046_PSU_xyz.dds / .sr
├── xyz/ # 新协议驱动目录（对齐 pmbus 结构）
│ ├── one_power.h # OnePowerXyz 电源主对象头文件
│ ├── one_power.cpp # 主对象实现（协议工厂表、start/stop、数据采集）
│ ├── psu_abi.cpp # ABI 导出（register_device_driver）
│ └── meson.build
└── meson.build # 增加 subdir('xyz')
```
### 3.2 配置型号描述（CSR：.dds + .sr）
型号级 CSR 成对存放在 `drivers/psu/csr/`：
- **`.dds`**（Device Description Standard，`Schema: "dds-v1"`）：声明设备对象到 D-Bus 路径的映射、以及该对象挂载的接口列表；
- **`.sr`**（Self-Description Record）：型号级实例配置，描述总线/芯片拓扑（`ManagementTopology`）、`Unit`（`Type`/`Compatible`）与各接口的静态属性，供 devmon 建树和驱动加载时使用。
#### 文件命名规则
```shell
格式：[分类代码]_PSU_<协议>.dds 与 [分类代码]_PSU_<协议>.sr
示例：14191046_PSU_pmbus.dds / 14191046_PSU_pmbus.sr
说明：14191046 是电源的分类代码；<协议> 与驱动/协议库对应（pmbus、pmbus_qb900、canbus、canbus_tpsu、smc）
```
#### DDS 文件内容（摘自 `drivers/psu/csr/14191046_PSU_pmbus.dds`）
```json
{
"Schema": "dds-v1",
"Type": "Component",
"DeviceCategory": "OnePower",
"ID": "N/A",
"Objects": {
"OnePower": {
"Path": "/bmc/dev/Chassis/:SystemId/PowerSubsystem/PowerSupplies/:Id",
"Interfaces": [
"bmc.dev.PowerSupply",
"bmc.dev.Cooling",
"bmc.dev.PowerSupply.Control",
"bmc.dev.PowerSupply.Metrics",
"bmc.dev.PowerSupply.Status",
"bmc.dev.PowerSupply.LogCollection",
"bmc.dev.PowerSupply.Oem"
]
}
}
}
```
#### 关键字段说明
| 字段 | 说明 | 注意事项 |
|------|------|---------|
| `DeviceCategory` | 设备类别 | 电源为 `"OnePower"`（风扇部件为 `"Fan"` 等，见 2.2.2） |
| `Objects` | 对象定义 | 键名（如 `OnePower`）与主对象 `MC_OBJECT` 的第 2 个参数（对象类型名）对应 |
| `Path` | 对象 D-Bus 路径模板 | `:SystemId`、`:Id` 等为动态参数；对象路径契约以 `dmc/path/bmc/dev/PowerSupply/PowerSupply.json` 为准 |
| `Interfaces` | 接口列表 | 应与代码 `MC_OBJECT` 声明、型号 `.sr` 中实际配置的接口保持一致 |
#### .sr 文件要点（摘自 `14191046_PSU_pmbus.sr`）
```json
{
"FormatVersion": "5.00",
"DataVersion": "5.00",
"Unit": { "Type": "PSU", "Name": "OnePower_0", "Compatible": ["psu_pmbus"] },
"ManagementTopology": {
"Anchor": { "Buses": ["I2c_2", "I2c_3"] },
"I2c_2": { "Chips": ["Smc_ExpBoardSMC"] },
"I2c_3": { "Chips": ["Eeprom_PsuChip"] }
},
"Objects": {
"OnePower_0": {
"PhysicalInterface": "pmbus",
"RefChip": "#/Eeprom_PsuChip",
"bmc.dev.PowerSupply": {
"SlotNumber": "${Slot}",
"Protocol": "pmbus",
"...": "..."
},
"bmc.dev.PowerSupply.Metrics": { "...": "..." },
"bmc.dev.PowerSupply.Status": { "...": "..." }
}
}
}
```
**配置要点：**
1. **`Unit` 匹配关系要对齐**：`.sr` 的 `Unit.Type`（电源为 `PSU`）与驱动 ABI 的 `device_name` 对应；`Compatible` 与驱动加载/协议工厂表使用的名称（如 `psu_pmbus`）对应，保证 devmon 能匹配到正确的 `.so`；
2. **`RefChip` 与拓扑要完整**：`ManagementTopology` 声明电源所在总线与关联芯片（如 EEPROM），`Objects.<对象>.RefChip` 引用该芯片，主对象 `init()` 据此解析出硬件访问通道；
3. **接口静态属性写在对应接口段**：`SlotNumber`、`Protocol` 等由 `.sr` 静态下发（经 `from_variant` 加载），运行期通过接口属性读取；
4. **风扇调速需求段（可选）**：需要“风扇随温度调速”的场景可在 `.sr` 中追加冷却/风扇需求（如 `CoolingRequirement_*`），由上层协同使用。
---
### 3.3 创建电源主对象（协议驱动）
> 电源主对象是每个协议驱动的核心：它组合各接口实现类，并承载协议相关的初始化和数据采集逻辑。公共逻辑（协议创建、属性读取分发、升级、BMC 主从带外管理、监控定时器管理等）已在 `OnePowerBase` 中实现，协议驱动只需完成少量协议相关的工作，参考对象：`drivers/psu/pmbus/one_power.h`（`OnePowerPmbus`）。
#### 代码示例：`one_power.h`（XYZ 协议电源主对象）
```cpp
#ifndef ONE_POWER_XYZ_H
#define ONE_POWER_XYZ_H
#include
#include
#include
#include
#include "../common/interface/i_power_supply.h"
#include "../common/interface/power_supply/i_control.h"
#include "../common/interface/power_supply/i_log_collection.h"
#include "../common/interface/power_supply/i_metrics.h"
#include "../common/interface/power_supply/i_oem.h"
#include "../common/interface/power_supply/i_status.h"
#include "../common/interface/power_supply/i_upgrade.h"
#include "../common/interface/shared_management.h"
#include "../common/one_power_base.h"
namespace dev {
class OnePowerXyz : public mc::app::object, public OnePowerBase {
public:
// MC_OBJECT 参数：类名 / 对象类型名 / 路径模板 / 接口列表
MC_OBJECT(
OnePowerXyz, "OnePower", "/bmc/dev/Chassis/1/PowerSubsystem/PowerSupplies/${SlotNumber}",
(IPowerSupply)(IPowerSupply_Control)(IPowerSupply_Metrics)(IPowerSupply_Status)
(IPowerSupply_LogCollection)(IPowerSupply_Oem)(IPowerSupply_Upgrade)(IPowerSupply_SharedManagement))
OnePowerXyz() = default;
~OnePowerXyz() = default;
bool init(mc::mutable_dict& csr_object, const mc::dict& connector);
bool start();
bool stop();
void from_variant(const mc::dict& d, dev::OnePowerXyz& obj);
// 实现 OnePowerBase 纯虚接口
const ps_protocol_map_t& get_protocol_map() const override; // 协议工厂表（协议名 -> 协议对象）
IPowerSupply& get_power_supply() override; // 返回 m_power_supply
const IPowerSupply& get_power_supply() const override;
IPowerSupply_SharedManagement& get_shared_mgmt() override;
const IPowerSupply_SharedManagement& get_shared_mgmt() const override;
// 接口成员变量（与 MC_OBJECT / MC_REFLECT 一一对应）
IPowerSupply m_power_supply;
IPowerSupply_Control m_power_supply_control;
IPowerSupply_Metrics m_power_supply_metrics;
IPowerSupply_Status m_power_supply_status;
IPowerSupply_LogCollection m_power_supply_log_collection;
IPowerSupply_Oem m_power_supply_oem;
IPowerSupply_Upgrade m_power_supply_upgrade;
IPowerSupply_SharedManagement m_shared_mgmt;
private:
// 协议名/物理通道（来自 .sr 静态属性）
mc::engine::property RefChip{"RefChip"};
mc::engine::property PhysicalInterface{"PhysicalInterface"};
std::string get_active_interface() const; // 返回 PhysicalInterface
// 协议相关的数据采集（按需覆写 start_monitor 等）
void read_frequency_property();
void read_slow_property();
bool start_oob_management() override; // 启动带外数据采集
};
} // namespace dev
#endif // ONE_POWER_XYZ_H
```
对应的 `MC_REFLECT` 注册（`one_power.cpp` 末尾），把接口成员映射到 `bmc.dev.*` 接口名：
```cpp
MC_REFLECT(dev::OnePowerXyz,
((RefChip, "RefChip"))((PhysicalInterface, "PhysicalInterface"))
((m_power_supply, "bmc.dev.PowerSupply"))
((m_power_supply_control, "bmc.dev.PowerSupply.Control"))
((m_power_supply_metrics, "bmc.dev.PowerSupply.Metrics"))
((m_power_supply_status, "bmc.dev.PowerSupply.Status"))
((m_power_supply_log_collection, "bmc.dev.PowerSupply.LogCollection"))
((m_power_supply_oem, "bmc.dev.PowerSupply.Oem"))
((m_power_supply_upgrade, "bmc.dev.Upgrade"))
((m_shared_mgmt, "bmc.dev.SharedManagement")))
```
> [!NOTE]说明
>
> - 若协议型号只支持部分接口，可在 `MC_OBJECT`/`MC_REFLECT`/`.dds`/`.sr` 中同步裁剪；
> - 如需温度数值、告警状态等属性，无需新增 `Cooling` 等“额外接口”：温度数值在 `PowerSupply.Metrics`（`EnvTemperatureCelsius` 等），告警/风扇状态位在 `PowerSupply.Status`，见 [2.5](#25-电源与风扇支持的能力)。
#### 关键说明
**1. MC_OBJECT 宏的参数：**
- **第 1 个**：类名（如 `OnePowerXyz`）
- **第 2 个**：对象类型名（电源为 `"OnePower"`，与 `.dds` 的 `Objects` 键名/`DeviceCategory` 对应）
- **第 3 个**：对象路径模板（`${SlotNumber}` 为属性占位，实际槽位号由 `.sr` 下发）
- **第 4 个**：对象组合的接口列表（按型号能力增删）
**2. 接口选择原则：**
| 接口 | 必需性 | 说明 |
|------|--------|------|
| `PowerSupply` | 必需 | 电源基础信息 |
| `PowerSupply.Control` | 常见 | 工作/休眠模式、复位、风扇最小 PWM 等控制 |
| `PowerSupply.Metrics` | 常见 | 电压/电流/功率/温度/风扇转速等指标 |
| `PowerSupply.Status` | 常见 | 在位与各类告警/风扇状态 |
| `PowerSupply.LogCollection`/`Oem`/`Upgrade`/`SharedManagement` | 可选 | 日志、私有能力、升级、共享管理 |
| `PowerSupply.Capacitor`/`DualInputs`/`DualChannel` | 按型号 | 超级电容、双路输入、双通道电源 |
---
### 3.4 实现电源主对象（one_power.cpp）
电源主对象的实现重点有三处：**协议工厂表**（`get_protocol_map`）、**生命周期**（`init/start/stop`）、**数据采集**（`start_oob_management` 与周期读取）。其余公共逻辑（属性更新分发、监控定时器管理、升级、BMC 主从等）复用 `OnePowerBase`，参考实现：`drivers/psu/pmbus/one_power.cpp`。
#### 协议工厂表与生命周期
```cpp
// one_power.cpp（节选，示意）
#include "one_power.h"
#include
#include
#include
#include
#include // 新协议实现（libraries/xyz，若有）
namespace dev {
// 协议工厂表：协议名字符串 -> 具体协议对象（构造参数为 mc::dict&，包含芯片/总线信息）
#define DEFINE_PS_PROTOCOL(name, ClassType) \
{name, [](mc::dict& data) -> std::unique_ptr { \
return std::make_unique(data); \
}}
static const ps_protocol_map_t xyz_protocol_map = {
DEFINE_PS_PROTOCOL("pmbus_xyz", pmbus_xyz),
// ...支持多个协议/厂商变种时在此追加
};
const ps_protocol_map_t& OnePowerXyz::get_protocol_map() const
{
return xyz_protocol_map;
}
// init：from_variant 装载 .sr 静态属性，并解析 RefChip 引用（协议访问硬件的通道）
bool OnePowerXyz::init(mc::mutable_dict& csr_object, const mc::dict& connector)
{
m_self = this;
try {
OnePowerXyz::from_variant(csr_object, *this); // 装载 SlotNumber/Protocol/静态属性
m_ref_obj = RefChip.get_value().as();
if (m_ref_obj == nullptr) {
elog("OnePowerXyz init FAILED: RefChip ref_object is NULL");
return false;
}
} catch (const std::exception& e) {
elog("OnePowerXyz init FAILED: ${exception}", ("exception", e.what()));
return false;
}
return true;
}
void OnePowerXyz::from_variant(const mc::dict& d, dev::OnePowerXyz& obj)
{
mc::from_variant(d, obj);
}
// start：创建协议 -> 初始化/启动接口 -> 评估并启动带外采集
bool OnePowerXyz::start()
{
// 1. 按 .sr 的 PhysicalInterface（协议名）创建协议对象，失败不阻断上线
init_protocol(get_active_interface(), m_power_supply.SlotNumber.get_value().as());
// 2. 接口对象 init(base)/start()：start 时向 base 注册“属性名->属性值”更新回调
m_power_supply.init(this);
m_power_supply_control.init(this);
m_power_supply_metrics.init(this);
m_power_supply_status.init(this);
m_power_supply_log_collection.init(this);
m_power_supply_oem.init(this);
m_power_supply_upgrade.init(this);
// ...各接口 start() 统一在协议就绪后调用（参考 pmbus 实现）
// 3. 主从/共享电源场景：按 ControlOwner 建立 BMC 主从监听，再评估是否启动采集
setup_oob_management();
evaluate_oob_management();
return true;
}
bool OnePowerXyz::stop()
{
teardown_oob_management(); // 断开主从监听、停止带外采集
m_power_supply.stop();
m_power_supply_control.stop();
m_power_supply_metrics.stop();
m_power_supply_status.stop();
m_power_supply_oem.stop();
m_power_supply_upgrade.stop();
return true;
}
std::string OnePowerXyz::get_active_interface() const
{
return PhysicalInterface.get_value().as(); // 例："pmbus_xyz"
}
} // namespace dev
```
> [!NOTE]说明
>
> - `init_protocol()` 由 `OnePowerBase` 实现：按协议名查 `get_protocol_map()` 创建协议对象，并用 `RefChip` 关联的芯片完成总线访问准备；`reinit_protocol()` 可在运行期按“厂商+型号”切换具体协议实现；
> - `setup_oob_management()/evaluate_oob_management()` 由 `OnePowerBase` 提供：无主从（`ControlOwner=0`）时协议就绪即开始采集；有主从（`ControlOwner=1`）时仅主 BMC 的 Active 态采集；
> - 协议就绪后的首次采集入口是虚函数 `start_oob_management()`（协议驱动实现），见下。
#### 数据采集（start_oob_management 与周期读取）
协议就绪后的带外数据采集入口为 `start_oob_management()`（协议驱动实现），示意如下：
```cpp
// 启动带外数据采集：首次带重试读取产品信息 + 启动周期采集（示意，参考 OnePowerPmbus）
bool OnePowerXyz::start_oob_management()
{
if (!is_protocol_ready()) {
ilog("OnePowerXyz protocol not ready, skip data collection");
return false;
}
// 1. 启动时带重试读取产品信息，保证设备树尽早出现非零关键值
get_dynamic_data("firmware_version", 3);
get_dynamic_data("manufacturer", 3);
get_dynamic_data("model", 3);
get_dynamic_data("serial_number", 3);
get_dynamic_data("rated_power_watts", 3);
// ...
get_dynamic_data("input_voltage", 5);
get_dynamic_data("output_voltage", 5);
// 2. 启动周期采集（500ms 定时器，由 OnePowerBase::start_monitor 管理）
start_monitor(mc::make_shared(this));
reinit_protocol();
return true;
}
// 周期回调（示意）：500ms 高频 + 分帧读取，参考 OnePowerPmbus::read_frequency_property()
void OnePowerXyz::read_frequency_property()
{
get_dynamic_data("input_power_watts", 1);
// 健康事件：告警状态位直接分发给 Status 接口
auto [ev, health_failed] = m_ps_protocol->get_health_event();
if (!health_failed) {
update_property("vout", ev.output_voltage_fault);
update_property("iout", ev.output_current_fault);
update_property("temperature", ev.temper_fault);
update_property("input", ev.input_voltage_fault);
update_property("fans_1_2", ev.fan_fault);
update_property("cml", ev.cml_fault);
update_property("mfr_specific", ev.mfr_specific_status);
update_property("other", ev.other_fault);
}
// 每 6 次（约 3s）读取一组动态指标：电压/电流/温度/风扇转速等
static uint8_t cnt = 0;
if (++cnt >= 6) {
get_dynamic_data("output_power_watts", 1);
get_dynamic_data("input_current_amps", 1);
get_dynamic_data("output_current_amps", 1);
get_dynamic_data("env_temperature_celsius", 1);
get_dynamic_data("primary_chip_temperature_celsius", 1);
get_dynamic_data("psu_fan_speed_rpm", 1);
cnt = 0;
}
}
// 慢速属性：每约 5s 读取控制数据/设备模式等（示意）
void OnePowerXyz::read_slow_property()
{
auto control = m_ps_protocol->get_ps_control_data();
if (control.has_value()) {
m_power_supply_control.SleepMode = control->sleep_mode;
m_power_supply_control.WorkMode = control->work_mode;
update_property("normal_and_redundancy_supported",
mc::variant(control->normal_and_redundancy_supported ? 1 : 0));
}
get_dynamic_data("equipment_mode", 1);
get_dynamic_data("rated_power_watts", 1);
}
```
> [!NOTE]说明
>
> - `get_dynamic_data(属性名, 重试次数)` 由 `OnePowerBase` 实现：按“属性名”调用协议库对应方法，成功后经 `update_property()` 分发给在 `start()` 中注册的各接口实现（接口侧再把 `snake_case` 属性名映射到自身属性，见 [3.5](#35-复用与补充接口实现)）。大多数属性无需协议驱动自己写 if-else 分发；
> - 控制类方法（`set_power_work_mode`/`reset`/`set_sleep_mode`/风扇最小 PWM 等）已在 `OnePowerBase` 中统一转发给协议库，主对象内无需重复实现，除非新协议需要特殊处理；
> - 轮询节奏建议与 PMBus 驱动保持一致（500ms 高频、约 3s/5s 分帧慢速），新协议可覆写 `start_monitor()/stop_monitor()` 调整。
#### 生命周期小结
| 阶段 | 关键动作 | 实现位置 |
|------|---------|---------|
| `init()` | `from_variant` 装载 `.sr` 静态属性并解析 `RefChip` | 协议驱动主对象 |
| `start()` | `init_protocol()` 创建协议对象 → 接口 `init/start`（注册更新回调）→ `setup_oob_management()`/`evaluate_oob_management()` | 协议驱动主对象 + `OnePowerBase` |
| 采集 | `start_oob_management()`：首次读取 + `start_monitor()` 周期采集 | 协议驱动覆写 + `OnePowerBase` |
| `stop()` | `teardown_oob_management()` → 接口 `stop()`（注销回调） | 协议驱动主对象 |
**启动流程：**
1. `from_variant()` 装载 `.sr` 静态属性（槽位、协议、接口静态配置），解析 `RefChip` 引用
2. `init_protocol()`：按 `.sr` 的 `PhysicalInterface` 从协议工厂表创建协议对象并绑定芯片
3. 各接口对象 `init(base)`、`start()`：向 `OnePowerBase` 注册“属性名→属性”更新回调
4. `setup_oob_management()`：无主从直接放行；有主从则监听 BMC Active/Standby 状态
5. `evaluate_oob_management()` → 协议就绪时调用 `start_oob_management()` 开始采集
---
### 3.5 复用与补充接口实现
#### 核心要点
电源各接口实现类位于 `drivers/psu/common/interface/`（`IPowerSupply`、`IPowerSupply_Control/Metrics/Status/LogCollection/Oem/Upgrade`、`IPowerSupply_SharedManagement` 等），**所有协议电源共享**，通常无需为新协议重写。每个接口实现类的职责是：继承对应的 `dev::gen` 基类，向 `OnePowerBase` 注册更新回调，把“协议返回的 `snake_case` 属性名”映射为接口自身的属性。
以 `IPowerSupply_Metrics` 为例（摘自仓库实际代码）：
```cpp
// interface/power_supply/i_metrics.h
class IPowerSupply_Metrics : public mc::engine::interface {
public:
void init(OnePowerBase* base_ptr); // 保存 base 指针
void start(); // 注册指标更新回调
void stop(); // 注销回调
bool update_metrics(std::string_view property, const mc::variant& info);
private:
OnePowerBase* m_base;
};
// interface/power_supply/i_metrics.cpp
namespace dev {
void IPowerSupply_Metrics::start()
{
register_metrics_handler();
}
void IPowerSupply_Metrics::init(OnePowerBase* base_ptr)
{
m_base = base_ptr;
}
void IPowerSupply_Metrics::register_metrics_handler()
{
if (!m_base) {
elog("register_metrics_handler failed, OnePowerBase is null");
return;
}
// 向公共基类注册更新回调：属性名 -> 更新本接口属性
m_base->register_update_interface(this, [this](std::string_view property, const mc::variant& info) -> bool {
return update_metrics(property, info);
});
}
bool IPowerSupply_Metrics::update_metrics(std::string_view property, const mc::variant& info)
{
if (property == "input_power_watts") {
InputPowerWatts = info.as();
return true;
}
if (property == "input_voltage") {
InputVoltage = info.as();
return true;
}
// output_power_watts / output_voltage / env_temperature_celsius / psu_fan_speed_rpm ...
return false;
}
} // namespace dev
MC_REFLECT(dev::IPowerSupply_Metrics) // 单参数反射注册，无需列出 gen 基类
```
**关键要点：**
- 接口实现类用**双模板参数**继承：`mc::engine::interface`，不要直接 `class Impl : public gen::Base`；
- `MC_REFLECT(dev::Xxx)` 写在实现 `.cpp` 末尾（单参数形式）；
- 属性名采用 `snake_case` 字符串（如 `input_power_watts`），与协议/基类 `get_dynamic_data()` 使用的名字一致；更新属性后框架自动对外发信号，无需手动通知上层；
- 如果某协议对接口方法有特殊处理（如控制方法差异大），在协议库实现类中覆写对应虚方法即可，接口层不变。
#### 补充新属性/新能力
适配中若需要暴露新属性，正确路径是：
1. **先在 `dmc/` 契约中定义**：在 `dmc/intf/bmc/dev/PowerSupply*.json` 增加属性/方法（改契约先改 dmc）；
2. **同步 `gen/`**：人工在 `gen/include/device_tree/interface/` 增加/修改对应基类属性（并同步 `gen/src/`），与 `dmc` 契约保持一致——当前仓库没有自动生成工具，不会自动重新生成；
3. **在对应接口实现中映射**：`update_xxx()` 增加属性名分支（或控制方法覆写）；
4. **配置下发**：静态值写进型号 `.sr` 对应接口段，动态值在协议库/驱动采集逻辑中读取。
> [!NOTE]说明
> 厂商私有/未标准化属性优先放到 `PowerSupply.Oem` 相关能力中，避免污染通用接口；风扇部件（非 PSU 内置风扇）的接口实现见 `drivers/fan/huawei/interface/`（`IFan`、`IFans`、`IFan_Control`、`IFan_PWMChannel` 等），实现方式与本节的电源接口一致。
---
### 3.6 实现 ABI 导出
ABI（Application Binary Interface）是驱动 `.so` 与 devmon 交互的标准接口：每个驱动 `.so` 导出一个 `register_device_driver()` 符号，返回 `device_driver_t` 数组。结构体与函数类型定义见 `include/devmon/driver_abi.h`。
#### 代码示例：`psu_abi.cpp`（XYZ 协议电源）
```cpp
#include
#include
#include "one_power.h"
#ifndef DEVICE_DRIVER_NAME
#define DEVICE_DRIVER_NAME "psu_xyz" // 与 .sr 的 Compatible、协议名对应
#endif
using namespace dev;
extern "C" {
driver_handle_t create_one_power(void* service, const char* name)
{
try {
if (service == nullptr || name == nullptr) {
return nullptr;
}
auto* device = new OnePowerXyz();
device->set_service(static_cast(service));
device->set_object_name(name);
return device;
} catch (const std::exception& e) {
elog("create_one_power failed: ${error}", ("error", e.what()));
return nullptr;
}
}
status_t init_one_power(driver_handle_t device, void* csr_object, void* connector)
{
if (device == nullptr || csr_object == nullptr || connector == nullptr) {
return STATUS_ERROR;
}
auto* device_object = static_cast(device);
mc::mutable_dict* csr_object_ptr = static_cast(csr_object);
mc::dict* connector_ptr = static_cast(connector);
return device_object->init(*csr_object_ptr, *connector_ptr) ? STATUS_OK : STATUS_ERROR;
}
status_t start_one_power(driver_handle_t device)
{
if (device == nullptr) {
return STATUS_ERROR;
}
return static_cast(device)->start() ? STATUS_OK : STATUS_ERROR;
}
status_t stop_one_power(driver_handle_t device)
{
if (device == nullptr) {
return STATUS_ERROR;
}
static_cast(device)->stop();
return STATUS_OK;
}
// device_name 与 .sr 的 Unit.Type（电源为 "PSU"）对应
device_driver_t one_power_device_driver = {.device_name = "PSU",
.ctor = create_one_power,
.init = init_one_power,
.start = start_one_power,
.stop = stop_one_power};
device_driver_t psu_device_driver[] = {one_power_device_driver};
status_t register_device_driver(device_driver_t** device_driver, uint8_t* count)
{
*device_driver = psu_device_driver;
*count = sizeof(psu_device_driver) / sizeof(psu_device_driver[0]);
return STATUS_OK;
}
}
```
#### 关键说明
- 所有 ABI 函数必须用 `extern "C"` 包装，确保符号可被 devmon 按 C 方式加载；
- 每个设备类型需要 4 个函数：`create`、`init`、`start`、`stop`（`device_driver_t` 还支持可选的 `dump`）；
- `device_name` 与 `.sr` 的 `Unit.Type` 对应（电源为 `"PSU"`，风扇部件为 `"Fans"`/`"Fan"`/`"FanType"`），`DEVICE_DRIVER_NAME` 与 `.sr` 的 `Compatible`、协议工厂表名称对应；
- 一个 `.so` 可注册多个设备类型：风扇驱动 `fan_abi.cpp` 一次注册 `Fans`/`Fan`/`FanType` 3 个条目，`register_device_driver` 返回 `count = 3`；
- `register_device_driver` 是框架调用的唯一入口符号。
---
### 3.7 配置构建编译
电源驱动的构建沿用仓库 meson 体系（`drivers/psu/meson.build` 先编 `common` 公共库，再编各协议驱动）。以 `pmbus` 为例（`drivers/psu/pmbus/meson.build`）：
```meson
# 公共库（drivers/psu/common/meson.build）：one_power_base + 全部接口实现编入 libPsu_common
libpsu_common = static_library('Psu_common', psu_common_sources, ...)
# 协议驱动：先静态库，再 link_whole 公共库打成动态库
libpsu_pmbus_static = static_library(
'psu_pmbus',
files('one_power.cpp', 'psu_abi.cpp'),
include_directories: include_dirs,
dependencies: [dev_deps, libpsu_common_dep, libpmbus_dep],
install: false,
)
libpsu_pmbus = shared_library(
'psu_pmbus',
include_directories: include_dirs,
name_prefix: 'lib',
name_suffix: 'so',
install: true,
install_dir: drivers_install_dir, # 驱动安装目录（框架定义）
link_whole: [libpsu_common, libpsu_pmbus_static],
dependencies: [dev_deps, libpsu_common_dep, libpmbus_dep],
)
```
若新增协议驱动目录 `drivers/psu/xyz`，还需在 `drivers/psu/meson.build` 增加 `subdir('xyz')`；若配套新增协议库 `libraries/xyz`，需在 `libraries/meson.build` 注册并让驱动依赖它。
#### 关键说明
- 库名即驱动 SO 文件名（`libpsu_pmbus.so`），与 `.sr` 的 `Compatible`/`DEVICE_DRIVER_NAME` 对齐；
- `install_dir` 使用 `drivers_install_dir` 变量（框架定义）；`build_tests` 开启时仓库会把驱动拷贝到该目录（`custom_target` 的 `cp` 逻辑），便于本地联调；
- 公共库 `libPsu_common` 通过 `link_whole` 全量打入协议驱动，保证各接口实现符号随 `.so` 一起导出；
- 依赖关系要明确列出（`dev_deps`、`libpsu_common_dep`、协议库依赖等），避免链接错误。
---
## 4. 最佳实践建议
### 4.1 代码规范
#### 命名规范
| 类型 | 规范 | 示例 |
|------|------|------|
| 对象类名 | 对象类型/协议相关 | `OnePowerPmbus`、`OnePowerXyz`（主对象）；`IPowerSupply_Metrics`（接口实现） |
| 文件名 | 与对象对应 | `one_power.h/.cpp`、`psu_abi.cpp`、`one_power_base.h/.cpp` |
| 成员变量 | `m_` 前缀 | `m_ps_protocol`、`m_property_query_timer` |
| 协议库类名 | 协议/型号相关 | `pmbus`、`pmbus_FP1420`、`pmbus_qb900` |
| 常量 | 大写+下划线 | `PSU_CONTROL_OWNER_YES`、`BMC_ROLE_ACTIVE` |
#### 日志规范
- **启动/停止**：使用 `ilog`
- **错误**：使用 `elog`
- **调试信息**：使用 `dlog`
- **日志要包含上下文信息**
```cpp
ilog("OnePowerXyz ${slot} started, protocol=${protocol}",
("slot", m_power_supply.SlotNumber)("protocol", get_active_interface()));
```
#### 错误处理
- 所有可能失败的操作都要检查返回值
- 使用`try-catch`捕获异常
- 记录详细的错误信息
```cpp
try {
auto value = m_ps_protocol->get_input_voltage();
if (!value.has_value()) {
elog("Failed to get input voltage");
return false;
}
} catch (const std::exception& e) {
elog("Exception caught: ${error}", ("error", e.what()));
return false;
}
```
---
### 4.2 性能优化
#### 定时任务间隔
- 根据数据变化频率设置不同的更新间隔，避免不必要的通信开销
- **快速变化数据**：0.5秒（500ms） - 电压、电流、功率、温度、状态
- **慢速变化数据**：5秒（5000ms） - 产品信息、配置信息
**实际应用示例（`OnePowerBase::start_monitor` 定时回调示意）：**
```cpp
// 500ms 定时器，回调内区分快慢属性（参考 OnePowerPmbus 实现）
m_property_query_timer->timeout.connect([this]() {
read_frequency_property(); // 每次 500ms：功率、健康事件等
static uint8_t slow_cnt = 0; // 慢属性：约每 10 次（5s）读取
if (++slow_cnt >= 10) {
read_slow_property();
slow_cnt = 0;
}
});
m_property_query_timer->set_single_shot(false);
m_property_query_timer->start(mc::milliseconds(500));
```
#### 内存管理
- 优先使用智能指针（`unique_ptr`、`shared_ptr`）
- 及时清理定时器等资源
**定时器资源管理：**
```cpp
// 清理定时器
if (m_property_query_timer) {
m_property_query_timer->stop();
m_property_query_timer.reset();
}
```
#### 协议优化
- 批量请求减少通信次数
- 缓存不变的数据（如产品信息）
- 失败时使用重试机制（带指数退避）
### 4.3 测试建议
#### 单元测试
- 测试每个接口的功能
- 测试异常情况处理
- 使用 mock 对象模拟协议
```cpp
// 1) 接口映射单测：验证“snake_case 属性名 -> 接口属性”的分发逻辑（无需硬件）
TEST(i_power_supply_metrics, update_metrics_mapping) {
dev::IPowerSupply_Metrics metrics;
EXPECT_TRUE(metrics.update_metrics("input_power_watts", mc::variant(100.0)));
EXPECT_TRUE(metrics.update_metrics("input_voltage", mc::variant(220.0)));
// 校验 InputPowerWatts / InputVoltage 属性已更新...
}
// 2) 协议层单测：mock 底层总线（参考 tests/libraries/smbus/chip_mock.*），
// 直接验证协议类（如厂商 PMBus 变种）的属性读取/命令解析
TEST(pmbus_variant, read_input_voltage) {
MockChip chip; // 打桩 I2C/SMBus 读写
mc::dict data{{"chip", ...}};
pmbus_xyz proto(data); // 厂商变种协议对象
auto v = proto.get_input_voltage();
EXPECT_TRUE(v.has_value());
}
```
> [!NOTE]说明
>
> - 电源主对象 `init()` 依赖 `.sr` 下发并解析 `RefChip` 引用，完整生命周期（create→init→start→stop）联调建议用 `AddDevice` 加载型号 `.sr` 验证（见《快速上手》）；
> - 风扇/电源控制类方法最终落到协议库，单测时在协议层打桩即可，不必构造真实对象。
#### 集成测试
- 测试完整的生命周期：`create` → `init` → `start` → `stop`
- 测试与实际硬件的通信
- 测试长时间运行的稳定性
**风扇相关测试重点：**
- 测试风扇转速监控的准确性
- 测试风扇转速控制的响应时间
- 测试风扇故障检测和告警
- 测试多风扇同时控制
- 测试风扇转速与温度的联动
#### 回归测试
- 每次修改后重新测试基本功能
- 检查是否影响其他电源驱动
- 验证 Redfish 接口数据正确
### 4.4 风扇管理最佳实践
> 风扇管理分两类场景，实现位置不同：
>
> 1. **PSU 内置风扇**：BMC 侧通常只设置**最小 PWM 下限**（`SetFanMinPWM`），实时调速由电源固件按温度完成；转速/状态经 `Metrics.FanSpeedRPM`、`Status.Fans_1_2`/`Fans_3_4` 上报；
> 2. **风扇部件（风扇框/模块）**：对象路径与接口见 [2.2.2](#222-drivers-目录---设备驱动实现)，由 `drivers/fan/huawei` 的 `Fans`/`Fan` 对象配合上层散热策略实现 PWM 通道与转速闭环，接口实现方式与电源接口一致。
#### PSU 内置风扇控制要点
- 通过 `PowerSupply.Control` 设置风扇最小 PWM（占空比），**取值范围与含义以 `dmc` 契约和厂商规格书为准**，不要在驱动里猜测单位或做 rpm 换算；
- 若确需直接调速（测试/调试），使用协议库 `set_fan_speed_percent()`；生产场景建议仅用“最小 PWM”+固件自动调速；
- 读取风扇状态时以**健康事件 + Status 接口**为准，不要在驱动对象里自行拼读寄存器位（厂商私有解析放协议库子类）。
#### 温度联动调速
- PSU 内置风扇的温度联动由**电源固件**完成；驱动侧保证温度指标（`EnvTemperatureCelsius` 等）与 `FanSpeedRPM` 采集及时、`.sr` 静态配置正确即可；
- 风扇框/风扇模块的温度联动属于上层散热策略，通过 `Fans` 对象（如 `SetPWM`）下发目标占空比，不在单驱动内做闭环。
#### 风扇故障处理
周期回调中健康事件已把风扇故障位分发给 `Status` 接口（例如 `update_property("fans_1_2", ev.fan_fault)` → `Status.Fans_1_2`），驱动只需保证：
```cpp
// 周期回调（示意）：健康事件 -> Status 接口，含风扇故障位
auto [ev, health_failed] = m_ps_protocol->get_health_event();
if (!health_failed) {
update_property("fans_1_2", ev.fan_fault); // 驱动把故障位交给 Status 接口
update_property("vout", ev.output_voltage_fault);
// ...
}
```
- 告警判定与防抖（连续 N 次才置位）由 `IPowerSupply_Status` 内部使用 `mc::debounce` 完成，无需驱动重复实现；
- 风扇故障后的“告警/日志”由上层（日志与告警接口）消费，驱动不直接处理自愈策略。
#### 风扇监控频率建议
| 监控项 | 建议频率 | 说明 |
|-------|---------|------|
| **健康事件（含风扇故障位）** | 500ms | 随快采周期，风扇故障能及时反映到 `Status.Fans_1_2` |
| **风扇转速 FanSpeedRPM** | 约 3s | 随指标分帧读取（`read_frequency_property` 内分帧） |
| **产品信息/慢速属性** | 约 5s 或启动时读取 | 避免频繁占用总线 |
> [!NOTE]说明
> 监控频率只是建议值。实际以各协议驱动的采集实现为准，且要避免在慢速 I2C 总线上对多路电源同时高频采集造成拥塞（必要时错峰）。
#### PMBus 命令注意事项
**1. 命令兼容性与厂商变种**
不同厂商/型号的 PMBus 实现存在差异，**不要在主对象里直接读写寄存器**；差异点收敛到 `libraries/pmbus` 的协议子类中，通过覆写虚方法表达，再注册进协议工厂表：
```cpp
// libraries/pmbus/pmbus_xyz.h（示意）：厂商变种协议子类
class pmbus_xyz : public pmbus {
public:
explicit pmbus_xyz(mc::dict& data) : pmbus(data) {}
// 厂商差异点：覆写风扇转速/私有属性读取等
std::optional get_psu_fan_speed_rpm() override;
std::optional get_firmware_version() override;
};
// drivers/psu/pmbus/one_power.cpp：注册进协议工厂表
// DEFINE_PS_PROTOCOL("psu_xyz", pmbus_xyz), ...
```
**2. 数据格式处理**
PMBus 的 LINEAR11/LINEAR16 等格式解析已封装在 `libraries/pmbus`（如 `get_linear_11()`/`get_linear_16()`），驱动层直接拿到物理量，**无需重复实现**；个别厂商编码不同时在协议子类内处理。
**3. 错误重试机制**
属性读取带重试能力由 `OnePowerBase::get_dynamic_data(属性名, 重试次数)` 提供：
```cpp
// 读取失败自动重试（例如启动阶段读产品信息，失败率高的场景给 3-5 次）
bool ok = get_dynamic_data("psu_fan_speed_rpm", 3);
```
总线级读写失败、超时等由 `chip/smbus` 层处理并上报日志；驱动无需自行 `sleep` 重试。若某个属性需要更精细的失败处理，可在协议子类中覆写对应方法并返回 `std::nullopt`，由调用侧按空值处理。
## 结语
南向风扇电源驱动适配是一项系统性工作，需要对硬件特性、PMBus 协议、软件架构都有深入理解。本文档提供了一套完整的适配流程和代码示例，涵盖了电源管理和内置风扇控制的方方面面。
**关键要点回顾：**
**电源管理：**
- 契约先行：接口/对象路径以 `dmc/`（`intf`+`path`）为准；`gen/` 下的 `dev::gen` 基类当前需人工随 dmc 同步修改（仓库内无自动生成工具链）
- 驱动按协议族组织（PMBus/CANbus/SMC…），公共能力（`OnePowerBase`、`IPowerSupply_*`）下沉 `drivers/psu/common` 供各协议复用
- 支持电压、电流、功率、温度、风扇转速等指标的周期采集，以及工作/休眠模式、复位、风扇最小 PWM、固件升级等控制
- 状态/告警经 `PowerSupply.Status` 上报（含防抖），共享电源场景支持 BMC 主从（Active/Standby）下的带外管理启停
**风扇管理：**
- PSU 内置风扇：`Metrics.FanSpeedRPM` + `Status.Fans_1_2`/`Fans_3_4` + `Control.SetFanMinPWM`，调速策略由固件完成
- 风扇部件（风扇框/模块）：由 `drivers/fan/huawei` 的 `Fans`/`Fan`/`FanType` 对象提供（PWM 通道/转速/状态等接口）
- 厂商差异（命令/数据格式）收敛到 `libraries/pmbus` 等协议库子类，避免散落在驱动对象中
**开发建议：**
- 适配新电源型号先判断适配形态：已有协议通常只需新增 `.sr/.dds` 与协议变种，无需新建驱动目录
- 仔细阅读厂商提供的 PMBus 命令规格书，注意不同型号扩展命令差异
- 依托 `get_dynamic_data()` 重试与接口更新回调，实现完善的错误处理
- 采用合理的监控频率（快慢分帧），避免 I2C 总线拥塞
- 定期进行长时间稳定性测试与回归测试
实际适配中还会遇到各种具体问题，欢迎大家积极在社区沟通交流和贡献。
---
# 总线芯片驱动开发指南
> URL: https://openubmc.cn/docs/zh/latest/component_driver/general_guide/bus_chip_driver_guide.html
> Language: zh
# 总线芯片驱动开发指南
## 概述
总线芯片驱动是南向硬件访问的底座，把 CSR 拓扑里的每个 Bus / Chip 节点变成可访问对象。本文面向需要在 `component_drivers` 中新增或修改总线、芯片驱动的开发人员。
> [!NOTE]说明
>
> 相对旧稿删除了已不存在的 `libhas/`、`Hi182x` / `SMBusHuawei` 示例和未落地的 SPI 教程。现行实现以 `device_topo`、`device_manager` 与 ABI 为准，并以 I2C、PCA9545 作为可对照源码的模板。
## 环境要求
硬件要求：交叉编译需要目标板与 `libsoc_adapter`。原生测试可用打桩驱动，不强制真实总线硬件。
软件要求：`component_drivers` 源码（以 `drivers/internal/`、`drivers/bus/`、`drivers/chip/` 为准）、meson 构建、能运行 `tests/drivers/` 单测。
权限要求：具备源码编译与单测执行权限。
## 目录
- [概述](#概述)
- [环境要求](#环境要求)
1. [范围与术语](#1-范围与术语)
2. [架构与调用链](#2-架构与调用链)
3. [目录与关键文件](#3-目录与关键文件)
4. [基类与 ACCESS_DATA_S](#4-基类与-access_data_s)
5. [CSR 配置与对象命名](#5-csr-配置与对象命名)
6. [新增 Bus 驱动](#6-新增-bus-驱动)
7. [新增 Chip 驱动](#7-新增-chip-驱动)
8. [对外接口、级联与错误处理](#8-对外接口级联与错误处理)
9. [构建与注册](#9-构建与注册)
10. [检查清单与常见问题](#10-检查清单与常见问题)
---
## 1. 范围与术语
总线芯片驱动不描述一块完整板卡。上层网卡、GPU、电源、Connector、Accessor 通过统一接口读写 I2C、Hisport、MUX、EEPROM 等器件。
| 术语 | 含义 |
|------|------|
| CSR | 部件自描述（`.sr` / `.dds` / 测试用 json）。含 `ManagementTopology` 与 `Objects`。 |
| 设备树对象 | `drivers/bus/`、`drivers/chip/` 中继承 `mc::engine::object` 的类，对 devmon 暴露 ABI 与属性。 |
| 内部器件对象 | `drivers/internal/` 中继承 `bus_base` / `chip_base` 的类，执行真正的硬件 I/O。 |
| HAS | 历史称呼。现行实现就是内部器件层 + `ACCESS_DATA_S`，没有独立 `libhas/` 目录。 |
| ABI | `include/devmon/driver_abi.h` 的 C 接口。每个设备树 SO 导出 `register_device_driver`。 |
| `device_manager` | 内部对象单例工厂，按 class_name 创建、按 object_name 索引。 |
| `device_topo` | devmon 侧拓扑引擎：解析 CSR、创建内部对象、dlopen SO、接线 `left_bus` / `host_bus` / `left_chip`。 |
| host_bus | 根物理总线。`Interface_Chip` 加锁必须锁它。 |
| left_bus | 芯片直连的那条总线，可能是 I2cMux 虚总线。 |
| left_chip | 前级 MUX / SMC 等，访问前会 `open_channel`。 |
协议栈（NCSI、MCTP、PMBUS）在 `libraries/`，不属于本指南。CSR1 专用类型（GPIO、JTAG、CPLD 等）由 `COMPONENT_DRIVERS_ENABLE_UNIDEV` 控制，不写入默认检查清单。
---
## 2. 架构与调用链
### 2.1 双层对象
每个总线 / 芯片都有两套对象，职责不能混：
```text
设备树对象（libI2c.so / libPca9545.so）
I2c_object / pca9545_object
└── Interface_*（属性 + 对外方法）
└── 裸指针 ──► 内部对象
内部对象（libInternal.so，device_manager 持有 shared_ptr）
bus_i2c / chip_pca9545
└── DRIVER_I2C::I2c 等底层驱动（生产环境来自 libsoc_adapter）
```
设备树 `init()` **不会 new 内部对象**，只按 `object_name` 从 `device_manager::find_object` 取已有实例。内部对象由 `device_topo` 在解析 CSR 时先 `create_bus` / `create_chip`。
### 2.2 加载顺序
```mermaid
sequenceDiagram
participant CSR as CSR
participant Topo as device_topo
participant Mgr as device_manager
participant SO as libXxx.so ABI
participant App as Interface_Chip
CSR->>Topo: ManagementTopology + Objects
Topo->>Mgr: create_bus / create_chip
Mgr->>Mgr: 工厂 lambda + 内部对象 init(csr)
Topo->>SO: ctor(service, name)
Topo->>SO: init(csr) → find_object + from_variant
Topo->>Topo: set_left_bus / set_host_bus / set_left_chip
Topo->>SO: start()
App->>App: BusLock(host_bus)
App->>Mgr: block_read / bit_write ...
```
类型名不是 CSR 里的单独字段，而是 **对象名第一个 `_` 之前的子串**：
| 对象名 | 抽出的类型 | 内部类 | 设备树 SO |
|--------|------------|--------|-----------|
| `I2c_3` | `I2c` | `bus_i2c` | `libI2c.so` |
| `Hisport_0` | `Hisport` | `bus_hisport` | `libHisport.so` |
| `I2cMux_Pca9545_PCA9545_4` | `I2cMux` | `bus_i2c_mux` | `libI2cMux.so` |
| `Pca9545_PCA9545` | `Pca9545` | `chip_pca9545` | `libPca9545.so` |
| `Chip_MCU1` | `Chip` | `chip_base` 或 `chip_mcu_switch` | `libChip.so` |
| `Eeprom_IEU` | `Eeprom` | `chip_eeprom` | `libEeprom.so` |
`device_name`、工厂 key、对象名前缀三者必须一致（区分大小写）。写成 `PCA9545_0` 会去找工厂 `"PCA9545"`，创建失败。
### 2.3 BlockIO 调用路径
```text
Interface_Chip::BlockIORead
→ BusLock(*host_bus) // 锁根物理总线，不是 I2cMux
→ chip_base::block_read
→ data_access → pack ACCESS_DATA_S → input()
├─ 同 topo_path 的 follower 转给 master（ChipMerge）
├─ 有 left_chip：
│ 类名 "smc" → forward_by_front_chip
│ 否则 open_channel(left_bus) → left_chip->output() → close_channel
└─ 只有 left_bus：bus->read / write
→ 物理驱动（如 DRIVER_I2C::I2c）
```
> [!WARNING]注意
>
> `open_channel` 失败必须返回，不能继续访问，否则可能写到错误通道。
### 2.4 默认支持的类型（CSR2）
**总线**：`I2c`、`Hisport`、`I2cMux`；打开 `chipv2` 时还有 `I2cOverHisport`。
**芯片**：`Chip`（`drivers/chip/complex/` 通用对象）、`Pca9545`、`Pca9555`、`Lm75`、`Eeprom`、`Ads78`、`Ina`、`Smc`。
`I2cMux` 是虚总线：只保存 `ChannelId`，`read` / `write` / `bus_lock` / `bus_unlock` 全部抛错。它的 `get_id()` 返回通道号，供 PCA9545 等 MUX 的 `open_channel` 使用。
---
## 3. 目录与关键文件
```text
component_drivers_blue/
├── drivers/
│ ├── bus/ # 总线设备树对象（每个类型一个 SO）
│ │ ├── i2c/ i2c_mux/ hisport/ i2c_over_hisport/
│ ├── chip/ # 芯片设备树对象
│ │ ├── interface/ # Interface_Chip、BlockIO、SelfDescriptionRecord
│ │ ├── pca9545/ pca9555/ lm75/ eeprom/ ads78/ powermeter/ smc/ complex/
│ ├── internal/ # 内部器件 + device_manager → libInternal.so
│ │ ├── hasdef.h # ACCESS_DATA_S
│ │ ├── manager.h/.cpp
│ │ ├── bus/bus_base/ bus_i2c/ bus_i2c_mux/ bus_hisport/ ...
│ │ └── chip/chip_base/ chip_pca9545/ chip_eeprom/ ...
│ ├── accessor/ scanner/ connector/
│ └── csr1/ # CSR1 设备树对象（unidev）
├── gen/include/device_tree/interface/
│ ├── Bus/I2c.h Hisport.h I2cMux.h
│ ├── Chip.h # bmc.dev.Chip 基础属性与 IO 方法
│ └── Chip/Pca9545.h Ina.h BlockIO.h SelfDescriptionRecord.h
├── include/devmon/driver_abi.h
└── tests/drivers/bus/ chip/ internal/
```
对照源码时优先看：
- 物理总线模板：`drivers/internal/bus/bus_i2c/` + `drivers/bus/i2c/`。
- 虚总线模板：`drivers/internal/bus/bus_i2c_mux/` + `drivers/bus/i2c_mux/`。
- MUX 芯片模板：`drivers/internal/chip/chip_pca9545/` + `drivers/chip/pca9545/`。
- 通用芯片：`drivers/chip/complex/`（工厂 key `"Chip"`）。
- CSR 样例：`tests/drivers/chip/eeprom/00000001040302044498.json`。
---
## 4. 基类与 ACCESS_DATA_S
### 4.1 ACCESS_DATA_S
定义在 `drivers/internal/hasdef.h`，是总线 `read` / `write` 的唯一入参。芯片层由 `chip_base::pack_access_data` 填充。
| 字段 | 含义 |
|------|------|
| `addr` | 器件地址。I2C 路径只取低 8 位，CSR 里通常是 **8-bit 写地址**（7-bit `<< 1`）。 |
| `offset` / `offset_width` | 寄存器或 EEPROM 偏移，及偏移Byte数（0~4）。`offset == 0xffffffff` 走 I2C / Hisport **扩展读**（无寄存器寻址，`in_buffer` 作写前缀）。 |
| `length` | 读写长度。 |
| `in_buffer` / `out_buffer` | 写数据 / 读回数据。 |
| `mask` | 位操作掩码。I2C 写路径不用它；`bit_read` 在读回后按掩码提取。 |
| `read_time_out` / `write_time_out` | 超时。 |
| `drv_write_delay` | 写后延时（ms），对应 CSR `DrvWriteDelay`。 |
| `optype` | `0` 读 / `1` 写。 |
| `protocol_flag` | `I2cOverHisport` 上 `== 2` 走 MCTP；I2C 上 `== 0x02` 走 SMBus。 |
| `cs` | SPI over Hisport 片选。 |
返回值：`HAS_OK`（0）成功，`HAS_ERR`（-1）或底层驱动错误码表示失败。
### 4.2 bus_base
路径：`drivers/internal/bus/bus_base/bus.h`。
物理总线必须覆盖：
```cpp
virtual uint32_t read(ACCESS_DATA_S& input) = 0;
virtual uint32_t write(ACCESS_DATA_S& input) = 0;
virtual void bus_lock() = 0;
virtual void bus_unlock() = 0;
virtual uint8_t get_id(); // 默认 0；I2C 返回 Id，I2cMux 返回 ChannelId
```
工厂创建成功后应调用 `set_class_name("I2c")` 等，供 `build_topo_path()` 生成 `BusType:BusId`。还有 `set_left_chip`、业务锁 `BusLockInfo`、单次最大传输长度。
I2C 组帧（`bus_i2c::format_tx_buf`）：
```text
[addr 1B] [offset 大端，OffsetWidth Byte] [payload length Byte]
```
`OffsetWidth = 0` 时没有偏移段（PCA9545 切通道）。普通读 `re_read_cnt = 1`；扩展读重试 3 次。
### 4.3 chip_base
路径：`drivers/internal/chip/chip_base/chip.h`。基类已实现默认 I/O，子类只覆盖差异。
可覆盖：
| 类别 | 函数 | 何时覆盖 |
|------|------|----------|
| 配置 / 自检 | `chip_init` / `chip_test` / `chip_reset` | 写阈值、复位脚等。`chip_init` 在拓扑接好后的 `start()` 调用，不是 `init(csr)`。 |
| 通道 | `open_channel` / `close_channel` | MUX 必须成对覆盖。 |
| 访问 | `bit_*` / `block_*` / `block_write_read` / `combo_block_write_read` | 分页、换算、RMW。 |
| 透传 | `forward_by_front_chip` / `get_class_name` | SMC 等前级。`get_class_name` 需返回稳定短名（如 `"lm75"`、`"smc"`）。 |
| 插件 | `plugin_request` | 默认：unidev 走 Lua，否则写 `0x1f` 再读 129 Byte。 |
| 诊断 | `dump` | 默认输出读写计数与错误历史 CSV。 |
`init(csr)` 解析 `Address`、`OffsetWidth`、`AddrWidth`、超时、块大小、间隔、重试、`DrvWriteDelay`。遇到 `$sync:` / `$ref:` / `<=` 等绑定表达式时跳过，留默认值，由设备树 property 系统再绑。
> [!NOTE]说明
>
> `WriteRetryTimes` / `ReadRetryTimes` 会写入成员，但 `data_access` 与 `bus_i2c` **当前不按它们重试**。真正用到写间隔的是 EEPROM 分页写的 `WriteInterval`。
CSR2 的 `Interface_Chip` 运行时只把 `DrvWriteDelay` 的变更写回内部对象。改 Address 等 property 不会自动同步到 `chip_base`（CSR1 对象才普遍绑了 `update_*`）。
---
## 5. CSR 配置与对象命名
没有合法 CSR，`device_topo` 不会 `create_*`，设备树 `init` 里 `find_object` 必然失败。
### 5.1 最小结构
```json
{
"ManagementTopology": {
"Anchor": { "Buses": ["I2c_3"] },
"I2c_3": { "Chips": ["Pca9545_Mux0"] },
"Pca9545_Mux0": { "Buses": ["I2cMux_Pca9545_Mux0_0"] },
"I2cMux_Pca9545_Mux0_0": { "Chips": ["Eeprom_Board"] }
},
"Objects": {
"I2c_3": { "Id": 3, "Speed": 0, "Mode": 0, "SlaveAddr": 0, "UseSmbus": false },
"Pca9545_Mux0": {
"Address": 226, "OffsetWidth": 0, "AddrWidth": 1,
"WriteTmout": 100, "ReadTmout": 100, "ChannelNum": 4
},
"I2cMux_Pca9545_Mux0_0": { "ChannelId": 0 },
"Eeprom_Board": {
"Address": 174, "OffsetWidth": 2, "AddrWidth": 1,
"WriteTmout": 100, "ReadTmout": 100,
"RwBlockSize": 32, "WriteInterval": 20
}
}
}
```
完整板卡样例见 `tests/drivers/chip/eeprom/00000001040302044498.json`（Hisport → PCA9545 → 多路 I2cMux → EEPROM / PCA9555 / Connector）。
### 5.2 接线规则（device_topo）
- 芯片 `left_bus` = 父总线。
- 有父芯片时：`left_chip` = 父芯片，`host_bus` = 父芯片的 host_bus（根物理总线）。
- 无父芯片：`host_bus` = 父总线。
- 子总线 `left_chip` = 当前芯片。
访问 `Eeprom_Board` 时：`left_bus` 是 I2cMux（不能 lock），`left_chip` 是 PCA9545（先 `open_channel`），`host_bus` 是 `I2c_3`（加锁并真正发事务）。
### 5.3 属性约定
**I2c**（`bmc.dev.Bus.I2c`）：`Id`、`Speed`（0→100k、1→400k、2→3400k，其它值当 kHz）、`Mode`、`SlaveAddr`、`UseSmbus`。
**I2cMux**（`bmc.dev.Bus.I2cMux`）：只有 `ChannelId`，**没有 `Id`**。不是所有总线都必须声明 `Id` 属性。
**Hisport**（`bmc.dev.Bus.Hisport`）：`Id`、`BusNum`、`RegNum`、收发 / 标志寄存器、最大长度等，见 `gen/include/device_tree/interface/Bus/Hisport.h`。
**Chip 基础**（`bmc.dev.Chip`）：`Address`、`OffsetWidth`、`AddrWidth`、`WriteTmout`、`ReadTmout`、`RwBlockSize`、`WriteInterval`、`ReadInterval`、`WriteRetryTimes`、`ReadRetryTimes`、`DrvWriteDelay`。
PCA9545 另有 `ChannelNum`。`Chip` + `"SwitchSupported": true` 时内部对象为 `chip_mcu_switch`。
---
## 6. 新增 Bus 驱动
以下以物理总线为模板。虚总线（通道选择）为可选路径，请对照 `I2cMux`：只解析 `ChannelId`，`read` / `write` / `lock` / `unlock` 抛 `invalid_op_exception`。
### 6.1 准备文件清单
新增如下路径：
```text
gen/include/device_tree/interface/Bus/{Name}.h
drivers/internal/bus/bus_{name}/{name}.h {name}.cpp meson.build
drivers/bus/{name}/
{name}.h {name}.cpp {name}_abi.cpp meson.build
interface/i_{name}.h i_{name}.cpp
```
另外还要改：`drivers/internal/manager.h` 的 include、`manager.cpp` 注册工厂；`drivers/internal/bus/meson.build` 与 `drivers/bus/meson.build` 增加 `subdir`。
### 6.2 新增设备树接口
`MC_INTERFACE` 路径：`"bmc.dev.Bus.{Name}"`。物理总线一般有 `Id`；虚总线按硬件语义定义（如 `ChannelId`）。
```cpp
namespace dev::gen {
class MC_API I2c : public mc::engine::interface {
public:
MC_INTERFACE("bmc.dev.Bus.I2c") // 须与 CSR 抽出的类型名一致
property Id;
property Speed;
property Mode;
property SlaveAddr;
property UseSmbus;
};
}
```
### 6.3 实现内部对象
继承 `bus_base`，`init` 从 CSR 取属性并创建底层驱动。`read` / `write` 只处理 `ACCESS_DATA_S`。
```cpp
class bus_i2c : public bus_base {
public:
bool init(mc::mutable_dict& csr_object); // 解析 CSR 并创建底层驱动
uint32_t read(ACCESS_DATA_S& input) override;
uint32_t write(ACCESS_DATA_S& input) override;
uint8_t get_id() override;
void bus_lock() override;
void bus_unlock() override;
private:
uint8_t m_id{};
uint32_t m_speed = 100;
std::unique_ptr m_i2c_drv;
};
```
测试 / 原生构建链入 `tests/drivers/bus/i2c/drivers/i2c.cpp` 打桩；交叉编译链 `libsoc_adapter`。不要在驱动里直接 `new` 一套与工厂无关的总线对象。
### 6.4 实现设备树对象
```cpp
class I2c_object : public mc::engine::object {
public:
MC_OBJECT(I2c_object, "I2c_object", "${object_name}", (Interface_I2c))
bool init(mc::mutable_dict& csr_object, const mc::dict& connector);
Interface_I2c m_interface_i2c;
};
```
`MC_OBJECT` 第二参数在仓内不完全统一（`I2c_object` 为 `"I2c_object"`，`Hisport_object` 为 `"Hisport"`）。**运行时匹配靠 ABI `device_name` 与对象名前缀**，新增时建议与工厂 key 一致（如 `"Hisport"`）。
`init` 只绑定内部对象：
```cpp
auto& manager = dev::device_manager::get_instance();
// 内部对象已由 device_topo 创建，这里只按 object_name 查找
auto bus_variant = manager.find_object(csr_object["object_name"].as(),
dev::object_type::bus);
auto bus_ptr = std::get>(bus_variant);
m_interface_i2c.m_bus_i2c = static_cast(bus_ptr.get());
m_interface_i2c.from_variant(csr_object);
```
`from_variant` 用 `contains()` 再 `as()`，缺省走接口类构造函数里的默认值。`.cpp` 末尾：
```cpp
MC_REFLECT(dev::I2c_object, ((m_interface_i2c, "bmc.dev.Bus.I2c")))
MC_REFLECT(dev::Interface_I2c)
```
接口类持有内部对象的 **裸指针**；生命周期由 `device_manager` 的 `shared_ptr` 管理。
### 6.5 实现 ABI
`extern "C"` 中实现 `create_*` / `init_*` / `start_*` / `stop_*`，可选 `dump_*`。
> [!WARNING]注意
>
> 禁止把 C++ 异常漏到 C 边界，否则 ABI 调用方进程可能崩溃。
```cpp
device_driver_t i2c_device_driver = {
.device_name = "I2c", // 须与对象名前缀、工厂 key 一致
.ctor = create_i2c,
.init = init_i2c,
.start = start_i2c,
.stop = stop_i2c
};
status_t register_device_driver(device_driver_t** device_driver, uint8_t* count)
{
*device_driver = i2c_device_driver_list;
*count = sizeof(i2c_device_driver_list) / sizeof(i2c_device_driver_list[0]);
return STATUS_OK; // create / init / start / stop 内须捕获异常后再返回
}
```
`ctor` 原型是 `(void* service, const char* object_name)`，不是旧文档里的 `create(config_json)` / `get_device_driver()`。
### 6.6 注册工厂
```cpp
m_bus_factories["I2c"] = [](mc::mutable_dict& csr_data) -> std::shared_ptr {
auto ptr = std::make_shared();
if (ptr && ptr->init(csr_data)) {
ptr->set_class_name("I2c"); // 供 topo_path 使用，须与工厂 key 一致
return ptr;
}
return nullptr; // init 失败则不注册
};
```
同名对象已存在时 `create_bus` 直接返回表中实例（跨 position 共享总线）。meson 与单测注册见[构建与注册](#9-构建与注册)。
### 6.7 验证新增结果
完成本章与第 9 章后，确认：
1. 内部单测 `tests/drivers/bus/{name}/` 的 `read` / `write` 通过。
2. ABI `init` 后 `find_object` 能取到内部对象。
3. 产物 `lib{Name}.so` 已拷贝到 `drivers_install_dir`。
---
## 7. 新增 Chip 驱动
通用寄存器类芯片可只复用 `Chip`（`complex_object` + `chip_base`），不必新 SO。需要 MUX、分页、换算或专有属性时再新增类型。
### 7.1 确认是否复用 Chip
先确认不能复用 `"Chip"` / `complex`，再新增类型。所有 Chip 设备树对象都必须包含 `Interface_Chip`（`drivers/chip/interface/`）。专有属性再加 `Interface_{Name}`。`meson.build` 通过 `chip_interface_sources` 链入公共 `i_chip.cpp`。
### 7.2 准备文件清单
新增如下路径：
```text
gen/include/device_tree/interface/Chip/{Name}.h # 仅专有属性时需要
drivers/internal/chip/chip_{name}/{name}.h {name}.cpp meson.build
drivers/chip/{name}/
{name}.h {name}.cpp {name}_abi.cpp meson.build
interface/i_{name}.h i_{name}.cpp # 有专有接口时
```
### 7.3 新增设备树接口
基础属性在 `bmc.dev.Chip`，不要重复定义。PCA9545 只额外声明通道数：
```cpp
namespace dev::gen {
class MC_API Pca9545 : public mc::engine::interface {
public:
MC_INTERFACE("bmc.dev.Chip.Pca9545") // 专有接口名，基础属性仍走 bmc.dev.Chip
property ChannelNum;
};
}
```
EEPROM **没有** `Chip/Eeprom.h`。分页用基础属性 `RwBlockSize` / `WriteInterval`，自描述用 `bmc.dev.Chip.SelfDescriptionRecord`。
### 7.4 实现内部对象
```cpp
class chip_pca9545 : public chip_base {
public:
bool init(mc::mutable_dict& csr_object);
int32_t open_channel(std::shared_ptr bus) override;
int32_t close_channel(std::shared_ptr bus) override;
int32_t chip_reset() override;
};
```
`init` 必须先调基类：
```cpp
bool chip_pca9545::init(mc::mutable_dict& csr_object)
{
// 先解析 Address、超时等基础字段
if (!chip_base::init(csr_object)) {
return false;
}
if (csr_object.contains("ChannelNum")) {
m_channel_num = csr_object["ChannelNum"].as();
}
return true;
}
```
通道切换按下游虚总线的 `get_id()` 写控制寄存器：
```cpp
uint8_t write_reg = static_cast(1 << bus->get_id());
block_write(0, {write_reg}, empty, error); // OffsetWidth=0，无寄存器寻址
```
关闭通道写 `0x00`。`open_channel` 失败用 `MC_THROW` 或返回 `HAS_ERR`，不要继续 I/O。
按需覆盖的其它模式：
- **PCA9555**：`bit_write` 先把 config 寄存器对应位配成输出，再 RMW 输出寄存器。
- **EEPROM**：`block_read` / `block_write` 按页拆分，写完 `sleep(WriteInterval)`。
- **LM75**：`start()` 里调 `chip_init()` 写温度阈值；覆盖 `bit_read` 做换算。
### 7.5 实现设备树对象
```cpp
class pca9545_object : public mc::engine::object {
public:
MC_OBJECT(pca9545_object, "Pca9545", "${object_name}",
(Interface_Pca9545)(Interface_Chip))
bool init(mc::mutable_dict& csr_object, const mc::dict& connector);
std::string dump();
Interface_Pca9545 m_interface_pca9545;
Interface_Chip m_interface_chip;
};
```
`init` 中把同一个 `chip_pca9545*` 赋给各接口的裸指针，再分别 `from_variant`。反射：
```cpp
MC_REFLECT(dev::pca9545_object,
((m_interface_chip, "bmc.dev.Chip"))
((m_interface_pca9545, "bmc.dev.Chip.Pca9545")))
```
需要硬件侧初始化时实现 `start()`（如 `eeprom_object::start` 解析 header，`lm75_object` 调 `chip_init()`）。总线类 `start` / `stop` 多为空操作。
### 7.6 实现 ABI 与工厂
`device_name` 用 `"Pca9545"`。芯片 SO 建议实现 `dump`（调用 `chip_base::dump`）。工厂：
```cpp
m_chip_factories["Pca9545"] = [](mc::mutable_dict& csr_data) -> std::shared_ptr {
auto ptr = std::make_shared();
if (ptr && ptr->init(csr_data)) {
return ptr;
}
return nullptr; // init 失败则不注册
};
```
通用 `"Chip"` 工厂在 `SwitchSupported == true` 时创建 `chip_mcu_switch`，否则 `chip_base`。meson 与单测注册见[构建与注册](#9-构建与注册)。
### 7.7 验证新增结果
完成本章与第 9 章后，确认：
1. 内部 `init` 先调用了 `chip_base::init`。MUX 的 `open_channel` / `close_channel` 成对生效。
2. ABI `device_name`、工厂 key、对象名前缀三者一致。
3. 单测 `tests/drivers/chip/{name}/` 通过，且 ABI `init` 能 `find_object`。
---
## 8. 对外接口、级联与错误处理
### 8.1 Interface_Chip（上层真正调用的 API）
声明在 `gen/include/device_tree/interface/Chip.h`，实现 `drivers/chip/interface/i_chip.cpp`。
| 方法 | 内部实现 | 说明 |
|------|----------|------|
| `BitIORead(offset, length, mask)` | `bit_read` | 读后按 mask 提取，length 仅 1 / 2 / 4。 |
| `BitIOWrite(...)` | `bit_write` | 按 mask 做读改写。 |
| `BlockIORead(offset, length)` | `block_read` | 连续块读。 |
| `BlockIOWrite(offset, buffer)` | `block_write` | 连续块写。 |
| `BlockIOWriteRead(indata, read_length)` | `block_write_read`，offset=`0xffffffff` | 扩展写读。 |
| `BlockIOComboWriteRead(...)` | 先 `block_write` 再 `block_read` | 两次独立事务。 |
每个方法都是：
```cpp
BusLock lock(*m_chip->get_host_bus()); // 锁根物理总线，不要锁 I2cMux
auto result = m_chip->block_read(...);
if (result != HAS_OK) {
MC_THROW(mc::method_call_exception, "BlockIORead failed, ...");
}
```
`BusLock`（`drivers/chip/bus_lock.h`）构造时 `bus_lock()`，析构时 `bus_unlock()` 且不抛异常。
`bmc.kepler.Chip.BlockIO` 的 `PluginRequest` 走 `plugin_request`。Lua 插件设计见《Chip 器件插件机制详细设计说明书》。
Accessor 通过 CSR 的 `Chip` + `Offset` + `Mask` + `Size` 调 BitIO，不在芯片 SO 内实现轮询。
### 8.2 级联与 ChipMerge
`chip_base::input` / `output` 沿 `left_chip` 递归。首次 I/O 按 `topo_path` 注册到 `ChipMergeRegistry`：相同路径的后续实例成为 follower，I/O 转到 master。路径形如：
```text
Hisport:0@Pca9545:e2w1_0-I2cMux:4@Eeprom:aew1_2
```
多份 CSR 描述同一颗物理芯片时会合并。调试时 `dump()` 统计记在 master 上。
### 8.3 错误处理
- 内部 I/O：返回 `HAS_OK` / 非 0；失败写入 `m_last_access_error` 与最多 10 条 `m_error_history`。
- 设备树 / 接口：`MC_THROW` + `elog`；ABI 捕获后返回 `STATUS_ERROR`。
- `open_channel` 失败：记录并返回，不继续 `output`。
- 参数：空 CSR、空 `in_buffer`、非法 `offset_width` 在对应层抛 `invalid_arg_exception` / `invalid_op_exception`。
- 日志：`tlog` / `dlog` / `ilog` / `wlog` / `elog`，格式 `"${key}"` + `("key", value)`。
---
## 9. 构建与注册
内部实现链接进 **一个** `libInternal.so`。每种设备树类型一个 SO：`libI2c.so`、`libPca9545.so`。测试通过 `dlopen` 加载 SO，因此必须把产物拷到 `drivers_install_dir`。
必须采用 core 静态库 + `link_whole` 共享库，禁止在测试侧重复编译驱动源文件。
```meson
# 源码只编译进 core，避免测试再编一份
xxx_core_lib = static_library(
'XxxCore',
xxx_sources,
include_directories: xxx_include_dirs,
dependencies: [internal_dep, libmcpp_deps],
cpp_args: ['-Os', '-ffunction-sections', '-fdata-sections'],
pic: true,
install: false,
)
# 空 sources + link_whole，生成运行时 SO
xxx_lib = shared_library(
'Xxx',
[],
dependencies: [internal_dep, libmcpp_deps],
link_whole: [xxx_core_lib],
link_args: common_link_args,
name_prefix: 'lib',
name_suffix: 'so',
install: true,
install_dir: drivers_install_dir,
)
# 单测链接 core，不要再列驱动 .cpp
xxx_test_dep = declare_dependency(
link_whole: xxx_core_lib,
dependencies: [internal_dep, libmcpp_deps],
)
```
测试拷贝使用 stamp 文件。`cp` 建议 `--remove-destination`。现行部分 meson 仍写 `cp -f`，新增请按本节模板。
还需要按顺序完成：
1. 在 `drivers/internal/bus/meson.build` 或 `chip/meson.build` 增加 `subdir('bus_xxx')`，并加入 `bus_sources` / `chip_sources`。
2. 在 `drivers/bus/meson.build` 或 `drivers/chip/meson.build` 增加 `subdir('xxx')`。
3. 在 `manager.h` include 头文件，在 `init_factory_maps()` 注册，总线调用 `set_class_name`。
单测放 `tests/drivers/bus/{name}/`、`tests/drivers/chip/{name}/`、`tests/drivers/internal/`。ABI 测试 `dlopen` 对应 `libXxx.so`，`test()` 声明 `depends: all_copy_targets` 并设置 `LD_LIBRARY_PATH`。
### 9.1 验证构建结果
构建完成后确认：`ninja` 能生成 `libInternal.so` 与 `libXxx.so`；测试目录能加载到拷贝后的 SO；`LD_LIBRARY_PATH` 指向 `drivers_install_dir`。
---
## 10. 检查清单与常见问题
### 10.1 新增 Bus
- [ ] 已新增 `gen/include/device_tree/interface/Bus/{Name}.h`，并声明 `MC_INTERFACE("bmc.dev.Bus.{Name}")`。
- [ ] 已在 `drivers/internal/bus/bus_{name}/` 实现纯虚函数（虚总线除 `get_id` 外应抛错）。
- [ ] 已在 `drivers/bus/{name}/` 实现设备树对象、`from_variant`、ABI、`MC_REFLECT`。
- [ ] meson 已在 internal 与 drivers 两处增加 `subdir`，并采用 core + `link_whole` 与 copy stamp。
- [ ] 已在 `manager.h` / `manager.cpp` 注册工厂，调用 `set_class_name`，且 key 与 `device_name`、对象名前缀一致。
- [ ] CSR 的 `Objects` 与拓扑同名，物理总线属性与接口一致。
- [ ] 内部 `read` / `write` 单测通过，ABI `init` 能 `find_object`。
### 10.2 新增 Chip
- [ ] 已确认不能复用 `"Chip"` / `complex`。
- [ ] 仅在有专有属性时新增 `Chip/{Name}.h`，并且挂了 `Interface_Chip`。
- [ ] 内部 `init` 先调 `chip_base::init`。MUX 已覆盖 `open_channel` / `close_channel`。
- [ ] 设备树 `init` 只 `find_object`。需要硬件配置时在 `start()` 调 `chip_init`。
- [ ] ABI `device_name`、工厂 key、对象名前缀一致，并建议实现 `dump`。
- [ ] meson 与 manager 注册与第 9 章一致。
- [ ] CSR 的 `Address` 为 8-bit 写地址，`OffsetWidth` 与手册一致（PCA9545 常为 0，EEPROM 常为 2）。
### 10.3 常见问题
| 现象 | 原因 | 处理 |
|------|------|------|
| `Unsupported chip/bus type` 或 create 返回 nullptr | 未注册工厂，或对象名前缀与 key 不一致。 | 检查 `extract_device_type` 与 `m_*_factories`。 |
| `bus/chip not found` | 拓扑未 `create_*`，或设备树 `init` 早于内部对象。 | 检查 CSR 拓扑与 object_name。 |
| 段错误 / 空 host_bus | 未接线或锁了 I2cMux。 | 确认 `set_host_bus`；锁 `get_host_bus()`。 |
| 读写到错误通道 | `open_channel` 失败仍继续，或 `ChannelId` 错。 | 失败即返回；核对 I2cMux 的 `ChannelId`。 |
| 配置不生效 | `from_variant` 字段名与 CSR 不一致；或改了 property 但 CSR2 未回写内部对象。 | 对齐字段；Address 等以内部 `init(csr)` 为准。 |
| 链接 / 测试找不到 SO | meson 未 copy，或测试未依赖 `all_copy_targets`。 | 按第 9 章补 copy 与 `LD_LIBRARY_PATH`。 |
| ABI 进程崩溃 | 异常穿过 `extern "C"`。 | 全部 catch 并返回状态码。 |
调试一次失败的 BlockIO，按顺序查：对象名能否抽出正确类型 → `device_manager` 是否已有内部对象 → `host_bus` / `left_bus` / `left_chip` 是否接上 → `open_channel` 是否成功 → `addr` / `offset_width` 是否与手册一致。
---
# 设备驱动开发指南
> URL: https://openubmc.cn/docs/zh/latest/component_driver/general_guide/device_driver_develop_guide.html
> Language: zh
# 设备驱动开发指南
## 1. 概述
本指南面向Component Drivers项目的设备驱动开发者，提供从设计到实现的完整开发流程。Component Drivers是一个基于C++17的硬件组件驱动程序框架，采用分层架构设计，支持多种设备类型和通信协议。
### 1.1 项目特点
- **分层架构**：设备树对象层 + 内部器件对象层 + 协议通信层
- **多设备支持**：PCIe网卡、GPU、传感器、总线设备、访问器等
- **协议集成**：NCSI over MCTP、IMU、MCTP、多厂商协议支持
- **配置驱动**：基于设备树的配置管理和反射机制
- **标准化ABI**：统一的驱动注册和生命周期管理
- **统一管理**：采用device_manager单例模式管理所有设备对象
- **智能指针**：使用shared_ptr自动管理设备生命周期
### 1.2 支持的设备类型
| 设备类型 | 实现示例 | 协议支持 | 厂商支持 |
|----------|----------|----------|----------|
| PCIe网卡 | `rp1000_card`, `hi182x_card`, `hi1822_fc_card` | NCSI over MCTP, IMU | 网迅、华为海思等 |
| PCIe GPU | `awm_m11p_card` | MCTP | 全志元芯等 |
| 通用访问器 | `accessor` | 标准PCIe | 通用 |
| 总线设备 | `bus_i2c`, `bus_hisport`, `bus_i2c_mux` | I2C, Hisport | 通用 |
| 芯片设备 | `chip_pca9545`, `chip_lm75`, `chip_eeprom` | I2C协议 | 通用芯片 |
| 扫描器 | `scanner` | 设备扫描 | 通用 |
| 复合器件 | `complex` | 多协议组合 | 通用 |
### 1.3 设备对象系统
Component Drivers采用基于MC_OBJECT宏的设备对象模型，实现设备的层次化管理：
#### 1.3.1 设备对象定义
设备对象通过MC_OBJECT宏定义其核心特征：
```cpp
// 以华为海思 hi182x 网卡为例（完整定义见 drivers/pcie_nic_card/hisi/hi182x/hi182x_card.h）
namespace dev {
// 协议智能指针类型别名（与库中定义一致）
using ncsi_over_mctp_hw_ptr = std::shared_ptr;
using smbus_obj_ptr = mc::shared_ptr;
using imu_ptr = std::shared_ptr;
class hi182x_card : public mc::engine::object {
public:
MC_OBJECT(
hi182x_card, "PCIeNicCard", "/bmc/dev/Systems/1/PCIeNicCard/${object_name}",
(PCIeDevice)(PCIeDevice_PCIeFunction)(PCIeDevice_Oem)(PCIeDevice_Status)(PCIeCard)(PCIeCard_Oem)
(PCIeCard_Metrics)(NetworkAdapter)(NetworkAdapter_FaultStatus)(Cooling)(NetworkAdapter_Oem)(Board)
(PCIeDevice_Bandwidth)(NetworkAdapter_LogCollection)(Fru))
// 接口实例 - 组合多个接口实现复杂功能（类型即接口名，与 MC_OBJECT 中声明一致）
PCIeDevice m_pcie_device;
PCIeDevice_PCIeFunction m_pcie_device_pcie_function;
NetworkAdapter m_network_adapter;
PCIeCard m_pcie_card;
Board m_board;
Cooling m_cooling;
NetworkAdapter_FaultStatus m_network_adapter_fault_status;
PCIeDevice_Bandwidth m_pcie_device_bandwidth;
NetworkAdapter_LogCollection m_network_adapter_log_collection;
// 子设备集合（原始指针由框架通过 get_children() 管理，驱动只做类型转换）
std::vector m_network_ports;
// 协议实例（MCTP 使用 mc::shared_ptr，其余使用 std::shared_ptr）
ncsi_over_mctp_hw_ptr m_ncsi_over_mctp_huawei;
imu_ptr m_imu_obj;
smbus_obj_ptr m_smbus_obj;
mc::shared_ptr m_mctp_object;
// 生命周期方法（实际签名）
bool init(mc::mutable_dict& csr_object, const mc::dict& connector);
bool start();
bool stop();
};
} // namespace dev
```
#### 1.3.2 设备对象层次结构
设备对象形成树状层次结构：
```shell
/bmc/dev/ # 根节点
└── Systems/ # 系统节点
└── 1/ # 系统ID
└── PCIeNicCard/ # 设备类型
└── {object_name}/ # 设备实例（由 ${object_name} 替换）
├── [PCIeDevice] # 接口：PCIe设备信息
├── [NetworkAdapter] # 接口：网络适配器
├── [PCIeCard] # 接口：PCIe卡信息
├── [Board] # 接口：板卡信息
└── NicPort/ # 子设备
├── 0/ # 端口0
│ ├── [NetworkPort] # 接口：网络端口
│ └── OpticalTransceiver/ # 光模块
│ └── [OpticalModule]
└── 1/ # 端口1
├── [NetworkPort]
└── OpticalTransceiver/
└── [OpticalModule]
```
#### 1.3.3 接口系统
接口采用"自动生成 + 手动实现"的模式：
| 命名空间 | 来源 | 职责 | 示例 |
|---------|------|------|------|
| **gen::** | 代码生成 | 接口基类定义 | `gen::PCIeDevice` |
| **dev::** | 手工编写 | 厂商接口实现 | `dev::PCIeDevice` |
| **子接口** | 手工编写 | 功能细分接口 | `NetworkPort_LinkInfo` |
**接口组合示例**：
```cpp
// PCIe网卡组合了多个接口
class hi182x_card {
PCIeDevice m_pcie_device; // PCIe设备接口
PCIeDevice_PCIeFunction m_pcie_device_pcie_function; // PCIe功能接口（BDF/VID/DID）
NetworkAdapter m_network_adapter; // 网络适配器接口
PCIeCard m_pcie_card; // PCIe卡接口
Board m_board; // 板卡信息接口
Cooling m_cooling; // 散热子接口（bmc.dev.Cooling）
NetworkAdapter_FaultStatus m_network_adapter_fault_status; // 故障状态子接口
NetworkAdapter_LogCollection m_network_adapter_log_collection; // 日志收集子接口
PCIeDevice_Bandwidth m_pcie_device_bandwidth; // 带宽监控子接口
};
```
#### 1.3.4 MC_REFLECT反射机制
MC_REFLECT实现属性的编译期反射和运行时动态访问：
```cpp
// 1. 接口类继承 mc::engine::interface 并关联的 gen:: 基类
class PCIeDevice : public mc::engine::interface {
public:
std::string DeviceName;
std::string VendorId;
std::string DeviceId;
uint8_t Bus, Device, Function;
};
// 2. 设备对象注册反射信息：将成员与 D-Bus 接口名关联（与 hi182x_card.cpp 一致）
MC_REFLECT(dev::hi182x_card,
((m_system_id, "SystemId"))((m_pcie_device, "bmc.dev.PCIeDevice"))
((m_pcie_device_pcie_function, "bmc.dev.PCIeDevice.PCIeFunction"))
((m_pcie_device_oem, "bmc.dev.PCIeDevice.Oem"))
((m_pcie_device_status, "bmc.dev.PCIeDevice.Status"))
((m_pcie_card, "bmc.dev.PCIeCard"))((m_pcie_card_oem, "bmc.dev.PCIeCard.Oem"))
((m_pcie_card_metrics, "bmc.dev.PCIeCard.Metrics"))
((m_network_adapter, "bmc.dev.NetworkAdapter"))
((m_network_adapter_fault_status, "bmc.dev.NetworkAdapter.FaultStatus"))
((m_cooling, "bmc.dev.Cooling"))((m_network_adapter_oem, "bmc.dev.NetworkAdapter.Oem"))
((m_board, "bmc.dev.Board"))((m_pcie_device_bandwidth, "bmc.dev.PCIeDevice.Bandwidth"))
((m_fru, "bmc.dev.Fru"))
((m_network_adapter_log_collection, "bmc.dev.NetworkAdapter.LogCollection")))
// 3. 运行时使用
mc::dict properties;
mc::reflect::to_variant(card->m_pcie_device, properties); // 对象 -> JSON
card->m_pcie_device.DeviceName = "NewCard"; // 直接访问属性
```
### 1.4 协议库系统
Component Drivers集成了多种通信协议，为设备驱动提供底层通信能力：
#### 1.4.1 协议架构
```mermaid
flowchart LR
subgraph "设备驱动层"
Driver["设备驱动
hi182x_card"]
end
subgraph "协议库层"
NCSI["NCSI
标准协议"]
MCTP["MCTP
传输协议"]
NOM["NCSI over MCTP
华为扩展"]
IMU["IMU协议
IPMI接口"]
end
subgraph "传输层"
PCIe["PCIe传输"]
I2C["I2C/SMBus"]
Socket["Socket通信"]
end
Driver -->|网卡管理| NOM
Driver -->|设备信息| IMU
NOM --> MCTP
NOM --> NCSI
MCTP --> PCIe
MCTP --> I2C
IMU --> I2C
NCSI --> Socket
```
#### 1.4.2 NCSI协议
**NCSI (Network Controller Sideband Interface)** 是DMTF标准的网卡带外管理协议：
**核心命令**：
| 命令 | 代码 | 功能 | 用途 |
|------|------|------|------|
| GET_LINK_STATUS | 0x0A | 获取链路状态 | 监控链路UP/DOWN |
| SET_MAC_ADDRESS | 0x0E | 设置MAC地址 | 配置网卡MAC |
| ENABLE_VLAN | 0x0C | 启用VLAN | 配置VLAN过滤 |
| GET_CAPABILITIES | 0x16 | 获取能力 | 查询控制器功能 |
| OEM_COMMAND | 0x50 | 厂商命令 | 厂商扩展功能 |
**使用示例**：
```cpp
// NCSI 标准命令通过 ncsi_over_mctp_standard 提供，需基于 MCTP 对象构造
mc::shared_ptr mctp_obj =
mc::make_shared(this, mctp::init_phy_addr(0x01, 0x00, 0x00),
MCTP_MESSAGE_TYPE::MCTP_MESSAGE_TYPE_NCSI, "");
ncsi_over_mctp_standard ncsi(mctp_obj);
// 获取链路状态
ncsi_link_status_info_t link_status;
if (ncsi.get_link_status(DEFAULT_PACKAGE_ID, DEFAULT_CHANNEL_ID, &link_status)) {
ilog("Link: ${status}, Speed: ${speed} Mbps",
("status", link_status.link_status ? "UP" : "DOWN")("speed", link_status.speed_mbps));
}
// 获取能力信息
ncsi_capabilities_info_t capability;
ncsi.get_capabilities(DEFAULT_PACKAGE_ID, DEFAULT_CHANNEL_ID, &capability);
```
#### 1.4.3 MCTP协议
**MCTP (Management Component Transport Protocol)** 是DMTF标准的管理组件传输协议：
**消息类型**：
- `MCTP_MESSAGE_TYPE_MCTP_CTRL` (0x00) - MCTP控制消息
- `MCTP_MESSAGE_TYPE_PLDM` (0x01) - PLDM消息
- `MCTP_MESSAGE_TYPE_NCSI` (0x02) - NCSI消息
- `MCTP_MESSAGE_TYPE_NVME` (0x04) - NVMe管理消息
- `MCTP_MESSAGE_TYPE_VDPCI` (0x7E) - PCIe厂商定义消息
**物理媒介**：
- `PHY_MEDIUM_PCI` (0x0F) - PCIe绑定
- `PHY_MEDIUM_SMBUS` (0x02) - SMBus绑定
- `PHY_MEDIUM_SMBUS_OEM` (0x80) - SMBus OEM绑定
**使用示例**：
```cpp
// MCTP 对象无默认构造函数，需传入父对象、物理地址、消息类型和位置
uint16_t phy_addr = mctp::init_phy_addr(bus, device, function); // 静态方法计算物理地址
mc::shared_ptr mctp_obj =
mc::make_shared(this, phy_addr, MCTP_MESSAGE_TYPE::MCTP_MESSAGE_TYPE_NCSI, "");
// 创建传输对象和端点对象，端点和传输就绪后回调初始化业务任务
mctp_obj->create_transport_and_endpoint(std::string(get_object_name()), [this]() {
// 端点就绪后，启动 NCSI 等上层协议任务
});
// 发送请求（request 返回 bool，响应保存在 rsp 字符串中）
mc::dict ctx = {{"timeout", 1000}};
std::vector request_data = {...}; // 填充请求数据
std::string rsp;
if (mctp_obj->request(ctx, request_data, 1000, rsp)) {
// 处理响应...
}
```
#### 1.4.4 NCSI over MCTP协议
**NCSI over MCTP** 是华为扩展的混合协议，通过MCTP传输层发送NCSI命令：
**架构优势**：
| 特性 | NCSI | MCTP | NCSI over MCTP |
|------|------|------|----------------|
| 传输方式 | Socket | PCIe/I2C | MCTP传输NCSI |
| OEM扩展 | 有限 | 丰富 | 丰富OEM命令 |
| 性能 | 中等 | 高 | 高性能 |
| 适用场景 | 标准网卡 | 通用管理 | 华为网卡 |
**协议栈实现**：
```shell
ncsi_over_mctp_huawei (华为OEM命令实现)
↓
ncsi_over_mctp_standard (标准NCSI命令实现)
↓
ncsi_over_mctp (基础封装)
↓
mctp (MCTP传输层)
```
**华为OEM命令**：
| 命令 | 功能 | 用途 |
|------|------|------|
| `get_bdf` | 获取 BDF 信息 | 获取网卡所在总线/设备/功能号 |
| `get_mac_addr` / `get_default_mac_addr` | 获取 MAC 地址 | MAC 地址管理 |
| `get_chip_temp` / `get_om_temp` | 获取芯片/光模块温度 | 温度监控 |
| `get_link_ability` / `get_link_info` | 获取链路能力/信息 | 链路状态查询 |
| `get_dcbx_status` | 获取 DCBX 状态 | 数据中心桥接配置 |
| `get_fault_state_code` | 获取故障状态码 | 故障诊断 |
| `get_optical_module_info` | 获取光模块信息 | 光模块管理 |
| `collect_logs_by_ncsi` / `collect_logs_by_new_cmd` | 收集日志 | 故障诊断 |
| LLDP 系列（`enable/disable/get_lldp_*`） | 管理 LLDP 能力与发送 | 链路发现 |
**使用示例**：
```cpp
// 1. 创建 MCTP 对象（NCSI over MCTP 基于 MCTP 传输层）
uint16_t phy_addr =
mctp::init_phy_addr(m_pcie_device_pcie_function.BusNumber,
m_pcie_device_pcie_function.DeviceNumber,
m_pcie_device_pcie_function.FunctionNumber);
mc::shared_ptr mctp_obj =
mc::make_shared(this, phy_addr, MCTP_MESSAGE_TYPE::MCTP_MESSAGE_TYPE_NCSI, "");
// 2. 通过 MCTP 对象构造华为扩展协议实例
ncsi_over_mctp_hw_ptr nom_hw = std::make_shared(mctp_obj);
// 3. 获取链路信息（package_id/channel_id 为入参，信息写入出参指针）
ncsi_link_info_t link_info;
if (nom_hw->get_link_info(DEFAULT_PACKAGE_ID, DEFAULT_CHANNEL_ID, &link_info)) {
ilog("Link width: ${width}, speed: ${speed}",
("width", link_info.link_width)("speed", link_info.link_speed));
}
// 4. 获取芯片温度
uint16_t chip_temp = 0;
if (nom_hw->get_chip_temp(DEFAULT_PACKAGE_ID, DEFAULT_CHANNEL_ID, &chip_temp)) {
ilog("Chip temperature: ${temp}", ("temp", chip_temp));
}
// 5. 在设备对象中，通常通过 mctp->create_transport_and_endpoint 回调中创建并绑定任务：
mctp_obj->create_transport_and_endpoint(std::string(get_object_name()), [this, mctp_obj]() {
m_ncsi_over_mctp_huawei = std::make_shared(mctp_obj);
m_network_adapter.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei, m_interval);
});
```
#### 1.4.5 IMU协议
**IMU (Inertial Measurement Unit)** 协议用于通过IPMI获取PCIe设备信息：
**使用示例**：
```cpp
// 创建IMU对象（无默认构造函数，需传入服务指针）
imu_ptr m_imu_obj = std::make_shared(get_service());
// 准备请求
imu_pcie_device_req_t req = {
.system_id = m_system_id,
.socket_id = m_pcie_device.SocketId,
.bus = m_pcie_device_pcie_function.BusNumber,
.device = m_pcie_device_pcie_function.DeviceNumber,
.function = m_pcie_device_pcie_function.FunctionNumber,
.pci_info_address = VID_DID_ADDRESS, // VendorID + DeviceID
.rlen = 4,
};
// 获取设备信息（返回 std::optional>，小端序 VID/DID）
auto info = m_imu_obj->get_info_from_imu(true, req);
if (info && info->size() >= 4) {
uint16_t device_id = (static_cast((*info)[3]) << 8) | (*info)[2];
uint16_t vendor_id = (static_cast((*info)[1]) << 8) | (*info)[0];
ilog("VID=0x${vid:04x}, DID=0x${did:04x}", ("vid", vendor_id)("did", device_id));
}
```
### 1.5 驱动ABI接口
驱动通过标准的C风格ABI接口与devmon框架交互。ABI定义在`include/devmon/driver_abi.h`中：
```cpp
// 设备驱动描述结构
struct device_driver {
const char* device_name; // 设备名称（如 "PCIeNicCard"）
const driver_ctor ctor; // 创建函数
const driver_init init; // 初始化函数
const driver_start start; // 启动函数
const driver_stop stop; // 停止函数
driver_dump dump = nullptr; // 可选：设备状态转储
};
typedef struct device_driver device_driver_t;
// 驱动SO导出的注册函数：返回驱动数组及其数量
status_t register_device_driver(device_driver_t** device_driver, uint8_t* count);
```
驱动SO导出的是`register_device_driver`符号（而非`get_device_driver`），实现方式见 4.6 节示例。
## 2. 架构设计
### 2.1 分层架构概览
```mermaid
graph TB
A[应用管理层
BMC管理应用、devmon服务]
B[设备树对象层
配置管理、ABI接口、生命周期管理]
C[设备管理层
device_manager单例管理]
D[内部器件对象层
硬件操作、业务逻辑、资源管理]
E[协议通信层
NCSI over MCTP、MCTP、IMU、SMBUS协议栈]
F[物理传输层
PCIe传输、I2C传输、Socket通信]
A -->|标准化ABI调用| B
B -->|设备管理| C
C -->|创建和管理| D
D -->|协议绑定| E
E -->|传输封装| F
style A fill:#e1f5fe
style B fill:#f3e5f5
style C fill:#fff9c4
style D fill:#e8f5e8
style E fill:#fff3e0
style F fill:#fce4ec
```
### 2.2 设备树对象与内部器件对象关系
```mermaid
graph LR
subgraph "设备树对象层"
A[hi182x_card
PCIe网卡对象]
B[PCIeDevice
接口对象]
C[NetworkAdapter
接口对象]
D[Board
接口对象]
E[network_ports
子设备集合]
end
subgraph "设备管理层"
F[device_manager
单例管理器]
end
subgraph "协议通信层"
G[ncsi_over_mctp_huawei
协议实例]
H[imu协议实例]
end
subgraph "内部器件对象层"
I[Hi182xCardInternal
内部实现]
J[硬件操作接口]
K[业务逻辑处理]
end
A --> B
A --> C
A --> D
A --> E
A -.管理.-> F
B --> G
C --> G
A --> H
A --> I
I --> J
I --> K
style A fill:#ffeb3b
style F fill:#fff9c4
style G fill:#4caf50
style H fill:#ff9800
style J fill:#2196f3
```
#### 2.2.1 职责分工
**设备树对象**：
- 负责设备树配置管理和对外ABI接口
- 继承自`mc::engine::object`，支持设备树配置
- 包含接口类成员，用于属性管理和配置加载
- 实现`init()`, `start()`, `stop()`等生命周期方法
**内部器件对象**：
- 负责具体的硬件操作和业务逻辑实现
- 继承自`bus_base`或`chip_base`基类
- 实现具体的读写、初始化、硬件自检等功能
- 管理底层驱动实例和硬件资源
## 3. 开发流程
### 3.1 开发准备
#### 3.1.1 环境要求
- **操作系统**：Linux (推荐Ubuntu 18.04+)
- **编译器**：支持C++17的GCC 7.0+或Clang 5.0+
- **构建系统**：Meson 0.50+
- **依赖库**：libmcpp (自动管理)
#### 3.1.2 源码结构
```shell
component_drivers/
├── drivers/ # 驱动实现
│ ├── [device_type]/ # 设备类型目录
│ │ ├── [vendor]/ # 厂商实现目录
│ │ └── interface/ # 接口实现
│ └── internal/ # 内部器件对象
├── gen/device_tree/interface/ # 生成的设备树接口
├── libraries/ # 协议通信库
├── include/devmon/ # 公共头文件
└── tests/ # 测试代码
```
### 3.2 新驱动开发步骤
```mermaid
flowchart TD
A[步骤1: 需求分析和设计] --> B[步骤2: 设备树接口定义]
B --> C[步骤3: 内部器件对象实现]
C --> D[步骤4: 接口类实现]
D --> E[步骤5: 设备对象实现]
E --> F[步骤6: ABI接口实现]
F --> G[步骤7: 构建配置]
G --> H[编译测试]
H --> I[集成测试]
I --> J[部署运行]
A1[确定设备类型
选择基类
协议选择
接口设计] -.-> A
B1[定义属性
虚函数接口
反射配置] -.-> B
C1[硬件操作逻辑
资源管理
状态控制] -.-> C
D1[连接设备树接口
配置加载
内部对象管理] -.-> D
E1[生命周期管理
子设备管理
协议集成] -.-> E
F1[驱动注册
生命周期函数
错误处理] -.-> F
G1[Meson配置
依赖管理
安装目录] -.-> G
style A fill:#ffeb3b
style B fill:#4caf50
style C fill:#2196f3
style D fill:#ff9800
style E fill:#9c27b0
style F fill:#f44336
style G fill:#607d8b
```
#### 步骤1: 需求分析和设计
1. **确定设备类型**：PCIe设备、I2C设备、传感器等
2. **选择基类**：继承相应的基类(`PCIeCard`, `bus_base`, `chip_base`等)
3. **协议选择**：确定需要的通信协议(NCSI, MCTP, IMU等)
4. **接口设计**：定义需要暴露的属性和方法
#### 步骤2: 设备树接口定义
在`gen/include/device_tree/interface/`中定义设备接口：
```cpp
// gen/include/device_tree/interface/MyDevice.h
#ifndef GEN_MY_DEVICE_INTERFACE_H
#define GEN_MY_DEVICE_INTERFACE_H
#include
namespace dev::gen {
class MC_API MyDevice : public mc::engine::interface {
public:
MC_INTERFACE("bmc.dev.MyDevice")
// 设备属性定义
property DeviceName;
property DeviceId;
property Version;
property IsEnabled;
// 虚函数接口（如需要）
virtual bool Initialize();
virtual bool GetStatus();
virtual void SetEnabled(bool enabled);
};
} // namespace dev::gen
#endif // GEN_MY_DEVICE_INTERFACE_H
```
**注意**:
- 现在使用`dev::gen`命名空间
- 无需手动编写反射宏，框架自动处理
- 属性使用`property`模板定义
- 虚函数可以有默认实现
#### 步骤3: 内部器件对象实现
实现具体的硬件操作逻辑：
```cpp
// drivers/internal/my_device/my_device_internal.h
#ifndef MY_DEVICE_INTERNAL_H
#define MY_DEVICE_INTERNAL_H
#include
#include
#include
class MyDeviceInternal {
public:
MyDeviceInternal() = default;
~MyDeviceInternal() = default;
bool init(const mc::dict& config);
bool start();
bool stop();
// 硬件操作接口
bool read_register(uint32_t offset, uint32_t& value);
bool write_register(uint32_t offset, uint32_t value);
bool get_device_status();
private:
std::string m_device_name;
uint8_t m_device_id;
bool m_initialized = false;
// 硬件资源管理
void* m_hardware_handle = nullptr;
};
#endif // MY_DEVICE_INTERNAL_H
```
```cpp
// drivers/internal/my_device/my_device_internal.cpp
#include "my_device_internal.h"
#include
bool MyDeviceInternal::init(const mc::dict& config) {
try {
m_device_name = config["DeviceName"].as();
m_device_id = config["DeviceId"].as();
// 硬件初始化逻辑
// m_hardware_handle = open_hardware_device(m_device_id);
m_initialized = true;
ilog("MyDevice initialized: ${name} (ID: ${id})",
("name", m_device_name)("id", m_device_id));
return true;
} catch (const std::exception& e) {
elog("Failed to initialize MyDevice: ${error}", ("error", e.what()));
return false;
}
}
bool MyDeviceInternal::read_register(uint32_t offset, uint32_t& value) {
if (!m_initialized) {
elog("Device not initialized");
return false;
}
// 实现具体的寄存器读取逻辑
// value = hardware_read(m_hardware_handle, offset);
return true;
}
```
#### 步骤4: 接口类实现
创建接口类，连接设备树接口和内部实现：
```cpp
// drivers/my_device/interface/i_my_device.h
#ifndef I_MY_DEVICE_H
#define I_MY_DEVICE_H
#include
#include "../internal/my_device_internal.h"
namespace dev {
// MyDevice 默认值常量
constexpr uint8_t MY_DEVICE_DEFAULT_ID = 0;
constexpr bool MY_DEVICE_DEFAULT_ENABLED = false;
constexpr const char* MY_DEVICE_DEFAULT_VERSION = "1.0";
class IMyDevice : public mc::engine::interface {
public:
IMyDevice() {
// 使用默认值初始化成员变量
DeviceId = MY_DEVICE_DEFAULT_ID;
IsEnabled = MY_DEVICE_DEFAULT_ENABLED;
Version = MY_DEVICE_DEFAULT_VERSION;
}
~IMyDevice() = default;
// 实现设备树接口的虚函数
bool Initialize() override;
bool GetStatus() override;
void SetEnabled(bool enabled) override;
// 从variant中加载配置到基类属性
void from_variant(mc::mutable_dict& csr_object);
private:
std::unique_ptr m_internal;
};
} // namespace dev
#endif // I_MY_DEVICE_H
```
#### 步骤5: 设备对象实现
实现主设备对象，管理整个设备的生命周期：
```cpp
// drivers/my_device/my_device.h
#ifndef MY_DEVICE_H
#define MY_DEVICE_H
#include
#include "interface/i_my_device.h"
namespace dev {
class MyDevice : public mc::engine::object {
public:
MC_OBJECT(MyDevice, "MyDevice", "/bmc/dev/MyDevice/${DeviceName}", (IMyDevice))
MyDevice() = default;
~MyDevice() = default;
// 生命周期管理
bool init(mc::mutable_dict& csr_object, const mc::dict& connector);
bool start();
bool stop();
// 设备接口实例
IMyDevice i_my_device;
private:
bool m_started = false;
};
} // namespace dev
MC_REFLECT(dev::MyDevice, ((i_my_device, "bmc.dev.MyDevice")))
#endif // MY_DEVICE_H
```
#### 步骤6: ABI接口实现
实现驱动注册和生命周期管理的ABI接口：
```cpp
// drivers/my_device/my_device_abi.cpp
#include
#include
#include "my_device.h"
using namespace dev;
extern "C" {
driver_handle_t create_my_device(void* service, const char* name) {
try {
if (service == nullptr || name == nullptr) {
elog("Error creating MyDevice: invalid parameters");
return nullptr;
}
MyDevice* device = new MyDevice();
device->set_service(static_cast(service));
device->set_object_name(name);
return (void*)device;
} catch (const std::exception& e) {
elog("Error creating MyDevice: ${error}", ("error", e.what()));
return nullptr;
}
}
status_t init_my_device(driver_handle_t device, void* csr_object, void* connector) {
if (device == nullptr || csr_object == nullptr || connector == nullptr) {
elog("Error initializing MyDevice: invalid parameters");
return STATUS_ERROR;
}
MyDevice* device_object = static_cast(device);
mc::mutable_dict* csr_object_ptr = static_cast(csr_object);
mc::dict* connector_ptr = static_cast(connector);
bool ret = device_object->init(*csr_object_ptr, *connector_ptr);
return ret ? STATUS_OK : STATUS_ERROR;
}
status_t start_my_device(driver_handle_t device) {
if (device == nullptr) {
elog("Error starting MyDevice: device is null");
return STATUS_ERROR;
}
MyDevice* device_object = static_cast(device);
bool ret = device_object->start();
return ret ? STATUS_OK : STATUS_ERROR;
}
status_t stop_my_device(driver_handle_t device) {
if (device == nullptr) {
elog("Error stopping MyDevice: device is null");
return STATUS_ERROR;
}
MyDevice* device_object = static_cast(device);
bool ret = device_object->stop();
return ret ? STATUS_OK : STATUS_ERROR;
}
// 设备驱动信息
device_driver_t my_device_driver = {
.device_name = "MyDevice",
.ctor = create_my_device,
.init = init_my_device,
.start = start_my_device,
.stop = stop_my_device
};
} // extern "C"
```
#### 步骤7: 构建配置
创建Meson构建配置：
```meson
# drivers/my_device/meson.build
my_device_sources = [
'my_device.cpp',
'my_device_abi.cpp',
'interface/i_my_device.cpp',
'internal/my_device_internal.cpp',
]
my_device_lib = shared_library(
'MyDevice',
my_device_sources,
include_directories: [
include_directories('.'),
include_directories('interface'),
gen_inc,
internal_inc
],
dependencies: [mcpp_dep, internal_dep],
install: true,
install_dir: drivers_install_dir,
)
my_device_dep = declare_dependency(
link_with: my_device_lib,
include_directories: include_directories('.')
)
```
## 4. PCIe板卡驱动开发规范
### 4.1 板卡驱动架构设计
PCIe板卡驱动采用分层架构，支持多厂商、多型号的复杂板卡设备：
```mermaid
graph TB
subgraph "PCIe板卡驱动总体架构"
A[板卡主对象
Card Object]
subgraph "多接口组合层"
B[PCIeDevice
PCIe设备接口]
C[PCIeCard
PCIe卡片接口]
D[NetworkAdapter/Gpu
功能专用接口]
E[Board
板卡信息接口]
F[扩展接口
Cooling/Status/Power等]
end
subgraph "协议通信层"
G[NCSI over MCTP
网络控制协议]
H[IMU
设备管理协议]
I[SMBUS
系统管理总线]
J[定时任务管理
Timer Management]
end
subgraph "子设备管理层"
K[NicPort 1..N
网络端口]
L[OpticalModule
光模块]
M[Gpu Memory
GPU内存]
N[Processor
处理器]
end
subgraph "厂商差异化层"
O[华为海思
Hi182x/Hi183x]
P[网迅
WX]
Q[英诺硅
AWM-M11P]
end
end
A --> B
A --> C
A --> D
A --> E
A --> F
A --> G
A --> H
A --> I
G --> J
H --> J
I --> J
A --> K
A --> L
A --> M
A --> N
O --> A
P --> A
Q --> A
style A fill:#ffeb3b
style G fill:#4caf50
style H fill:#ff9800
style I fill:#9c27b0
style K fill:#2196f3
style L fill:#2196f3
```
### 4.2 板卡驱动文件组织规范
#### 4.2.1 目录结构标准
```shell
drivers/pcie_{card_type}_card/ # 板卡类型根目录
├── {vendor}/ # 厂商实现目录
│ ├── {model}/ # 型号具体实现
│ │ ├── {model}_card.h # 主板卡对象定义
│ │ ├── {model}_card.cpp # 主板卡对象实现
│ │ ├── {model}_abi.cpp # ABI导出实现
│ │ ├── {model}_{sub_device}.h # 子设备对象定义
│ │ ├── {model}_{sub_device}.cpp # 子设备对象实现
│ │ └── meson.build # 构建配置
│ ├── csr/ # 设备树配置
│ │ ├── *.dds # 设备描述文件
│ │ └── *.sr # 自描述记录文件
│ └── interface/ # 厂商专用接口
│ ├── {interface}.h # 接口定义
│ ├── {interface}.cpp # 接口实现
│ └── {interface}/ # 子接口目录
└── meson.build # 根构建配置
```
**实际目录示例**：
- `pcie_nic_card/hisi/hi182x/` - 华为海思Hi182x网卡
- `pcie_nic_card/wangxun/rp1000/` - 网迅RP1000网卡
- `pcie_gpu_card/innosilicon/awm_m11p/` - 英诺硅AWM-M11P GPU
#### 4.2.2 命名规范
**主对象命名**：
- 类名：`{vendor}_{model}_card`（如`hi182x_card`, `wx_card`）
- 文件名：`{vendor}_{model}_card.{h|cpp}`
- ABI函数：`create_{vendor}_{model}_card`
**子设备命名**：
- 类名：`{vendor}_{model}_{sub_type}`（如`hi182x_port`, `awm_m11p_gpu`）
- 设备类型：`NicPort`, `OpticalTransceiver`, `Gpu`, `Memory`
### 4.3 板卡主对象设计模式
#### 4.3.1 多接口组合模式
板卡驱动的核心特征是组合多个标准接口，形成完整的设备功能。以华为海思Hi182x网卡为例：
##### 接口组合架构
| 接口类别 | 接口名称 | 成员变量 | 功能说明 | 是否必需 |
|---------|---------|---------|---------|---------|
| **基础接口** | PCIeDevice | m_pcie_device | PCIe设备基本信息(VID/DID) | ✅ 必需 |
| **基础接口** | PCIeDevice_PCIeFunction | m_pcie_device_pcie_function | PCIe功能信息(BDF、链路能力) | ✅ 必需 |
| **基础接口** | PCIeCard | m_pcie_card | PCIe卡片信息(插槽、链路状态) | ✅ 必需 |
| **基础接口** | Board | m_board | 板卡信息(序列号、制造商) | ⭕ 可选 |
| **功能接口** | NetworkAdapter | m_network_adapter | 网络适配器功能(MAC地址、速率) | ✅ 网卡必需 |
| **扩展接口** | NetworkAdapter_FaultStatus | m_network_adapter_fault_status | 故障状态监控 | ⭕ 可选 |
| **扩展接口** | Cooling | m_cooling | 冷却和温度管理（bmc.dev.Cooling） | ⭕ 可选 |
| **扩展接口** | PCIeDevice_Bandwidth | m_pcie_device_bandwidth | PCIe带宽监控 | ⭕ 可选 |
| **扩展接口** | NetworkAdapter_LogCollection | m_network_adapter_log_collection | 日志收集功能 | ⭕ 可选 |
| **扩展接口** | NetworkAdapter_Oem | m_network_adapter_oem | 厂商扩展功能 | ⭕ 可选 |
##### 协议栈集成
| 协议类型 | 成员变量 | 协议作用 | 应用场景 |
|---------|---------|---------|---------|
| **NCSI over MCTP** | m_ncsi_over_mctp_huawei | 华为扩展的NCSI协议 | 网卡状态查询、配置管理、OEM命令 |
| **IMU** | m_imu_obj | 设备管理单元协议 | 通过IPMI获取设备信息、固件版本 |
| **SMBUS** | m_smbus_obj | 系统管理总线协议 | 温度监控、电源管理、芯片通信 |
##### 子设备管理
| 子设备类型 | 容器类型 | 说明 | 生命周期管理 |
|-----------|---------|------|------------|
| **网络端口** | `std::vector` | 管理多个物理网络端口 | 父设备启动时初始化，停止时清理 |
| **光模块** | 由端口对象管理 | 每个端口可包含光模块 | 随端口生命周期管理 |
##### 生命周期方法
| 方法类型 | 方法名称 | 调用时机 | 主要职责 |
|---------|---------|---------|---------|
| **公有方法** | `init()` | 设备创建后 | 加载CSR配置、初始化成员变量 |
| **公有方法** | `start()` | 初始化完成后 | 启动协议、初始化子设备、注册回调 |
| **公有方法** | `stop()` | 设备停止时 | 停止协议、清理子设备、释放资源 |
| **私有方法** | `init_network_ports()` | start()阶段 | 发现和初始化网络端口 |
| **私有方法** | `start_ncsi_protocol()` | start()阶段 | 启动NCSI协议并绑定接口 |
| **私有方法** | `start_smbus_protocol()` | start()阶段 | 启动SMBUS协议通信 |
| **私有方法** | `init_imu_protocol()` | start()阶段 | 初始化IMU设备管理 |
##### 类定义示例
```cpp
// 华为海思Hi182x网卡示例
class hi182x_card : public mc::engine::object {
public:
MC_OBJECT(
hi182x_card, "PCIeNicCard", "/bmc/dev/Systems/1/PCIeNicCard/${object_name}",
(PCIeDevice)(PCIeDevice_PCIeFunction)(PCIeDevice_Oem)(PCIeDevice_Status)(PCIeCard)(PCIeCard_Oem)
(PCIeCard_Metrics)(NetworkAdapter)(NetworkAdapter_FaultStatus)(Cooling)(NetworkAdapter_Oem)(Board)
(PCIeDevice_Bandwidth)(NetworkAdapter_LogCollection)(Fru))
// === 接口对象组合 ===
NetworkAdapter_Oem m_network_adapter_oem; // 网络适配器OEM扩展
PCIeDevice m_pcie_device; // PCIe设备信息
PCIeDevice_PCIeFunction m_pcie_device_pcie_function; // PCIe功能信息
PCIeDevice_Oem m_pcie_device_oem; // PCIe设备OEM扩展
PCIeDevice_Status m_pcie_device_status; // PCIe设备状态
PCIeCard m_pcie_card; // PCIe卡片信息
PCIeCard_Oem m_pcie_card_oem; // PCIe卡片OEM扩展
PCIeCard_Metrics m_pcie_card_metrics; // 卡片运行态指标
Cooling m_cooling; // 冷却管理
NetworkAdapter m_network_adapter; // 网络适配器
NetworkAdapter_FaultStatus m_network_adapter_fault_status; // 故障状态
Board m_board; // 板卡信息
PCIeDevice_Bandwidth m_pcie_device_bandwidth; // 带宽监控
NetworkAdapter_LogCollection m_network_adapter_log_collection; // 日志收集
Fru m_fru; // FRU信息
uint8_t m_system_id; // 系统ID
// === 生命周期管理 ===
bool start();
bool stop();
bool init(mc::mutable_dict& csr_object, const mc::dict& connector);
private:
// === 子设备管理 ===
std::vector m_network_ports; // 网络端口集合
// === 协议支持 ===
ref_chip_ptr m_ref_chip; // 参考芯片对象
smbus_obj_ptr m_smbus_obj; // SMBUS通信
imu_ptr m_imu_obj; // IMU设备管理
ncsi_over_mctp_hw_ptr m_ncsi_over_mctp_huawei; // 华为NCSI over MCTP协议
mc::milliseconds m_interval = mc::milliseconds(5000); // NCSI更新间隔5s
mc::milliseconds m_smbus_interval = mc::milliseconds(5000); // SMBUS更新间隔5s
mc::shared_ptr m_mctp_object; // MCTP底层协议
// === 协议生命周期管理 ===
void init_network_ports(); // 初始化网络端口
bool start_ncsi_protocol(); // 启动NCSI协议
bool start_smbus_protocol(); // 启动SMBUS协议
bool init_imu_protocol(); // 初始化IMU协议
bool start_protocol(); // 启动NCSI over MCTP协议
};
```
##### 接口组合设计原则
| 原则 | 说明 | 示例 |
|------|------|------|
| **必需接口优先** | 基础接口(PCIeDevice/PCIeCard/Board)必须实现 | 所有PCIe设备都需要 |
| **功能接口明确** | 根据设备类型选择功能接口 | 网卡选NetworkAdapter，GPU选Gpu |
| **扩展接口可选** | 根据硬件能力添加扩展接口 | 支持温度监控则添加Cooling |
| **接口命名规范** | 使用下划线连接主接口和子接口 | NetworkAdapter_FaultStatus |
| **接口分组排列** | MC_OBJECT宏中按功能分组 | 基础接口→功能接口→扩展接口 |
#### 4.3.2 GPU板卡设计模式
```cpp
// 英诺硅AWM-M11P GPU卡示例
class awm_m11p_card : public mc::engine::object {
public:
MC_OBJECT(awm_m11p_card, "PCIeGpuCard",
"/bmc/dev/Systems/1/PCIeGpuCard/${object_name}",
(PCIeDevice)(PCIeDevice_Oem)(PCIeDevice_Status)(PCIeDevice_PCIeFunction)(PCIeCard)(PCIeCard_Oem))
PCIeDevice m_pcie_device; // PCIe设备信息
PCIeDevice_Oem m_pcie_device_oem; // PCIe设备OEM信息
PCIeDevice_Status m_pcie_device_status; // PCIe设备状态
PCIeDevice_PCIeFunction m_pcie_device_pcie_function; // PCIe功能信息
PCIeCard m_pcie_card; // PCIe卡片信息
PCIeCard_Oem m_pcie_card_oem; // PCIe卡片OEM信息
uint8_t SystemId; // 系统ID
bool start();
bool stop();
bool init(mc::mutable_dict& csr_object, const mc::dict& connector);
};
```
### 4.4 协议集成管理
#### 4.4.1 多协议并行管理
PCIe板卡通常需要集成多种通信协议，每种协议有独立的生命周期：
```cpp
class hi182x_card : public mc::engine::object {
private:
// === 协议对象管理 ===
ncsi_over_mctp_hw_ptr m_ncsi_over_mctp_huawei; // 华为NCSI over MCTP
imu_ptr m_imu_obj; // IMU设备管理协议
smbus_obj_ptr m_smbus_obj; // SMBUS系统管理总线
mc::shared_ptr m_mctp_object; // MCTP底层协议对象
// === 定时任务管理 ===
mc::milliseconds m_interval = mc::milliseconds(5000); // NCSI更新间隔
mc::milliseconds m_smbus_interval = mc::milliseconds(5000); // SMBUS更新间隔
// === 协议启动和管理 ===
// 各协议独立启动，start() 中按序调用：
// start_protocol(); // 启动 NCSI over MCTP
// start_smbus_protocol(); // 启动 SMBUS
// init_imu_protocol(); // 初始化 IMU
bool start_protocol() {
return start_ncsi_protocol();
}
bool start_ncsi_protocol() {
// 校验BDF已初始化
if (m_pcie_device_pcie_function.BusNumber == 0 &&
m_pcie_device_pcie_function.DeviceNumber == 0 &&
m_pcie_device_pcie_function.FunctionNumber == 0) {
elog("PCIe device BDF not initialized");
return false;
}
// 1. 计算物理地址并创建 MCTP 对象
uint16_t phy_addr =
mctp::init_phy_addr(m_pcie_device_pcie_function.BusNumber,
m_pcie_device_pcie_function.DeviceNumber,
m_pcie_device_pcie_function.FunctionNumber);
m_mctp_object = mc::make_shared(this, phy_addr,
MCTP_MESSAGE_TYPE::MCTP_MESSAGE_TYPE_NCSI, "");
// 2. 在端点就绪回调中创建 NCSI over MCTP 实例并绑定各接口任务
auto ncsi_update_task = [this]() {
m_ncsi_over_mctp_huawei = std::make_shared(m_mctp_object);
for (auto& port : m_network_ports) {
port->start_ncsi_update_task(m_ncsi_over_mctp_huawei, m_interval);
port->enable_lldp_over_mctp(); // 开启 lldp_over_mctp 透传
}
m_network_adapter.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei, mc::milliseconds(120000));
m_network_adapter_fault_status.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei, m_interval);
m_pcie_device_bandwidth.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei, mc::milliseconds(180000));
m_pcie_device_pcie_function.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei,
mc::milliseconds(120000));
m_cooling.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei, m_interval);
m_network_adapter_log_collection.init_ncsi_endpoint(m_ncsi_over_mctp_huawei);
};
m_mctp_object->create_transport_and_endpoint(std::string(get_object_name()), ncsi_update_task);
return true;
}
};
```
**协议集成规范**：
1. **协议隔离**：每种协议使用独立的智能指针管理
2. **统一初始化**：在`start_protocol()`中统一管理协议启动
3. **接口绑定**：将协议实例绑定到相关接口对象
4. **错误处理**：协议初始化失败时进行适当的错误处理和资源清理
5. **定时任务**：使用统一的定时间隔管理协议更新
#### 4.4.2 协议差异化处理
不同厂商的板卡支持不同的协议组合：
```cpp
// 华为海思 - 支持NCSI+IMU+SMBUS
class hi182x_card {
ncsi_over_mctp_hw_ptr m_ncsi_over_mctp_huawei; // 华为专用NCSI
imu_ptr m_imu_obj; // IMU协议
smbus_obj_ptr m_smbus_obj; // SMBUS协议
};
// 网迅 - 支持NCSI+IMU，附加四元组更新
class rp1000_card {
ncsi_over_mctp_wx_ptr m_ncsi_over_mctp_wx; // 网迅专用NCSI over MCTP
imu_ptr m_imu_obj; // IMU协议
mc::shared_ptr m_mctp_object = nullptr; // MCTP底层协议
mc::milliseconds m_interval = mc::milliseconds(5000); // NCSI更新间隔5s
mc::milliseconds m_quadruple_interval = mc::milliseconds(10000); // 四元组更新间隔10s
mc::shared_ptr m_quadruple_timer; // 四元组更新定时器
bool m_first_quadruple_update; // 是否首次四元组更新
};
// 英诺硅GPU - 简化协议支持
class awm_m11p_card {
// GPU卡通常协议需求较简单，主要依赖PCIe标准接口
};
```
### 4.5 子设备管理模式
#### 4.5.1 动态子设备发现
板卡驱动通过框架提供的`get_children()`方法动态发现和管理子设备：
```cpp
void hi182x_card::init_network_ports() {
auto objects = get_children(); // 获取所有子对象
if (objects.empty()) {
elog("Error: No network ports found");
return;
}
for (auto& object : objects) {
auto object_name = object->get_name();
// 通过对象名前缀识别设备类型
if (object_name.substr(0, object_name.find_first_of("_")) == "NicPort") {
// 使用 dynamic_cast 并校验空指针，避免向下转换失败
auto* port = dynamic_cast(object.get());
if (port == nullptr) {
elog("hi182x_card child ${name} is not hi182x_port, skip", ("name", object_name));
continue;
}
ilog("hi182x_card init network port ${name}", ("name", object_name));
m_network_ports.push_back(port);
}
// 可以添加其他子设备类型的识别
else if (object_name.find("OpticalTransceiver") != std::string::npos) {
// 光模块设备处理
}
}
}
```
**子设备管理规范**：
1. **类型识别**：通过对象名前缀或特征字符串识别子设备类型
2. **类型转换**：使用`dynamic_cast`将基类指针转换为具体子设备类型，并必须校验空指针（禁止使用`static_cast`向下转换）
3. **集合管理**：使用`std::vector`管理同类型子设备集合
4. **生命周期同步**：主设备的启动/停止时同步管理所有子设备
#### 4.5.2 子设备生命周期管理
```cpp
bool hi182x_card::start() {
// 1. 初始化子设备
init_network_ports();
// 2. 启动所有子设备
for (auto& port : m_network_ports) {
port->start();
if (port->m_optical_module) {
port->m_optical_module->m_optical_module_status.set_network_adapter_oem(&m_network_adapter_oem);
port->m_optical_module->m_optical_module_temperature_celsius.set_network_adapter_oem(
&m_network_adapter_oem);
}
}
// 3. 建立主接口间的交叉引用
m_cooling.set_network_adapter_oem(&m_network_adapter_oem);
m_network_adapter_fault_status.set_network_adapter_oem(&m_network_adapter_oem);
m_network_adapter_oem.set_network_adapter(&m_network_adapter);
m_network_adapter.set_network_adapter_oem(&m_network_adapter_oem);
// 4. 各协议独立启动
start_protocol(); // 启动 NCSI over MCTP
start_smbus_protocol(); // 启动 SMBUS
setup_vdpci_lldp_listener();
init_imu_protocol(); // 初始化 IMU
// 5. 注册事件回调
m_network_adapter_oem.register_os_reset_callback([this]() {
this->handle_os_reset();
});
m_network_adapter_oem.register_os_off_callback([this]() {
this->handle_os_off();
});
return true;
}
bool hi182x_card::stop() {
// 1. 停止各协议更新任务
stop_ncsi_update_task();
m_network_adapter_log_collection.clean_ncsi_endpoint();
for (auto& port : m_network_ports) {
if (port != nullptr) {
port->stop_ncsi_update_task();
}
}
if (m_smbus_obj) {
stop_smbus_update_task();
m_network_adapter_log_collection.clean_smbus_obj();
m_network_adapter_oem.clean_smbus_obj();
for (auto& port : m_network_ports) {
if (port != nullptr) {
port->stop_smbus_update_task();
}
}
}
for (auto& port : m_network_ports) {
if (port != nullptr) {
port->stop_lldp_clear_timer();
}
}
// 2. 注销回调并断开交叉引用
m_network_adapter_oem.unregister_os_reset_callback();
m_network_adapter_oem.unregister_os_off_callback();
m_network_adapter_oem.unregister_eeprom_wp_callback();
m_network_adapter_oem.set_network_adapter(nullptr);
m_network_adapter.set_network_adapter_oem(nullptr);
m_cooling.set_network_adapter_oem(nullptr);
m_network_adapter_fault_status.set_network_adapter_oem(nullptr);
return true;
}
```
### 4.6 ABI实现规范
#### 4.6.1 多设备ABI导出
PCIe板卡驱动通常需要导出主设备和多个子设备的ABI接口：
```cpp
// PCIe网卡ABI实现示例
extern "C" {
// === 主板卡设备ABI ===
driver_handle_t create_hi182x_card(void* service, const char* name) {
try {
if (service == nullptr || name == nullptr) {
return nullptr;
}
hi182x_card* device = new hi182x_card();
device->set_service(static_cast(service));
device->set_object_name(name);
return (void*)device;
} catch (const std::exception& e) {
elog("Error creating hi182x PCIeNicCard: ${error}", ("error", e.what()));
return nullptr;
}
}
status_t init_hi182x_card(driver_handle_t device, void* csr_object, void* connector) {
if (device == nullptr || csr_object == nullptr || connector == nullptr) {
elog("Error initializing hi182x PCIeNicCard: device is null");
return STATUS_ERROR;
}
hi182x_card* device_object = static_cast(device);
mc::mutable_dict* csr_object_ptr = static_cast(csr_object);
mc::dict* connector_ptr = static_cast(connector);
bool ret = device_object->init(*csr_object_ptr, *connector_ptr);
return ret ? STATUS_OK : STATUS_ERROR;
}
status_t start_hi182x_card(driver_handle_t device) {
if (device == nullptr) {
elog("Error starting hi182x PCIeNicCard: device is null");
return STATUS_ERROR;
}
hi182x_card* device_object = static_cast(device);
device_object->start();
return STATUS_OK;
}
status_t stop_hi182x_card(driver_handle_t device) {
if (device == nullptr) {
elog("Error stopping hi182x PCIeNicCard: device is null");
return STATUS_ERROR;
}
hi182x_card* device_object = static_cast(device);
device_object->stop();
return STATUS_OK;
}
// === 网络端口子设备ABI ===
driver_handle_t create_hi182x_port(void* service, const char* name) {
try {
if (service == nullptr || name == nullptr) {
return nullptr;
}
hi182x_port* device = new hi182x_port();
device->set_service(static_cast(service));
device->set_object_name(name);
return (void*)device;
} catch (const std::exception& e) {
elog("Error creating hi182x NicPort: ${error}", ("error", e.what()));
return nullptr;
}
}
// === 光模块子设备ABI ===
driver_handle_t create_hi182x_optical_module(void* service, const char* name) {
try {
if (service == nullptr || name == nullptr) {
return nullptr;
}
hi182x_optical_module* device = new hi182x_optical_module();
device->set_object_name(name);
device->set_service(static_cast(service));
return (void*)device;
} catch (const std::exception& e) {
elog("Error creating hi182x OpticalTransceiver: ${error}", ("error", e.what()));
return nullptr;
}
}
// === 设备驱动注册表 ===
device_driver_t hi182x_card_device_driver = {
.device_name = "PCIeNicCard",
.ctor = create_hi182x_card,
.init = init_hi182x_card,
.start = start_hi182x_card,
.stop = stop_hi182x_card
};
device_driver_t hi182x_port_device_driver = {
.device_name = "NicPort",
.ctor = create_hi182x_port,
.init = init_hi182x_port,
.start = start_hi182x_port,
.stop = stop_hi182x_port
};
device_driver_t hi182x_optical_module_device_driver = {
.device_name = "OpticalTransceiver",
.ctor = create_hi182x_optical_module,
.init = init_hi182x_optical_module,
.start = start_hi182x_optical_module,
.stop = stop_hi182x_optical_module
};
// === 驱动导出 ===
device_driver_t hi182x_device_driver[] = {
hi182x_card_device_driver,
hi182x_port_device_driver,
hi182x_optical_module_device_driver
};
status_t register_device_driver(device_driver_t** device_driver, uint8_t* count) {
*device_driver = hi182x_device_driver;
*count = sizeof(hi182x_device_driver) / sizeof(hi182x_device_driver[0]);
return STATUS_OK;
}
} // extern "C"
```
**ABI实现规范**：
1. **设备分离**：主设备和子设备分别实现独立的ABI函数
2. **统一命名**：函数名格式`{action}_{vendor}_{model}_{device_type}`
3. **设备表管理**：使用数组管理多个设备驱动结构
4. **错误处理**：每个ABI函数都要进行参数验证和异常处理
### 4.7 构建系统集成
#### 4.7.1 分层构建配置
```meson
# 主目录 drivers/pcie_nic_card/hisi/hi182x/meson.build
hisi_182x_sources = files(
'hi182x_abi.cpp', # ABI导出实现
'hi182x_card.cpp', # 主板卡对象
'hi182x_om.cpp', # 光模块子设备
'hi182x_port.cpp', # 网络端口子设备
)
include_dirs += include_directories('../../../chip') # 芯片驱动路径
include_dirs += include_directories('../../../internal') # 内部实现路径
# 静态库构建（用于测试）
libhisi_182x_static = static_library(
'hisi_182x',
hisi_182x_sources,
include_directories: include_dirs + hisi_interface_inc,
# 接口实现编译为独立共享库 libhisi_interface，此处仅声明依赖
dependencies: [
dev_deps, # 基础开发依赖
libhisi_interface_dep, # 厂商接口共享库
libncsi_over_mctp_dep, # NCSI over MCTP协议库
libpldm_over_mctp_dep, # PLDM over MCTP协议库
libmctp_dep, # MCTP协议库
libimu_dep, # IMU协议库
libsmbus_dep, # SMBUS协议库
liblldp_dep, # LLDP协议库
],
cpp_args: ['-Os', '-ffunction-sections', '-fdata-sections'],
install: false,
)
# 动态库构建（用于部署）
libhisi_182x = shared_library(
'hisi_182x',
include_directories: include_dirs + hisi_interface_inc,
name_prefix: 'lib',
name_suffix: 'so',
install: true,
install_dir: drivers_install_dir,
cpp_args: ['-Os', '-ffunction-sections', '-fdata-sections'],
link_args: ['-Wl,--gc-sections', '-Wl,--strip-all', '-Wl,--as-needed'],
link_whole: [libhisi_182x_static], # 链接静态库
)
# 测试依赖声明
if build_tests
hisi_182x_dep = declare_dependency(
include_directories: include_dirs + hisi_interface_inc,
link_with: libhisi_182x_static,
dependencies: [
libmcpp_deps,
libncsi_over_mctp_dep,
libmctp_dep,
libimu_dep,
libsmbus_dep,
liblldp_dep,
],
)
endif
```
**构建配置规范**：
1. **协议依赖**：明确声明所有使用的协议库依赖
2. **路径管理**：正确配置include路径，包括芯片和内部实现路径
3. **双库构建**：同时提供静态库（测试用）和动态库（部署用）
4. **条件编译**：支持测试模式和部署模式的条件编译
### 4.8 设备树配置规范
#### 4.8.1 DDS设备描述文件
```json
{
"Schema": "dds-v1",
"Type": "Component",
"DeviceCategory": "PCIeNicCard",
"ID": "N/A",
"Objects": {
"PCIeNicCard": {
"Path": "/bmc/dev/Systems/:SystemId/PCIeNicCard/:Id",
"Interfaces": [
"bmc.dev.PCIeDevice", // PCIe设备基础接口
"bmc.dev.PCIeDevice.PCIeFunction", // PCIe功能信息接口
"bmc.dev.PCIeDevice.Status", // PCIe设备状态接口
"bmc.dev.PCIeDevice.Oem", // PCIe设备OEM扩展接口
"bmc.dev.PCIeCard", // PCIe卡片信息接口
"bmc.dev.PCIeCard.Oem", // PCIe卡片OEM扩展接口
"bmc.dev.PCIeCard.Metrics", // PCIe卡片指标接口
"bmc.dev.Board", // 板卡信息接口
"bmc.dev.NetworkAdapter", // 网络适配器接口
"bmc.dev.PCIeDevice.Bandwidth", // 带宽扩展接口
"bmc.dev.Cooling", // 冷却扩展接口
"bmc.dev.NetworkAdapter.FaultStatus", // 故障状态扩展接口
"bmc.dev.NetworkAdapter.LogCollection", // 日志收集扩展接口
"bmc.dev.NetworkAdapter.Oem" // 网络适配器OEM扩展接口
]
},
"NicPort": {
"Path": ":Parent/NicPort/:Id",
"Interfaces": [
"bmc.dev.NetworkPort", // 网络端口基础接口
"bmc.dev.NetworkPort.LinkInfo", // 链路信息扩展接口
"bmc.dev.NetworkPort.DataCenterBridging", // 数据中心桥接
"bmc.dev.NetworkPort.LLDPReceive", // LLDP接收扩展接口
"bmc.dev.NetworkPort.Metrics" // 监控指标扩展接口
]
},
"OpticalTransceiver": {
"Path": ":Parent/OpticalTransceiver",
"Interfaces": [
"bmc.dev.OpticalModule", // 光模块基础接口
"bmc.dev.OpticalModule.Status", // 状态扩展接口
"bmc.dev.OpticalModule.TemperatureCelsius", // 温度扩展接口
"bmc.dev.OpticalModule.Voltage", // 电压扩展接口
"bmc.dev.OpticalModule.Power", // 功耗扩展接口
"bmc.dev.OpticalModule.Current", // 电流扩展接口
"bmc.dev.OpticalModule.Diagnose" // 诊断扩展接口
]
}
}
}
```
**设备树配置规范**：
1. **层次结构**：主设备作为根，子设备通过`:Parent`引用父设备
2. **接口组合**：每个设备明确列出支持的所有接口
3. **路径约定**：遵循BMC设备路径标准，支持动态参数替换
4. **扩展接口**：使用点号分隔的命名空间表示扩展接口
## 5. 板卡驱动开发最佳实践
### 5.1 开发流程规范
```mermaid
flowchart TD
A[需求分析] --> B[设备树接口设计]
B --> C[接口类实现]
C --> D[主设备对象实现]
D --> E[子设备对象实现]
E --> F[协议集成]
F --> G[ABI导出实现]
G --> H[构建配置]
H --> I[设备树配置]
I --> J[测试验证]
J --> K[部署集成]
A1[确定板卡类型
分析厂商差异
定义功能需求] -.-> A
B1[设计接口组合
定义扩展接口
规划子设备结构] -.-> B
C1[实现基础接口
添加协议绑定
配置参数加载] -.-> C
D1[组合多接口
管理协议实例
实现生命周期] -.-> D
E1[继承框架基类
实现设备功能
绑定父设备] -.-> E
F1[初始化协议
配置定时任务
处理协议差异] -.-> F
G1[导出多设备ABI
实现驱动注册
错误处理] -.-> G
H1[配置依赖库
设置构建选项
支持条件编译] -.-> H
I1[定义设备路径
配置接口列表
设置参数映射] -.-> I
J1[单元测试
集成测试
协议验证] -.-> J
K1[驱动安装
配置部署
运行验证] -.-> K
style A fill:#ffeb3b
style D fill:#4caf50
style F fill:#ff9800
style J fill:#2196f3
```
### 5.2 代码质量规范
#### 5.2.1 架构设计原则
**单一职责原则**：
- 主设备对象：负责接口组合和协议管理
- 子设备对象：负责具体功能实现
- 接口类：负责配置加载和协议绑定
**开闭原则**：
- 通过继承扩展新厂商支持
- 通过接口组合扩展新功能
- 避免修改现有稳定代码
**依赖倒置原则**：
- 依赖抽象接口而非具体实现
- 使用智能指针管理协议依赖
- 通过依赖注入管理对象关系
#### 5.2.2 内存管理规范
```cpp
class hi182x_card : public mc::engine::object {
private:
// === 智能指针管理协议对象 ===
mc::shared_ptr m_mctp_object; // 框架智能指针管理MCTP
std::shared_ptr m_ncsi_over_mctp_huawei; // 自动管理生命周期
std::shared_ptr m_imu_obj; // 支持多对象共享
mc::shared_ptr m_smbus_obj; // 框架智能指针
mc::shared_ptr m_quadruple_timer; // 定时器使用框架智能指针
public:
~hi182x_card() {
// === 取消回调注册，避免悬空指针 ===
m_network_adapter_oem.unregister_os_reset_callback();
m_network_adapter_oem.unregister_os_off_callback();
}
};
```
**内存管理规范**：
1. **智能指针为主**：协议对象、定时器等动态资源统一使用`mc::shared_ptr`或`std::shared_ptr`管理，禁止手动`delete`原始指针
2. **明确所有权**：MCTP底层对象使用`mc::shared_ptr`（框架对象），协议上层使用`std::shared_ptr`
3. **回调注销**：析构/停止时先注销回调，避免悬空指针
#### 5.2.3 异常安全保证
```cpp
bool hi182x_card::start_ncsi_protocol() {
// === 资源获取即初始化(RAII) ===
// MCTP对象由框架智能指针管理，端点就绪后创建 NCSI over MCTP 实例
if (m_mctp_object == nullptr) {
elog("mctp object is null");
return false;
}
auto ncsi_update_task = [this]() {
try {
// 创建 NCSI over MCTP 实例（构造参数为 MCTP 智能指针）
m_ncsi_over_mctp_huawei = std::make_shared(m_mctp_object);
// === 批量操作的事务性处理 ===
for (auto& port : m_network_ports) {
port->start_ncsi_update_task(m_ncsi_over_mctp_huawei, m_interval);
}
// === 各接口绑定独立的更新任务 ===
m_network_adapter.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei,
mc::milliseconds(120000));
m_network_adapter_fault_status.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei, m_interval);
m_pcie_device_bandwidth.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei,
mc::milliseconds(180000));
m_pcie_device_pcie_function.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei,
mc::milliseconds(120000));
m_cooling.start_ncsi_update_task_huawei(m_ncsi_over_mctp_huawei, m_interval);
m_network_adapter_log_collection.init_ncsi_endpoint(m_ncsi_over_mctp_huawei);
} catch (const std::exception& e) {
elog("Exception in start_ncsi_protocol: ${error}", ("error", e.what()));
// 异常时清理已启动的任务
stop_ncsi_update_task();
} catch (...) {
elog("Unknown exception in start_ncsi_protocol");
stop_ncsi_update_task();
}
};
// 创建传输层和端点，就绪后回调 ncsi_update_task
m_mctp_object->create_transport_and_endpoint(std::string(get_object_name()), ncsi_update_task);
return true;
}
```
### 5.3 多厂商差异化处理
#### 5.3.1 厂商特性对比表
| 板卡类型 | 厂商 | 型号 | 协议支持 | 特有功能 | 子设备 |
|---------|------|------|----------|----------|---------|
| PCIe网卡 | 华为海思 | Hi182x | NCSI+IMU+SMBUS | 温度监控、故障诊断、日志收集 | NicPort, OpticalModule |
| PCIe网卡 | 华为海思 | Hi1822_Fc | NCSI+IMU+SMBUS | FC网络功能支持 | NicPort, OpticalModule |
| PCIe网卡 | 网迅 | RP1000 | NCSI+IMU | 四元组更新、电源状态检测 | NicPort |
| PCIe GPU | 英诺硅 | AWM-M11P | 基础PCIe | GPU监控、内存管理 | Gpu, Memory |
#### 5.3.2 差异化实现策略
```cpp
// === 基础接口统一，实现差异化 ===
// 1. 协议差异 - 继承统一基类，实现厂商专用协议
class ncsi_over_mctp_huawei : public ncsi_over_mctp_base { /* 华为实现 */ };
class ncsi_over_mctp_wx : public ncsi_over_mctp_base { /* 网迅实现 */ };
// 2. 功能差异 - 通过接口组合支持不同功能集
class hi182x_card {
NetworkAdapter_FaultStatus m_fault_status; // 华为特有
NetworkAdapter_LogCollection m_log_collection; // 华为特有
};
class wx_card {
// 网迅不支持故障状态和日志收集接口
mc::shared_ptr m_quadruple_timer; // 网迅特有四元组更新定时器
};
// 3. 定时任务差异 - 不同厂商使用不同更新间隔
class hi182x_card {
mc::milliseconds m_interval = mc::milliseconds(5000); // 5秒NCSI更新
mc::milliseconds m_smbus_interval = mc::milliseconds(5000); // 5秒SMBUS更新
};
class wx_card {
mc::milliseconds m_interval = mc::milliseconds(5000); // 5秒NCSI更新
mc::milliseconds m_quadruple_interval = mc::milliseconds(10000); // 10秒四元组更新
};
```
### 5.4 调试和故障排除
#### 5.4.1 日志记录规范
```cpp
class hi182x_card {
bool start() {
ilog("Starting hi182x_card: ${name}", ("name", get_object_name()));
// === 关键步骤日志 ===
ilog("Initializing network ports...");
init_network_ports();
ilog("Found ${count} network ports", ("count", m_network_ports.size()));
// === 协议启动日志 ===
ilog("Starting NCSI protocol...");
if (!start_ncsi_protocol()) {
elog("Failed to start NCSI protocol");
return false;
}
ilog("NCSI protocol started successfully");
// === 性能监控日志 ===
dlog("hi182x_card started in ${time}ms", ("time", start_time));
return true;
}
void update_device_status() {
try {
// === 调试级详细日志 ===
dlog("Updating device status via NCSI...");
// NCSI over MCTP 实例未创建时记录警告
if (m_ncsi_over_mctp_huawei == nullptr) {
wlog("NCSI over MCTP instance is null, skip update");
return;
}
dlog("Device status updated: ${name}, BDF=${bus}:${dev}:${func}",
("name", m_pcie_device.DeviceName.get_value().as()),
("bus", m_pcie_device_pcie_function.BusNumber),
("dev", m_pcie_device_pcie_function.DeviceNumber),
("func", m_pcie_device_pcie_function.FunctionNumber));
} catch (const std::exception& e) {
elog("Exception in update_device_status: ${error}", ("error", e.what()));
}
}
};
```
**日志级别使用规范**：
- `elog()`: 错误和异常情况
- `wlog()`: 警告和非致命问题
- `ilog()`: 重要信息和状态变化
- `dlog()`: 调试信息和详细过程
- `tlog()`: 临时调试和开发期日志
#### 5.4.2 常见问题诊断
**协议初始化失败**：
```cpp
bool start_ncsi_protocol() {
// 1. 验证PCIe设备BDF已初始化
if (m_pcie_device_pcie_function.BusNumber == 0 &&
m_pcie_device_pcie_function.DeviceNumber == 0 &&
m_pcie_device_pcie_function.FunctionNumber == 0) {
elog("PCIe device ${name} BDF not initialized",
("name", m_pcie_device.DeviceName.get_value().as()));
return false;
}
// 2. 检查网络端口子设备是否发现
if (m_network_ports.empty()) {
elog("No network ports found, NCSI protocol cannot start");
return false;
}
// 3. 计算物理地址并创建MCTP对象
uint16_t phy_addr =
mctp::init_phy_addr(m_pcie_device_pcie_function.BusNumber,
m_pcie_device_pcie_function.DeviceNumber,
m_pcie_device_pcie_function.FunctionNumber);
m_mctp_object = mc::make_shared(this, phy_addr,
MCTP_MESSAGE_TYPE::MCTP_MESSAGE_TYPE_NCSI, "");
// 4. 创建传输层和端点，就绪后回调绑定接口任务
m_mctp_object->create_transport_and_endpoint(std::string(get_object_name()), ncsi_update_task);
return true;
}
```
**子设备管理失败**：
```cpp
void init_network_ports() {
auto objects = get_children();
// 1. 检查子设备数量
if (objects.empty()) {
wlog("No child objects found, expected network ports");
return;
}
// 2. 验证子设备类型
for (auto& object : objects) {
if (!dynamic_cast(object.get())) {
wlog("Invalid child object type: ${name}", ("name", object->get_name()));
continue;
}
// 添加到管理列表
}
// 3. 验证最终结果
if (m_network_ports.empty()) {
elog("No valid network ports found");
}
}
```
## 5. 测试开发
### 5.1 测试策略
```mermaid
graph TD
A[测试策略]
A --> B[单元测试]
A --> C[集成测试]
A --> D[性能测试]
A --> E[压力测试]
B --> F[设备初始化测试]
B --> G[接口功能测试]
B --> H[错误处理测试]
C --> I[ABI接口测试]
C --> J[协议通信测试]
C --> K[多设备协同测试]
D --> L[吞吐量测试]
D --> M[延迟测试]
D --> N[资源使用测试]
E --> O[长时间运行测试]
E --> P[并发访问测试]
E --> Q[异常恢复测试]
style A fill:#ffeb3b
style B fill:#4caf50
style C fill:#2196f3
style D fill:#ff9800
style E fill:#f44336
```
### 5.1 单元测试
```cpp
// tests/my_device_test.cpp
#include
#include "../drivers/my_device/my_device.h"
class MyDeviceTest : public ::testing::Test {
protected:
void SetUp() override {
m_device = std::make_unique();
}
void TearDown() override {
if (m_device) {
m_device->stop();
}
}
std::unique_ptr m_device;
};
TEST_F(MyDeviceTest, InitializationTest) {
mc::mutable_dict config;
config["DeviceName"] = std::string("TestDevice");
config["DeviceId"] = uint8_t(1);
mc::dict connector;
EXPECT_TRUE(m_device->init(config, connector));
}
```
### 5.2 集成测试
```cpp
// tests/integration/my_device_integration_test.cpp
class MyDeviceIntegrationTest : public ::testing::Test {
protected:
void SetUp() override {
m_service = std::make_unique();
}
std::unique_ptr m_service;
};
TEST_F(MyDeviceIntegrationTest, ABI_Test) {
driver_handle_t handle = create_my_device(m_service.get(), "TestDevice");
EXPECT_NE(handle, nullptr);
mc::mutable_dict config;
config["DeviceName"] = std::string("TestDevice");
mc::dict connector;
EXPECT_EQ(init_my_device(handle, &config, &connector), STATUS_OK);
EXPECT_EQ(start_my_device(handle), STATUS_OK);
EXPECT_EQ(stop_my_device(handle), STATUS_OK);
}
```
## 6. 性能优化
### 6.1 性能优化策略
```mermaid
mindmap
root((性能优化))
内存管理
对象池
预分配缓冲区
智能指针
RAII原则
并发优化
异步操作
线程池
锁优化
无锁数据结构
IO优化
批量操作
缓冲机制
DMA传输
零拷贝
算法优化
时间复杂度优化
空间复杂度优化
缓存友好
分支预测
```
### 6.1 内存管理
```cpp
class PerformantDevice {
private:
// 使用对象池减少内存分配
std::vector> m_buffer_pool;
std::mutex m_pool_mutex;
static constexpr size_t BUFFER_POOL_SIZE = 64;
static constexpr size_t BUFFER_SIZE = 4096;
public:
void init_buffer_pool() {
m_buffer_pool.reserve(BUFFER_POOL_SIZE);
for (size_t i = 0; i < BUFFER_POOL_SIZE; ++i) {
m_buffer_pool.push_back(
std::make_unique(BUFFER_SIZE));
}
}
std::unique_ptr get_buffer() {
std::lock_guard lock(m_pool_mutex);
if (!m_buffer_pool.empty()) {
auto buffer = std::move(m_buffer_pool.back());
m_buffer_pool.pop_back();
return buffer;
}
return std::make_unique(BUFFER_SIZE);
}
};
```
### 6.2 异步操作
```cpp
class AsyncDevice {
private:
// 使用 mc::runtime 线程池执行异步任务
std::shared_ptr m_thread_pool;
mc::runtime::thread_pool::executor_type m_executor;
public:
AsyncDevice()
: m_thread_pool(std::make_shared(4, "device_pool")),
m_executor(m_thread_pool->get_executor())
{}
// 提交异步任务（post 不等待返回）
void submit_async_task(std::function task) {
m_executor.post(std::move(task));
}
// 分发任务（dispatch 可在调用线程直接执行）
void dispatch_async_task(std::function task) {
m_executor.dispatch(std::move(task));
}
// 延迟执行（defer 延迟到当前任务结束后执行）
void defer_async_task(std::function task) {
m_executor.defer(std::move(task));
}
};
```
## 7. 错误处理和调试
### 7.1 错误处理流程
```mermaid
flowchart TD
A[错误发生] --> B{错误类型}
B -->|初始化失败| C[重试初始化]
B -->|硬件错误| D[硬件重置]
B -->|协议错误| E[重启协议]
B -->|超时错误| F[调整超时参数]
B -->|配置错误| G[验证配置]
C --> H{重试成功?}
D --> I{重置成功?}
E --> J{重启成功?}
F --> K[继续操作]
G --> L[修正配置]
H -->|是| M[记录恢复日志]
H -->|否| N[报告严重错误]
I -->|是| M
I -->|否| N
J -->|是| M
J -->|否| N
M --> O[正常运行]
N --> P[停止设备]
L --> A
style A fill:#f44336
style N fill:#f44336
style O fill:#4caf50
style M fill:#4caf50
```
### 7.1 错误处理策略
```cpp
enum class DeviceError {
SUCCESS = 0,
INIT_FAILED,
HARDWARE_ERROR,
PROTOCOL_ERROR,
TIMEOUT_ERROR,
INVALID_CONFIG
};
class ErrorHandler {
public:
static bool handle_error(DeviceError error, const std::string& context) {
switch (error) {
case DeviceError::INIT_FAILED:
elog("Device initialization failed in ${context}", ("context", context));
return retry_initialization();
case DeviceError::HARDWARE_ERROR:
elog("Hardware error detected in ${context}", ("context", context));
return perform_hardware_reset();
default:
elog("Unknown error in ${context}", ("context", context));
return false;
}
}
};
```
### 7.2 调试工具
```cpp
class DebugHelper {
public:
// 设备状态转储
static void dump_device_state(const MyDevice& device) {
ilog("=== Device State Dump ===");
ilog("Name: ${name}", ("name", device.i_my_device.DeviceName.value()));
ilog("ID: ${id}", ("id", device.i_my_device.DeviceId.value()));
ilog("========================");
}
// 性能监控
class PerformanceMonitor {
private:
std::chrono::high_resolution_clock::time_point m_start;
std::string m_operation;
public:
PerformanceMonitor(const std::string& operation)
: m_operation(operation), m_start(std::chrono::high_resolution_clock::now()) {}
~PerformanceMonitor() {
auto end = std::chrono::high_resolution_clock::now();
auto duration = std::chrono::duration_cast