Why does BIOS needs to load first stage boot loader from MBR, but this is not the case with UEFI?
I guess it might be because BIOS cannot address 64 bits(as well as 32 bits) memory while UEFI has direct access to all of the memory. Or am I wrong?
-
The short answer is “because it does”. The slightly longer answer, is “because it has to be standardised, and if it was any different, then it would be different and therefore not complying to the standard, and there for not work.” It is like screw threads, or what side of the road to drive on, etc. There are many ways that can work, but we have to agree or it will stop working. – ctrl-alt-delor Jan 28 '15 at 21:51
Add a comment
|
MBR is a partitioning scheme (a layout for how partitions appear on disk). The classic BIOS doesn't know about partitions. It simply loads 512 bytes from sector 0 of a boot disk (originally known as Cylinder-Head-Track, now usually Logical Block Addressing), verifies a two byte signature, and runs the code if the signature matches. The BIOS's first stage boot loader is one 512 byte area of the disk loaded with 16-bit execution code, with two bytes reserved for a signature.
In contrast, UEFI does know about MBR and GPT, and can use either partition system to load the first stage loader files, which is a pre-OS boot environment located in a specifically defined partition, and can even be tailored to boot across multiple chip types, with various amounts of physical memory available, etc.
A BIOS that implements UEFI knows how to read (certain types of) partitions and load that code in memory. Once loaded, a UEFI boot environment can use 32-bit mode or 64-bit mode, load an OS from anywhere on a disk, and offer additional services, such as choosing an OS to load, verifying boot conditions are safe, etc. UEFI uses an entire partition as its first stage boot loader.
BIOS was traditionally restricted from switching CPU modes (enhanced mode, long mode, etc) or altering the A20 gate, which would alter the boot conditions of the OS. These limitations also meant that the sector 0 boot loader would be limited in how much memory it could access or sectors it could load. Also, the first stage boot loader in such a scenario also usually needed most of the space it had available to load the second stage boot loader, and thus couldn't afford to switch CPU modes, enable more memory, etc.
The second stage boot loader had to be physically present within a certain offset on the disk to be boot-sector bootable. Basically, everything about BIOS was maintained for backwards compatibility. Boot sector code had to be 16-bit mode initially, although it could switch to 32-bit mode if it knew the next stage was in 32-bit mode, but it was hard to take the limited space available to do anything more than load more data from a disk and jump to that location.
Also, using 32-bit mode would reduce the remaining number of instructions it could execute accordingly. Finally, BIOS supplied its "drivers" only in 16 bits, so changing the mode of the CPU would effectively disable use of the BIOS, something you wouldn't want to do until the second-stage boot loader, when you had time to load core drivers, etc.
You can install DOS 5.0 (or even earlier versions) on a new, 8-core processor with 16GB of memory and a 4TB hard drive, and as long as the BIOS supports boot-sector loading, and as long as it provides the necessary BIOS calls (e.g. disk read/write/seek, keyboard interrupt, etc), your programs will still run within the limitations of the underlying OS (e.g. you could only partition some of the hard drive space, access some of the installed memory, and use just 1 core). The latest and greatest hardware still typically supports code written thirty years ago or more, even on bare metal (i.e. without a virtual machine or emulator).
-
"UEFI uses an entire partition as its first stage boot loader" is a bit incorrect. It uses a file that just needs to be stored in a partition that it can read, and the only filesystem type it is required to be able to read is FAT. – psusi Feb 3 '15 at 13:54
-
@psusi - no, I don't think so - I think phyrfox hit it right on. If a BIOS's first-stage is a 512-byte block of code which can locate the second-stage, then translated to an EFI-context the first-stage is the file-system - which is the code that is run to find the EFI-executable within. – mikeserv Feb 3 '15 at 15:14
-
It's true that technically an OS could be installed in the FAT partition, but no major OS uses FAT as a system partition anymore. FAT wastes disk space, has no security model built in, and only supports limited space. Even if an OS did use FAT, you wouldn't want users to be operating in the same space as a matter of users monkeying around in a partition that could render their computer inoperable if they deleted just one single file. – phyrfox Feb 3 '15 at 16:13
-
@mikeserv, that's not what he said ( or at least not the part I quoted ).. the part I quoted says that the whole partition is the boot loader.. that's not true... it's a filesystem that holds various files, one of which is a bootloader ( and there can be multiple ones installed, which was always a problem with bios ). – psusi Feb 3 '15 at 20:04
-
Besides one or more boot loaders, the ESP can also contain EFI drivers and applications. Likewise, the firmware could support filesystems other than fat and then you don't need the ESP. I believe some Macs have support for booting directly from hfs. There's an open source EFI firmware implementation out there and while I haven't checked, I'd bet it can boot directly from ext4. – psusi Feb 3 '15 at 20:08
BIOS is an older standard left from the older IBM compatible 16-bit days. It could only address 1 MB of memory and did not take advantage of the latest advances in modern personal computers. UEFI supports using GPT, the GUID Partition Table. Using GPT allows addressing a much larger disk and partition space (up to 8 ZB (8 × 270 bytes). UEFI also explicitly supports FAT format file systems. Other formats may optionally be supported, we are not limited to FAT and NTFS in the firmware.
-
Yep, I read about this. Though it is not clear why UEFI does not need to load first stage boot loader from MBR. What is the major reason for that? – YohanRoth Jan 28 '15 at 21:51
-
According to the FreeBSD wiki link, "The UEFI boot process uses an EFI System Partition (ESP) to store system bootstrap components. The ESP is a GPT or MBR partition with a specific identifier, and contains a FAT file system with a specified hierarchy." So it can, but does not need to boot from the MBR. – DDay Jan 28 '15 at 22:07
Your guess is close, but wrong. the real limits are 640k and the size of the bios rom which created the convention which is the constraint which limits bios boots to this day. EFI is big. it is actually more powerful and useful than early versions of DOS by a significant amount, It can read and write files directly. It would have been exceptional expensive to put on a early rom array (notice i did not say chip, I don't think you could have fit it on four!) Until dos was loaded (which understood filesystems and files) the bootloader could only use blocks, that is ask the bios to read this block or that block from the disk, and bios would only look for the bootloader in the first block on the disk.
