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?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
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).
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.
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.