> unlike new x86 hardware having an interest in still being able to run old versions of Windows

The "secret sauce" is... we're not speaking about "x86" systems, at least as long as UEFI doesn't enter the game. In fact what we're talking about is "IBM PC-compatible x86" and its BIOS that provides ultra-low-level interfaces for input and output (including a very very basic USB stack). These can then be used to continuously load higher level systems.

Basically what you start with in the BIOS land is the boot sector, you got barely enough code capacity that you have input from the disk and text console output. That you can use to load a second stage bootloader (e.g. GRUB, NTLDR) which now has better knowledge of filesystems, maybe even enough of the driver to bring the GPU up with the basic VESA interface. And that then loads the actual operating system which brings up the rest of the system - proper GPU, a full featured USB stack, you name it. And layered in between that is ACPI for dynamic hardware discovery.

UEFI based systems can skip a lot of the slow early code used to boot in BIOS - it hands over directly to the OS itself in the best case, or to a high-level bootloader such as the modern Windows bootloader that can do all sorts of magic.

In contrast, the ARM world sucks hardcore - there are no standards for board bringup and boundaries, there is only DeviceTree which replaces a very small part of the wonder/hellscape that is ACPI. And that is something even Apple couldn't get rid of. Hell, you can't even be sure it's the CPU that brings everything up - there are weird systems like Broadcom's VideoCore architecture that underpins the Raspberry Pi, where the video chip part of the SoC handles bringing up the ARM CPU.

Basically, x86 has a ton of legacy and warts but for that, backwards compatibility and to a degree even forwards compatibility is a thing. ARM in contrast... it's like if you let a bunch of drugged up monkeys loose.

▲

pzmarzly 11 hours ago | parent [-]

> In contrast, the ARM world sucks hardcore - there are no standards for board bringup and boundaries

There are standards for ARM, and they are called UEFI, ACPI, and SMBIOS. ARM the company is now pushing hard for their adoption in non-embedded aarch64 world - see ARM SBBR, SBSA, and PC-BSA specs.

▲

hu3 10 hours ago | parent | next [-]

Yes but these standards are clearly far from enough to run Linux on M chips otherwise the support wouldn't lag so far behind.

▲

mschuster91 9 hours ago | parent | prev | next [-]

> There are standards for ARM, and they are called UEFI, ACPI, and SMBIOS.

The most popular ARM dev and production board - the Raspberry Pi - doesn't speak a single one of these on its own, so do many of the various clones/alternatives, and many phones don't either, it's LK/aboot, Samsung and MTK have their proprietary bootloaders, and at least in the early days I've come across u-boot as well (edit: MTK's second-stage seems to be an u-boot fork). And Apple of course has been doing their own stuff with iBoot ever since the iPhone/iPod Touch that is now used across the board (replacing EFI which was used in the Intel era), and obviously there was a custom bootloader on the legacy iPods but my days hacking these are long since gone.

I haven't had the misfortune of having to deal with ARM Windows machines, maybe the situation looks better there but that's Qualcomm crap and I'm not touching that.

	▲	pzmarzly 3 hours ago \| parent [-]
		TIL Raspberry Pi doesn't support UEFI - I once read RPi 4 and 5 do, but apparently that was just a community project. https://www.cnx-software.com/2020/02/18/raspberry-pi-4-uefia... Regarding phones, Google is trying to push UEFI adoption with their EFI bootloader, but that's still some time away. Recent talk: https://lpc.events/event/19/contributions/2257/ Regarding Windows/PC ARM devices, I think the best experience would be on System76 Thelio (with Ampere CPU), but that's quite a pricy machine. I don't really care what Apple does on this regard, they were always doing things differently. IIRC, even Macs that supported EFI, only supported EFI 1.1, not 2.0, no?

▲

bigyabai 10 hours ago | parent | prev [-]

They should have pushed for it years ago, ARM's devicetree clutter and bootloader "diversity" has been a curse on the end user. At this point it's too late, and doubtful that they even have the influence to make OEMs adopt it.