GPT vs MBR && BIOS vs. UEFI

• UEFI systems require an EFI System Partition.

BIOS systems that are partitioned with GPT require a BIOS boot partition if GRUB is used as the bootloader.
 
GUID Partition Table (GPT) is an alternative, contemporary, partitioning style; it is intended to replace the old Master Boot Record (MBR) system. GPT has several advantages over MBR which has quirks dating back to MS-DOS times. With the recent developments to the formatting tools fdisk (MBR) and gdisk (GPT), it is equally easy to get good dependability and performance for GPT or MBR

If you are partitioning a disk of 2 TiB or larger, you need to use GPT.

https://wiki.archlinux.org/index.php/partitioning

• Compared with MBR disk, A GPT disk can support larger than 2 TB volumes where MBR cannot.

GPT disks also support up to 128 partitions rather than the 4 primary partitions limited to MBR
GPT keeps a backup of the partition table at the end of the disk. Furthermore, GPT disk provides greater reliability due to replication and cyclical redundancy check (CRC) protection of the partition table


BIOS
The name originated from the Basic Input/Output System used in the CP/M operating system in 1975
The fundamental purposes of the BIOS are to initialize and test the system hardware components, and to load a bootloader or an operating system from a mass memory device.
The BIOS additionally provides abstraction layer for the hardware, i.e. a consistent way for application programs and operating systems to interact with the keyboard, display, and other input/output devices

UEFI
The Unified Extensible Firmware Interface (UEFI)
UEFI is meant to replace the Basic Input/Output System (BIOS) firmware interface


BIOS vs. UEFI
UEFI enables better use of bigger hard drives. Though UEFI supports the traditional master boot record (MBR) method of hard drive partitioning, it doesn't stop there. It's also capable of working with the GUID Partition Table (GPT), which is free of the limitations the MBR places on the number and size of partitions. GPT ups the maximum partition size from 2.19TB to 9.4 zettabytes.

Technical changes abound in UEFI. UEFI has room for more useful and usable features than could ever be crammed into the BIOS. Among these are cryptography, network authentication, support for extensions stored on non-volatile media, an integrated boot manager, and even a shell environment for running other EFI applications such as diagnostic utilities or flash updates. In addition, both the architecture and the drivers are CPU-independent, which opens the door to a wider variety of processors (including those using the ARM architecture, for example).

https://wiki.manjaro.org/index.php?title=Some_basics_of_MBR_v/s_GPT_and_BIOS_v/s_UEFI

• Traditionally, the system BIOS performs initialization, boot, system management, and configuration tasks. The

BIOS initializes the system’s processors, memory, bus controllers, and I/O devices. After initialization is
complete, the BIOS passes control to operating system (OS) software. The OS loader uses basic services
provided by the system BIOS to locate and load OS modules into system memory. After booting the system,
the BIOS and embedded management controllers execute system management algorithms, which monitor
and optimize the condition of the underlying hardware. BIOS configuration settings enable fine-tuning of the
performance, power management, and reliability features of the system


Comparing UEFI and Traditional BIOS
This sections explains how UEFI corrects certain shortcomings in traditional BIOS implementations. The UEFI
boot mode offers:
 Improved Partitioning scheme for boot media
o Support for media larger than 2 TB
o Redundant partition tables
 Flexible handoff from BIOS to OS
 Consolidated firmware user interface
 Enhanced resource allocation for boot device firmware

Partitioning Scheme for Boot Media
Traditional BIOS implementations use the Master Boot Record (MBR) scheme for partitioning boot media.
Because it uses 32-bit addressing and 512-byte blocks, the MBR scheme limits the addressable storage in
the boot media to 2 TB. The MBR scheme also limits the number of partitions to four, and expects bootstrap
code to reside at specific locations in the media.
UEFI defines an improved partitioning scheme known as a GUID Partition Table (GPT). The GPT scheme
uses 64-bit addressing, so the boot media can be much larger than 2 TB. Each entry in the table is identified
by a 128-bit Globally Unique Identifier (GUID), so the scheme supports a large number of partitions. Bootstrap
code is no longer required at fixed locations, and a backup partition table provides redundancy


Handoff from BIOS to Operating System
After performing system initialization, the BIOS attempts to transfer control to an operating system. Traditional
BIOS implementations maintain a prioritized list (“boot order”) of bootable media in the system, and attempt to
launch boot software according to the list of media. For each entry in the list, the BIOS loads bootstrap code
from a well-known location and passes control to it; if the attempt fails, the BIOS attempts subsequent entries
in the list.
UEFI implementations also maintain a boot order, but each entry corresponds to an individual file instead of
an entire bootable medium. This scheme allows for one medium (such as a hard disk) to contain multiple boot
order entries (for example, multiple operating system loaders). Since each entry specifies the location of the
boot file, UEFI also supports booting via Uniform Resource Identifiers (URIs).
Unlike traditional BIOS implementations, all bootable files (executable bootstrap images) must be formatted
according to the Portable Executable / Common Object File Format (PE/COFF). This requirement applies to
any code executed by the BIOS, including device firmware (traditionally called “option ROMs”), pre-boot
execution environment (PXE) boot programs, and operating system loaders


UEFI defines a shared user interface known as the Human Interface Infrastructure (HII). A user can configure
all the firmware settings - including BIOS, onboard management controller, and boot devices – using a single
user interface, without needing a reboot between changes for each device. HII also facilitates remote
configuration of all firmware settings via baseboard management controller interfaces.

Traditional BIOS implementations offer limited memory space for boot device firmware. Boot devices such as
storage controllers and network interface controllers require increasing amounts of memory to execute their
firmware during the boot process. When a system contains multiple boot devices, a traditional BIOS may not
allocate enough memory space for all of the device firmware to execute.
UEFI eliminates this limitation by defining standard interfaces for memory management. In UEFI boot mode,
boot devices use these interfaces to request memory space from the BIOS memory manager. When a system
contains multiple boot devices, UEFI boot mode allocates memory on-demand for each device’s firmware.

Boot Mode Considerations: BIOS vs. UEFI
DELL EMC

• What is expansion ROM for BIOS ?

The purpose of the BIOS is to initialize the system before calling the boot loader to start the OS.
After completing the motherboard initialization, the BIOS start scanning for option ROM modules (expansion ROM) on the various devices. The expansion ROM includes device-specific initialization code. Once the BIOS identifies a compatible expansion ROM, it will simply call it. After the device specific code is executed, it will return the control back to the BIOS.
What changed with the introduction of UEFI?
Unified Extensible Firmware Interface (UEFI) is replacing and extending the traditional BIOS.
Traditional BIOS does not specify the behavior of the vendor’s code on the expansion ROM, so different vendors may have very different implementation. In contrast, UEFI’s spec clearly defines division of labor between the BIOS itself and the expansion ROMs. The standard defines a variety of functionalities or Services.
Each module manufacturer can implement any subset of these Services, so the behavior becomes uniform across vendors.
Once the UEFI BIOS identifies a compatible expansion ROM, it will use the API as defined in the spec to query the module’s capabilities and utilize the implemented functionalities.
Common functionalities can be implemented by the BIOS itself, e.g. significant parts of PXE boot.
https://community.mellanox.com/docs/DOC-1852