Standardization is something what will carry x86 very far into the future despite its infectivity on low power devices.
Standardization is something what will carry x86 very far into the future despite its infectivity on low power devices.
That's not even the half of it either... what firmware does the board run? U-boot is nice, but sometimes you aren't lucky and you're stuck with something proprietary. Although if you're extremely lucky, you'll have a firmware that supports efi kernels.
That is largely due to IBM choosing x86, and the PC taking off in a huge way with its de-facto "open" design that ended up being successful and kept backwards compatibility. One could easily imagine a world in which IBM chose ARM (and it was invented earlier) for its first PC, and proprietary x86 SoCs based on Intel's cores are everywhere instead. A world in which CISC is the new fad.
Note: Intel has non-PC-compatible x86 SoCs too.
The "non-PC" x86 chips I can think of:
80186/188 - Sort of predates the IBM hegemony, can be hammered into shape by adding replacements for onboard peripherals 80376 - a failed long-gone experiment 386CX/EX - not entirely sure how incompatible they are Xeon Phi/Larrabee/Knight's Corner designs -- not really SoCs so much as special purpose acceleratirs.
They are basically a 486 pipeline with some Pentium instructions.
Unfortunately it seems Intel didn't realise that x86 without the PC legacy is worth little, so their attempts at non-PC x86 have mostly failed. On the other hand, "PC-on-a-chip" SoCs like https://en.wikipedia.org/wiki/Vortex86 have enjoyed more popularity.
You want to install Ubuntu on your laptop? Download this ISO and you're good.
You want to install LineageOS on your phone? You have to download the exact binary for your phone (which means LineageOS needs to maintain those hundreds of versions) and hope your phone is supported.
It's true that another factor is the software discoverability of hardware. A lot of stuff on ARM platforms is not discoverable because those platforms are intended to run specific software.
Where this gets absurd is modern Debian supports i686 and up. You should be able to get a 27-year-old Pentium Pro to boot the same image as a Raptor Lake CPU.
Not to mention various drivers have gone without maintainers and pulled from the upstream linux kernel.
Not to mention dropping IA32 and related PAE support.
This has come with a stack of caveats since the advent of Secure Boot.
All PCs have some kind of fast-updating display output (often HDMI) and a BIOS to emulate a CGA card from 199whatever on this interface. My PineNote has an e-ink driver connected by something called EBC. Is that compatible? Maybe, if someone writes a BIOS to make it work. And that wouldn't be amiss, actually, even though e-ink display isn't optimal for software designed for HDMI, it would at least make it possible to get something working quickly.
It also has a touch stylus and a battery - among other peripherals. Can you tell me which BIOS function code gets the X/Y position of a touch stylus? There isn't one - it would be a non-standard extension and we're back to square one. Or should the BIOS implement an on-screen keyboard? Every PC has a keyboard.
Truth.
This is why RISC-V put a lot of effort on this, and put it early.
Relevant specs include but isn't limited to SBI[0], UEFI protocol[1] and the ongoing platform specification[2].
0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases
1. https://github.com/riscv-non-isa/riscv-uefi/releases/tag/1.0...