In the long history of computer development, boot firmware plays a crucial role. From the early BIOS to today’s powerful UEFI, it has continuously evolved to meet the growing performance, security, and management needs of hardware.

Origin: The Golden Age of BIOS

In the 1980s, IBM PC introduced BIOS (Basic Input/Output System), which was etched into the motherboard ROM and took on three major responsibilities for computer startup:

1. Power-On Self-Test (POST): Detecting whether CPU, memory, graphics cards, keyboards, and other hardware are available.
2. MBR Loading and Hardware Interrupt Interface: Reading the primary bootloader from the first sector of the hard disk (Master Boot Record, 512 bytes), and providing unified hardware access capabilities through interrupt calls such as INT 13h/INT 10h.

Although the BIOS architecture was simple and highly compatible, it encountered bottlenecks in the following aspects:

• Disk Capacity Limitations: MBR supports a maximum of 2 TB and up to 4 primary partitions.
• Difficult Firmware Updates: Driver code is hardcoded in ROM, making it inflexible for extension or patching.
• Lack of Graphics and Network Capabilities: Only providing the most basic text interface and simple PXE network microcode loading.

Disruption: The Emergence of UEFI

Entering the 21st century, Intel initiated the UEFI (Unified Extensible Firmware Interface) alliance, aiming to create a more flexible, extensible, and secure boot environment.

• GPT Partition Support: Breaking through TB-level storage limitations, capable of managing hundreds of partitions.
• Modular Drivers: Extending hardware support through loadable .efi drivers without flashing ROM.
• Modern Graphical Interface: Supporting GUI, mouse, and multiple languages for more user-friendly interactions.
• Security and Remote Management:
  • Verifying signatures of boot programs and operating systems at each stage to prevent tampering and rootkits (Secure Boot).
  • Built-in HTTP/FTP clients and UEFI Shell for remote updates or script execution.

Brief UEFI Boot Process

1. Parallel Firmware Initialization: Multi-threaded loading of hardware drivers and firmware components.
2. Scanning ESP: Reading the EFI System Partition (FAT32 format), looking for .efi files under the \EFI\ path.
3. Running Boot Manager: Executing EFI applications according to the boot option order stored in NVRAM.
4. Loading Kernel: EFI applications (such as bootx64.efi) boot the operating system kernel and transfer control to it.

Comparative Summary

Real-World Choices and Migration

• Legacy Devices & Embedded Systems: BIOS+MBR remains effective due to small size and strong compatibility.
• Modern PCs & Servers: UEFI+GPT is standard, improving boot speed, security, and large disk support.
• Dual/Multi-Boot Systems: Recommended to standardize on UEFI mode, using BCD for Windows and shim+GRUB EFI for Linux to reduce boot conflicts.

Migration Key Points:

• BIOS → UEFI: Back up data, use Windows mbr2gpt or Linux gdisk to convert to GPT, create an ESP ≥100 MB, switch firmware mode, and rebuild the boot.
• UEFI → BIOS: Convert GPT to MBR (note the loss of GPT information), rewrite traditional MBR boot code, and adjust firmware to Legacy mode.

Common Boot Issues and Troubleshooting Techniques

1. Unable to Recognize ESP
   • Check partition type: ESP must be set to EF00 (GPT) or FAT32 (MBR).
   • Verify files: Confirm that \EFI\BOOT\BOOTX64.EFI (or corresponding platform) exists.
2. Secure Boot Errors
   • Disable or configure: Enter firmware settings, temporarily disable Secure Boot, or import the correct public keys (PK/KEK).
3. Missing Boot Options
   • Use efibootmgr (Linux) or bcdedit (Windows) to recreate boot entries.
4. Unable to Boot After Switching Disk Mode
   • Check controller mode: After switching IDE/RAID/AHCI, kernel modules and driver signatures need to be updated synchronously.

Advanced Customization and Extensions

• UEFI Shell Automation: Write .nsh scripts to automatically mount partitions, perform self-tests, or remotely download firmware updates.
• Driver Injection: Place vendor .efi drivers in ESP to extend native support for NVMe, RAID controllers, etc.
• Variable Management: Use dmpstore (Shell) or efivar tools to read and write firmware variables, enabling automated startup or log collection.
• Open Firmware Alternatives: Such as TianoCore (OVMF), Coreboot, can be customized for size and functionality as needed.