When these ARM boards start coming with UEFI and I don't need to hunt around for blessed OS images with patched kernels I'll be a lot more interested, until then I've got to stick with x86 to maintain my sanity.
UEFI is not enough if you don't have all the drivers in the OS image, especially the GPU drivers. Last year I bought a cheap Windows Qualcomm 8xx ARM tablet on sale and it was very nice for the money but I returned it when none of the ARM Linux ISOs I found online could boot on it despite the tablet having UEFI support, because Qualcomm.
Booting Linux distros out of the box is such a non-issue on X86 that we take it for granted when on ARM it's just a pipe dream.
If the ARM PC future is all proprietary custom firmware blobs that need to patched for each SoC/motherboard for Linux to boot, then you can keep them, I'll stick to X86 thank you very much.
Right, you need reasonable firmware (boot path and device enumeration) and to actually have the drivers upstreamed. Both necessary, neither sufficient alone. (Although, either one alone still a massive improvement over the usual)
Part of the point of UEFI is to support a graphical framebuffer and HID devices (keyboard and mouse) out of the box, that's what powers the fancy BIOS setup screens on newer PC's. Hardware-specific drivers are supposed to be optional.
FWIW, there is a port of EDK2 to the RK3588, which is what powers this board. Most of the peripherals work. So that's nice. But the thing is, it isn't UEFI so much as the device-tree/ACPI distinction you need to be mindful of. ARM systems use both methods (whereas everything on x86 is ACPI.) You can use either DTBs (kernel configuration option) or ACPI to boot Linux on this device, though. https://github.com/edk2-porting/edk2-rk3588
A tiny subset of UEFI would be nice (ability to load files from a fat32/exfat/something partition, framebuffer, memory map). Also a subset of ACPI (enumeration of PCI devices) and XHCI (enumeration of USB devices). That's enough of a starting point where you can load drivers, and show the user an error if there's unknown hardware.
Comments
When these ARM boards start coming with UEFI and I don't need to hunt around for blessed OS images with patched kernels I'll be a lot more interested, until then I've got to stick with x86 to maintain my sanity.
UEFI is not enough if you don't have all the drivers in the OS image, especially the GPU drivers. Last year I bought a cheap Windows Qualcomm 8xx ARM tablet on sale and it was very nice for the money but I returned it when none of the ARM Linux ISOs I found online could boot on it despite the tablet having UEFI support, because Qualcomm.
Booting Linux distros out of the box is such a non-issue on X86 that we take it for granted when on ARM it's just a pipe dream.
If the ARM PC future is all proprietary custom firmware blobs that need to patched for each SoC/motherboard for Linux to boot, then you can keep them, I'll stick to X86 thank you very much.
Right, you need reasonable firmware (boot path and device enumeration) and to actually have the drivers upstreamed. Both necessary, neither sufficient alone. (Although, either one alone still a massive improvement over the usual)
Part of the point of UEFI is to support a graphical framebuffer and HID devices (keyboard and mouse) out of the box, that's what powers the fancy BIOS setup screens on newer PC's. Hardware-specific drivers are supposed to be optional.
Can I run X or Wayland with the UEFI framebuffer?
It should - linux's simpledrm driver should work with uefi framebuffers using the "standard" user interfaces.
FWIW, there is a port of EDK2 to the RK3588, which is what powers this board. Most of the peripherals work. So that's nice. But the thing is, it isn't UEFI so much as the device-tree/ACPI distinction you need to be mindful of. ARM systems use both methods (whereas everything on x86 is ACPI.) You can use either DTBs (kernel configuration option) or ACPI to boot Linux on this device, though. https://github.com/edk2-porting/edk2-rk3588
Bingo. Basically ARM SystemReady SR or gtfo.
In practice that means Ampere Altra CPU. There was a uatx board released recently that seems viable, if bit pricy.
https://www.servethehome.com/asrock-rack-altrad8ud-1l2t-revi...
https://www.arm.com/architecture/system-architectures/system...
A tiny subset of UEFI would be nice (ability to load files from a fat32/exfat/something partition, framebuffer, memory map). Also a subset of ACPI (enumeration of PCI devices) and XHCI (enumeration of USB devices). That's enough of a starting point where you can load drivers, and show the user an error if there's unknown hardware.
Same thing I'm thinking as well when it comes to ARM PC's, being restricted to a specifically patched distro is very limiting.
It's also bad for the planet as it artificially restricts the lifetime in which a board can be used.
This as well. In comparison, you can repurpose any old x86 PC rather easily.
How do we know it doesn't? I didn't see any info in the linked page about the system firmware, though I could easily have missed it.
RK3588 has pretty good mainline kernel support
Does KMS/Mesa support the GPU yet? I know they've been working at it.
They should be getting support soon: https://www.cnx-software.com/2024/03/05/panthor-open-source-...
That's what I heard a year ago... Looks like it is seeing progress, which is good.