RISC-V UEFI 生态现状如何？赛昉星光开发板上手实例，和 UEFI 生态短板修补神器：MultiArchUefiPkg
原版的x86Emulator仅支持在ARM的AARCH64（64位ARM ISA）上模拟x64的内容，不支持RISC-V。Intel的工程师将它移植到RISC-V上，支持仿真x86，甚至是AARCH64的环境来驱动x86或者是ARM的UEFI驱动。它的技术细节不变和x86Emulator一样，这里不再赘述。我们需要将MultiArchUefiPkg移植到VisionFive2上即可。VisionFive2要用市面上已有的显卡，需要PCIe x16的插槽，这在小小的单板上当然是不可能提供的。所幸VisionFive2为了支持M.2 NvME，提供M.2接口的PCIe插座，我们只需要在某宝上购买一个M.2转PCIe x16的转接卡即可。我们共试验了两款显卡，一块A卡W330亮机卡，一块N卡。其中A卡非常顺利点亮，它只有x86的UEFI GOP驱动，这也证明这种用MultiArchUefiPkg来解决UEFI生态的可行性。而N卡则产生了Assert，原因还待查明。
体验下来，字符界面的BIOS的显示，经过MultiArchUefiPkg将GOP驱动中x86指令翻译成RISC-V，稍微显得慢一些，但尚属可以接受。有同学可能会问，UEFI下GOP驱动可以通过MultiArchUefiPkg来转译，那Linux下怎么办？Linux的驱动大多开源的，可以方便的重新编译一下打包进来就行了，而UEFI设备驱动通常是闭源的，不好自己加RISC-V的支持，这才显示出来MultiArchUefiPkg这种仿真环境对生态的价值，谓其神器。缺憾和Next Step 大家也许注意到了，Ubuntu和Deepin都为VisionFive2做了单独的适配，并提供单独定制的OS image下载，这是为什么呢？我在这篇文章中介绍了原因：RISC-V 架构发展现状的碎片化隐忧
VisionFive2尽管做了 UEFI 适配，但缺乏统一标准和ACPI的支持，导致硬件抽象能力不足，OS分支化严重。这点需要业界继续努力。我们也会跟进支持，并加入图形化BIOS和其他产品化功能，来促进RISC-V在通用领域的产品化速度。
原文，网页链接
原版的x86Emulator仅支持在ARM的AARCH64（64位ARM ISA）上模拟x64的内容，不支持RISC-V。Intel的工程师将它移植到RISC-V上，支持仿真x86，甚至是AARCH64的环境来驱动x86或者是ARM的UEFI驱动。它的技术细节不变和x86Emulator一样，这里不再赘述。我们需要将MultiArchUefiPkg移植到VisionFive2上即可。VisionFive2要用市面上已有的显卡，需要PCIe x16的插槽，这在小小的单板上当然是不可能提供的。所幸VisionFive2为了支持M.2 NvME，提供M.2接口的PCIe插座，我们只需要在某宝上购买一个M.2转PCIe x16的转接卡即可。我们共试验了两款显卡，一块A卡W330亮机卡，一块N卡。其中A卡非常顺利点亮，它只有x86的UEFI GOP驱动，这也证明这种用MultiArchUefiPkg来解决UEFI生态的可行性。而N卡则产生了Assert，原因还待查明。
体验下来，字符界面的BIOS的显示，经过MultiArchUefiPkg将GOP驱动中x86指令翻译成RISC-V，稍微显得慢一些，但尚属可以接受。有同学可能会问，UEFI下GOP驱动可以通过MultiArchUefiPkg来转译，那Linux下怎么办？Linux的驱动大多开源的，可以方便的重新编译一下打包进来就行了，而UEFI设备驱动通常是闭源的，不好自己加RISC-V的支持，这才显示出来MultiArchUefiPkg这种仿真环境对生态的价值，谓其神器。缺憾和Next Step 大家也许注意到了，Ubuntu和Deepin都为VisionFive2做了单独的适配，并提供单独定制的OS image下载，这是为什么呢？我在这篇文章中介绍了原因：RISC-V 架构发展现状的碎片化隐忧
VisionFive2尽管做了 UEFI 适配，但缺乏统一标准和ACPI的支持，导致硬件抽象能力不足，OS分支化严重。这点需要业界继续努力。我们也会跟进支持，并加入图形化BIOS和其他产品化功能，来促进RISC-V在通用领域的产品化速度。
原文，网页链接
Cain
