问题
I was studying about bootloaders when exactly came upon the term UEFI. I can understand some things about UEFI. But still, In what mode(Real,Protected,Long) does a system with UEFI start? If normal boot loaders cant work with UEFI, Then what is the alternate of boot loader while dealing with UEFI? And do I need any other programming to create one, than assembly?
回答1:
UEFI firmware runs in 64 bit long mode for 64 bit platforms and flat mode for 32 bit platforms; Unlike BIOS, UEFI features its own architecture, independent of the CPU, and its own device drivers. UEFI can mount partitions and read certain file systems.
When an x86 computer equipped with UEFI, the interface searches the system storage for a partition labeled with a specific globally unique identifier (GUID) that marks it as the EFI System Partition (ESP). BTW Windows doesn't mount this partition and you cannot see it in the OS. But there is a trick, you simply change the partition type (using HexWorkshop) in VBR to regular FAT32 code and it will be mounted into the OS.
This partition contains applications compiled for the EFI architecture. In general you don't have to deal with assembler to write a UEFI application/loader, it's just a regular C code. By the default it is located at "EFI/BOOT/BOOTX64.EFI". When a bootloader is selected, manually or automatically, UEFI reads it into the memory and yields control of the boot process to it.
回答2:
Here's a good answer to this question:
Other modern 64-bit machines have new EFI firmwares. These don't load a bootstrap program from sector #0 of a disc at all. They bootstrap by the EFI Boot Manager loading and running an EFI boot loader application. Such programs are run in protected mode. This is the EFI bootstrap process.
EFI firmwares in general switch to protected mode within a few instructions of exiting processor reset. Switching to protected mode is done early on in the so-called "SEC Phase" of EFI firmware initialization. Technically, 32-bit and greater x86 processors don't even start in real mode proper, but in what is colloquially known as unreal mode. (The initial segment descriptor for the CS register does not describe the conventional real mode mapping and is what makes this "unreal".)
As such, it could be said that those EFI systems never enter real mode proper at all, when bootstrapping natively to an EFI bootloader (i.e. when they don't employ a compatibility support module), since they switch from unreal mode directly to protected mode and stay in protected mode from then on.
回答3:
When you asked "In what mode(Real,Protected,Long) does a system with UEFI start?", what do you mean? The processor starts executing in a mode that is similar to the mode of the 80386 of the past. But do you really care. Don't you really care about the mode of the processor when your OS loader code is given control? And you care about what services are provided to your OS loader code.
The environment is defined in the UEFI spec. Latest Versions of the UEFI Specifications
As for which language you use, assembly is good to start with. It's probably easier to use C or some other high level language after a bit.
Other background:
There are a lot of terms here that we are not always careful about using correctly.
The code that executes when the processor comes out of reset is system firmware that does a lot of initialization of various hardware in the system.
In the old days on a x86 PC system before the UEFI Forum existed, the system firmware was called BIOS. The BIOS in those days executed all of its initialization code, then loaded some code off of a floppy diskette or the hard drive and jumped into the code. The BIOS also provided some interfaces between the hardware and the operating system to help isolate the OS from hardware differences. Nothing was standardized though. The only standards were the OS and applications level software that used the BIOS interfaces.
If the OS and apps functioned correctly then the BIOS was considered correct. But you could only prove correctness by lack of failure. Thus new OSs or applications would work on one correct system yet fail on a different correct system.
Today we've tried to provide some actual standardization of those interfaces. They are defined by the UEFI Forum. Today I can prove that my system is correct according to meeting the UEFI specifications.
When people say things like the UEFI, they are usually referring to the actual system firmware installed on the system that is executed before the OS starts executing. But a lot of us still toss around these terms like we've spilled alphabet soup.
The boot loader is actually OS owned code that is loaded in memory by the system firmware and the system firmware gives control of the hardware to the boot loader. One could say that the end of the system firmware is the UEFI Boot Loader. Or you could just say BDS uses the system policy to find the OS. And you could still find someone that disagreed with the words.
回答4:
If you wish to know more about how UEFI works then the post UEFI boot: how does that actually work, then? by Adam Williamson is highly recommended.
He answers the questions you have and its a good read:
Now let’s look at how booting works on a UEFI system. Even if you don’t grasp the details of this post, grasp this: it is completely different. Completely and utterly different from how BIOS booting works. You cannot apply any of your understanding of BIOS booting to native UEFI booting. You cannot make a little tweak to a system designed for the world of BIOS booting and apply it to native UEFI booting. You need to understand that it is a completely different world.
The Wikipedia page Unified Extensible Firmware Interface is also a useful resource.
来源：https://stackoverflow.com/questions/32223339/how-does-uefi-work