OSDev.org

I'm doing some research on EFI right now and while I haven't delved too deep into it, it looks as if it could be somewhat of a good thing. I know that Macs use EFI and that most PCs use BIOS so I've been wondering, can BIOS be removed from a computer and EFI be reinstated? Or is BIOS there forever once it is put in?

It's probably not going to be possible for x86 systems, but I think several x86-64 systems already ship with EFI support

I'm actually starting to think EFI might be a bad idea..
http://en.wikipedia.org/wiki/Extensible ... l_property

EFI is a sort of bios, just different (more modern mainly). Since the bios is tailored to the motherboard, you can't simply change between EFI and PC Bios.

You can however layer (emulate) one on top of the other. Bootcamp provides a pc bios service for Intel Mac's which are EFI, and the other way around should very well be possible. There isn't a standard solution for that as MacOS is known not to work with non-mac hardware, and other OSes use PC bios so there is no demand.

Maybe a dual PC Bios/EFI interface will help in the process of modernising the pc bios.

Hi,

In theory, it would be technically possible for someone to write their own EFI BIOS and flash it onto a normal computer, and it's probably possible for someone to write an "EFI compatability layer" to emulate EFI on top of a normal PC BIOS.

Writing a compatability layer on top of a normal PC BIOS would be much easier (much less motherboard/chipset dependant) and easier for end-users (who may be worried about trashing their BIOS and/or being able to boot Windows).

IMHO in practice, it makes much more sense (from an OS developer's perspective) to write a "firmware abstraction layer" in the OS - some code the runs early during boot that gathers any information needed from the BIOS and stores it in a common format in RAM. That way you could have several different "firmware abstraction layers" (one for PC BIOS, one for EFI, one for LinuxBIOS, one for OpenFirmware, etc).

This would be especially important for a portable OS. For e.g. imagine something designed to be ported to Intel/Macs and Itaniums (EFI), normal 80x86 (PC BIOS), and other systems (SPARC, PowerPC, IBM POWER, etc that use OpenFirmware).

Brynet-Inc wrote:I'm actually starting to think EFI might be a bad idea..
http://en.wikipedia.org/wiki/Extensible ... l_property

I tend to think EFI is a bad idea too (it's overcomplicated, and is more like a "mini-OS" than just some code to boot an OS).

From your Wikipedia link:

"According to Ron Minnich, the lead developer for LinuxBIOS, one of the stated goals of EFI is to "protect hardware vendors' intellectual property"[16]. This raises security concerns[citation needed] and notably makes creating a free software implementation impossible.[citation needed] EFI could be used to create a "DRM BIOS", thus letting vendors build computers which limit what the user can do.[citation needed]"

This is 2 seperate issues - "protect hardware vendors' intellectual property" (where it makes no difference if this intellectual property is protected by a PC BIOS or an EFI BIOS), and the possibility of supporting DRM in an EFI BIOS (where DRM could just as easily be supported by a PC BIOS). Obviously neither of these arguments can be used to say that EFI is better or worst than PC BIOS.

These arguments could be used to say that LinuxBIOS is different from both EFI and PC BIOS, where "different" may mean "better" or "worse" depending on your perspective. For e.g. (from one possible perspective) you could say that LinuxBIOS is worse than either EFI because it doesn't allow hardware manufacturers to have trade-secrets (and forces them into a position where using patents may be an attractive alternative) and doesn't allow end-users like you and me to use DRM to protect our own works.

Before you get the wrong idea, I'm not saying this is my perspective... My perspective is that all manufacturers of any product should provide enough information to allow all end-users to use the product they paid for (where for hardware manufacturers, "end-users" includes OS developers and programmers). I also think DRM is a tool that can be used for both "good" and "bad" purposes, and that it would be naive to think all possible uses of DRM are "bad".


Cheers,

Brendan

Brendan wrote: I tend to think EFI is a bad idea too (it's overcomplicated, and is more like a "mini-OS" than just some code to boot an OS).

Heh... Have you seen OpenFirmware? The whole thing is implemented in Forth!

I'm not sure "simple" firmware exists anymore...

Hi,

Colonel Kernel wrote:

Brendan wrote: I tend to think EFI is a bad idea too (it's overcomplicated, and is more like a "mini-OS" than just some code to boot an OS).

Heh... Have you seen OpenFirmware? The whole thing is implemented in Forth!

I'm not sure "simple" firmware exists anymore...

I haven't looked into OpenFirmware - I've got nothing that can support it, and don't think it really exists for 80x86.

I should follow my own advice though, and am currently looking into LinuxBIOS. I figure it shouldn't be too hard to get Bochs, LinuxBIOS and my OS all working together...


Cheers,

Brendan

Thanks for the responses everyone. I do like the idea of the firmware abstraction layers for cross compatibility so I'll look into that some more!

Hi,

Brackets wrote:Thanks for the responses everyone. I do like the idea of the firmware abstraction layers for cross compatibility so I'll look into that some more!

I've been looking into it...

Colonel Kernel is right about OpenFirmware (and OpenBIOS, which is an open source implementation of the OpenFirmware specification) - it's all based on Forth, where the documentation has no information about how you're meant to use it on 80x86 (no standard exists for the binding between 80x86 and the BIOS). I have a feeling that OpenBIOS gets around this by assuming the OS is linked to the BIOS (so the OS finds out the BIOSs entry point via. an "extern").

EFI is still a huge over-complicated mess.

LinuxBIOS isn't a huge over-complicated mess, and once you ask lots of questions on their mailing list it's not that hard to use. The problem here is that they have no standards or specifications and anything your code relies on may change tomorrow. The common response on the mailing list is "look at the source code", but different pieces of source code contradict each other, comments are scarce, explanations don't exist, and you can't find out how things may be used in future or were used in the past by making assumptions about what you see in source code today.

Despite all of this, I still think it's a good idea to have an abstraction layer between the boot code that deals with firmware and the OS itself.

In most (all?) cases the OS can scan for ACPI, MP specification, SMI/DMI and PCI IRQ routing tables after it boots and use what it finds, so you don't need to worry about them. Also, you can assume other CPUs are left in the "wait for SIPI" state, and the same AP CPU startup code can work for all cases.

My advice is to bring all systems to the same state using "firmware dependant code", then have universal OS boot code after that. This includes:

• 1.) make sure everything the OS needs to boot is in RAM (LinuxBIOS has no device drivers for accessing storage devices, and for the PC BIOS it's all in real mode).
  2.) detect physical address space areas in the "firmware dependant code".
  3.) assume your universal OS boot code begins running in protected mode
  4.) don't use virtual80x86 (no guarantee that real mode BIOS functions for video and/or SCSI exist)
  5.) for video, make the firmware dependant code setup a framebuffer and tell the universal OS boot code the details (physical address of display memory, resolution, etc)
  6.) for headless systems, make the firmware dependant code tell the universal OS boot code the details for a serial port or other output device (e.g. base I/O port, baud rate, IRQ, etc), but be prepared for headless systems that don't tell the universal OS boot code any of this or only part of this. Some firmware (e.g. LinuxBIOS) is typically configured over serial, and it'd be good if the OS tried to use the same communication protocols and serial port as the firmware to avoid annoying users (i.e. provide a seemless transition from firmware over serial to OS over serial)
  7.) don't assume that the firmware knows if the computer is headless or not (just because a video card is present and the "firmware dependant code" tells you video information doesn't mean that a monitor is attached). I'd get the firmware dependant code to pass a "headless | not headless | unknown" value to the OS.
  8.) Don't assume anything about the state of other motherboard resources (PIT, PICs, I/O APICs, etc). For e.g. the PIT might be set to generate any frequency or not setup at all. The PIC chips may or may not be enabled or programmed in any specific way. The keyboard controller may or may not work, the BIOS may or may not make USB keyboards look like PS/2 keyboards, disk controllers may or may not have been initialised.
  9.) In general you can assume PCI buses have been enumerated and bridges have been configured. You can also assume hyper-transport links, MTRRs and thermal monitoring (for critical over-temperature shutdown or throttling) has also been configured.
  10.) Don't assume that information about CPUs in ACPI and MP specification tables (i.e. the "local APIC entries" is correct. For LinuxBIOS (and PC BIOS for Bochs and Qemu) the CPU type, CPU feature flags, local APIC type, etc can be dodgy (get them from the CPUs themselves). The APIC ID is the only thing you should rely on. The rest of the ACPI and MP specification should be reliable.
  11.) For all other information, gather as much as you can and use "known/unknown" flags. This includes APM, which PCI configuration space access mechanism to use, etc.

Cheers,

Brendan

You can get EFI on top of a standard PC Bios from IBM, including all source code. You can download it from their homepage for free.