|
时间回到2011年，Intel Fellow（Intel院士）马克·多兰（Mark Doran）在西雅图搭上飞往旧金山的飞机，兴致勃勃的试图去说服Google在即将推出的x86网络笔记本（后来的Chromebook）中继续使用UEFI标准固件。此时的他应该不会想到，这次说服工作没有成功，而随后Google全面倒向coreboot，极大地改变了x86固件的版图。 尽管Intel和微软的网络本都销声匿迹了，Chromebook在未推出前也不被看好。但Google又一次证明了自己，Chromebook在北美学生市场大受欢迎。因为大家都知道的原因，Chromebook在中国几乎无人购买，无法使用，但在其他市场却颇受学生欢迎。受新冠肺炎疫情影响，工作方式与教育形态出现转变，2020年第二季Chromebook笔记本的出货规模增至1,160万台，不但创下单季新高，占全球整体笔记本的出货比重更是史上首次来到25%！对BIOS市场来讲，UEFI BIOS占固件市场比重又一次大幅下滑！ Google不愿意接受UEFI作为Chromebook固件的原因，除了对UEFI固件背后另一个大佬微软的敌视和警惕，而它对coreboot的Linux编程风格更熟悉外，还有一个原因。当时ARM对UEFI的支持度不太好，而Google希望保留用ARM做Chromebook的一个选项（实际上它现在也这么做了），而选用coreboot则能同时解决这三个问题。那么，什么是coreboot，它从哪来，又向哪去呢？ coreboot的由来  coreboot源自LinuxBIOS（注意区别我们将来要讲的LinuxBoot）。1999年，洛斯阿拉莫斯（Los Alamos ）美国州立实验室的Ron Minnich想用很多x86的主板攒出一个Cluster服务器。但他不懂当时的传统BIOS，也不想懂。他觉得Linux自己就有很多设备的驱动，为什么还要在BIOS里面做一遍呢？他用了20多行汇编完成了简单的初始化（内存初始化就几行汇编搞定），将Flash中的Linux拷贝到内存中，直接跳到Linux，就这样打完收工！ 这20多行汇编和Flash中的Linux就可以替代传统BIOS，多么简洁，LinuxBIOS v1诞生了。这也是LinuxBIOS名字的来源：Linux is the BIOS。在v1的基础上，Ron和他的同事们开始加入更多的硬件CPU支持：Alpha、PPC；同时因为DDR内存的引入，内存需要大量的初始化工作要做，20多行汇编远远不够了，甚至需要支持c语言；支持更多外围设备也带来很多问题，实际上，Linux从零开始初始化硬件的能力完全不足，需要在LinuxBIOS里面初始化PCI的BAR等等琐碎的事情。他们从两方面对v1 LinuxBIOS进行了扩展： 1.采用了一种叫做ROMCC的办法来在支持c语言，调用c语言函数就可以完成更多的功能，也有更多现成的代码可以参考。 2.引入LinuxBIOS Device Tree。 这些改动加上网络boot等Payload，和更多的硬件支持，构成了LinuxBIOS v2。Ron在他的一篇讲稿详细描述了当时的窘境和对策[1]。 时间到了2005年，LinuxBIOS用Intel Cache As RAM （CAR）技术替代了ROMCC，并加入了AMD64支持。支持的主板也从十来块扩张到数百块，构成了LinuxBIOS v3，它发布给了众多商业用户，但因为稳定性受到一定诟病。 到了2008年，发生了一件转折性的事件，那就是LinuxBIOS改名coreboot，个中缘由Ron在一篇发给社群的邮件中有详细描述[2]。简单来说就是LinuxBIOS的名字随着它代码和payload的发展慢慢得变得不合时宜： LinuxBIOS = 简单的core boot程序 + Linux 慢慢的，这些core boot程序变得越来越大，和后面的Linux越来越独立。Linux变得只是众多选择中的一个，越来越像一个payload；其他的payload包括： BIOS ROM = (LinuxBIOS) + (Open Firmware) 再叫LinuxBIOS会造成误解和疑惑。于是受core boot code这个名字启发，LinuxBIOS正式改名coreboot。 LinuxBIOS/coreboot一直是电脑爱好者和某些定制用户的玩具，很少有大型商业用户敢于用它。时间到了2011，随着Google全面倒向coreboot，coreboot开始从角落转向主流商业，于是发生了本文开头那一幕。Google凭借其巨大的影响力和商业价值，力压Intel支持coreboot，毕竟复杂和众多的Intel芯片组，由第三方来初始化是不现实的，而Intel当时只支持用纯UEFI来初始化Intel的硬件。这个芯片组初始化的功能应该而且只能由Intel来提供，它应该是BootLoader无关的，甚至最好是个二进制包，如此既可以打消Intel机密泄露的顾虑，也简化了设计（实际上关心具体实现方法的人也不多）。如此指导思想下，Intel BIOS组和coreboot社区一起商定了coreboot和Intel芯片初始化代码的接口，这就诞生了固件支持包（Intel® Firmware Support Package，简称为Intel® FSP）第一代雏形，并发布了相关Spec。需要特别指出的是，coreboot在支持FSP之前，就已经支持了AMD的AMD Generic Encapsulated Software Architecture (AGESA)。关于FSP的简介，可以参考我的这篇文字： X86生态圈为什么在物联网玩不转？什么是Intel® FSP ？它能解决什么问题？ 公平而论，coreboot设计简单，入门门槛较低。随着Intel开始探索IOT市场，coreboot上手容易的特点也成为了Intel支持IOT用户的一个选项： Intel IOT firmware = coreboot + FSP 另一个选项则是今后我们要介绍的SBL（Slim BootLoader）。 coreboot技术简介 coreboot的文档十分完备[3]，它的执行周期如我在这篇颇受欢迎的文章中： 所描述一样，和UEFI BIOS甚至传统BIOS来讲，没有本质区别。都是先由一段在Flash上运行的代码来初始化内存等必要硬件，叫做ROM Stage；后面一段在内存初始化好了，进行一些更复杂的操作，叫做RAM stage。UEFI两个分别是PEI和DXE（并不是100%准确），coreboot分别是ramstage/romstage。下面这个图比较形象的对比了两者的区别：  来源：参考资料3 |
|
|
