Hi Everyone,

Trust everyone is doing great. Anyways, I have been reading about UEFI/EFI and how it is supposed to be the next big thing after BIOS. Based on the information and articles that I have read, I have a few doubts on this. Please feel free to answer them.

1. The Boot Process as we know it consists of 3 parts
a. Cpu, chipset initialisation with POST (BIOS)
b. Loading of a Primary Bootloader (MBR)
c. Loading of a Secondary Bootloader to load the Kernel image.

As stated at http://www.uefi.org/about/ that UEFI does not replace BIOS completely, which part does UEFI replace (from a, b, c)?

2. The again, the FAQs also mention that UEFI can stack up above the BIOS as an interface. What is idea in using BIOS and UEFI together? I mean should nt it be either UEFI or BIOS?

3. Is there any documentation available on the code flow of UEFI? Please share any information if any.

4. Open Source BIOS' such as Coreboot/U boot are working on to provide support to many chipsets and processors. For eg, you have AMD supporting these and also UEFI at the same time. So where does that leave BIOS developers? I mean will they stick with BIOS or will they eventually move on to EFI?

Thanks!

I have seen other posts over the years making this same claim. Older/bigger systems never did have a bios as such. Bios was more of a PC deal.

It does get complex in the between times. On some systems you may need both to boot various OS's.

My guess is bios has reached it's limits but not it's demise. It will be around for another 20 years maybe and slowly going.

Who knows, some of the newer processors may even dethrone x86. I have heard that claim over the years too. Gosh, I sure liked those Alpha processors.

Yeah, I went to a confidential/NDA Release Announcement about Alpha back when I worked on VAX/VMS; sounded real good. Shame DEC didn't have better marketing.

Re BIOS; other HW has some sort of equiv eg SUN Sparc has the OpenBoot PROM.

In general, in any computer, the motherboard (or equiv) needs to know how to start a disk and where to find the OS bootloader as a bare minimum.
In Sun's case, there are a lot of other things you can set with it.

PS There's some stuff about EFI in real use here for RHEL systems http://www.linuxtopia.org/online_boo...ide/index.html

True, I didn't want to get too far off the original question but I did.


As to specs they are usually open. As to how a single vendor makes theirs is almost always different. The creator of syslinux had a lot of trouble with non-standard bios implementations. So we can assume that this will happen in all the standards until the public complains enough.

My neighbor was selling Alpha chips. I think some of the first runs were like $5000 in lots of 10,000. He actually has a belt buckle with an epoxy over Alpha chip. Pretty sure it is a defective one or is now.

Hi Everyone,

After reading informatin from various sources on the Net, here's what I have

1. The BIOS as we know it consists of 3 parts
a. Cpu, chipset initialisation with POST
b. Loading of a Primary Bootloader (MBR)
c. Loading of a Secondary Bootloader to load the Kernel image.

As stated at http://www.uefi.org/about/ that UEFI does not replace BIOS completely, which part does UEFI replace (from a, b, c)?

A -> The BIOS cannot be replaced as I understand. This is because the BIOS will initialise the Motherboard and is motherboard specific. This code will initialise the CPU, North,South bridges and other peripherals and devices. The UEFI layer is a layer this is present above the BIOS and can communicate with the underlying layer via its API calls or protocols as it is called. An EFI system will replace points b and c. This is because EFI uses the GPT partition and not the MBR. Also the EFI system has a Boot Manager that is responsible for loading the OS. Though a boot loader is needed in the form of elilo/grub2 (boot.efi) the boot manager plays a vital role in loading the OS Image.


2. The again, the FAQs also mention that UEFI can stack up above the BIOS as an interface. What is idea in using BIOS and UEFI together? I mean should nt it be either UEFI or BIOS?

A -> UEFI also supports legacy BIOS booting. The UEFI layer is a layer above the Platform specific code (PSC). Hence a board can either boot up in the legacy fashion (PSC - MBR - Bootloader) or via UEFI (PSC - GPT - Bootmanager - OS)

3. Is there any documentation available on the code flow of UEFI? Please share any information if any.

A - Yes. The code of the EFI can be broken up in five different phases such as
1. Pre-EFI Initialisation -> Driver Execution Environment -> Boot Device Select -> Transient System Load -> Run Time

Please refer to Figure 1 of VOLUME 2: Platform Initialization Specification Driver Execution Environment Core Interface for a better understanding. There are individual manual explaining the Individual stages.

4. Open Source BIOS' such as Coreboot/U boot are working on to provide support to many chipsets and processors. For eg, you have AMD supporting these and also UEFI at the same time. So where does that leave BIOS developers? I mean will they stick with BIOS or will they eventually move on to EFI?

A -> What I understand is that BIOS developers will still provide open source support for motherboards, since the board related firmware is used on both Legacy BIOS and UEFI.


I am now closing this thread.
Any further comments/corrections/feedback are most welcome.

/me nods...

Every computer system has some amount of system-specific on-board software, which executes first. Then, that software has some means to transfer control to a "boot loader compatible" environment.

UEFI is simply a specification for such an environment. It is designed to be downward-compatible with the earlier BIOS system, for any boot loaders who assume nothing more, but also to expose more advanced interfaces to those loaders and operating-systems that are conscious of what's been going on during the past twenty-five years.

Computers can never entirely break with the past, because it's important that they be able to support, "more or less," as much existing software and hardware as possible. (The computing machinery is, after all, "merely a means of achieving a much-more-valuable business objective." A computer that costs maybe a thousand bucks might be part of a software system worth thousands of millions.)

If you look around, you'll find lots of examples of this "meet-in-the-middle, software slip-joint" technology. As long as two perhaps very-incompatible (or even yet-to-be-invented) technologies can agree upon some common ground that includes a well thought out provision for future expansion, the two technologies will remain free to "go their own way" as long as they remain compatible with, ex minimis, the slip-joint interfaces and protocols.

Not to nitpick or anyting but the BIOS is only responsible for getting the hardware going, seting up ACPI, detecting the amount of physical memory, and setting up the basic hardware.

It doesn't do any of the following...
Switch CPU modes (the BIOS operates in 16bit real mode)
Setup 32bit or 64bit modes (see above, this is done by the boot loader)
Boot any hard drive at all (the MBR is not part of the BIOS The BIOS only points to whatever is in the MBR and then that program (lilo,loadin,grub,ntloader) opens the A20 Gate on the CPU to set the mode and is responsible for booting the rest... )

BIOS = Basic I/O System, not load everything up to the O/S, That would be LEUTTOS. :P

You must be a C/++ coder because in your world everything is done for you by a magical ROM when in fact there are ASM routines that do most of the work.

Yes, I should have mentioned that the Booting process consists of 3 parts and not the BIOS. Thanks for correcting me.

Current boot-up sequence: BIOS -> Bootloader -> Operating system

"New" boot-up sequence: UEFI -> Bootloader -> Operating system

Isn't this basically all it is? A new (presumably faster) way of doing the POST/getting initial "setup" done, or is there something I'm missing?

Note: I do know about the whole secure boot/"signed OS"/Windows 8 debacle, so that's an "added feature" of UEFI, but other than that…

Yes, MrCode, basically you are quite right.

In the earliest PC systems, the embedded firmware was called BIOS. This is what IBM tried to control and what was clean-room copied. Many generations later now, the system-startup firmware has more or less "gone its own way, in different and sometimes very hardware-specific ways." To provide an agreed-upon way to enable them to do that, the UEFI specification was invented.

Part of that specification is that UEFI supports downward-compatible BIOS calls.

So, once the vendor-specific software has done its thing, it sets up an environment that's compatible with UEFI (therefore also compatible with BIOS), and from that environment it hands control to the boot-loader ... which can now take over the show, knowing that a UEFI-compatible (nee BIOS-compatible) framework is underneath it. (The boot-loader has the means to detect whether the supporting framework is "UEFI" or just "BIOS," so that it can respond appropriately. If it finds the presence of UEFI, it can query for the presence of additional features including those not yet contemplated.)

This, then, is the "slip-joint." Hardware vendors can do what they like, as long as the system's status is conformant to the UEFI specification at the point that they hand-over the keys to the boot loader. The boot loader can do what it likes, as long as it is compatible with UEFI/BIOS.

From what I got, UEFI = BIOS that has a GUI, a few more features (some of which can be made draconian), and is larger.