作者 | 鲁冬雪
近日,字节跳动、英特尔、OCP-OSF、OSFF 社区联合举办的云固件沙龙交流会暨产品发布会顺利落地,在此次活动上,字节跳动正式发布新一代云固件 Cloud Firmware 2.0,这标志着 X86 服务器中产品化 coreboot 的固件解决方案在业界首次完成落地。
据悉,字节跳动历经两次次迭代,云固件 Cloud Firmware 的 LinuxBoot 和 coreboot 快速完成产品化。在整个研发过程中,英特尔为其提供了可生产级别的 FSP,同时帮助字节完成云固件的服务器平台开发工作,大大缩短了其上线时间。
1 云固件的发展为什么离不开芯片厂商?
作为电子硬件系统中最底层的软件,固件负责对硬件进行初始化后供上层操作系统和应用软件使用,BIOS 是服务器领域里最重要的固件。一直以来,UEFI 固件很多功能模块由 BIOS 厂商把控,而绝大多数系统厂商都采用的又都是 BIOS 厂商的解决方案,众多功能 / 核心模块掌控在 BIOS 厂商手里,线上问题无法快速解决,同时还存在用户、芯片厂商、系统厂商无法保持代码同步的问题。如果能够将这些问题妥善解决,那云厂商的硬件研发及运维成本便可大幅降低。
目前,云厂商拥有的 Linux 开发工程师要比 UEFI 开发工程师多得多,而且 UEFI 代码既复杂又几乎闭源。所以,云厂商期望把更多的功能从传统的固件中迁移到基于 Linux 的开源固件中来,以此打造自身技术优势并推动产业向前发展。同时希望通过使用自己的开发人员解决线上问题以此来缩短故障解决的周期,把“开发具备自身特色的功能”作为长期目标。
基于云厂商这些需求,代码效率高、学习成本更低、代码模块化程度高的“云固件”应时而生。在云厂商驱动的白盒开发模型中,底层硬件初始化采用芯片厂商提供的 FSP(Firmware Support Package 芯片固件支持包),云厂商可以便捷地进行平台开发;在中间层,选型一个开源的、稳定的、精简的、通用的 BootLoader 黏结芯片固件支持包和 OS Payload;在最上层,选型一个开源的、高度自由的、定制的 OS Payload,方便 CSP 根据数据中心的应用管理需求完成个性化定制。
从全球情况来看,这种固件开发模式变得越来越重要,现在很多机器的 BIOS 都已经是基于这种 open 的快捷开发模式。所以,与其说是云固件的发展离不开芯片厂商,不如说是云厂商对于固件的需求离不开芯片厂商的底层支持。
目前英特尔固件支持包(Intel® Firmware Support Package,简称为 Intel® FSP)是该领域技术成熟度比较高的产品,Intel® FSP 是由英特尔公司为支持其 X86 平台的芯片而发布的二进制格式文件,因为是二进制文件 Binary,不会透露什么商业机密,所以解决了 open 开发模式中芯片厂商知识产权的安全问题。简单来说就是英特尔把芯片初始化代码封装成二进制文件,客户不需要知道里面做了什么,只需进行调用即可。而这也是英特尔 USF 一直关心和在持续努力推动的方向——只关心芯片初始化,一心为平台提供标准接口。经过几代产品的迭代,具有高成熟度产品化的它已经在字节跳动云固件 Cloud Firmware 中完美呈现出来。
2 Intel ® FSP 赋能字节两步完成 Cloud Firmware 产品化
在固件领域,LinuxBoot 将 Linux 作为固件的一部分的解决方案,可以很好地利用成熟的 Linux 模块解决传统固件驱动存在的不稳定性问题。于是,字节跳动一直打算将 Linux 下沉到固件。字节跳动 2021 年在英特尔、OCP-Open System Firmware 社区的支持下,全球首发的云固件 Cloud Firmware 1.0 成功地实现了服务器 LinuxBoot 产品化落地,一时之间引起众多行业人员关注。它基于 FSP Dispatch Mode + Minimal BIOS + LinuxBoot,精简了传统固件方案,将一些功能移至生态更佳的 LinuxBoot 里实现。而近日字节跳动发布的新一代固件解决方案 Cloud Firmware 2.0 则重新定义了服务器系统固件架构,打破了传统固件技术方案的局限性,彻底去除 UEFI,全面引入了 Linux 生态的 coreboot,是全球第一个在 X86 服务器中产品化 coreboot 的固件解决方案。目前 Cloud Firmware 2. 首批套餐已完成生产,字节跳动计划在今年上线数万颗 CPU 以上规模。为了支持 Cloud Firmware 2.0 的上线,英特尔开发了多个 RAS 和 Flash 更新功能帮助字节和各 ODM 解决了 RAS、固件升级、双路 CPU 支持这三个领域中的核心问题。
通过对 Eagle Stream 板的多重协同验证,使得英特尔和字节跳动实现了共赢。一方面,Intel® FSP 完成了从 Dispath Mode 到 API Mode 的进化,可拓展性大幅度提升;另一方面,英特尔帮助字节完成了 coreboot 支持服务器的各项功能,使得 coreboot 这一 BootLoader 首次在服务器上完成生产。
此外,Intel® FSP 的易开发性加之英特尔强大的核心交付能力,使其提前向字节跳动高质量交付了 FSP-API BKC;与此同时,英特尔一直活跃在 coreboot 社区,从服务器 coreboot 角度向 coreboot 社区贡献了数十个补丁,这些补丁主要集中在支持双路服务器,服务器可靠性、稳定性以及可维护性等方面。
在 Silicon Code 层面,Intel® FSP 由调度模式过渡到了 API 模式。以往客户需要事先拿到 Silicon Code,之后将其编译集成到整个 Firmware 代码库中。而如今的 API 模式让“随插随用”在固件开发中成为可能,同时解决了 Silicon Code 的集成效率问题。客户在不修改 Silicon Code 的前提下,可以针对不同业务场景进行配置进而实现不同的特点。Intel® FSP 作为一个包含所有 Silicon Code 的包,更符合 OCP 原则的 API 模式使得其在 Silicon 特性可配置性方面表现出了优越性。
从平台应用方面,Cloud Firmware1.0 应用在了 Whitley 平台上,而 Cloud Firmware 2.0 应用在了 Eagle Stream 平台上。这个迭代过程的背后,也体现出了 Intel® FSP 的升级过程,其表现出了相当不错的特性。在 BootLoader 层面,从之前 EDK2 精简版的 MinPlatform(Cloud Firmware 1.0)切换到了 coreboot(Cloud Firmware 2.0)。在 Cloud Firmware 1.0 的实践中,最重要的就是使得 LinuxBoot 这样一个开源方案达到了产品级别,在 Cloud Firmware 2.0 中直接复用了 Cloud Firmware 1.0 中的 LinuxBoot,包括基于 LinuxBoot 配套的相关工具链。总之,目前 Cloud Firmware 2.0 大大缩短了开发集成周期,大大降低了开发难度,减轻开发人员成本。
值得一提的是,Cloud Firmware 2.0 包括 FSP API、coreboot 和 LinuxBoot 三大部分,在这种方案中,Intel® FSP 和 LinuxBoot 都是直接由 coreboot 来集成到最终的可用固件,这也使得 Silicon Code 和 Platform Code 实现了解耦,使像 EGS 这样复杂的系统能够根据客户的需求进行定制。换言之,对于 Silicon 特性的定制,客户可以通过 UPD 对 Intel® FSP 进行客制化的配置,对于平台端的定制,客户可以将这个部分转化为基于 LinuxBoot 的 APP,这也打破了传统 Monolithic Firmware 模式,实现从固件端更好地配合芯片 Chiplet 和平台端 Reusable Compute Block 的理念。
迭代后的 Cloud Firmware 2.0,搭载第四代英特尔®至强®可扩展处理器(代号:Sapphire Rapids),技术数据显著提升。相关数据显示,火山引擎基于第四代英特尔® 至强® 可扩展处理器的第三代弹性计算实例,相比上一代整机算力提高了 70%,单核算力提高了 18%,网络转发性能提高 2 倍,存储 IOPS 性能提高 2.3 倍,加解密性能提高 1 倍,AI 推理加速性能提高 2.2 倍。
据悉,第四代英特尔® 至强® 可扩展处理器采用了英特尔最新的 Intel 7 制程技术,带来了更高的能耗比,与前一代处理器相比,其通过内置加速器将目标工作负载的平均每瓦性能提升了 2.9 倍,在优化电源模式下每个 CPU 节能高达 70 瓦,且性能没有显著下降情况,用户的总体拥有成本可降低 52%-66%。Sapphire Rapids 最高可以提供 80 个 PCIe 5.0 通道,支持 1.5TB 的 DDR5-4800 内存,为高性能计算带来了庞大的存储容量。
3 英特尔 USF 推动云固件高速发展
除了帮助字节跳动完成云固件的改造,事实上,英特尔一直在关注下一代固件技术的演进。
在云厂商的强烈需求下,2019 年英特尔就开始发力 Universal Scalable Firmware(USF)标准的建设,它建立在 UEFI 和 ACPI 等现有行业标准之上,既可以降低固件开发的复杂性,又可以跨 CPU 和 XPU 进行拓展。目前已知标准中的功能及组件涵盖了可跨不同操作系统和 BootLoader 工作的通用 Payload,具有简化的 ACPI 支持、Rust 编程语言接口、YAML 配置及 SoC FSP 等,有效提升了固件的质量和安全性。
对行业而言,降低固件开发成本, 同时提升固件质量和安全性、以及推动固件领域的其它创新。得益于代码复用和易于集成的特性,开发人员可以专注于创新和部署新功能,有利于推动技术迭代。
整体来说,英特尔对外传达出了一个明确的信息:“将 UEFI、coreboot、SLB 和 U-boot 同等对待,均视为 BootLoader 的一种,英特尔更关心芯片的初始化,为平台提供标准化接口。”而这也直接促就了云固件的发展。至今英特尔也有了不少的成功案例,比如由 Intel® FSP、Slim BootLoader、基于裁剪后 Linux 的 RTOS 三者共同构成的板载固件方案等。
当前,业内还只是部分云厂商参与到了云固件生产领域的开发和探索中,有云固件改造需求的云厂商的核心诉求其实也很简单,就是需要一个稳定的、可拓展的、可生产的 FSP,以及能够适配各种形态的 BootLoader。
目前来看,英特尔在该方面一直持续发力。经过几代 CPU 的迭代,Intel® FSP 已经非常稳定,并且具备支持云固件产品化需求的能力。Intel® FSP 和 Open BMC 目标统一,持续致力于推广聚焦于 Silicon Enabling 的固件解决方案,助力并影响固件开源社区的发展。
积土成山,风雨兴焉。Intel® FSP 最新的规格说明书目前已经升级到 V2.4 版本。据悉,英特尔的研发团队将按照最新的规格说明书在下一代做对应的升级动作。其中最大的改变在于会将对 RAS 的支持从 coreboot 调整到 FSP 中。英特尔将会陆续在 FSP 里集成云固件需要的各方面能力,以便在下一代产品中推动更多的云厂商加入,让云厂商的开发和生产变得简单便捷,比如上一代发现的 feature gap 以及对配置的升级等都会做到 Intel® FSP 中,让其更加适配客户应用。
总之,技术演进进行得如火如荼的云固件,值得我们期待,而英特尔 USF 作为推动云固件技术演进的催化剂,也非常值得我们期待。