OSDev.org

Glancing over Intel's EFI 1.1 specification, I have found myself with more questions than answers. Overall, I am currently feeling even more repulsed by EFI. BIOS may be evil, but EFI seems no better.

First off, I did not see anything about a requirement for a BIOS to be included for support of older software. Did I just overlook it, or is this actually the case? (If so, my have things changed! When continued legacy support is no longer considered a priority, but rather, something to be ditched whenever seen fit... What's next? x86 processors without real-address mode?)

Also, is there any resource about EFI and assembly programming? Erm, in my case, more like machine-code programming. I do not use an actual assembler for my code.

And lastly, a couple of other quick questions:
Can the GPT be placed beyond LBA 1?
What is the purpose of code in the MBR, if the EFI loads the OS automatically via the GPT?

Sorry, but the specification (and everything else I have been reading about EFI) has left my head spinning.

Question 7 in the FAQs here: http://www.uefi.org/about/ suggests that the normal BIOS services will still be available. If that's really the case, you can just work with the BIOS for now and think about converting to using EFI some time in the distant future. There's no need to dislike the BIOS, by the way: people have put millions of man-hours into writing BIOS code, even though the big OSes only use it to get information about available memory and to load in a modest number of sectors, so we're lucky they still put in so much time making sure you can use the BIOS to save data back to all manner of devices.

EFI could be a good or bad thing, it all depends on the direction it moves in and what bit is left out.
As you pointed out, there's no part of the spec that says you need a fall back BIOS emulation or implementation.

But to some, eg: more high level languages, it would be a god send.
In that it would be easier to use C, it will give you a 32bit pm or long mode enter point.
It would give you basic drivers to hardware, including things like basic network drivers.

I found this link very useful when i was writing my code:
http://x86asm.net/articles/uefi-program ... rst-steps/

It includes both C and ASM explanations .

Most motherboards and machines these days ship with EFI. The legacy BIOS emulation layer is loaded as an EFI application, like a native kernel would be.

Remember these things:

• EFI supports non IA-32 platforms. In fact, it was originally specified for Itanium. A binding for ARM has also been defined
• EFI provides services similar to a modern bootloader (e.g. GRUB)
• EFI requires applications to be provided in the PE-32 (32-bit) or PE-32X (64-bit) format
• EFI provides an architecture-independent bytecode format for applications and drivers, so we will no longer have the ridiculous situation where e.g. X.Org on SPARC uses an x86 emulator in order to initialize PC graphics cards; they can instead contain EBC firmware which is usable anywhere

The BIOS is probably not going away in the near future, but it certainly is going away. It doesn't understand GUID partition tables and therefore cannot support disks larger than 2TB.

There is no special documentation for working with EFI from assembly or machine code. It is designed for use from a systems programming language.

I can see most of the points have been covered already, but I'll add a little to that.

SmD wrote:First off, I did not see anything about a requirement for a BIOS to be included for support of older software. Did I just overlook it, or is this actually the case? (If so, my have things changed! When continued legacy support is no longer considered a priority, but rather, something to be ditched whenever seen fit... What's next? x86 processors without real-address mode?)

Even if you don't have hybrid firmware, you can still use virtualization tools anytime. You can't natively run DOS applications with Windows x64 (because long mode is funkier) but you can install DOSBox (or other tools) for that purpose. The Win16 subsystem has also been gone for a long time. How many do you think have complained?

What is the purpose of code in the MBR, if the EFI loads the OS automatically via the GPT?

It's not a MBR, it's a PMBR (the P stands for Protective). The idea is to have a partition in the PMBR covering the entire disk such that when that disk is used on a legacy system, there is no risk of data corruption; it will just look like one full disk. However, you can also synchronize the MBR and GPT (at least for the paritions that the MBR can fully see) in order to have a system that's functional under both BIOS and (U)EFI systems---the T13 committee have written a specification for this purpose.

Hi,

Owen wrote:Most motherboards and machines these days ship with EFI. The legacy BIOS emulation layer is loaded as an EFI application, like a native kernel would be.

Currently UEFI systems do come with a PC BIOS layer, but I'd be very careful. There's a lot of old hardware that exists because of the BIOS and compatibility with old software like DOS.

Consider these things:

• For UEFI, A20 makes no sense (its continued existence is dubious even for BIOS)
• It's already possible that there is no PIT. For BIOS, HPET and SMM would emulate the PIT, but this wouldn't be necessary for UEFI - for UEFI there's no need for the firmware's SMM code to do the PIT emulation.
• Since the original ACPI spec, there's been an "8042" flag in the FADT table that says if the system has an "8042 or equivalent keyboard controller". Newer systems don't - they use USB and SMM to emulate it.
• Since the original ACPI spec, there's been a "PCAT_COMPAT" flag in the MADT/APIC table that says if the system has a "PC AT compatible dual-8259 setup". For UEFI they could just set this flag and let the OS use IO APIC only. Also, because devices drivers in UEFI use polling, there's no need for the firmware itself to configure the IO APIC (or PICs) in a sane/usable state. UEFI does use an IRQ for a timer, but it could use the local APIC timer for that.
• Newer systems have no serial ports, no parallel ports and no floppy controller (all replaced by USB devices). This also means there's no use for the ISA DMA controllers in these systems.

I fully expect that after everyone gets used to UEFI most of the old hardware (everything except CMOS/RTC?) will be removed from the chipset, and a PC BIOS layer won't be possible (without expensive full system emulation/virtualisation) because the hardware needed for compatibility doesn't exist anymore. I'd estimate that it won't be too long before we start seeing "legacy free UEFI" systems, starting from embedded systems and thin clients (maybe in as little as 2 years), and then moving up to mobile devices. After maybe 5 years "legacy free UEFI" might leap over to high-end servers, and eventually find it's way to normal desktop/server systems after that.

The tricky thing for OS developers is not just supporting UEFI, but also making sure their code doesn't rely on the existence of legacy hardware. For example, in the past (during boot, for starting other CPUs) I've assumed there's a PIT and assumed the PIT's IRQ is routed via. the PIC chips (until after the OS sets up IO APIC) - that's 2 assumptions that I wouldn't be comfortable with for UEFI for a start.

Owen wrote:The BIOS is probably not going away in the near future, but it certainly is going away. It doesn't understand GUID partition tables and therefore cannot support disks larger than 2TB.

That's not quite right. The BIOS doesn't understand the old MBR partitioning scheme either. The industry could have easily shifted to GPT without adopting UEFI (e.g. see Love4Boobies comments).

Also note that for the old MBR partitioning scheme, you can have a 2 TiB partition starting at "2 TiB", so you can make it work for disk drives up to 4 TiB (by having at least 2 partitions). That assumes 512-byte sectors though, and hard drives are slowly shifting to 4 KiB sectors. With 4 KiB sectors the MBR partitioning scheme would have worked up to a maximum of 32 TiB.

The other thing I've been seeing a lot in news articles, etc is "UEFI means pretty graphics for firmware". It's annoy how something so wrong could be repeated so often (and good that nobody here has believed it)..


Cheers,

Brendan

Here is my problem with BIOS: I do not feel I can trust it. I mean, what if there were a bug, or some discrepancy from that which you expect? Then what?

Somewhere, I read that some (presumably very old) BIOSes would load the boot sector someplace other than the usual 0x7C00. If an inconsistency in operations such as that is true, how can anything else be trusted?

My approach to BIOS is: Use it as little as possible, and kill it as soon as possible. (I totally agree with a quotation I have read of Linus Torvalds.) I have to use it for acquiring a memory map (which I then attempt to verify) and loading some of my own code, but once I have enough to be autonomous, I rid myself of it. I never even use it for any video output or anything. INT 12, INT 13, and done.

I do not trust it to not overwrite my memory, to not trash registers when returning from my calls to it... Heck, I do not even trust that it has the processor in real-address mode when it transfers control to me.

The only positive I can see with EFI is that it loads all of your code at once. No having to deal with getting a drive's parameters, reading sectors, possibly having to reset the drive, et cetera. Basically, just get a memory map, then disable it as much as possible.

At the person who mentioned the architecture-independent bytecode format: That sounds to me like a lose for everyone. Non-architectural bytecode? So the firmware has to interpret this bytecode and convert it to the processor's native instructions? So, it is slower and less efficient for everyone, rather than only being so for those who are using an alternative processor architecture.

I had hoped that maybe I had overlooked something. Unfortunately, it seems that I had not. Rather than continuing to go to absurd lengths to maintain at least somewhat decent backwards compatibility with older software... Now, that older software is like nothing more than a broken electronics component. Do not repair. Just throw it away, and buy a more recent one. What a sad mindset.

Lastly, no one has addressed my question about relocating the GPT away from LBA 1. If, in the MBR, I was to have the GPT partition not begin until a higher sector, would EFI accept it? Or, would it act as though there was no GPT?

Hi,

SmD wrote:Here is my problem with BIOS: I do not feel I can trust it. I mean, what if there were a bug, or some discrepancy from that which you expect? Then what?

You're just as likely to find bugs in UEFI firmware, or in any other firmware. The only alternative would be to write your own firmware, but it'd take a huge amount of work just to support a fraction of the chipsets/motherboards, and you'll never get sane end-users to flash their BIOS with your buggy firmware (partly because they won't be able to use any other OS ever again).

SmD wrote:Somewhere, I read that some (presumably very old) BIOSes would load the boot sector someplace other than the usual 0x7C00. If an inconsistency in operations such as that is true, how can anything else be trusted?

Some BIOSs load the boot sector at the real mode address 0x07C0:0x0000 (which is the 32-bit physical address 0x00007C00) and some load the boot sector at the real mode address 0x0000:0x7C00 (which is the exact same physical address 0x00007C00). It's a well known (and easily fixed) problem that's caused by poorly defined standards; and it isn't a problem caused by bugs in the BIOS.

SmD wrote:My approach to BIOS is: Use it as little as possible, and kill it as soon as possible. (I totally agree with a quotation I have read of Linus Torvalds.) I have to use it for acquiring a memory map (which I then attempt to verify) and loading some of my own code, but once I have enough to be autonomous, I rid myself of it. I never even use it for any video output or anything. INT 12, INT 13, and done.

Basically, your paranoia prevents your OS from reliably using any video (without native video drivers) because it didn't bother to make sure the video mode is set to anything (including 80*25 text mode) at all?

SmD wrote:The only positive I can see with EFI is that it loads all of your code at once. No having to deal with getting a drive's parameters, reading sectors, possibly having to reset the drive, et cetera. Basically, just get a memory map, then disable it as much as possible.

In my experience, EFI is easier in that you get higher level functions to use, and EFI is also harder because it's more complicated (and because they insist on using high level "C++ pretending to be C" calling conventions that are a pain in the neck for me).

SmD wrote:At the person who mentioned the architecture-independent bytecode format: That sounds to me like a lose for everyone. Non-architectural bytecode? So the firmware has to interpret this bytecode and convert it to the processor's native instructions? So, it is slower and less efficient for everyone, rather than only being so for those who are using an alternative processor architecture.

Nobody cares about performance for stuff that is normally only executed briefly during boot. Everything in EFI does support native binaries - the byte-code stuff is optional, and is mostly only there for device ROMs and EFI applications, not for OS boot loaders.

SmD wrote:Lastly, no one has addressed my question about relocating the GPT away from LBA 1. If, in the MBR, I was to have the GPT partition not begin until a higher sector, would EFI accept it? Or, would it act as though there was no GPT?

GPT uses a redundant pair of partition tables, one at LBA 1 and the other in the last sector of the disk. It would attempt to load the first copy from LBA 1, and if it's not sane it'd attempt to read the second one at the end of the disk. If the second one is sane then it'd probably overwrite LBA 1 with a sane copy of the partition table to correct the original failure. It'll never search through any/all other sectors for "things that might look like partition tables".


Cheers,

Brendan

I think the EFI is a mess and it's one of the reasons i think alot of future OSDev's will move to ARM, as a dev platform.
I know that they want to use EFI for arm device too, but there not a one fits all with ARM's, as there is with x86, or the legacy.
Even the next windows will run on ARM, that spells the end for x86, in the very long term.

Yes, I am definitely paranoid when it comes to code that is not my own.

My mindset is to avoid all assumptions. The more that is assumed, the more that can be different from that assumed.

I think it was even mentioned on the osdev.org wiki that some old BIOSes even tried to be "helpful" by switching to protected mode before passing control to the boot sector.

Like switching to protected mode is that difficult...

EFI sounds very inflexible and demanding. It has to have LBA 1 through whatever, it has to have duplicates of those sectors at the end of the disk... From what I can tell, there is no documentation for low-level programmers like myself.

EFI's successor will have to be much more adaptive. Or, better yet, as another poster suggested, maybe EFI shall be the end of x86. Suddenly, I cannot help but take a curiosity in other architectures...

I hate the idea of having to rewrite everything just because the industry has decided my code is too old to matter. (Or, as is actually the case, that it just tries to be supported on as old a hardware as possible, hoping that the future will retain compatibility.)

SmD wrote:First off, I did not see anything about a requirement for a BIOS to be included for support of older software.

That may be in part because EFI is designed for use on many platforms - if it's on a machine with an ARM processor there's no point in insisting that it include BIOS functions. It does however leave the door open to the BIOS disappearing altogether, but so long as equivalent services are provided, that can't really be a bad thing - it just needs a few little modifications to our OSes. All most of us want is memory information, the ability to change screen mode and services for loading and saving to USB devices (so that it isn't impossibly hard to get your foot in the door). If that can be done while staying in 32-bit mode (or 64), then that's a real gain, and a massive one if you don't have to stop every other processor in the machine while EFI code is running - I assume that's a large part of the intention.

SmD wrote:Here is my problem with BIOS: I do not feel I can trust it. I mean, what if there were a bug, or some discrepancy from that which you expect? Then what?

If there's a significant problem with any BIOS code, someone here will find it pretty quickly and warn everyone, but it doesn't happen very often. If you're just using the BIOS in standard ways, you aren't likely to hit any problem caused by anything other than your own bugs, but if you are lucky enough to find a bug in a BIOS, it will demonstrate that you are a fine entomologist.

My approach to BIOS is: Use it as little as possible, and kill it as soon as possible. (I totally agree with a quotation I have read of Linus Torvalds.)

And if you treat EFI the same way, you aren't going to have a lot to worry about. When it becomes necessary for everyone to use EFI, someone here will put together a tutorial showing you how to boot your OS and get what you need from EFI. The worst case scenario is that you might have to copy a few little bits of code to interface with EFI, and there's no reason why those shouldn't be provided in assembly language form.

I do not trust it to not overwrite my memory, to not trash registers when returning from my calls to it...

The former would be dead easy to identify, and the latter is expected - why would anyone care what it does to the registers? You have to trash a lot more than just registers when you go back into real mode to speak to the BIOS. And if you're only writing an OS to run in real mode, you're wasting most of the capability of the machine.

Heck, I do not even trust that it has the processor in real-address mode when it transfers control to me.

Has anyone ever found a BIOS that doesn't hand back control in real mode after you've called a BIOS service in real mode? Any machine with a BIOS that strange isn't going to matter - just don't support it.

The only positive I can see with EFI is that it loads all of your code at once. No having to deal with getting a drive's parameters, reading sectors, possibly having to reset the drive, et cetera. Basically, just get a memory map, then disable it as much as possible.

The positive is that it does what it needs to do, just as the BIOS does, and it might allow you to use its services without having to undo most of the changes you've made to the setup of your machine every time you use EFI for something - that could be a huge positive. The only real negative is that you will have to write a few unexciting parts of your OS in order to get going, but the important stuff isn't going to change at all, and that's the bulk of your OS (unless you've made the mistake of writing it all in 16-bit mode).

I had hoped that maybe I had overlooked something. Unfortunately, it seems that I had not. Rather than continuing to go to absurd lengths to maintain at least somewhat decent backwards compatibility with older software... Now, that older software is like nothing more than a broken electronics component. Do not repair. Just throw it away, and buy a more recent one. What a sad mindset.

Are you now complaining that they're not continuing to go to absurd lengths to maintain backwards compatibility? Looks like they can't win either way! The reality is that all the old stuff can be still run in an emulator, and it'll still run faster than it did in the machines it was originally designed to run on. EFI might lead to real mode and 16-bit protected mode disappearing from the processor altogether, but that won't be a bad thing if it speeds it up a fraction and reduces its power comsumption. 16-bit mode is horribly restricted for programming in anyway and I doubt any low-level programmer will miss it.

SmD wrote:I am definitely paranoid when it comes to code that is not my own.

My mindset is to avoid all assumptions. The more that is assumed, the more that can be different from that assumed.

If you restrict your OS to code that is entirely your own, how advanced will it ever get? You're going to have to include code written by someone (or something) that isn't you at some stage, and BIOS or EFI code is much better tested than most code.

EFI sounds very inflexible and demanding. It has to have LBA 1 through whatever, it has to have duplicates of those sectors at the end of the disk... From what I can tell, there is no documentation for low-level programmers like myself.

I have no idea how many duplicate sectors are required, but a few wasted sectors aren't going to be missed. Low-level documentation will be created by someone when it's needed. In the mean time, just continue to develop your OS while keeping in mind the things that may need to be changed later on so that you don't paint yourself into a corner.

EFI's successor will have to be much more adaptive. Or, better yet, as another poster suggested, maybe EFI shall be the end of x86. Suddenly, I cannot help but take a curiosity in other architectures...

You might easily move to something else that suddenly takes a turn towards extinction. If legacy stuff can be dropped, x86 is actually more likely to survive - it needs to reduce its power consumption to compete with ARM, and getting rid of 16-bit modes would help.

I hate the idea of having to rewrite everything just because the industry has decided my code is too old to matter. (Or, as is actually the case, that it just tries to be supported on as old a hardware as possible, hoping that the future will retain compatibility.)

If your old code matters, it can run in an emulator. If it's OS code and can't run on the latest machines, it's past it anyway. What kind of code are you actually writing and what are you writing it for? Isn't most of it in 32-bit mode (or 64) already? That isn't going to go extinct for a good long while, and when it does you'll still be able to run it in an emulator - if it's OS code that's all it'll be fit for by then anyway.

SmD wrote:My approach to BIOS is: Use it as little as possible, and kill it as soon as possible. (I totally agree with a quotation I have read of Linus Torvalds.) I have to use it for acquiring a memory map (which I then attempt to verify) and loading some of my own code, but once I have enough to be autonomous, I rid myself of it. I never even use it for any video output or anything. INT 12, INT 13, and done.

I do not trust it to not overwrite my memory, to not trash registers when returning from my calls to it... Heck, I do not even trust that it has the processor in real-address mode when it transfers control to me.

If you don't trust the BIOS to not trash your memory or registers... give up now. After all, the BIOS gets to take control of the CPU at any time by entering system management mode. Maybe it will do it when you write some legacy device, maybe it will do it in response to some external influence.. whatever, the BIOS chooses when it wants SMM entered and it will be entered then.

And additionally, if you want a usable OS, you have no choice but to enable ACPI, which involves executing AML bytecode... which can also request that you connect various system interrupts to it, perform timed events, interact with the hardware and system management mode code. After all, power management support is pretty much mandatory when running on a laptop, and most machines these days are laptops. Well, it is unless you want to run with the machine running at full power all the time and with a half an hour battery life.

Well, the above if you're lucky. If you're unlucky, you'll be running off wall power but the BIOS will have setup the GPU at boot time in a low power state, where next to none of its functionality is available and its on the other end of a 50MB/s bus.

System firmware is generally trustworthy. However, the firmware support for brand new features is often buggy. They generally get better at supporting these things over time; I assume this is because the cycle often starts with the release of enthusiast products (which will be aimed at buyers running Windows), then moves upmarket into servers, where support for other OSes becomes mandatory. The second iteration of enthusiast products is generally better; by that time they've probably merged in the fixes which were developed for the server segment (and if you're lucky the 1st gen enthusiast products will get firmware upgrades to fix their bugs)

EFI is kinda like IPv6. It looks fancy, but not many are really using it.

EDIT: IMO, IPv6 is even fancier than EFI, lol

The difference is that IPv4 is actually insufficient, whereas the legacy bios isn't

DavidCooper wrote:You have to trash a lot more than just registers when you go back into real mode to speak to the BIOS.

Go *back* to real-address mode to speak to BIOS? Why would anyone want to do that? Surely, by the time they are ready to switch to protected mode, one is ready to be autonomous, no? I cannot imagine going back. I mean, I would have to restore the IVT and the memory directly above it that BIOS uses.

"Get information about the memory, load enough code with BIOS to be able to load the rest of the system by myself... Then switch over to protected mode and be done with BIOS."

DavidCooper wrote:Are you now complaining that they're not continuing to go to absurd lengths to maintain backwards compatibility? Looks like they can't win either way!

I was not complaining. In fact, I am glad that backwards compatibility has been made a priority. It is this sudden change towards not caring that disturbs me. To strive for years to maintain support, then all of a sudden say, "On second thought, no. Who cares about old hardware/software?"

DavidCooper wrote:In the mean time, just continue to develop your OS while keeping in mind the things that may need to be changed later on so that you don't paint yourself into a corner.

That is my primary concern. Painting myself into a corner. I aim for compatibility with as old a hardware as possible. But, at the same time, current and future hardware has to also be kept in mind.

The Intel Software Developer's Manuals repeatedly assures you of compatibility with past and future processors. But, at the same time, Intel's EFI seems focused only on the future. Not a word about legacy support.

Owen wrote:If you don't trust the BIOS to not trash your memory or registers... give up now. After all, the BIOS gets to take control of the CPU at any time by entering system management mode.

Oh, yes, SMM. Alas, there is nothing I can do about it. But, since I cannot even detect its occurrence, I just have to accept that whatever it does is fine.

Though, unless I am mistaken, SMM occurs outside the normal execution environment, with its own memory. Or am I thinking of something else?



Okay, one last question: LBA 1. How does the switch to 4,096-byte sectors affect that? Still absolute byte offset 0x200? Or, does that mean what would have been LBA 8 (byte offset 0x1000)?