Liam on Linux

For some 30 years, the PC platform had the BIOS. Old-fashioned, clunky, designed for 8/16-bit OSes such as DOS and largely irrelevant to 32-bit OSes which couldn't call it anyway. So either they used it to kick off their bootloader, which set some stuff up then jumped to 32-bit mode and subsequently ignored it (i.e. NT, OS/2, Netware), or, they just stuck an exploit in the Master Boot Record and bypassed it altogether (i.e. Linux, BSD, Solaris, etc.)

It was a limitation, but it was a baseline for PC compatibility, and it kinda worked. There have been multiple workarounds to get round size restrictions for hard disks in x86 PCs: first ST-506 and RLL, and SCSI controllers with their own firmware; then IDE (max 512MB); then EIDE with LBA (max 8GB); then UltraEIDE (max 128GB); then SATA and banishing the ancient 2-drives-per-channel thing and a limit of 2TB per drive.

This was a ceiling. You can't work around the ancient cylinders/heads/sectors-per-track code in the BIOS any more; all the values are maxed out to get 2TB. And the BIOS dictated the structure of the Master Boot Record, meaning this was a hard limit for the PC disk partitioning system. So it had to go. Something new had to replace it. That replacement was GPT partitioning, and with that came UEFI.

UEFI is allegedly an open standard. Sure, there is a UEFI consortium and so on, yes.

But it's like a lot of things in the IT industry. We all talk about how there are standards bodies and so on, but really, there are a bunch of tiny marmosets and tamarins, and two grumpy 400kg silverback gorillas who don't like each other but are totally dependant on one another and know it.

UEFI is an extension of EFI. EFI was originally called IBI: Intel Boot Initiative. EFI was and is Intel-proprietary, closed-source and paid-for. EFI is Intel's proprietary 64-bit firmware for booting Windows on Itanium, basically.

Intel chose to adopt and adapt this for x86-64, but it was not a sure thing. Intel had choices.

Intel could have used Open Firmware. Open Firmeare has been standard on SPARC and many POWER and PowerPC boxes, including PCI PowerMacs, for decades. It works fine on x86 -- the OLPC XO-1 used it.

Or it could have used CoreBoot. It works, it's FOSS, it's fast, it supports BIOS emulation and DOS/Windows.

Or it could have used ARC firmware from the ACE initiative, as the SGI Visual Workstations did. (I wish I'd picked up one when they were going cheap. Lovely machines.) You've probably never heard of it, but the ACE consortium's device-naming system (supporting Windows NT, Unix and VMS) is the reason for the weird device naming in the NT bootloader from 1993 (NT 3.1) through NT 4 & Win2K until XP's BCD, incidentally.

Intel had options. But it didn't take them. For Intel's first stab at firmware for its first 64-bit PC processor, Itanium, It went with something closed and proprietary.

Why? Well, let's back up a bit.

It may seem sweeping when I say that Intel and Microsoft rule the industry. If it wasn't apparent, those are the 2 gorillas I was alluding to in my metaphor earlier.

But what about AMD?

Realistically, AMD has significantly influenced the direction of the PC industry just once ever: AMD64.

The story is more complicated than it looks. It didn't happen because of AMD's actions. It happened because of Microsoft's response to Intel's actions.

Intel's plan for the next-gen PC processor, IA-64 (i.e. Itanium) flopped. At peak it was selling a few thousand units a year. Not a typo. The PC industry deals in millions of units and Itanium failed to achieve even 1% of that.

Intel had no fallback plan; it had sold its ARM licence to Marvell, it had leaned heavily on HP/Compaq to kill Alpha. So Intel was left with an unimpressive, hot, underperforming range of x86-32 chips (the Netburst Pentium 4) and nowhere to go. It was bitten by the fallacy of sunk costs: having spent tens of billion on Itanium, it was not inclined to launch a competitor to its own struggling next-gen architecture when it didn't have a compelling option available.

AMD saw an opportunity and invented AMD64 — a pretty inspired hack, IMHO. Still a bit stingy with registers compared to most RISC ISAs, but good.

AMD64 caught on. Partly because of FOSS and Linux jumping to adopt it.

Intel responded as Intel is wont to do: it invented its own, different 64-bit extension to x86. It showed this to MS and asked for a version of Windows for it.

MS, to Intel's shock, said a firm NO. Paraphrased, the statement I heard described was: "We already support your crappy IA64. We already support AMD64. We are not going to support a third 64-bit PC architecture, especially as we support two of yours already. [x86 and IA-64.] You need us. Without us, without Windows, you're dead and you know it. We will not do it. AMD64 is fine, it's good, it works, the industry likes it. Get compatible with it or go unsupported by MS."

Intel, smartly, caved. It threw away its own IX64 (I'm afraid I've forgotten the official name) and tweaked its 64-bit Netburst cores to support AMD64.

Then, discovering corruption and massive nepotism going on in its new Indian R&D centre, where it was working on its future quad-core Netburst chips, it closed the entire operation, and switched focus to Intel Israel's low-power Pentium-M design for laptops. It became the future, but the new "Core" and "Core Duo" chips had to be rushed out somewhat, so the 64-bit Pentium 4 was replaced by the 32-bit Core series... closely followed by the 64-bit Core 2, rendering all Core 1 machines obsolete at a stroke.

Back to UEFI.

AMD set the agenda on 64-bit x86, and the FOSS world swung the prow of the boat towards it.

My suspicion is that when Intel management realised that Itanium was dead in the water and they'd lost control of x86-64, they set up an allegedly open-source body for UEFI, based on their own EFI, which Intel could totally dominate — thus giving Intel a way to keep its hand on the tiller of x86-64.

Only one other partner had a significant role: MS, who have slighly more knowledge of writing firmware than I do.

The Linux world were, as usual, too busy hating each other, pretending each other didn't exist or if they acknowledged they do, flinging poop at one another. They had no real say in it.

AMD didn't get much of a say. (AMD supported CoreBoot, incidentally.)

So we got UEFI, which is an Intel standard and was designed to boot Windows and basically nothing else. That's why getting a free Linux to boot on UEFI can be such a pain.

The best I can say for UEFI is that it's better than the situation in the ARM world, where there is no standard firmware at all, some of the most popular devices have none, and Arm Ltd's vain attempt to urge one on AArch64 licensees has failed completely, AFAICS.