[New Friends]Click “Haiyun Internet” above to follow us[Old Friends] Click the “•••” in the upper right corner of the screen to share
1. EFI (Extensible Firmware Interface)
Introduced by Intel, a leading company in personal computer technology development, as an upgrade solution to replace BIOS in future PC-like computer systems. The rise of BIOS technology originated from the popularity of IBM PC/AT machines and the first “clone” PC developed by Compaq. During the PC boot process, BIOS is responsible for initializing hardware, detecting hardware functionality, and booting the operating system. In earlier times, BIOS also provided a set of runtime service programs for the operating system and application programs. The BIOS program is stored in a read-only memory that retains its content even after power loss. When the system is powered on, the address of the first instruction executed by the processor is located in the BIOS memory, facilitating the execution of the initialization program.
Origin of EFI
It is well known that Intel has led the PC technology trend based on the x86 series processors for nearly two decades, with its products like CPUs and chipsets occupying an absolute leadership position in the PC production line. Therefore, many believe this move demonstrates Intel’s ambition to enter the firmware product market. In fact, EFI technology originated from the launch of Intel’s Itanium processor platform. The Itanium processor was designed by Intel with nearly ten years of research and development aimed at the high-end server market, featuring a completely different 64-bit architecture from the x86 series. As x86 processors transitioned to 32-bit, compatibility issues led to the new processors (i80386) retaining a 16-bit operating mode (real mode), and subsequent upgrades continued to maintain this operating mode. Even in the Xeon series processors, which include 64-bit extensions, the processors still switch to 16-bit real mode at power-up. Intel attributes this situation to the slow development of BIOS technology. Since PC-compatible manufacturers replicated the first set of BIOS source code through clean room methods, BIOS has existed in the form of 16-bit assembly code, register parameter calling methods, static linking, and fixed addressing below 1MB for more than a decade. Although many new elements have been added to products by major BIOS manufacturers in recent years, such as PnP BIOS, ACPI, and traditional USB device support, the fundamental nature of BIOS has not changed. This has forced Intel to consider adding compatibility modes that significantly reduce performance when developing newer processors. Someone once likened this to a new generation of Porsche fully automatic sports cars being fitted with a clunky manual gearbox.
However, the Itanium processor does not have such concerns; it is a new processor architecture where the interface between system firmware and the operating system can be completely redefined. This time, Intel defined it as a scalable, standardized firmware interface specification, differing from the traditional BIOS, which is fixed, lacks documentation, and is based entirely on experience and obscure conventions. The first system product based on EFI has been around for five years now, and Intel is attempting to promote the successful technology used in high-end servers to the more advantageous PC product line, promising to invest fully in technical support during 2006.
Comparison of EFI and BIOS
A significant difference is that EFI is constructed using a modular, C language-style parameter stack-passing method and dynamic linking, making it easier to implement and with stronger fault tolerance and error correction features compared to BIOS, thus shortening system development time. It operates in 32-bit or 64-bit mode, and even in future enhanced processor modes, breaking through the traditional 16-bit code addressing capability to achieve the processor’s maximum addressing. It utilizes EFI drivers to identify and manipulate hardware, unlike BIOS which uses mounted real-mode interrupts to add hardware functionality. The latter must place a segment of 16-bit code, similar to a driver, in the fixed storage area between 0x000C0000 and 0x000DFFFF, running the initialization portion of this code, which provides services to other programs through the agreed-upon interrupt vectors in real mode. For instance, VGA graphics and text output interrupts (INT 10h), disk access interrupt services (INT 13h), etc. Due to the limited storage space (128KB), BIOS is powerless when the size of the required driver code exceeds the available space. Additionally, BIOS hardware service programs exist in 16-bit code form, complicating access for operating systems running in enhanced mode. Therefore, the services provided by BIOS can only realistically be used by operating system boot loaders or MS-DOS-like operating systems. In contrast, the drivers in an EFI system are not composed of code that can be directly executed on the CPU, but are written in EFI Byte Code. This is a set of virtual machine instructions specifically for EFI drivers, which must be interpreted and executed in the Driver Execution Environment (DXE). This ensures sufficient downward compatibility; for example, an extended device with an EFI driver can be installed in both an Itanium processor system and a new PC system that supports EFI without needing to rewrite its EFI driver. Thus, there is no need to consider compatibility factors arising from system upgrades. Furthermore, as EFI driver development is simple, all PC component providers can participate, creating a situation very similar to modern operating system development models, which allowed Windows to become a powerful and high-performance operating system in just two to three years. The EFI driver model allows EFI systems to access all hardware features, making it no longer a dream to browse the World Wide Web before the operating system runs, and it can even be implemented very easily. This is an impossible task for systems based on traditional BIOS; adding simple USB device support in BIOS has often caused great distress to many BIOS designers, not to mention the need to construct a TCP/IP protocol stack in 16-bit mode while adding support for numerous network hardware.
Some people believe that BIOS is merely an inconsequential remnant left over due to compatibility issues, not worth significant upgrade efforts. In contrast, opponents argue that when the emergence of BIOS restricts the development of PC technology, necessary changes must be made.
EFI and Operating Systems
Conceptually, EFI is very similar to a low-level operating system and has the ability to control all hardware resources. Many feel that its continued development may potentially replace modern operating systems. In fact, the creators of EFI limited its capabilities in the first version specification to ensure it does not threaten the dominance of operating systems. First, it is merely an interface specification between hardware and pre-boot software; secondly, the EFI environment does not provide an interrupt access mechanism, meaning each EFI driver must poll to check hardware status and needs to run in an interpreted manner, which is less efficient than drivers under operating systems; furthermore, the EFI system does not provide complex memory protection features, only possessing a simple memory management mechanism, specifically referring to the flat segment under the segment protection mode of x86 processors, where all programs have permission to access any segment without providing real protection services. Once all components of EFI are loaded, the system can open a command interpretation environment similar to an operating system shell, where users can invoke any EFI application. These programs can include hardware detection and debugging software, boot management, configuration software, operating system boot software, etc. Theoretically, there are no restrictions on the functionality of EFI applications; anyone can write such software, and the effects can be more elegant and powerful than previous MS-DOS software. Once the boot software hands over control to the operating system, all services code used for booting will cease to operate, while some runtime service programs may continue to work to allow devices to be used even when the operating system cannot find specific device drivers.
Components of EFI
EFI is generally considered to consist of the following components:
1. Pre-EFI Initialization Module 2. EFI Driver Execution Environment 3. EFI Driver Programs 4. Compatibility Support Module (CSM) 5. EFI High-Level Applications 6. GUID (GPT) Disk Partition
In implementation, the EFI initialization module and driver execution environment are usually integrated into a read-only memory. The Pre-EFI initialization program is executed first when the system powers on, responsible for the initial CPU, main bridge, and memory initialization, followed by loading the EFI Driver Execution Environment (DXE). When DXE is loaded, the system gains the ability to enumerate and load other EFI drivers. In PCI architecture-based systems, EFI drivers for various PCI bridges and adapters will be sequentially loaded and initialized; at this point, the system will enumerate and load the drivers for various buses and devices behind the bridges and adapters, repeating until the last device’s driver is successfully loaded. Because of this, EFI drivers can be placed anywhere in the system as long as they can be enumerated correctly in order. For example, an ATAPI mass storage adapter with a PCI bus interface usually has its EFI driver placed in the device’s PCI-compliant expansion ROM, and when the PCI bus driver is loaded and starts enumerating its sub-devices, this storage adapter is correctly recognized and its driver is loaded. Some EFI drivers can also be placed in a dedicated EFI partition on a disk, as long as these drivers are not essential components for loading that disk’s driver. In the EFI specification, a GUID disk partition system (GPT) that breaks through the limitations of the traditional MBR disk partition structure has been introduced; in this new structure, the number of partitions on a disk is no longer limited (under MBR structure, only four primary partitions can exist), and the partition types are represented by GUIDs. Among the many partition types, the EFI system partition can be accessed by the EFI system to store certain drivers and applications. Many worry this could lead to new security issues, as EFI systems are more susceptible to computer viruses than traditional BIOS; when some EFI drivers are compromised, the system may face boot issues. In reality, the EFI drivers that the system boot relies on are typically not stored in the EFI GUID partition; even if the drivers in the partition are compromised, simple recovery methods can be employed, consistent with the storage habits of drivers under operating systems. The CSM is a special module in x86 platform EFI systems that provides services similar to traditional BIOS for operating systems that lack EFI boot capabilities.
Development of EFI
Intel is undoubtedly a driving force behind the promotion of EFI. In recent years, as the industry has gained deeper insights into it, more manufacturers are investing in research in this area. Some PC manufacturers, including Intel and AMD, have jointly established the Unified Extensible Firmware Interface Forum, which will soon release the first version of the specification. This organization will take on the responsibility of planning EFI development and interpret Intel’s EFI framework as a specific implementation of this specification. Additionally, major BIOS providers like Phoenix and AMI, previously seen as obstacles to EFI development, are now continuously introducing their own solutions. Analysts point out that this is because BIOS manufacturers have found a market position in the EFI architecture, such as the Pre-EFI environment; however, with the successful application of EFI in PC systems and the introduction of Intel’s new generation chipsets, this market share will likely be under Intel’s control.
2. UEFI
The graphical hardware setup interface of UEFI (Extensible Firmware Interface) is a proposed standard by Intel for a new type of PC firmware architecture, interface, and services. Its main purpose is to provide a set of consistent and correctly specified boot services across all platforms before the OS loads (pre-boot), viewed as the successor to the nearly 20-year-old PC BIOS.
Due to the popularization of computer education, many people know that BIOS stands for Basic Input/Output System, which is a type of “firmware” responsible for hardware startup and detection when powering on, and serves as an intermediary when the operating system controls hardware.
However, those were matters of the DOS era; since the advent of Windows NT and the rise of Linux, these operating systems have moved the hardware control programs that previously required BIOS into the operating system, no longer needing to call BIOS functions. Generally speaking, today’s so-called “computer experts” mostly use BIOS to perform some overclocking adjustments on hardware, and aside from professionals, few use BIOS for low-level work.
Due to rapid hardware development, traditional (Legacy) BIOS has become a burden to progress, and the latest EFI (Extensible Firmware Interface) has been developed. According to the viewpoint of traditional BIOS, the future will be an era of computers “without specific BIOS”.
UEFI is developed based on EFI 1.10, and its ownership is no longer with Intel but with an international organization called Unified EFI Forum (www.uefi.org), with contributors including Intel, Microsoft, AMI, and several major manufacturers, belonging to Open Source, with the current version being 2.1. Compared to Legacy BIOS, the main differences are:
1. 99% of the code is completed in C language. 2. It changes the previous interrupt and hardware port operation methods and adopts a new Driver/protocol approach. 3. It does not support X86 mode but directly adopts Flat mode (i.e., DOS can no longer be used; some EFI or UEFI can still be used due to compatibility, but this part does not belong to the definition of UEFI). 4. The output is no longer simple binary code but Removable Binary Drivers. 5. OS boot no longer calls Int19 but directly uses Protocol/device Path. 6. For third-party development, the former basically could not be done unless involved in BIOS design, but it must also be limited by the size of the ROM, while the latter is much more convenient.
UEFI will be a trend for the next three years, ushering in a new era for PC utilization and maintenance.
UEFI Structure
The UEFI concept can be divided into two parts: the entity of UEFI (UEFI Image) and the platform initialization framework.
The entity of UEFI – UEFI Image (the part enclosed in the blue box in the diagram)
According to the UEFI specification, the UEFI Image consists of three types: UEFI Applications, OS Loaders, and UEFI Drivers.
UEFI Applications are core applications that run before the operating system starts after hardware initialization, such as boot management, BIOS settings, UEFI Shell, diagnostic programs, scheduling and supply programs, debugging applications, etc.
OS Loaders are special UEFI Applications whose main function is to start the operating system and exit or shut down UEFI applications.
UEFI Drivers provide device interface protocol, allowing each device to run independently, providing device version numbers and corresponding parameters, as well as associations between devices, without requiring support from the operating system.
Boot Queue
Platform Initialization Framework
The UEFI framework mainly consists of two parts: PEI (Pre-EFI Initialization) and the Driver Execution Environment (DXE).
PEI is primarily used to detect the boot mode, load the main memory initialization module, and detect and load the core of the driver execution environment.
DXE is the main stage of device initialization, providing the device driver and protocol interface environment.
3. MBR (Master Boot Record)
For ease of understanding, MBR is generally divided into broad and narrow definitions: the broad definition of MBR includes the entire sector (boot program, partition table, and separator identifier), which is the aforementioned Master Boot Record; the narrow definition of MBR refers only to the boot program.
The 0 cylinder, 0 head, and 1 sector of the hard disk is called the Master Boot Sector (also known as the Master Boot Record MBR). It consists of three parts: the Master Boot Program, Disk Partition Table (DPT), and Disk Valid Flag (55AA). In the total of 512 bytes of the Master Boot Sector, the Master Boot Program (boot loader) occupies 446 bytes, the second part is the Partition Table (DPT), occupying 64 bytes, which records how many partitions are in the hard disk and the size of each partition. The third part is the Magic Number, fixed at 55AA.
MBR does not belong to any operating system, nor can it be read using disk operation commands provided by the operating system, but it can be modified and rewritten through commands. For example, in minix3, you can use the command: installboot -m /dev/c0d0 /usr/mdec/masterboot to write the masterboot program into the mbr, which is usually written in assembly language. We can also use the INT13H function provided in the ROM-BIOS to read the contents of that sector, or use software tools like Norton8.0’s DISKEDIT.EXE to read it.
The call parameters for the INT13H disk sector reading function are as follows:
Entry Parameters: AH=2 (specifying function number) AL=number of sectors to read DL=disk number (0,1-soft disk; 80,81-hard disk) DH=head number CL high 2 bits + CH=cylinder number CL low 6 bits=sector number CS:BX=address of memory buffer to store read data Exit Parameters: CS:BX=address where read data is stored Error Information: If an error occurs CF=1 AH=error code The operation to read the sector located at cylinder 0, head 0, sector 1 using DEBUG is as follows: A>DEBUG -A 100 XXXX:XXXX MOV AX,0201 (use function number 2 to read 1 sector) XXXX:XXXX MOV BX,1000 (put the read data into the buffer address CS:1000) XXXX:XXXX MOV CX,0001 (read cylinder 0, sector 1) XXXX:XXXX MOV DX,0080 (specify the first physical disk’s 0 head) XXXX:XXXX INT 13 XXXX:XXXX INT 3 XXXX:XXXX (press Enter) -G=100 (execute the above program segment) -D 1000 11FF (display the 512-byte MBR content)
In Windows operating systems such as XP, 2003, Vista, and Windows 7, there are Microsoft-provided interfaces for directly reading and writing the mbr;
FILE * fd=fopen(“\\.\PHYSICALDRIVE0″,”rb+”); char buffer[512]; fread(buffer,512,1,fd); //then you can edit buffer[512] as your wish…… fseek(fd,0,SEEK_SET); //very important fwrite(buffer,512,1,fd); //write the modified MBR back to your machine fclose(fd); //done
MBR Composition
A sector of the hard disk’s Master Boot Record MBR consists of four parts.
The Master Boot Program (offset address 0000H–0088H), which is responsible for loading and running the system boot program from the active partition.
Error message data area, offset address 0089H–00E1H for error messages, 00E2H–01BDH all zero bytes.
Partition Table (DPT, Disk Partition Table) contains 4 partition entries, offset address 01BEH–01FDH, each partition entry is 16 bytes long, totaling 64 bytes for partition entries 1, 2, 3, and 4.
End Flag Word, offset address 01FE–01FF, 2-byte value as the end flag 55AA; if this flag is incorrect, the system cannot boot.
4. GPT (Globally Unique Identifier Partition Table Format)
A disk partition architecture used by the Extensible Firmware Interface (EFI) based on Itanium computers. Compared to the Master Boot Record (MBR) partition method, GPT has more advantages as it allows each disk to have up to 128 partitions, supports volume sizes of up to 18 exabytes, allows for primary and backup partition tables for redundancy, and supports unique disk and partition IDs (GUID).
In contrast to the Master Boot Record (MBR) partition style, which supports a maximum volume of 2TB (terabytes) and a maximum of 4 primary partitions (or 3 primary partitions, 1 extended partition, and an unlimited number of logical drives), the GUID Partition Table (GPT) disk partition style supports a maximum volume of 18EB (exabytes) and up to 128 partitions per disk. Unlike MBR partition disks, critical platform operational data is located within the partition, not in non-partitioned or hidden sectors. Additionally, GPT partition disks have redundant primary and backup partition tables to enhance the integrity of partition data structures.
In the “Disk Management” dialog under the disk properties tab, disks with GPT partition styles are displayed as GUID Partition Table (GPT) disks, while disks with MBR partition styles are displayed as Master Boot Record (MBR) disks. In the event of the following unexpected incidents, operations supported by MBR disks can be performed on GPT disks:
On x86-based computers running Windows Server 2003 with Service Pack 1 (SP1) and x64-based computers, the operating system must reside on MBR disks. Other disks can be either MBR or GPT.
On Itanium-based computers, the operating system loader and boot partition must reside on GPT disks. Other disks can be either MBR or GPT.
GPT cannot be moved to x86-based computers running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003. However, GPT disks can be moved from x86-based computers running Windows Server 2003 with SP1 or x64-based computers to Itanium-based computers running Windows Server 2003 or Windows XP, and vice versa.
The Windows version based on Itanium cannot move GPT disks from Itanium-based computers to x86-based computers running Windows Server 2003 with SP1 or x64-based computers and then boot the operating system. GPT disks used on non-Itanium-based computers must only be for data storage.
In a single dynamic disk group, both MBR and GPT disks can coexist. Basic GPT and MBR disks can also be mixed, but they are not part of the disk group. MBR and GPT disks can be used simultaneously to create mirrored volumes, striped volumes, spanned volumes, and RAID-5 volumes, but the cylinder alignment limitations of MBR may complicate the creation of mirrored volumes. Typically, MBR disks can be mirrored to GPT disks to avoid cylinder alignment issues.
MBR disks can be converted to GPT disks, and GPT disks can only be converted to MBR disks when the disk is empty.
GPT partition styles cannot be used on removable media or on clustered disks connected to shared SCSI or Fibre Channel buses used with cluster services.
You can create partitions on basic GPT disks using the DiskPart.exe command-line utility or the EFI firmware utility Diskpart.efi. For more information on DiskPart.exe, refer to DiskPart. For an overview of the Disk Management snap-in, refer to the Disk Management overview. For more information on Diskpart.efi, refer to Intel’s website.
In the system recovery scheme on Itanium-based computers, refer to the manufacturer’s documentation that comes with the computer to recreate or recover GPT disks.
For more information on managing GPT and MBR disks, refer to the Extensible Firmware Interface or the Microsoft Windows Resource Kit website’s “Disk Management” section.
How WeChat Users Can Access and Share
Click the upper right corner → Send to friends Click the upper right corner → Share to Moments Click the upper right corner → Copy link to send to a computer for viewing
How to Subscribe to Haiyun Internet WeChat
Add Friends → Search for Public Account: Haiyun Internet Add Friends → Search Number: NetboyEDU Click the upper right corner → View Public Account → Add Follow
If you like this article, please like ↓