OSDev.org

I got a new laptop the other day, and it uses UEFI. You can use "legacy mode" to use BIOS, but I am scared that UEFI will replace BIOS in the future and from what I've read about UEFI (not much actually), it doesn't sound good.

Has anyone made their OS work with UEFI? If so, is it alright?

Conceptually, UEFI is a very good idea (Replacing the old RMode bios with something more extensible). However, I have not (yet) attempted to OSDev with it, but from what I've seen, you can still use grub to boot you using multiboot and just not care that there's UEFI at the low level (except that VBE is now unavaliable).

I already run an UEFI system (no legacy involved) on my desktop and in practice there's little difference, other than GRUB having gone the way of the trash.

What you should not forget is that UEFI actually allows you to make calls to the firmware without having to switch to realmode and whatnot, doesn't stick you with an 1MB limit to load stuff, and more of those legacy nuisances.

What you've probably read about is the SecureBoot eature. There was some concern that most firmware vendors wouldn't let users manage their keys, meaning the choice of OS would have been that of the vendor's instead of that of the user's. Or that the user would have been forced not to use the feature (if disabling it was an option). This didn't happen, though.

UEFI is not bad as it seems.
1. It is removing Real Mode addiction. This is a REALLY good thing.
2. No boot sectors, 0x7C00's,512 byte-addiction,16 bit puke etc.
3. Your bootloader is not loaded in puke Real Mode, and UEFI is
capable of loading a whole file from the FAT disk. Plenty of disk space + RAM.
4. Much easier, C compilers like GCC are able to produce EFI Based code, without
any ridiculous tweaking or forcing the poor compiler to write 16-bit code.
5. EFI does provide services like the BIOS, except that you don't have to stick to 1MB or
some 10000000 limitations.
The wikipedia page about EFI says the following.

EFI defines two types of services: boot services and runtime services. Boot services are only available while the firmware owns the platform (before the ExitBootServices call). Boot services include text and graphical consoles on various devices, and bus, block and file services. Runtime services are still accessible while the operating system is running; they include services such as date, time and NVRAM access. In addition, the Graphics Output Protocol (GOP) provides limited runtime services support. The operating system is permitted to directly write to the framebuffer provided by GOP during runtime mode. However, the ability to change video modes is lost after transitioning to runtime services mode until the OS graphics driver is loaded.

nerdguy wrote:1. It is removing Real Mode addiction. This is a REALLY good thing.

I think you're probably overstating the benefits of not needing real mode. Sure, a step in the right direction, but I don't see too much practical importance.

nerdguy wrote:2. No boot sectors, 0x7C00's,512 byte-addiction,16 bit puke etc.

• At least for PXE, it already meant no boot sectors.
• 7C00h is irrelevant---things still need to be loaded somewhere. Who cares where that is? (There's something to be said about faulty RAM here.)

4. Much easier, C compilers like GCC are able to produce EFI Based code, without
any ridiculous tweaking or forcing the poor compiler to write 16-bit code.

Strictly speaking, it's a C dialect. The (U)EFI C requires sizeof to be a function rather than an operator, as it normally is.

I find this page useful for an Introduction to UEFI. (Just wanted to share with you people in case anyone finds it interesting)
http://www.rodsbooks.com/efi-programming/index.html

What's bothered me the most about UEFI until today is the difficulty in saving data back to flash drives without having to conquer USB first, but it looks as if this EFI service can actually handle that http://wiki.phoenix.com/wiki/index.php/ ... sfer.28.29, just so long as you don't exit EFI boot services. It may even be able to handle multiple flash drives and allow them to be plugged in and out and continue to be used, unlike with the BIOS (which will reject them after they've been removed and plugged back in, and which doesn't even like an SD card being changed for an identical one). If these capabilities really work that way, or even if they only work as well as the BIOS (has anyone tried them out for anything other than loading their OS?), it means EFI could still be a good environment for the early development of an OS even if the OS designer wants to be able to do useful work with that new OS from early on without having to write his/her own USB drivers first (as in my case where my OS has from the beginning been a self-sufficient development platform capable of modifying and saving itself, and where I've also been using my text editor to write a book, where again it's vital to be able to save data).

There will doubtless be a point at which things break as you change the setup of the machine, at which time you would need to bite the bullet and get your own USB code written, but it looks as if you may be able to reap the rewards of writing a simple OS to run in an EFI environment without having vast amounts of complex code to write before you reach that stage. I don't think I'll explore that route now myself as I've already gone down the BIOS-dependent route already and am at the point where writing my own USB drivers is the next logical step anyway (after which I will be able to write code to boot on EFI machines without any need to depend on EFI services beyond setting a screen mode and picking up a few pieces of information about things such as memory), but if I was starting out from scratch today I'd be looking at EFI instead as it may actually be better than the BIOS even for for someone who wants to be able to do useful work with their OS from the outset.

BMW wrote:Has anyone made their OS work with UEFI? If so, is it alright?

Yes, I did. And it's a real nightmare. You'll find BIOS easy and nice.

Basically, you have to link a special PE executable, and place it under "\EFI\BOOT\BOOTX32.EFI" on a FAT partition labelled "EFI System" of a GPT disk. Since there's a minimum limit for FAT32 (FAT12 and FAT16 not surely supported), your loader partition will need at least 64Mb. Next (if your code get's called on boot by some voodoo magic), you'll have to walk through pointer tables, and pray to find UUIDs you want and play being CPU looking up IDT entries (but with different tables)), and try to avoid calling malicious code (no checks on service entry points at all). Technically every EFI loader application eager to call EFI ExitBootServices and get the hell out of there. Oh, and it has a really big overbloated SDK.

Does anybody really think this is easier or better than 512 bytes of code at 7C00h with well defined environment and services? Remember, computer use this code only for a small fraction of time. And it uses that to boot something else that has it's own way to communicate with the hardware anyway.

But, EFI is the way to go to boot your OS on modern machines.

Luckily the big mess can be smaller, you can use an assembler to produce that special PE (similar to writing a BIOS boot record).
Calling EFI services should be straightforward using the library on our wiki: uefi.inc

Good luck!

512 bytes of code at 7C00h with well defined environment and services

lol

Griwes wrote:

512 bytes of code at 7C00h with well defined environment and services

lol

Well,
Int 16/AH=00h and AH=01h for getting user input
Int 13/AH=0Ah and AH=42h for reading sectors into memory
did not change much in the last few decades. Nor did the VGA. What else do you need for a fancy OS loader?

OS kernels have their own way to do things, they do not rely on boot firmware once they are up and running.

turdus wrote:Int 13/AH=0Ah and AH=42h for reading sectors into memory

Under some circumstances, you may need to use AH=02h instead. For example, a USB device that the BIOS has decided to emulate in "superfloppy" mode.

Octocontrabass wrote:Under some circumstances, you may need to use AH=02h instead. For example, a USB device that the BIOS has decided to emulate in "superfloppy" mode.

Who cares? Never saw BIOS and USB stick behave like that, those circumstances are marginal errors.
As a matter of fact AH=42h alone enough to boot from any fixed disk (ide, ata, sata, etc.) or removable USB storage (ahci,uhci,ehci) manufactured in the last decade or so. I did not implement anything else in my bootloader, yet never had any problem with booting my OS on real hardware from a pendrive or sd card.
On the other hand I experienced problems finding the UEFI block protocol when booting on real hardware. Currently I do not have proper fallback solution if it's not found

turdus wrote:Who cares? Never saw BIOS and USB stick behave like that, those circumstances are marginal errors.

You have not looked hard enough: most BIOSes only allow AH=42h if the first sector is a "valid" MBR, and each BIOS uses different criteria. Most only check for a partition table, but some also check that the partitions don't overlap, or that one of them is marked bootable. One BIOS checks for a FAT BPB!

If you like to boot Linux ISOs from a flash drive (using isohybrid), you've probably seen a computer boot without using AH=42h, since the isohybrid boot sector is not "valid" enough for many BIOSes.

Octocontrabass wrote:most BIOSes only allow AH=42h if the first sector is a "valid" MBR

Where did you get such a nonsense? Let's make this clear: AH=42h reads a sector from disk to memory, nothing more, nothing less.

Octocontrabass wrote:Most only check for a partition table, but some also check that the partitions don't overlap, or that one of them is marked bootable.

Wrong again. No BIOS checks for partition table of any kind, it's the job of MBR code. As the last step of POST, BIOS checks whether the first sector has a magic, and if yes, transfers control to it. That's all, and it has nothing to do with sector loading nor with partition tables. Writing a VBR in place of MBR would boot just fine, give it a try.

Octocontrabass wrote:One BIOS checks for a FAT BPB!

Wrong again. No BIOS checks for BPB, it's the job of VBR code. Besides, it would mean BIOS can only boot from FAT, which is simply not true.

Octocontrabass wrote:If you like to boot Linux ISOs from a flash drive (using isohybrid), you've probably seen a computer boot without using AH=42h, since the isohybrid boot sector is not "valid" enough for many BIOSes.

I don't care linux boot hacks. I was talking about BIOS Boot Specification.

Let's make this to an end. You are not aware of basic terms, and how an IBM compatible PC boots up, and this thread is about using UEFI anyway.

Have a nice day and don't learn too hard.