BIOSer必读：Intel的下一代BIOS标准USF 国产芯片爆发，Intel和AMD激烈竞争，新品不断。各位BIOSer想必在过去的2021年，忙得前脚打后脚，同时又收获着大笔奖金或者新Offer，痛并快乐着。大家别光急着赶路，也要偶尔停下来看看脚下的路将我们引向何方，那里的风景又如何呢？ 诞生于1990年代末的UEFI到现在已有20多岁高龄，作为它的发明者、引领者和主要受益者，Intel的一举一动对UEFI或者说BIOS都影响巨大。2019年，Intel在OpenSource大会上宣布开始发力Next Generation Firmware（NGFW）。尽管在过去的两年多的时间进展有些缓慢，但工作仍在继续，且因为云服务厂商（CSP）的强烈需求，路线也愈发清晰。近期，Intel在官网[1]宣布该技术的最新官方名字：Universal Scalable Firmware (USF)。USF也喜提了自己独立的官网[2]。本专栏写了大量下一代BIOS标准的文字，那么这个USF和他们什么关系呢？这是我们今天需要一起讨论的问题，在我们开始今天的探索之旅前，如果大家错过了或者忘记了前面的相关内容，推荐复习一下相关下面几篇文章，对理解后面的介绍会有所帮助：https://zhuanlan.zhihu.com/p/https://zhuanlan.zhihu.com/p/https://zhuanlan.zhihu.com/p/https://zhuanlan.zhihu.com/p/https://zhuanlan.zhihu.com/p/https://zhuanlan.zhihu.com/p/https://zhuanlan.zhihu.com/p/ USF是什么？ USF的名字是Universal Scalable Firmware，起名具有Intel起名的一贯特点：好像说了什么，又好像什么都没说，总之感觉很牛的样子。为了一探究竟，我们还是从系统框图看起：
来源：参考资料2 图中包含了非常多的内容，这桌大餐尽管让人眼花缭乱，但如果我们细细看来，其中的大多数菜品确是非常熟悉的。如经典的韩式晚餐，在几十种泡菜的簇拥下，核心的内容总是那么几样。而这些知识点我们几乎都介绍过，这也是我让大家复习一下前面的知识点的原因。 框架中，通过将UEFI和它的唯一参考实现TianoCore，仅仅置于一隅的方式，传递了一个清晰的声音：那就是站在芯片厂商的立场上，Intel已经不再站队UEFI了，而是将UEFI、CoreBoot、SLB和uBoot同等对待，他们仅仅都是各种BootLoader的一种而已。Intel只关心芯片的初始化，并为平台提供标准接口而已，置于厂家选择哪种BootLoader，则各花入各眼了。个人理解，这也是芯片厂商的无奈之举，在CSPs这些强大甲方的重压下，产品竞争力减弱的Intel也只有从了。 图中还有颇多亮点，如我讲过的IP FW，FSP的升级版sFSP等。这些知识点相当重要，我们还是逐个看看他们。 IP FW IP FW是IP的固件Firmware。CPU SOC可以看做一个大框子（Chassis），它由许许多多IP（单独具有知识产权的模块）经过布局（Floorplan）布线组合，再加上Chassis的dfx、efuse、power和时钟逻辑等等组成。这些IP有的需要带内驱动，也就是需要Core来驱动，有些则自己带有MCU或者复杂的逻辑电路，从而需要自己的固件驱动。这些需要Core来驱动的IP，如CPU中的数个内存控制器（IMC），数个PCIe Root Complex，QPI控制器等等。过去它们大都是死IP，也就是没有自己的固件，需要BIOS这个最大的固件来一个个填寄存器，驱动它们运行。而自带MCU的IP可以理解是自洽的活IP，如CPU中的PCU，需要自己的FW。这些固件往往是单独开发的，它们之间或它们和BIOS之间往往通过简单的MailBox进行沟通：
CPU和PCH中的活IP越来越多，它们大部分都被打包在最后的IFWI中，和BIOS一起发布。 死IP有什么问题呢？主要问题是验证周期长，因为需要Core来驱动，IP在整合到SOC前没有经过充分功能验证，只有单验证，导致SOC验证周期反馈链条过长，从而延缓产品上市。死IP接口没有标准化，尽管也有带外sideband的方式，但效率不高，带内管理为主，从而导致功能设计复杂，自洽性低等。 死IP向活IP的转移是个趋势，近期也被现代待机、精细电源管理的需求加速。但遗憾的是，从框图看起来，IP FW是被包含在sFSP中，而不是在IFWI中，意味着此处IP FW是IP代码模块化而已。 sFSP FSP的内容我就不赘述了，大家可以参考这篇文章：https://zhuanlan.zhihu.com/p/ 注意成文较早，那时候还只有FSP API mode，后期加上了FSP dispatch mode。现在往往一个FSP binary，可以支持两者模式，而选择权力由平台通过改变PCD来控制。详细内容可以在我的云课堂中学习。 作为FSP的升级版，sFSP带来了两个新亮点： 1：64bit reset。说到这里，我要问大家两个问题：为什么CPU启动一定要到实模式？为什么现在的64位BIOS都要在32位的PEI那里转一圈？天下苦秦久矣！64bit reset和后面的Flat Memory at reset一起吹响了割掉鞭子的号角，它的详细内容等内容解密了我们再详谈。 2：SMM in FSP。什么技术原因阻止了CoreBoot、LinuxBoot等在服务器BIOS中的应用？是RAS。没有RAS的服务器是不可用的，不完整的。因为RAS牵扯到很多Runtime而不是Boot time管理，现在大部分都是SMM模块来完成。如果需要让CoreBoot等方案的服务器也具有RAS功能，要不就是OOBRAS（带外RAS），要不就将SMM 模块整合到FSP中。而框图中就是第二种选择的情形。注意字节跳动的方案两者都不是，它的内容我们今后我们单独讲。 Payload USF对传统UEFI OS的支持通过UEFI payload来进行：
来源：参考资料2 这里注意有些资料将LinuxBoot归入payload中，也有CSP厂商确实这样用，但其实LinuxBoot完全可以自己当BootLoader，我不能认同这种矮化的归类方法。 其他 还有一些亮点，如YAML这种Bootloader中立的配置库，和各层的API接口定义。大家如果感兴趣可以自行查阅参考资料（尽管现在资料很少，而且现阶段这些资料很可能将来会修改）。 总结 有天吃饭，一位同事问我，说我总在发下一代BIOS标准，是不是马上BIOSer就没饭吃了，UEFI马上就过期作废了？是啊，红旗能打多久呢？这关乎大家的饭碗，也是个严肃的问题。 我这里给个定心丸。UEFI不会马上完蛋，至少在这三年之内，这些竞争对手还在追赶和添加功能，UEFI的完备功能短时间还不能被替代。某种程度上，其实恰恰相反，短期内BIOSer又有了一块“新”工作，就是做LinuxBoot、CoreBoot等，工作内容不降反增，饭碗更稳了。长期来看，毕竟BIOS的传统是相当大的，完全可以容纳这些新朋友，让他们也成为广义BIOS的一部分，就像曾经的UEFI那样。Long Live BIOS! 话说回来，用个我女儿老师常用语言：“学有余力的同学”可以抽空学习一下Coreboot和LinuxBoot，做好准备。而各个公司也应该进行一些相关技术储备，以备不时之需。 欢迎大家本专栏和用扫描下方二维码加入”UEFIBlog”，在那里有最新的文章。，留言“资料”，有一些公开芯片资料供下载。
2024最新激活全家桶教程，稳定运行到2099年，请移步至置顶文章：https://sigusoft.com/99576.html
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。 文章由激活谷谷主-小谷整理,转载请注明出处：https://sigusoft.com/57366.html
