| ▲ | mort96 2 days ago | ||||||||||||||||
You can hope but I don't think it'll happen any time soon. The lack of standardized boot and runtime discovery isn't such a big issue; u-boot deals with the former and devicetrees deal with the latter, we could already have an ecosystem where you download a bog standard Ubuntu ARM image plus a bootloader and devicetree for your SBC and install them. It wouldn't be quite as elegant as in x86 but it wouldn't be that far off; you wouldn't have to use SBC-specific distros, you could get your packages and kernels straight from Canonical (or Debian or whatever). The reason we don't have that today is that drivers for important hardware just isn't upstream. It remains locked away in Qualcomm's and Rockchip's kernel forks for years. Last I checked, you still couldn't get HDMI working for the popular RK3588 SoC for example with upstream Linux because the HDMI PHY driver was missing, even though the 3588 had been out for many years and the PHY driver had been available under the GPL for years in Rockchip's fork of Linux. Even if we added UEFI and ACPI today, Canonical couldn't ship a kernel with support for all SBCs. They'd have to ship SBC-specific kernels to get the right drivers. | |||||||||||||||||
| ▲ | sunshine-o 2 days ago | parent | next [-] | ||||||||||||||||
I thought the Radxa Orion O6 [0] with it's "SystemReady SR-certified BIOS", UEFI(EDK2) support and "Boot-up in Line with X86 Conventions" was an answer to this problem. | |||||||||||||||||
| |||||||||||||||||
| ▲ | gspr 2 days ago | parent | prev [-] | ||||||||||||||||
Right. Thanks! | |||||||||||||||||