为什么RISC-V需要引入UEFI？何时引入？UEFI on RISC-V的主要问题、现状和未来展望
最近，杂志The Register对RISC-V International CEO Calista Redmond进行了一次采访【1】 。在访谈中，Redmond的一个判断很有意思，他认为RISC-V对Intel可能不会构成威胁（Intel也加入了RISC-V社群），但对ARM则会形成直接威胁。他这个观点我深以为然，如果我们观察RISC-V的发展路径，就会发现它和ARM曾经的路线十分相似，都是从低端向高端进攻。我们可以说，ARM的今天就是RISC-V的明天。只不过这一次RISC-V带着免费的光环，发展更加迅猛。
鉴于这几年美国的技术霸权和封锁，中美两国技术硬脱钩的风险越来越高。RISC-V的开源和开放，让它在国内拥有了无与伦比的魅力，发展十分迅猛，行业大佬（华为、阿里等）和各种初创公司在CPU、DPU、IPU、MCU等各种U上百花齐放，可谓烈火烹油。在这花团锦簇中，作为BIOS/UEFI固件的从业者，我经常被问到对UEFI在RISC-V上的应用怎么看？
其实，我们可以参照UEFI在ARM上的发生和发展，来预测未来UEFI在RISC-V系统中的未来趋势。可以说，UEFI on RISC-V面临的问题和挑战，和十几年的ARM几乎一样。相信未来也会殊途同归，只不过这次转变将更加迅速。
RISC-V需不需要引入UEFI？
答案是肯定的，只不过在目前迫切性并不强：
现阶段，RISC-V因为性能问题，专注嵌入式领域。在这里，方案多采用垂直整合的方式，由最终产品厂家整合系统中所有软硬件，而轻量级和简单的U-Boot在这种场合下，投入产出比最大，是首选。现在，RISC-V需要解决的首要问题是生存问题。
未来一旦RISC-V性能提高（只是时间问题），将不可避免地将进入消费品领域（台式机或者笔电）甚至是服务器领域。那时，RISC-V CPU将要和ARM一样，面对一个成熟的、分散的、玩家众多的和重度依赖生态的市场。届时RISC-V CPU将只是生态中的一环，如何将其作为一个标准件产品交付，从而和既有的玩家一起愉快地玩耍，则是一个必须解决的问题。它的出路也将和ARM类似，只有采用UEFI。为什么这么说呢？
UEFI可以带来诸多收益：
收益一，标准化：UEFI标准化了固件接口和启动过程，让固件间的互操作标准化和模块化，从而硬件和固件各个部分可以分别交付和互动，可以形成各自标准件产品。这是现在消费品和服务器领域业态选择的必由之路。
收益二，抽象硬件：UEFI抽象了芯片、板卡等计算资源、存储资源和IO资源，从而操作系统等中上层软件不需要修改就可以到处运行。UEFI是OS形成标准件产品的必要条件。
收益三，生态：传统消费品和服务器领域积攒了大量硬件和软件资源。接纳UEFI可以为初生的RISC-V解决软硬件配套缺乏问题。指令集兼容问题可以参考ARM的短期和长期方案。
既然RISC-V必将拥抱UEFI，那么现在UEFI对RISC-V的支持状态如何呢？
UEFI on RISC-V现状
现状用一句话来说就是：内核已经基本支持，平台很少，生态匮乏。
如图，我们从UEFI生态的三个层级分别来看一下：
UEFI SPEC & EDK2内核：如果你打开最新的UEFI和PI Spec会发现，RISC-V架构、ABI（应用程序二进制接口 ）等基础定义已经加入。如此同时，EDK2内核TianoCore中 RISC-V相关支持已经进入。可以说从内核和SPEC层面来看，RISC-V已经基本完成，只是尚需完善。
硬件平台支持：尽管RISC-V平台不多，但也有数款硬件平台和虚拟平台【2】已经支持UEFI启动，还有更多RISC-V平台在陆续增加中：
来源：参考资料2
外围软硬件：目前在RISC-V上通过UEFI启动Linux Kernel已经适配完成，还需要继续完善。板卡的native代码则还需要继续努力。
结论
UEFI社区已经准备好了对RISC-V的基本支持，现在由于需求不足，开发活动并不算活跃。可以预测，随着RISC-V CPU性能的提高和各个玩家进入通用市场，UEFI的支持也必将和现在ARM UEFI社群的开发一样火热。
参考资料
[1] RISC-V CEO Interview：https://www.theregister.com/2022/05/07/riscv_ceo_seeks_world_domination/
[2] RISC UEFI:
https://github.com/riscv-admin/riscv-uefi-edk2-docs