Why cheap systems run 32-bit UEFI on x64 processors

For years I’ve been getting questions about the UEFI implementation found on many low-cost tablets and 2-in-1 platforms. Why would a system with a 64-bit Intel processor ship with 32-bit UEFI? Why can’t I get Linux on a 32-bit UEFI system? The answer, as with many things, involves money.

The main thing we need to understand is a core concept of the UEFI Specification: the OS and firmware architecture need to match. For most non-Intel processors, this isn’t a big deal since they only have one architecture. The “x86 compatible” processor is a bit different, and can switch into various 16/32/64 bit modes for application compatibility. Because most Intel platforms support both 32-bit & 64-bit architecture, along with old school Intel 8086/80286 16-bit instructions, the UEFI firmware on these platforms can be compiled in IA32 or x64 mode. This is reflected in firmware provided for 32/64-bit platforms (ex: MinnowBoard Max) or 32-bit platforms (ex: Intel Galileo & MinnowBoard).

On a legacy BIOS system the firmware-OS hand-off happened in 16-bit real mode, and the OS was expected to transition to 32/64-bit protected mode. Aside from a number of technical limitations and security problems in the legacy BIOS boot model, this caused problems between the 16-bit BIOS runtime interfaces and 32/64-bit OS services. Vincent Zimmer, as usual, provides a lot of detail on problems facing firmware interfaces at runtime. The TL;DR version is that it’s easier for the OS to get along with the firmware if they run at the same bitness (32-bit OS boots from 32-bit firmware, 64-bit OS boots from 64-bit firmware) and this is reflected as a fundamental principle of the UEFI Specification.

Now look at this from the side of a Linux vendor back in 2011-2012 when UEFI was becoming the dominant firmware interface. The main targets for off-the-shelf distributions like Ubuntu and Fedora are servers and the typical desktop/laptop “client” system. These are usually 64-bit systems with a legacy BIOS (UEFI Class 0), UEFI with legacy compatibility (UEFI Class 2) or UEFI-only firmware (UEFI Class 3). So the “UEFI capable” Linux installer sits along side the legacy BIOS installer in a multi-volume CD/DVD ISO image.

At the time, this 64-bit mixed image approach was the primary use case for Linux users. Go to the store, buy a system, make references to the questionable parentage of software developers in Redmond, and install Linux. Those systems would be designed to boot Microsoft Windows 8 x64 or Server 2012 x64, so there was no need for mainstream support of a 32-bit UEFI environment.

As tablets and cheaper laptops came into the market, more manufacturers started to ship Microsoft Windows 8.1 x86 … the 32-bit version. This decision was driven by cost, but not the cost of the software. A 64-bit OS does theoretically perform better than a 32-bit OS, but those performance gains are tied to larger amounts of memory (over 4GB). The 64-bit version of Windows takes up more disk space, thanks to larger binaries (hello, bigger opcodes) and any underlying 64/32-bit translation layers. This means your Black Friday special purchase with 2GB of RAM and 16-32GB of internal flash storage doesn’t see any 64-bit architecture benefits.

Apparently my "Black Friday" clipart is woefully out of date.

Apparently my “Black Friday” clipart is woefully out of date.

So now that cheap computer doesn’t run popular versions of free software out of the box. This isn’t a grand conspiracy, it’s a side-effect of how the market adapted to build cheaper systems. For Intel it was easy to support, just recompile the UEFI C-code in IA32 mode instead of x64. For Linux distros, it’s a bit more complex.

Matthew Garrett has an in-depth description of the problems Linux vendors face trying to build an all-purpose 32-bit distribution. From the distro point of view, adding a UEFI loader to the i386 distribution built for older systems introduces compatibility issues because those systems haven’t been tested with UEFI capable software. My problem with Matt’s assessment has always been that he’s trying to solve the wrong problem. The ecosystem doesn’t need an all-purpose 32-bit Linux distro, it just needs one that supports UEFI IA32. That el-cheapo tablet/laptop/2-in-1 doesn’t even have a CD/DVD drive, and won’t have legacy BIOS compatibility, so why bother with an El Torito ISO image? An IMG or ZIP file works just fine for distributing a UEFI OS image.

There’s nothing technically preventing someone from building a UEFI IA32 Linux distribution. Angstrom Linux has an image for the original MinnowBoard that’s 32-bit only with no dependencies on legacy BIOS. But Angstrom is focused on embedded computing. The mainstream Linux vendors perceived IA32 as an architecture for the embedded market, not low-cost consumer devices that hobbyists often use as Linux targets.

The market for budget Intel platforms looks a bit fragmented from a UEFI standpoint … some run Microsoft Windows 8.1 x86 (the 32-bit version), some run Microsoft Windows 8.1 x64 and some run Android x64. That presents a mix of UEFI IA32 and UEFI x64 firmware for Linux vendors to support and validate, which is a business decision for how they wish to allocate resources. Free code doesn’t negate the time and resources required to package a new distro for download, and eventually those things add costs to development.

The shift away from CD/DVD as the “default install media” is a big help in building a UEFI IA32 only distribution. UEFI boots from a standard file system, not a magic disk sector or an esoteric specification named for the Mexican restaurant where it was conceived. It seems pointless to build an ISO image for OS installation when the target media is a FAT32 formatted USB thumb drive or SDHC memory card. Almost all of the problems Matthew raises in his analysis go away when you remove considerations for ISO packaging, El Torito and legacy BIOS compatibility.

So again, we’re down to money. Vendors use a 32-bit version of Windows because they can make a cheaper product (cost matters to end users), and they typically aren’t interested in testing an OS that’s not shipping with the platform (QA doesn’t work for free). Intel’s customers want the option for UEFI IA32 and x64 on the same core hardware, and Intel wants their money (sorry kids, Brian’s gotta eat). Linux distros need more resources to add UEFI IA32 support, which eventually costs them money (test hardware eats into the beer fund).

Will vendors stop shipping 32-bit versions of 64-bit platforms anytime soon? It’s hard to tell, but I doubt demand will cease for cheaper consumer devices. So Linux support for UEFI IA32 is still an unanswered question. Linux users have requested this option, and some work has been done to bridge the gap … but it’s still an unofficial hack with mixed results. That means Linux distros have to evaluate how they support cheaper Intel devices, and Linux users have to do a bit homework when selecting a new system for experimentation.

Update: Thanks to Steve for pointing out that Debian 8.1.0 has a “multi-dist” image that works around this issue. Check out this follow-up post for more information:

Brian Richardson

About Brian Richardson

Brian Richardson is a senior technical marketing engineer. He’s spent most of his career as a ?BIOS guy,” working on the firmware that quietly boots billions of computers. Brian has focused on the industry transition to the Unified Extensible Firmware Interface (UEFI), demystifying how firmware works and simplifying firmware development tools. He also produces videos for Intel’s YouTube channel, and is a frequent presenter at the Intel Developer Forum (IDF).

6 Responses to Why cheap systems run 32-bit UEFI on x64 processors

  1. FYI, we will have Mixed Mode enabled on Console OS by month’s end, opening the door to running Android-IA on 20 million UEFI-compliant Intel Android tablets.

    Mixed Mode has been a major struggle for the Linux community, I will grant that – but the reason why should be well understood.

    My understanding was that Bay Trail ran UEFI32 due to InstaGo bugs that prevented 64-bit Windows 8 certification, forcing 32-bit mode. The only way WHQL would certify Bay Trail-T was if the firmware ran in 32-bit mode, thus permitting a 64-bit processor to be sold with 32-bit firmware. As of Windows 8, 64-bit CPUs must be licensed with 64-bit Windows otherwise.

    (This wasn’t a secret either. It was confirmed to several media outlets upon the launch of BayTrail-T that it was an InstaGo issue in Windows 8 that compelled UEFI32 – Cost was never a factor).

    By Windows 8.1 this was resolved in the Windows kernel, but there is no way for a Bay Trail BIOS vendor to know if a SKU is being flashed with Windows 8 or 8.1, hence Bay Trail remained limited to UEFI32, and why Intel crafted Mixed Mode for the Linux community.

    The problem is Mixed Mode was only mainlined in Kernel 3.15. Even Android-IA Lollipop runs Kernel 3.14 to this day. We had to backport Mixed Mode, with major assistance from Intel. The problem is kernel lag in distributions – something the entire Linux community (my team included) has to be a part of solving).

  2. Dyson says:

    Mainstream Linux distributions are incredibly unlikely to go to the trouble of QAing an entire additional install image just to support 32-bit UEFI systems, and right now they’re also unlikely to remove support for older systems, so by choosing to ship 32-bit UEFI you’re reducing the number of OSes that your platform will run. If the mainstream vendors won’t do it, somebody else will.

    • Dyson, that’s not how it has to be though. With UEFI Mixed Mode, all a 64-bit Linux distribution has to do is flip a few kernel switches, and make sure they’re using Linux kernel 3.15 or newer.

      The only step left is to make sure you put in a couple of 32-bit EFI bootloader files, and make sure your bootloader (GRUB, etc) is Mixed Mode-aware. Unfortunately some bootloaders like Gummiboot (now deprecated, but point of reference) lack the ability to support this.

      This is why the latest Ubuntu releases can boot on 32-bit UEFI devices. Ubuntu finally stepped up to Kernel 3.15 and flipped on the switches for Mixed Mode.

      Now, if you don’t (or can’t) have Kernel 3.15 or newer, then yes, 32-bit UEFI can get very complicated, very fast. I have an entire bottle of aspirin dedicated to that subject on my wall…