固件操作系统驱动开发嵌入式【免费下载链接】edk2EDK II项目地址https://gitcode.com/gh_mirrors/ed/edk2点击查看免费下载导读本文以仓库根目录 ReadMe.rst 为骨架系统拆解 EDK II 这一现代、功能丰富、跨平台的 UEFI/PI 固件开发环境——从项目定位与许可证体系、Python 工具链前置要求到覆盖 Windows/Ubuntu 多工具链的 CI 矩阵、平台级固件构建流程OvmfPkg/EmulatorPkg/ArmVirtPkg再到子模块管理、代码贡献与 DCO 签署规范。读完本文你将掌握该仓库的获取与初始化方法、CI 状态图的解读方式、基于 Pytoolsstuart的本地构建工作流以及向 TianoCore 社区提交补丁的完整礼仪。一、项目定位为 UEFI 与 PI 规范而生的现代固件开发环境ReadMe.rst 开篇将 EDK II 定义为a modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications from www.uefi.org——即一个面向 UEFIUnified Extensible Firmware Interface统一可扩展固件接口与 PIPlatform Initialization平台初始化规范的现代、功能丰富、跨平台固件开发环境。从仓库目录结构可以直观印证其跨平台与包Package化的组织思路顶层按功能域划分为数十个 Package例如MdePkg / MdeModulePkgUEFI/PI 核心库与模块实现是整个体系的地基MdePkg/Include下包含 600 头文件MdePkg/Library下包含 1200 文件覆盖各架构汇编与 C 实现ArmPkg / ArmPlatformPkg / ArmVirtPkg面向 ARM 架构与虚拟化平台QEMU、KVMTOOL、CloudHv、Xen的支持OvmfPkg面向 QEMU 虚拟机的开放虚拟固件OVMF支持 X64 与 IA32X64 等多种配置EmulatorPkg可在 Windows/Linux 桌面上以本地进程模拟方式运行的固件环境适合无硬件调试CryptoPkg / SecurityPkg / NetworkPkg / UefiCpuPkg等分别承载密码学、安全启动与 TPM、网络协议栈、CPU 初始化等专项能力。这种按 Package 组织、以.dec描述包、以.dsc定义构建、以.inf描述模块的结构是 EDK II 区别于普通嵌入式工程的显著特征也是后续所有构建与 CI 流程的基础。二、环境前置Python 版本要求与 Pytools 生态2.1 官方建议的 Python 最低版本ReadMe.rst 在简介后立即给出一个醒目的徽章信息CI Minimum Python Version由edk2-pytool-extensions仓库的pyproject.toml动态解析得出。它明确说明It is recommended to install this Python version to run the full set of scripts that enable CI in the project.也就是说要在本地完整运行仓库中的 CI 脚本需要安装符合该最低版本要求的 Python。其他构建期 Python 依赖ReadMe 指引读者查看官方EDK II Build Instructions中的工具清单。2.2 pip-requirements.txtCI 运行的核心 Python 依赖与 ReadMe 呼应仓库根目录的 pip-requirements.txt 精确列出了 CI/构建所依赖的 Python 组件edk2-pytool-library~0.23.16 edk2-pytool-extensions~0.31.1 antlr4-python3-runtime4.13.2 lcov-cobertura2.1.1 regex2026.7.19 pefile其中最关键的是两个 TianoCore 官方维护的 PIP 模块edk2-pytool-library提供底层库能力edk2-pytool-extensions提供stuart_setup、stuart_update、stuart_ci_build、stuart_build等命令行工具统称 Pytools。从 .pytool/Readme.md 可以看到这套 CI 与测试基础设施正是构建在这两个模块之上的。安装命令为pip install --upgrade -r pip-requirements.txt建议在 Python 虚拟环境中安装避免污染系统环境。三、CI 构建状态矩阵读懂仓库的健康仪表盘ReadMe.rst 用两张状态表格展示项目的持续集成情况一张是核心 CICore CI构建状态一张是平台 CIPlatform CI构建状态。这些状态图由 Azure DevOps 徽章动态渲染直接反映了 master 分支各工具链组合下的实时构建/测试/覆盖率情况。3.1 Core CI五条工具链组合Host Type Toolchain覆盖能力说明Windows_VS构建 测试 覆盖率Microsoft Visual Studio 工具链Ubuntu_GCC构建 测试 覆盖率Linux 下 GCC 工具链Windows_CLANGPDB构建 测试 覆盖率Windows 下 Clang生成 PDB 调试信息Ubuntu_CLANGPDB构建 测试 覆盖率Linux 下 Clang PDBUbuntu_CLANGDWARF构建 测试 覆盖率Linux 下 Clang DWARF 调试格式其中覆盖率一列当前统一标注为 coming_soon即将推出表明代码覆盖率统计仍在建设阶段构建与测试徽章则实时反映最新流水线结果。更多底层 CI 细节见 .pytool/Readme.md。3.2 Platform CI三大参考平台 × 多种工具链平台 CI 面向三个真实可运行的平台固件分别对应 DEBUG / RELEASE / NOOPT 三种构建目标以及 X64 / AARCH64 架构平台包工具链架构/配置覆盖的构建目标EmulatorPkgWindows VS / CLANGPDB、Ubuntu GCC / CLANGDWARFX64、X64 FULLDEBUG / RELEASE / NOOPTOvmfPkgWindows VS、Ubuntu GCC / CLANGPDB / CLANGDWARFX64DEBUG / RELEASE / NOOPTArmVirtPkgUbuntu GCC / CLANGPDB / CLANGDWARFAARCH64DEBUG / RELEASE / NOOPT一个值得注意的已知问题ReadMe 以特殊标记列出TCBZ_2639 —— EmulatorPkg 在 Ubuntu GCC 下执行时存在段错误Segfaults对应 issue 编号 9905。这说明即便是参考平台在特定工具链组合下也可能存在已知缺陷社区正在跟踪处理。每个平台包都提供了更详细的平台 CI 说明文档可在仓库内直接查阅ArmVirtPkg/PlatformCI/ReadMe.mdEmulatorPkg/PlatformCI/ReadMe.mdOvmfPkg/PlatformCI/ReadMe.md3.3 各 Package 的 CI 覆盖情况来自 .pytool/Readme.md.pytool/Readme.md 的Basic Status表进一步细化到每个 Package 在 Windows VS2026IA32/X64与 Ubuntu GCCIA32/X64/AARCH64两条核心流水线上的覆盖情况。概括如下双平台全覆盖CryptoPkg、DynamicTablesPkg、FatPkg、FmpDevicePkg、MdeModulePkg、MdePkg、NetworkPkg、PcAtChipsetPkg、SecurityPkg、ShellPkg、StandaloneMmPkg、UefiCpuPkg、UnitTestFrameworkPkg 等均已在 Windows 与 Ubuntu 双流水线启用 CI平台包走独立流程ArmVirtPkg、EmulatorPkg、OvmfPkg 属于平台级构建其 CI 定义见各自 Package 内的 PlatformCI 目录即上文 3.2 的平台矩阵部分包尚未接入EmbeddedPkg、IntelFsp2Pkg、IntelFsp2WrapperPkg、SourceLevelDebugPkg、UefiPayloadPkg 在表中未标记为双流水线启用已知限制MdeModulePkg 的 DxeIpl 依赖 ArmPkg、整体依赖 StandaloneMmPkgShellPkg 有 3 个模块未通过 DSC 构建UefiCpuPkg 有 2 个二进制模块未通过 DSC 构建多个包CryptoPkg、MdePkg、NetworkPkg、OvmfPkg、SecurityPkg、ShellPkg、UefiCpuPkg 等的拼写检查以审计模式audit mode运行。四、从 ReadMe 到实操用 Pytools 搭建可复现的固件构建工作流虽然 ReadMe.rst 本身只给出了概览但其链接的.pytool/Readme.md与三个平台包的 PlatformCI ReadMe 共同构成了完整的本地构建实操路径。以 OvmfPkg/PlatformCI/ReadMe.md 为例完整流程如下。4.1 准备开发环境Git版本控制QEMU运行 OVMF 固件用需加入 PATHWindows 上需手动添加不在安装器自动路径内EDK II 源码即本仓库Ubuntu 额外依赖apt-get install gcc g make uuid-dev。关键点使用 Pytools 后手动执行 edksetup、初始化子模块、手工安装 NASM/iASL 或交叉编译工具链都不是必须的——这些都由 Pytools 构建系统自动处理。4.2 构建命令序列OvmfPkg 示例# 1. [可选] 创建 Python 虚拟环境一般每个工作区一次 python -m venv 虚拟环境名 # 2. [可选] 激活虚拟环境每次打开新 shell 执行 # Linux: source 虚拟环境名/bin/activate # Windows: 虚拟环境名/Scripts/activate.bat # 3. 安装 Pytools虚拟环境创建后或 pip-requirements.txt 变更时 pip install --upgrade -r pip-requirements.txt # 4. 初始化并更新子模块仅当子模块更新时 stuart_setup -c OvmfPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAGTOOL_CHAIN_TAG -a TARGET_ARCH # 5. 初始化并更新外部依赖仅当 ext_deps 变更时 stuart_update -c OvmfPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAGTOOL_CHAIN_TAG -a TARGET_ARCH # 6. 必要时编译 BaseTools仅当 BaseTools 的 C 源码变更时 python BaseTools/Edk2ToolsBuild.py -t ToolChainTag # 7. 编译固件X64 stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py -a X64 TOOL_CHAIN_TAGTOOL_CHAIN_TAG # 编译 IA32X64 混合固件PEI-IA32、DXE-X64 stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py -a IA32,X64 TOOL_CHAIN_TAGTOOL_CHAIN_TAG # 8. 构建完成后运行模拟器二选一 stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAGTOOL_CHAIN_TAG -a TARGET_ARCH --FlashRom # 构建后立即启动 stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAGTOOL_CHAIN_TAG -a TARGET_ARCH --FlashOnly # 仅运行模拟器实用提示stuart_build -c ... -h可查看全部附加选项如--clean。4.3 平台构建的自定义选项以 OvmfPkg 为例PlatformBuild.py 支持以下自定义构建选项MAKE_STARTUP_NSHTRUE向 fs0 映射位置输出startup.nsh脚本。CI 中常与--FlashOnly配合实现启动 QEMU 进入 UEFI Shell 后自动执行脚本的自动化测试QEMU_HEADLESSTRUECI 服务器通常无显示器设置后 QEMU 以无显示模式运行避免报错本地开发无需设置。4.4 通过BLD_*_前缀传递构建宏使用 stuart_build 时传统-D XXX的宏传递方式要改写为BLD_*_前缀形式且 stuart_build 要求赋值裸宏需追加1。例如启用 TPM2 支持传统写法-D E1000_ENABLE应写为stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py BLD_*_E1000_ENABLE14.5 本地运行 CI 插件.pytool/Readme.md 指出默认所有 CI 插件均为启用状态可通过插件名skip跳过指定插件CompilerPluginskip # 跳过编译测试 GuidCheckskip # 跳过 GUID 唯一性检查 SpellCheckskip # 跳过拼写检查每个 Package 的详细报告与日志生成在Build目录下。CI 配置按优先级依次来自命令行参数 → 包级配置文件包名.ci.yaml例如各包根目录下的MdePkg.ci.yaml、OvmfPkg.ci.yaml→ 全局配置模块.pytool/CISettings.py。4.6 了解 CI 测试插件能力矩阵仓库.pytool/Plugin目录实际存放了全套 CI 插件包括CharEncodingCheck非法字符检查、CompilerPlugin编译测试、DependencyCheck跨包依赖检查、DscCompleteCheck模块包含性检查、EccCheckEDK II 编码规范、GuidCheckGUID 唯一性、HostUnitTestCompilerPlugin、HostUnitTestDscCompleteCheck主机单元测试、LibraryClassCheck库类声明检查、LicenseCheck许可证检查、MarkdownLintCheck、SpellCheckcspell 拼写检查与 UncrustifyCheck代码格式合规。这些插件构成了 EDK II 质量保障的多层防线。五、许可证体系BSD-2-Clause-Patent 与多许可证组件5.1 主许可证ReadMe.rst 明确指出EDK II 开源项目的绝大部分内容采用BSD-2-Clause Plus Patent LicenseBSD 双条款 专利授权见 License.txt。该许可证在标准 BSD-2-Clause 文本之外额外授予与贡献相关的专利许可兼顾了开源共享与专利保护。5.2 采用附加许可证的组件仓库内可验证ReadMe 逐项列出了仓库中采用其他许可证的组件组件路径说明BaseTools/Plugin/CodeQL/analyzeApache License 2.0BaseTools/Source/C/LzmaCompressLZMA SDK见 LZMA-SDK-README.txtBaseTools/Source/C/VfrCompile/PcctsPCCTS 编译器工具见 RIGHTSCryptoPkg/Library/BaseCryptLib/SysCall/inet_pton.c特定许可证文件头注释说明CryptoPkg/Library/Include/crypto/dso_conf.h等OpenSSL 相关许可证MdeModulePkg/Library/LzmaCustomDecompressLibLZMA SDK见 LZMA-SDK-README.txtOvmfPkg见 OvmfPkg/License.txt5.3 以 git 子模块引入的上游项目及其许可证EDK II 通过 git 子模块方式引入多个上游项目这些项目使用各自独立的许可证与本仓库主许可证无关brotliBaseTools/Source/C/BrotliCompress/brotli、MdeModulePkg/Library/BrotliCustomDecompressLib/brotli压缩算法opensslCryptoPkg/Library/OpensslLib/openssl密码学库mbedtlsCryptoPkg/Library/MbedTlsLib/mbedtls轻量密码学库onigurumaMdeModulePkg/Universal/RegularExpressionDxe/oniguruma正则表达式引擎cmockaUnitTestFrameworkPkg/Library/CmockaLib/cmocka与googletestUnitTestFrameworkPkg/Library/GoogleTestLib/googletest、subhook单元测试与钩子框架janssonRedfishPkg/Library/JsonLib/janssonJSON 库libfdtMdePkg/Library/BaseFdtLib/libfdt扁平设备树库mipisystMdePkg/Library/MipiSysTLib/mipisystMIPI Sys-T 库libspdmSecurityPkg/DeviceSecurity/SpdmLib/libspdmSPDM 设备安全协议实现TPMTcgTpmPkg/Library/TpmLib/TPMTPM 参考实现。这些子模块的完整清单与远端地址记录在仓库根目录的 .gitmodules 中是理解 EDK II 供应链构成的第一手资料。六、子模块管理克隆与更新的标准姿势6.1 获取完整可构建的仓库ReadMe.rst 给出了标准克隆流程注意ReadMe 中使用的是 tianocore 官方地址本镜像仓库同样适用如下操作逻辑git clone https://github.com/tianocore/edk2.git cd edk2 git submodule update --init cd ..6.2 子模块更新流程当上游子模块有更新时cd edk2 git pull git submodule update6.3 关键注意事项不要使用--recursiveReadMe 特别强调克隆子模块仓库时不推荐使用--recursive选项。理由有二EDK II 本身不会使用列出的子模块内部再嵌套的任何代码或功能使用--recursive会引入对我们并不需要其代码的服务器的可达性依赖并白白下载用不到的代码。这一约定能显著减少克隆体积与网络依赖值得所有 EDK II 使用者遵守。七、Package 维护者体系Maintainers.txt 的读取方式ReadMe 指出EDK II 项目由若干 Package 组成每个 Package 的维护者maintainer名单记录在 Maintainers.txt 中。该文件采用类 Linux 内核的get_maintainer格式核心字段含义如下L相关邮件列表默认edk2-devel补丁与问题应发送至此MPackage 维护者负责评审与推送包变更RPackage 评审者协助维护者评审代码但无推送权限W状态/信息网页TSCM 树类型与位置git/svnS状态——Supported有人专职维护、Maintained有人维护、Odd Fixes维护者时间有限、Obsolete已废弃F受维护的文件/目录通配符F: MdeModulePkg/表示含子目录的全部文件F: MdeModulePkg/*仅顶层F: */Pci/*任意深度的 Pci 目录X明确不受维护的排除规则后于 F 规则测试。顶层还列出了 Tianocore StewardsTianoCore 管家名单以及两个当前需要额外维护者的包NetworkPkg与SecurityPkg——这也是社区招募贡献者的活跃信号。八、代码贡献规范从提交信息到 DCO 签署8.1 贡献流程四步走ReadMe.rst 规定向 TianoCore 项目贡献代码需遵循按下方规定格式撰写变更描述change description用于提交日志提交信息必须包含Signed-off-by签名通过项目网页上记载的流程提交代码若流程未记载则提交到项目开发邮件列表优先采用与主项目一致的版权许可证提交若无法一致可接受以下许可Apache License 2.0、BSD2-clause、BSD3-clause、MIT、Python-2.0、Zlib文档类贡献接受 FreeBSD Documentation License进入公有领域的代码也可接受其他许可证可能被接受但需要进一步评审。8.2 Developer Certificate of OriginDCO1.1所有补丁必须包含Signed-off-by行以证明贡献者拥有按指定许可证提交的合法权利。DCO 1.1 的核心认证内容为全文见 ReadMe 原文(a) 贡献全部或部分由本人创作且本人有权按开源许可证提交(b) 贡献基于本人所知处于适当开源许可证下的既有成果本人有权在相同许可证下提交含修改(c) 贡献由其他已认证 (a)/(b)/(c) 的人直接提供且本人未作修改(d) 本人理解并同意项目与贡献是公开的记录含提交的全部个人信息将长期保留并可按本项目或所涉开源许可证的规定再分发。8.3 提交信息格式模板与字段定义ReadMe 给出了标准提交信息样例From: Contributor Name contributorexample.com Subject: [Repository/Branch PATCH] Pkg-Module: Brief-single-line-summary Full-commit-message Signed-off-by: Contributor Name contributorexample.com各字段定义Repository补丁所适用仓库的标识仅当非edk2时提供例如edk2-BuildSpecification或stagingBranch补丁所适用分支标识仅当非edk2/master时提供例如edk2/UDK2015、edk2-BuildSpecification/release/1.27、staging/edk2-testModule受影响代码/文档的短标识例如MdePkg、MdeModulePkg/UsbBusDxe、Introduction或EDK II INF File FormatBrief-single-line-summary变更的简短摘要整个首行应少于约 70 个字符Full-commit-message详述变更的多行说明每行也应少于约 70 个字符Signed-off-by贡献者的真实/法定姓名与邮箱签名。格式说明提交信息首行取自邮件主题中[Repository/Branch PATCH]之后的部分其余内容取自邮件正文git format-patch是生成该格式的一种方式。九、资源与社区入口ReadMe 的 Resources 一节列出了与 EDK II 相关的官方资源入口以下均为项目官方公开资源读者可据此深入了解TianoCore社区主页EDK II 官方 Wiki涵盖规范、教程与工具链说明Getting Started with EDK II新手入门教程Mailing Lists开发者邮件列表补丁与讨论的主要渠道How To Contribute贡献指南Release Planning版本规划与路线图。十、快速自检清单使用本仓库前请确认Python 环境已安装满足 CI 最低版本要求的 Python并已pip install --upgrade -r pip-requirements.txt子模块已执行git submodule update --init切勿加--recursive工具链已按目标平台准备 GCC / VS / CLANGPDB / CLANGDWARF 中的相应工具链平台模拟类构建OvmfPkg/EmulatorPkg还需将 QEMU 加入 PATH构建方式优先使用 Pytools 工作流stuart_setup→stuart_update→stuart_build而非手工 edksetup NASM/iASL 安装贡献礼仪提交信息含Signed-off-by、遵循 DCO 1.1、标题行与正文行控制在 70 字符内、首行采用Pkg-Module: Brief-summary格式已知问题留意 ReadMe 标记的已知缺陷如 EmulatorPkg 在 Ubuntu GCC 下的段错误 TCBZ_2639避开不稳定的工具链组合。通过以上六个维度的梳理你已具备从看懂 EDK II 仓库到本地构建固件再到参与社区贡献的完整知识链路任何一步的细节都可以沿着文中给出的仓库内文档路径.pytool/Readme.md、三个平台的 PlatformCI ReadMe、Maintainers.txt、.gitmodules、License.txt等继续深入。赞分享固件操作系统驱动开发嵌入式【免费下载链接】edk2EDK II项目地址https://gitcode.com/gh_mirrors/ed/edk2点击查看免费下载相关推荐Synergy 仓库 AI 协作开发规范全解析构建纪律、CI 矩阵陷阱与 Deskflow 上游回移策略Synergy 仓库 AI 协作开发规范全解析构建纪律、CI 矩阵陷阱与 Deskflow 上游回移策略 本指南以 Synergy 仓库根目录下的协作笔记C桌面应用网络通信agentic-awesome-skills 实战基于 Rube MCPComposio的 Canva 设计自动化全流程指南agentic awesome skills 实战基于 Rube MCPComposio的 Canva 设计自动化全流程指南 导读 本文以 agenticAI 技能AI 插件guidance 仓库贡献开发指南开发环境搭建、测试矩阵扩展与 Ruff 代码规范guidance 仓库贡献开发指南开发环境搭建、测试矩阵扩展与 Ruff 代码规范 本指南面向希望向 guidance 仓库提交代码、新增模型测试或参与维护的大模型提示工程AI Agent上一篇如何用 bilibili-downloader 免费下载 B 站 4K 视频新手零门槛完整教程下一篇鼠标增强工具Mac Mouse Fix完全指南三步告别生硬滚动与闲置侧键创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 走进 EDK II：UEFI/PI 固件开发环境、CI 矩阵与协作规范完全指南
固件操作系统驱动开发嵌入式【免费下载链接】edk2EDK II项目地址https://gitcode.com/gh_mirrors/ed/edk2点击查看免费下载导读本文以仓库根目录 ReadMe.rst 为骨架系统拆解 EDK II 这一现代、功能丰富、跨平台的 UEFI/PI 固件开发环境——从项目定位与许可证体系、Python 工具链前置要求到覆盖 Windows/Ubuntu 多工具链的 CI 矩阵、平台级固件构建流程OvmfPkg/EmulatorPkg/ArmVirtPkg再到子模块管理、代码贡献与 DCO 签署规范。读完本文你将掌握该仓库的获取与初始化方法、CI 状态图的解读方式、基于 Pytoolsstuart的本地构建工作流以及向 TianoCore 社区提交补丁的完整礼仪。一、项目定位为 UEFI 与 PI 规范而生的现代固件开发环境ReadMe.rst 开篇将 EDK II 定义为a modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications from www.uefi.org——即一个面向 UEFIUnified Extensible Firmware Interface统一可扩展固件接口与 PIPlatform Initialization平台初始化规范的现代、功能丰富、跨平台固件开发环境。从仓库目录结构可以直观印证其跨平台与包Package化的组织思路顶层按功能域划分为数十个 Package例如MdePkg / MdeModulePkgUEFI/PI 核心库与模块实现是整个体系的地基MdePkg/Include下包含 600 头文件MdePkg/Library下包含 1200 文件覆盖各架构汇编与 C 实现ArmPkg / ArmPlatformPkg / ArmVirtPkg面向 ARM 架构与虚拟化平台QEMU、KVMTOOL、CloudHv、Xen的支持OvmfPkg面向 QEMU 虚拟机的开放虚拟固件OVMF支持 X64 与 IA32X64 等多种配置EmulatorPkg可在 Windows/Linux 桌面上以本地进程模拟方式运行的固件环境适合无硬件调试CryptoPkg / SecurityPkg / NetworkPkg / UefiCpuPkg等分别承载密码学、安全启动与 TPM、网络协议栈、CPU 初始化等专项能力。这种按 Package 组织、以.dec描述包、以.dsc定义构建、以.inf描述模块的结构是 EDK II 区别于普通嵌入式工程的显著特征也是后续所有构建与 CI 流程的基础。二、环境前置Python 版本要求与 Pytools 生态2.1 官方建议的 Python 最低版本ReadMe.rst 在简介后立即给出一个醒目的徽章信息CI Minimum Python Version由edk2-pytool-extensions仓库的pyproject.toml动态解析得出。它明确说明It is recommended to install this Python version to run the full set of scripts that enable CI in the project.也就是说要在本地完整运行仓库中的 CI 脚本需要安装符合该最低版本要求的 Python。其他构建期 Python 依赖ReadMe 指引读者查看官方EDK II Build Instructions中的工具清单。2.2 pip-requirements.txtCI 运行的核心 Python 依赖与 ReadMe 呼应仓库根目录的 pip-requirements.txt 精确列出了 CI/构建所依赖的 Python 组件edk2-pytool-library~0.23.16 edk2-pytool-extensions~0.31.1 antlr4-python3-runtime4.13.2 lcov-cobertura2.1.1 regex2026.7.19 pefile其中最关键的是两个 TianoCore 官方维护的 PIP 模块edk2-pytool-library提供底层库能力edk2-pytool-extensions提供stuart_setup、stuart_update、stuart_ci_build、stuart_build等命令行工具统称 Pytools。从 .pytool/Readme.md 可以看到这套 CI 与测试基础设施正是构建在这两个模块之上的。安装命令为pip install --upgrade -r pip-requirements.txt建议在 Python 虚拟环境中安装避免污染系统环境。三、CI 构建状态矩阵读懂仓库的健康仪表盘ReadMe.rst 用两张状态表格展示项目的持续集成情况一张是核心 CICore CI构建状态一张是平台 CIPlatform CI构建状态。这些状态图由 Azure DevOps 徽章动态渲染直接反映了 master 分支各工具链组合下的实时构建/测试/覆盖率情况。3.1 Core CI五条工具链组合Host Type Toolchain覆盖能力说明Windows_VS构建 测试 覆盖率Microsoft Visual Studio 工具链Ubuntu_GCC构建 测试 覆盖率Linux 下 GCC 工具链Windows_CLANGPDB构建 测试 覆盖率Windows 下 Clang生成 PDB 调试信息Ubuntu_CLANGPDB构建 测试 覆盖率Linux 下 Clang PDBUbuntu_CLANGDWARF构建 测试 覆盖率Linux 下 Clang DWARF 调试格式其中覆盖率一列当前统一标注为 coming_soon即将推出表明代码覆盖率统计仍在建设阶段构建与测试徽章则实时反映最新流水线结果。更多底层 CI 细节见 .pytool/Readme.md。3.2 Platform CI三大参考平台 × 多种工具链平台 CI 面向三个真实可运行的平台固件分别对应 DEBUG / RELEASE / NOOPT 三种构建目标以及 X64 / AARCH64 架构平台包工具链架构/配置覆盖的构建目标EmulatorPkgWindows VS / CLANGPDB、Ubuntu GCC / CLANGDWARFX64、X64 FULLDEBUG / RELEASE / NOOPTOvmfPkgWindows VS、Ubuntu GCC / CLANGPDB / CLANGDWARFX64DEBUG / RELEASE / NOOPTArmVirtPkgUbuntu GCC / CLANGPDB / CLANGDWARFAARCH64DEBUG / RELEASE / NOOPT一个值得注意的已知问题ReadMe 以特殊标记列出TCBZ_2639 —— EmulatorPkg 在 Ubuntu GCC 下执行时存在段错误Segfaults对应 issue 编号 9905。这说明即便是参考平台在特定工具链组合下也可能存在已知缺陷社区正在跟踪处理。每个平台包都提供了更详细的平台 CI 说明文档可在仓库内直接查阅ArmVirtPkg/PlatformCI/ReadMe.mdEmulatorPkg/PlatformCI/ReadMe.mdOvmfPkg/PlatformCI/ReadMe.md3.3 各 Package 的 CI 覆盖情况来自 .pytool/Readme.md.pytool/Readme.md 的Basic Status表进一步细化到每个 Package 在 Windows VS2026IA32/X64与 Ubuntu GCCIA32/X64/AARCH64两条核心流水线上的覆盖情况。概括如下双平台全覆盖CryptoPkg、DynamicTablesPkg、FatPkg、FmpDevicePkg、MdeModulePkg、MdePkg、NetworkPkg、PcAtChipsetPkg、SecurityPkg、ShellPkg、StandaloneMmPkg、UefiCpuPkg、UnitTestFrameworkPkg 等均已在 Windows 与 Ubuntu 双流水线启用 CI平台包走独立流程ArmVirtPkg、EmulatorPkg、OvmfPkg 属于平台级构建其 CI 定义见各自 Package 内的 PlatformCI 目录即上文 3.2 的平台矩阵部分包尚未接入EmbeddedPkg、IntelFsp2Pkg、IntelFsp2WrapperPkg、SourceLevelDebugPkg、UefiPayloadPkg 在表中未标记为双流水线启用已知限制MdeModulePkg 的 DxeIpl 依赖 ArmPkg、整体依赖 StandaloneMmPkgShellPkg 有 3 个模块未通过 DSC 构建UefiCpuPkg 有 2 个二进制模块未通过 DSC 构建多个包CryptoPkg、MdePkg、NetworkPkg、OvmfPkg、SecurityPkg、ShellPkg、UefiCpuPkg 等的拼写检查以审计模式audit mode运行。四、从 ReadMe 到实操用 Pytools 搭建可复现的固件构建工作流虽然 ReadMe.rst 本身只给出了概览但其链接的.pytool/Readme.md与三个平台包的 PlatformCI ReadMe 共同构成了完整的本地构建实操路径。以 OvmfPkg/PlatformCI/ReadMe.md 为例完整流程如下。4.1 准备开发环境Git版本控制QEMU运行 OVMF 固件用需加入 PATHWindows 上需手动添加不在安装器自动路径内EDK II 源码即本仓库Ubuntu 额外依赖apt-get install gcc g make uuid-dev。关键点使用 Pytools 后手动执行 edksetup、初始化子模块、手工安装 NASM/iASL 或交叉编译工具链都不是必须的——这些都由 Pytools 构建系统自动处理。4.2 构建命令序列OvmfPkg 示例# 1. [可选] 创建 Python 虚拟环境一般每个工作区一次 python -m venv 虚拟环境名 # 2. [可选] 激活虚拟环境每次打开新 shell 执行 # Linux: source 虚拟环境名/bin/activate # Windows: 虚拟环境名/Scripts/activate.bat # 3. 安装 Pytools虚拟环境创建后或 pip-requirements.txt 变更时 pip install --upgrade -r pip-requirements.txt # 4. 初始化并更新子模块仅当子模块更新时 stuart_setup -c OvmfPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAGTOOL_CHAIN_TAG -a TARGET_ARCH # 5. 初始化并更新外部依赖仅当 ext_deps 变更时 stuart_update -c OvmfPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAGTOOL_CHAIN_TAG -a TARGET_ARCH # 6. 必要时编译 BaseTools仅当 BaseTools 的 C 源码变更时 python BaseTools/Edk2ToolsBuild.py -t ToolChainTag # 7. 编译固件X64 stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py -a X64 TOOL_CHAIN_TAGTOOL_CHAIN_TAG # 编译 IA32X64 混合固件PEI-IA32、DXE-X64 stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py -a IA32,X64 TOOL_CHAIN_TAGTOOL_CHAIN_TAG # 8. 构建完成后运行模拟器二选一 stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAGTOOL_CHAIN_TAG -a TARGET_ARCH --FlashRom # 构建后立即启动 stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAGTOOL_CHAIN_TAG -a TARGET_ARCH --FlashOnly # 仅运行模拟器实用提示stuart_build -c ... -h可查看全部附加选项如--clean。4.3 平台构建的自定义选项以 OvmfPkg 为例PlatformBuild.py 支持以下自定义构建选项MAKE_STARTUP_NSHTRUE向 fs0 映射位置输出startup.nsh脚本。CI 中常与--FlashOnly配合实现启动 QEMU 进入 UEFI Shell 后自动执行脚本的自动化测试QEMU_HEADLESSTRUECI 服务器通常无显示器设置后 QEMU 以无显示模式运行避免报错本地开发无需设置。4.4 通过BLD_*_前缀传递构建宏使用 stuart_build 时传统-D XXX的宏传递方式要改写为BLD_*_前缀形式且 stuart_build 要求赋值裸宏需追加1。例如启用 TPM2 支持传统写法-D E1000_ENABLE应写为stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py BLD_*_E1000_ENABLE14.5 本地运行 CI 插件.pytool/Readme.md 指出默认所有 CI 插件均为启用状态可通过插件名skip跳过指定插件CompilerPluginskip # 跳过编译测试 GuidCheckskip # 跳过 GUID 唯一性检查 SpellCheckskip # 跳过拼写检查每个 Package 的详细报告与日志生成在Build目录下。CI 配置按优先级依次来自命令行参数 → 包级配置文件包名.ci.yaml例如各包根目录下的MdePkg.ci.yaml、OvmfPkg.ci.yaml→ 全局配置模块.pytool/CISettings.py。4.6 了解 CI 测试插件能力矩阵仓库.pytool/Plugin目录实际存放了全套 CI 插件包括CharEncodingCheck非法字符检查、CompilerPlugin编译测试、DependencyCheck跨包依赖检查、DscCompleteCheck模块包含性检查、EccCheckEDK II 编码规范、GuidCheckGUID 唯一性、HostUnitTestCompilerPlugin、HostUnitTestDscCompleteCheck主机单元测试、LibraryClassCheck库类声明检查、LicenseCheck许可证检查、MarkdownLintCheck、SpellCheckcspell 拼写检查与 UncrustifyCheck代码格式合规。这些插件构成了 EDK II 质量保障的多层防线。五、许可证体系BSD-2-Clause-Patent 与多许可证组件5.1 主许可证ReadMe.rst 明确指出EDK II 开源项目的绝大部分内容采用BSD-2-Clause Plus Patent LicenseBSD 双条款 专利授权见 License.txt。该许可证在标准 BSD-2-Clause 文本之外额外授予与贡献相关的专利许可兼顾了开源共享与专利保护。5.2 采用附加许可证的组件仓库内可验证ReadMe 逐项列出了仓库中采用其他许可证的组件组件路径说明BaseTools/Plugin/CodeQL/analyzeApache License 2.0BaseTools/Source/C/LzmaCompressLZMA SDK见 LZMA-SDK-README.txtBaseTools/Source/C/VfrCompile/PcctsPCCTS 编译器工具见 RIGHTSCryptoPkg/Library/BaseCryptLib/SysCall/inet_pton.c特定许可证文件头注释说明CryptoPkg/Library/Include/crypto/dso_conf.h等OpenSSL 相关许可证MdeModulePkg/Library/LzmaCustomDecompressLibLZMA SDK见 LZMA-SDK-README.txtOvmfPkg见 OvmfPkg/License.txt5.3 以 git 子模块引入的上游项目及其许可证EDK II 通过 git 子模块方式引入多个上游项目这些项目使用各自独立的许可证与本仓库主许可证无关brotliBaseTools/Source/C/BrotliCompress/brotli、MdeModulePkg/Library/BrotliCustomDecompressLib/brotli压缩算法opensslCryptoPkg/Library/OpensslLib/openssl密码学库mbedtlsCryptoPkg/Library/MbedTlsLib/mbedtls轻量密码学库onigurumaMdeModulePkg/Universal/RegularExpressionDxe/oniguruma正则表达式引擎cmockaUnitTestFrameworkPkg/Library/CmockaLib/cmocka与googletestUnitTestFrameworkPkg/Library/GoogleTestLib/googletest、subhook单元测试与钩子框架janssonRedfishPkg/Library/JsonLib/janssonJSON 库libfdtMdePkg/Library/BaseFdtLib/libfdt扁平设备树库mipisystMdePkg/Library/MipiSysTLib/mipisystMIPI Sys-T 库libspdmSecurityPkg/DeviceSecurity/SpdmLib/libspdmSPDM 设备安全协议实现TPMTcgTpmPkg/Library/TpmLib/TPMTPM 参考实现。这些子模块的完整清单与远端地址记录在仓库根目录的 .gitmodules 中是理解 EDK II 供应链构成的第一手资料。六、子模块管理克隆与更新的标准姿势6.1 获取完整可构建的仓库ReadMe.rst 给出了标准克隆流程注意ReadMe 中使用的是 tianocore 官方地址本镜像仓库同样适用如下操作逻辑git clone https://github.com/tianocore/edk2.git cd edk2 git submodule update --init cd ..6.2 子模块更新流程当上游子模块有更新时cd edk2 git pull git submodule update6.3 关键注意事项不要使用--recursiveReadMe 特别强调克隆子模块仓库时不推荐使用--recursive选项。理由有二EDK II 本身不会使用列出的子模块内部再嵌套的任何代码或功能使用--recursive会引入对我们并不需要其代码的服务器的可达性依赖并白白下载用不到的代码。这一约定能显著减少克隆体积与网络依赖值得所有 EDK II 使用者遵守。七、Package 维护者体系Maintainers.txt 的读取方式ReadMe 指出EDK II 项目由若干 Package 组成每个 Package 的维护者maintainer名单记录在 Maintainers.txt 中。该文件采用类 Linux 内核的get_maintainer格式核心字段含义如下L相关邮件列表默认edk2-devel补丁与问题应发送至此MPackage 维护者负责评审与推送包变更RPackage 评审者协助维护者评审代码但无推送权限W状态/信息网页TSCM 树类型与位置git/svnS状态——Supported有人专职维护、Maintained有人维护、Odd Fixes维护者时间有限、Obsolete已废弃F受维护的文件/目录通配符F: MdeModulePkg/表示含子目录的全部文件F: MdeModulePkg/*仅顶层F: */Pci/*任意深度的 Pci 目录X明确不受维护的排除规则后于 F 规则测试。顶层还列出了 Tianocore StewardsTianoCore 管家名单以及两个当前需要额外维护者的包NetworkPkg与SecurityPkg——这也是社区招募贡献者的活跃信号。八、代码贡献规范从提交信息到 DCO 签署8.1 贡献流程四步走ReadMe.rst 规定向 TianoCore 项目贡献代码需遵循按下方规定格式撰写变更描述change description用于提交日志提交信息必须包含Signed-off-by签名通过项目网页上记载的流程提交代码若流程未记载则提交到项目开发邮件列表优先采用与主项目一致的版权许可证提交若无法一致可接受以下许可Apache License 2.0、BSD2-clause、BSD3-clause、MIT、Python-2.0、Zlib文档类贡献接受 FreeBSD Documentation License进入公有领域的代码也可接受其他许可证可能被接受但需要进一步评审。8.2 Developer Certificate of OriginDCO1.1所有补丁必须包含Signed-off-by行以证明贡献者拥有按指定许可证提交的合法权利。DCO 1.1 的核心认证内容为全文见 ReadMe 原文(a) 贡献全部或部分由本人创作且本人有权按开源许可证提交(b) 贡献基于本人所知处于适当开源许可证下的既有成果本人有权在相同许可证下提交含修改(c) 贡献由其他已认证 (a)/(b)/(c) 的人直接提供且本人未作修改(d) 本人理解并同意项目与贡献是公开的记录含提交的全部个人信息将长期保留并可按本项目或所涉开源许可证的规定再分发。8.3 提交信息格式模板与字段定义ReadMe 给出了标准提交信息样例From: Contributor Name contributorexample.com Subject: [Repository/Branch PATCH] Pkg-Module: Brief-single-line-summary Full-commit-message Signed-off-by: Contributor Name contributorexample.com各字段定义Repository补丁所适用仓库的标识仅当非edk2时提供例如edk2-BuildSpecification或stagingBranch补丁所适用分支标识仅当非edk2/master时提供例如edk2/UDK2015、edk2-BuildSpecification/release/1.27、staging/edk2-testModule受影响代码/文档的短标识例如MdePkg、MdeModulePkg/UsbBusDxe、Introduction或EDK II INF File FormatBrief-single-line-summary变更的简短摘要整个首行应少于约 70 个字符Full-commit-message详述变更的多行说明每行也应少于约 70 个字符Signed-off-by贡献者的真实/法定姓名与邮箱签名。格式说明提交信息首行取自邮件主题中[Repository/Branch PATCH]之后的部分其余内容取自邮件正文git format-patch是生成该格式的一种方式。九、资源与社区入口ReadMe 的 Resources 一节列出了与 EDK II 相关的官方资源入口以下均为项目官方公开资源读者可据此深入了解TianoCore社区主页EDK II 官方 Wiki涵盖规范、教程与工具链说明Getting Started with EDK II新手入门教程Mailing Lists开发者邮件列表补丁与讨论的主要渠道How To Contribute贡献指南Release Planning版本规划与路线图。十、快速自检清单使用本仓库前请确认Python 环境已安装满足 CI 最低版本要求的 Python并已pip install --upgrade -r pip-requirements.txt子模块已执行git submodule update --init切勿加--recursive工具链已按目标平台准备 GCC / VS / CLANGPDB / CLANGDWARF 中的相应工具链平台模拟类构建OvmfPkg/EmulatorPkg还需将 QEMU 加入 PATH构建方式优先使用 Pytools 工作流stuart_setup→stuart_update→stuart_build而非手工 edksetup NASM/iASL 安装贡献礼仪提交信息含Signed-off-by、遵循 DCO 1.1、标题行与正文行控制在 70 字符内、首行采用Pkg-Module: Brief-summary格式已知问题留意 ReadMe 标记的已知缺陷如 EmulatorPkg 在 Ubuntu GCC 下的段错误 TCBZ_2639避开不稳定的工具链组合。通过以上六个维度的梳理你已具备从看懂 EDK II 仓库到本地构建固件再到参与社区贡献的完整知识链路任何一步的细节都可以沿着文中给出的仓库内文档路径.pytool/Readme.md、三个平台的 PlatformCI ReadMe、Maintainers.txt、.gitmodules、License.txt等继续深入。赞分享固件操作系统驱动开发嵌入式【免费下载链接】edk2EDK II项目地址https://gitcode.com/gh_mirrors/ed/edk2点击查看免费下载相关推荐Synergy 仓库 AI 协作开发规范全解析构建纪律、CI 矩阵陷阱与 Deskflow 上游回移策略Synergy 仓库 AI 协作开发规范全解析构建纪律、CI 矩阵陷阱与 Deskflow 上游回移策略 本指南以 Synergy 仓库根目录下的协作笔记C桌面应用网络通信agentic-awesome-skills 实战基于 Rube MCPComposio的 Canva 设计自动化全流程指南agentic awesome skills 实战基于 Rube MCPComposio的 Canva 设计自动化全流程指南 导读 本文以 agenticAI 技能AI 插件guidance 仓库贡献开发指南开发环境搭建、测试矩阵扩展与 Ruff 代码规范guidance 仓库贡献开发指南开发环境搭建、测试矩阵扩展与 Ruff 代码规范 本指南面向希望向 guidance 仓库提交代码、新增模型测试或参与维护的大模型提示工程AI Agent上一篇如何用 bilibili-downloader 免费下载 B 站 4K 视频新手零门槛完整教程下一篇鼠标增强工具Mac Mouse Fix完全指南三步告别生硬滚动与闲置侧键创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考