Intel to axe the traditional BIOS by 2020.

Keatah · November 23, 2017

https://arstechnica.com/gadgets/2017/11/intel-to-kill-off-the-last-vestiges-of-the-ancient-pc-bios-by-2020/

..anyways. I think it still cool that Intel's Xeon Platinum 8180M can still boot in 16-bit x86 mode. No need to kill it off. Keep a fine tradition going.

Edited November 23, 2017 by Keatah

tschak909 · November 23, 2017

As somebody who has done board bring-up...I'll drop my two cents here...

The legacy 16-bit BIOS is a fucking mess.

Typically, for a given board manufacturer, they have HUNDREDS of seperate code trees in their source code repositories, for each combination of chipset, typically, processor, north bridge (which contains the PCI and RAM controller bring-up. Things like AHCI are here as well), and sometimes south bridge (legacy PC like things like serial ports, parallel port, floppy controller, etc..) combinations which are all brought up using hand written 16-bit x86 assembler. The whole thing runs in vm86 mode, which requires all sorts of work-arounds to initialize devices that don't come up in vm86 mode... (and I'm not even going over the incredible challenge in and of itself to write code tight enough to stay in your processor cache to bring up the RAM controllers on each ram module, just so that you can have RAM TO RUN BOOTSTRAP CODE IN!)

Every board needs its own bring up, while there is tons of common code, it's tweaked and mashed to all hell in the process of bringing a board up.

While I am of the opinion that CoreBoot should have become a standard (literally, a Linux kernel to bring up a board. It's quite fantastic, if you have just the right supported motherboard, i've had motherboards fully initialize and jump to a vfs root mount in roughly 3 seconds (!) , it was not the direction that Intel went.

Intel wanted to provide a sort of micro-kernel for hardware bring-up (and allow certain parties to black box pieces of hardware bring-up that they didn't want others to know about, notwithstanding messy things like TPM initialization and the like), and as such basically provided a complete operating system that the loaded operating system ultimately runs over, anyway. (Although, unlike with real mode, EFI goes to great pains to explicitly allow co-located kernel drivers and routines, like Open Firmware)...

For all its faults (and boy there are many), EFI is an incremental step forward from the pure chaos of the BIOS, by greatly simplifying the amount of initialization (bring-up) that the OS kernel has to do, many times, it can simply call EFI to get the status of brought up devices, and zero copy that state into the kernel drivers.

-Thom