5月28日，全球计算联盟(GCC)正式发布《统一基本输入输出系统(UBIOS)接口规范》。该标准与2025年发布的《统一基本输入输出系(UBIOS)基础架构规范》相配套，分别定义了框架和接口。此标准的发布标志着UBIOS系列标准已基本完善。欢迎访问GCC官网成果发布专区，下载UBIOS系列标准！(文末附下载链接）

去年10月，UBIOS的架构规范《统一基本输入输出系统（UBIOS）基础架构规范》发布，开启了自主固件生态标准的第一步。

拓展阅读：中国BIOS新标准：UBIOS标准正式发布！为什么发明它？它有哪些亮点？

在架构规范中，我们看到的是一个充满想象力的Unified Bus概念 —— 通过统一虚拟总线（UVB）打破传统BIOS内部、BIOS与OS、BIOS与外设之间的交互壁垒，为异构计算时代的固件交互提供了一套全新的解决方案。如果说去年的架构规范是UBIOS的"骨架"，那么这次的接口规范就是UBIOS的 "神经脉络"。它让那个抽象的架构有了具体的交互语言，也让UBIOS从一个概念性的标准，向可落地的技术方案迈出了关键一步，可以看作是UBIOS体系从“概念架构”逐渐进入“工程实现”的一个重要阶段。

从架构到接口：UBIOS 的完整技术拼图

回顾去年发布的UBIOS基础架构规范，其核心创新在于提出了 ：统一虚拟总线（UVB）的概念。传统BIOS架构中，不同组件之间的交互方式五花八门：BIOS内部各模块通过Protocol调用直接交互，BIOS与OS通过ACPI、SMBIOS表和运行时服务交互，BIOS与BMC通过IPMI、RedFish等专有协议交互，BIOS与外设则通过各种硬件总线交互一些私有协议。这种碎片化的交互方式不仅增加了固件开发的复杂度，也限制了异构计算系统的扩展性。

UBIOS架构通过UVB这一软件抽象层，将所有底层物理通信通道（ISA调用、共享内存、IPMI 等）统一封装起来。所有组件——主系统固件、子系统固件、BMC 固件、设备固件甚至操作系统——都通过相同的UVB接口进行通信。组件之间不再需要关心对方的硬件实现细节，只需要知道对方提供的功能标识（Function ID）和信息标识（Information ID）即可完成交互。

来源：参考资料1

   而这次发布的接口规范，正是对UVB总线上传输的 "内容" 进行了标准化定义。在UBIOS接口的两种基本形式中填入了具体核心接口：

• Call ID Service（CIS）：双向的功能调用接口，支持同步和异步两种模式。调用方通过指定 Call ID 发起功能请求，被调用方执行后返回结果。这次细化公布了系统接口、网络接口、文件系统接口的细节。

• Notify ID Information（NII）：单向的信息上报接口。当BIOS或外设检测到硬件故障等事件时，通过NII主动向OS或BMC上报信息。这次定义了系统RAS、Core RAS、DDR RAS等硬件故障信息的上报格式。

这些接口的定义，使得不同厂商开发的UBIOS组件之间有了统一的 "对话语言"。理论上，只要遵循UBIOS接口规范，任何厂商的BIOS固件都可以与任何厂商的BMC固件、设备固件无缝交互，这正是UBIOS"统一" 理念的核心体现。

   客观看待UBIOS与UEFI的对比与差距

在肯定UBIOS创新价值的同时，我们也必须客观地认识到，作为一个刚刚起步的标准，UBIOS与已经发展了二十多年的UEFI标准相比，还存在着明显的差距。首先，内容体量和覆盖范围上的差距是显而易见的。UEFI标准是一个庞大而完整的体系，它不仅包含了架构规范和接口规范，还详细定义了启动流程、驱动模型、安全机制、配置管理、固件更新等几乎所有固件相关的内容。最新的UEFI 2.10标准有超过2000页的篇幅，而UBIOS目前发布的两个规范加起来也只有不到100 页。

  这种内容偏少的情况，与UBIOS处于发展初期的阶段特征是完全相符的。UEFI从1998年的Intel Boot Initiative（IBI）开始，经历了EFI 1.0、UEFI 2.0等多个版本的迭代，用了二十多年的时间才逐步完善到今天的程度。UBIOS从2025 年年底发布第一个架构规范到现在，才刚刚走过一年的时间，我们不能期望它在这么短的时间内就达到UEFI的成熟度。如果读者曾经看过EFI 0.8版本的Spec，就不会对UBIOS规范现在的体量大惊小怪了。

其次，UEFI标准实际上是架构规范和接口规范的整合体，而UBIOS则采用了分阶段发布的策略。UEFI标准在一个文档中同时定义了整体架构和所有接口细节，开发者可以通过一个标准文档了解UEFI的全部内容。而UBIOS则将架构和接口分成了两个独立的规范分别发布，未来可能还会发布更多的专项规范（如安全规范、驱动规范等）。这种分阶段的发布策略虽然可以让标准更快地推出，但也增加了开发者学习和使用的成本。当然，未来也可能会整合成一个一站式规范。

第三，生态系统的成熟度是UBIOS与UEFI之间最大的差距。UEFI之所以能够成为今天的行业标准，很大程度上得益于其完善的生态系统。从EDK到EDK II，作为 UEFI规范的开源参考实现，已经被几乎所有的BIOS厂商和芯片厂商采用。它提供了完整的固件开发框架、丰富的驱动程序和工具链，支持x86、ARM、MIPS、LoongArch、RISC-V等多种处理器架构，并且已经在数十亿台设备上得到了验证。

而UBIOS目前还没有公开的开源参考实现。虽然接口规范已经定义了各种接口的格式和功能，但开发者还没有一个可以直接使用的代码框架来实现这些接口。这意味着任何想要尝试UBIOS的厂商，都需要从零开始编写自己的UBIOS实现，这无疑会大大增加UBIOS的落地难度。

展望UBIOS的未来

    那么，UBIOS接下来应该如何发展，才能真正实现其 "统一基本输入输出系统" 的目标呢？我认为，尽快开源一个高质量的参考内核实现，是UBIOS当前最紧迫、最重要的任务。
    就像EDK和EDK II对于UEFI的意义一样，一个好的参考实现可以起到事半功倍的效果。它不仅可以大大降低厂商的开发门槛，让更多的厂商能够快速参与到 UBIOS的生态建设中来，还可以作为标准的 "活文档"，帮助开发者更好地理解和遵循UBIOS规范。

• 模块化设计：采用与UBIOS架构一致的分层设计，将信息交互层和功能接口层清晰分离
• 跨平台支持：能够在x86、ARM、RISC-V 等多种主流处理器架构上运行
• 可扩展性：提供简单易用的接口，方便厂商添加自己的功能模块
• 开源许可：采用宽松的开源许可（如BSD、MIT），允许厂商在商业产品中自由使用

欢迎访问GCC官网（www.gccorg.com）成果发布专区，下载《统一基本输入输出系统（UBIOS）接口规范》及系列标准，共同参与UBIOS生态建设！

  图一 扫码下载UBIOS基础架构规范       

  图二 扫码下载UBIOS接口规范