“EFI? Intel has been trying to shove that down our throats for years.” (2003) | Hacker News Reader

“EFI? Intel has been trying to shove that down our throats for years.” (2003)

groups.google.com

46 pointsyuhong15 comments

What is this particular HN post supposed to be pointing out? This is a very old thread in a newsgroup about the usage of protected mode in the (traditionally 16-bit) de facto standard PC BIOS, but the link wasn't to the thread. Rather the link was to this one specific post.

Is the editorializing about EFI the thing that is supposed to be interesting here? If so, here it is in its entirety:

"EFI?? Intel has been trying to shove that down our throats for years. IMO it hasn't been adopted by the industry because it would require a large investment in infrastructure to get the ball rolling. You have to understand that a lot of BIOS development has gone to the Pacific Rim area where labor is cheap but excellent. Margins are so thin on motherboards the OEMs don't want to retrain their BIOS programmers to start with EFI when everything is working just fine with a traditional BIOS because each new project is leveraged from the prior. I guess after a while we'll all be assimilated into EFI by Intel, but yikes, that means I'd have to learn 'C'."

OK, and...? This is a mostly reasonable observation for a reasonably informed PC BIOS engineer to make in 2003, but I don't know what insight people on HN are supposed to get from it in 2016.

Even now UEFI bugs are still a serious problem. And it was not long after this was posted that IBM sold the PC division to Lenovo for example.

So? PC firmware bugs have been a serious problem at least as far back as the introduction of ACPI. (U)EFI vs BIOS doesn't seem to have made much difference.

But there are things like UEFI variable bugs bricking systems.

Earlier than that, even. 100% PC compatibility used to be measured on if the PC itself could run Flight Simulator, because Flight Simulator made a lot of bios calls, etc, and a lot of early bioses were rather buggy. Those were also the fun days where updating your bios meant removing the chip and replacing it with a new one

EFI was intended to solve the problems with the BIOS and ACPI and the custom module hell but vendors haven't really adopted it so much as tolerated it. They use it to just load their legacy BIOS and ACPI implementations with all the nasty custom modules.

I should also mention ACPI. ACPI 1.0 for example dates back to the end of 1996 (of course before then there was drafts):

http://uefi.org/sites/default/files/resources/ACPI_1.pdf

But of course ACPI took years to catch on, during which low cost PCs from for example eMachines was coming. EFI was actually designed not long after ACPI, but it was first targeted at IA64.

I miss the old PowerPC/POWER OpenFirmware days and hacking about in it with Forth.

OpenFirmware is still around and open source: http://www.openfirmware.info/Open_Firmware

By far the most sane boot system IMO. Shame it never really caught on. I guess IBM was stuck in their own little (albeit fascinating) world, per the usual….

Wasn't OpenFirmware a Sun thing? I thought that was how it migrated because a lot of Sun stuff made it elsewhere (well, before Oracle).

Actually, maybe it was. I tend to associate it with IBM since it's mainly used for POWER and PowerPC, but now that you mention it I think Sun created it. Does anyone know if Oracle's SPARC still uses OpenFirmware?

Mitch Bradley originally developed a Forth system at Sun for use diagnosing and developing hardware, by burning it into ROM and running it via a serial port.

It was based on Langston and Perry's Forth-83, and had a meta compiler that could target different word sizes and architectures. He made it even more architecture and word size independent, implemented interactive top level loops and conditionals, emacs-like line editing, all kinds of low level device drivers and testers that ran in stand-alone mode, and many other features, including full 16 and 32 bit support with a vocabulary for writing word size and endian independent code.

He ported Sun Forth to 68K and SPARC Sun workstations, as well as the Amiga and other systems. It ran in both stand-alone mode (from disk, tftp or ROM), or under Unix. Under Unix, it could dynamically relocate and link in Unix libraries, and you could call back and forth between Forth and C.

Sun Forth eventually evolved and standardized into the Open Firmware [1], whose purpose was to support machine independent byte code [2], so plug-in hardware cards could include ROMs with Forth byte code drivers that ran on 68K, SPARC, x86 and other systems.

Sun shipped it with the SPARC workstations, Apple adopted it and shipped it on their PowerPC Macs, IBM shipped with their POWER servers, and Mitch worked directly with the OLPC project extending OpenFirmware to support the OLPC XO-1 Children's Computer secure and power efficient hardware. [3]

>OLPC Wiki: Open Firmware

>Open Firmware is the hardware-independent firmware (computer software which loads the operating system) that the XO runs.

>It was developed by Mitch Bradley at Sun Microsystems, and used in post-NuBus PowerPC-based Apple Macintosh computers (though it has been dropped with Apple's transition to Intel processors), Sun Microsystems SPARC based workstations and servers, IBM POWER systems, and PegasosPPC systems, among others. On those computers, Open Firmware fulfills the same tasks as BIOS does on PC computers.

>For example Fedora and Debian use the YaBoot BootLoader for Open Firmware.

>The Open Firmware user interface includes a FORTH-based shell interface. FORTH is a powerful high level language that is remarkably compact. A complete Forth development environment including compiler, decompiler, assembler, disassembler, source level debugger, and assembly language debugger is present in the XO boot ROM (SPI FLASH). With the Open Firmware Forth system, you can directly access all of the hardware devices on the XO, use built-in functions like selftest diagnostics and games, and even write complete applications, without needing any external tools. The bulk of Open Firmware is written in Forth, so the source level debugger can be used to debug Open Firmware itself.

[1] http://www.openfirmware.info

[2] http://www.openfirmware.info/FCODE_suite

[3] http://wiki.laptop.org/go/Open_Firmware

Was -> Is, it's still in use by modern POWER machines.

Thanks, Don, for the summary of Open Firmware history. It did start at Sun, as Open Boot, then we (a committee with representatives from Sun, Apple, IBM, and others) standardized it as IEEE 1275-1994. In addition to its use on Sun SPARC systems, it was the standard firmware for PowerPC systems based on the PREP and CHRP hardware platform specs (IBM, Apple, Motorola, ...). It was also adopted by HP for PA-RISC severs, by DEC (shortly before their demise) on their ARM-based "SHARK" network computer platform, by NetApp on their early x86 and Alpha based storage servers, and by a few other lesser-known companies.

Then x86 pretty much took over the world.

When IA64 was starting to come out, HP flew me up to Intel to propose - with the support of Microsoft! - that Open Firmware should be the standard firmware for IA64. Intel declined, because they had a couple of guys working on their own firmware design that would have similar functionality. That eventually morphed into UEFI, and after more than 10 years it was sort of up to part with Open Firmware - although I doubt that it will ever have the level of instant programmability and debugging capabilities of OFW.

I understand why Intel chose the way they did. Their business model requires that they control as much of the low-level ecosystem as possible. "Owning" the firmware spec gives them leverage and control.

I have two Twitter threads on this:

https://twitter.com/yuhong2/status/751955059609526272

https://twitter.com/getwired/status/752737513005912064

I should also mention a more recent Slashdot post:

https://linux.slashdot.org/comments.pl?sid=8693705&cid=51419...

Reply on news.ycombinator.com