文章介绍了作者对Rock 5 ITX+主板的喜爱及其硬件配置，并提到由于microSD插槽位置不便，作者计划通过安装EDK2 RK3588 UEFI固件来实现从USB启动和安装通用ARM Linux镜像的目标。EDK2 RK3588是一款基于EDK2的UEFI固件，支持多种操作系统，提供类似PC的标准启动体验。

EDK2：为ROCK 5 ITX+打造的UEFI固件

作者对Radxa的Rock 5 ITX+主板情有独钟，这款主板基于Rockchip 3588 SoC，支持ATX电源接口、4针Molex、PoE、32GB eMMC、前置USB 2.0接口以及两个Gen 3×2 M.2插槽，适合Mini-ITX机箱。然而，由于microSD卡槽位于主板侧面，频繁拆卸机箱更换操作系统变得十分不便。为了解决这个问题，作者决定通过SPI闪存安装EDK2 UEFI固件，以便从USB启动并安装通用的ARM Linux系统。

EDK2 RK3588固件

EDK2-RK3588是基于EDK2的UEFI固件，专为RK3588系列主板设计，提供类似PC的标准启动体验，支持Windows、Linux、BSD和VMware ESXi等多种操作系统。然而，Rock 5 ITX+的特殊性使得无法通过microSD卡或eMMC直接启动EDK2固件，因此作者选择通过SPI闪存进行固件刷写。

Armbian与EDK2安装

为了完成这一操作，作者首先使用Armbian 25.2.2 Noble Gnome系统启动Rock 5 ITX+，然后通过GNOME Disks工具将EDK2固件刷写到SPI闪存中。整个过程耗时约一分钟，完成后只需移除microSD卡并重新启动系统。

UEFI启动与设置

启动后，作者发现EDK2启动界面仅在第一HDMI输出上显示。通过进入设置菜单，作者调整了ACPI/Device Tree配置，选择同时使用ACPI和Device Tree进行启动，并启用了DTB覆盖和固件修复功能。

通用ARM Linux安装

作者的目标是能够像在x86-64 PC上一样安装通用的ARM Linux系统。然而，EDK2-RK3588要求内核版本为6.15+，这排除了当前版本的Armbian、openSUSE、Ubuntu和Fedora。作者尝试了Fedora Rawhide和Ubuntu 25.10，最终成功在Ubuntu上实现了硬件加速的桌面体验。

Fedora Rawhide的挑战

Fedora Rawhide在启动时遇到了一些问题，需要将Config Table切换为Device Tree才能显示输出。尽管最终成功进入桌面，但GNOME桌面在启动后出现了功能不全的情况，经过一段时间的等待后，系统恢复正常。

Ubuntu 25.10的成功

相比之下，Ubuntu 25.10的安装过程更为顺利，GRUB菜单和安装界面正常显示，系统安装后网络、电源和显示功能均正常运作，且音频功能也得以支持。此外，Vulkan在Ubuntu和Fedora上均能正常运行，尽管开源驱动仍有改进空间。

NetBSD的尝试

作者还尝试了NetBSD，系统能够正常启动并识别网络接口，但未进行进一步安装测试。

总结

作者最初的目标是将Rock 5 ITX+放入机架式机箱，并能够在不拆卸机箱的情况下更换操作系统。尽管SD卡延长线可以解决部分问题，但作者更关注EDK2 RK3588的发展前景。目前，EDK2 + RK3588尚未完全成熟，但在无头文件服务器等场景下已可正常使用。随着Linux内核对RK3588的支持逐步完善，未来这一组合将更加稳定和高效。

产品链接

文章中所有链接均直接指向相关资源，不含任何推广链接。如需支持Interfacing Linux，可通过Patreon进行赞助。

评论主要围绕ARM单板计算机（SBC）的UEFI支持和标准化问题展开，观点多样且各有侧重。

支持UEFI的观点： 1. UEFI简化了启动流程：评论3提到“UEFI确实让事情变得更容易”，并认为ARM板卡在UEFI支持方面正在向正确的方向发展。 - 引用：“UEFI does make things a lot easier. It's a shame that this isn't more common for Arm boards, but it's good to see things heading in the right direction.” 2. UEFI的标准化优于自定义方案：评论5认为UEFI虽然复杂，但作为一个完整的规范，遵循它比自定义方案更可取。 - 引用：“UEFI is a fairly insane spec, but at least it's a fairly complete spec. Following it is preferable to custom nonsense.”

对UEFI的替代方案或改进建议： 1. 推广Open Firmware：评论7提出应推广和改进IEEE 1275 Open Firmware，而不是进一步传播UEFI。 - 引用：“Instead of propagating UEFI further, we as an industry should be promoting and improving IEEE 1275 Open Firmware.” 2. 让操作系统自行处理启动：评论9建议让操作系统自行处理启动过程，减少对BIOS/UEFI的依赖。 - 引用：“But wouldn't it be nice if we took it all the way and just let the OS figure this out?”

对ARM生态系统的批评： 1. 缺乏标准启动环境和设备自动发现机制：评论8指出ARM生态系统在通用计算领域存在两大问题：缺乏标准启动环境和可靠的设备自动发现机制。 - 引用：“There are two fundamental issues in the ARM ecosystem for general-purpose computing: the lack of a standard boot environment and the lack of a reliable device auto-discovery mechanism.”

U-Boot的使用与限制： 1. U-Boot的UEFI模拟功能：评论4提到U-Boot提供了基本的UEFI模拟功能，适用于大多数场景，但某些设备需要特殊配置。 - 引用：“U-Boot does basic enough UEFI emulation for most use cases. I find that I don't need native UEFI firmware and I can just build U-Boot with UEFI support for most ARM devices.”

RISC-V的UEFI要求： 1. RISC-V平台规范要求UEFI：评论6指出RISC-V服务器平台规范要求必须使用UEFI，并提供了相关实现规范。 - 引用：“Note on RISC-V, the RISC-V Server Platform Specification requires UEFI always.”

总结：评论中对ARM SBC的UEFI支持普遍持积极态度，认为其简化了启动流程并推动了标准化。然而，也有声音提出应推广Open Firmware或让操作系统自行处理启动过程。此外，ARM生态系统在标准启动环境和设备自动发现机制方面的不足也受到批评。U-Boot的UEFI模拟功能被认为足够应对大多数场景，但某些设备需要特殊配置。RISC-V平台则明确要求使用UEFI。