Introduction to EFI

This article consists of the following parts:
1. EFI Overview: describes what is EFI as a whole. And the benefits of applying EFI to us.
2. Framework: it focuses on the implementation of an Intel Platform Innovation Framework for EFI standard in terms of principle and architecture ).
3. Development tools: focuses on visual ebios, a development tool provided by Ami. It also briefly discusses the related tools of insyde. It also introduces the hardware simulators provided by American arium and the source point of the debugging software.
4. EFI development: Applications & drivers: discusses in detail the details of EFI development. A simple EFI application is analyzed. We also discuss EFI drivers.
5. EFI shell: Discusses the EFI shell.

The above is the main discussion direction, which will be further subdivided. For details, refer to the text section.

1. Summary of EFI overview EFI

1.1 problems faced by problems on legacy BIOS traditional BIOS
Before carefully discussing EFI, let's review what BIOS is. BIOS is short for Basic Input/Output System. Since IBM launched the world's first PC in the early 1980s S, BIOS has become an essential System Software for personal computers to manage basic hardware and provide various types of Interrupt calls, boot the operating system. We can see that BIOS is a very important system software for personal computers. computers without BIOS cannot run.
Traditionally, the BIOS has gone through more than 20 years and has not been significantly improved. Today, the operating system is fully 32-bit, the BIOS remains in the 16-bit real-time mode. We know that in this mode, the CPU of the ia32 architecture can only access 1 MB of basic memory, which greatly increases the creativity of programmers. At the same time, when the BIOS on various boards is mapped to the system memory, it is subject to the size of Kbytes ***. This makes it impossible for a computer to install too many boards. Otherwise, their bios capacity will easily exceed 128 Kbytes. However, it is common to install many boards on some servers.
At the same time, it is difficult to get started with development because the BIOS is generally developed in an assembly language. Many junior Engineers cannot even complete such tasks. In addition, the codes of various companies are not compatible, which seriously hinders their development.

1.2 Intel's solutions: EFI intel solution: EFI
EFI is a new technology launched by Intel to solve the above BIOS challenges, designed to provide the industry with a BIOS architecture that can still be applied in the next 20 years. EFI is the abbreviation of extensible firmware inte *** ce. The firmware interface is extensible. Because it is traditionally called EFI, this article will continue to refer it as EFI rather than its Chinese translation.
Just like its name, EFI is not a set of software, but a set of well-defined interfaces. It is a specification. Intel has officially released EFI specification revisions 1.10. Anyone can write their own implementations according to EFI. Intel has also prepared a standard implementation for us: Intel Platform Innovation Framework for EFI (framework ). It is even more worth mentioning that the framework has implemented open source code under the BSD Protocol Specification, which provides sufficient technical support for our future development of applications on EFI.

1.3 advantages of the EFI
The full principle of the EFI design is to shield the hardware that falls down the layer. In fact, through our analysis, EFI is very operating system. EFI includes the following parts:
1) pre-EFI basic code
2) pre-EFI module for specific chips
3) dxe basic code
4) dxe Driver (framework)
5) dxe Driver (hardware)
6) Compatibility support module CSM (optional, only ia32 supported)
With these components, EFI provides all the features that previously provided by BIOS and implements a large number of updates. At the same time, the capacity is also quite perfect, and can be put into a 4 MB flash. The startup speed and wake-up speed also comply with the hdg standard.
More importantly, EFI requires the use of C language as the development language, so that we can more easily join the development of bios, but also easy to implement modularization and standardization. One advantage of completely modular deployment is that the ODM or OEMs can easily add the desired features to EFI. For us, the benefits are self-evident. If we decide to start an EFI-based project, we can add our own modules to EFI to facilitate customization of our users, it even provides users with personalized services.

1.4 support for the supported OS Operating System
At present, it is officially announced that the OS supporting EFI includes Microsoft Windows Longhorn and some Linux. At present, Longhorn has entered the beta1 test phase, and Intel also demonstrated the actual situation of using EFI to guide Longhorn in a demo. It also shows how to use EFI to guide RedHat Linux (using a third-party open-source software elilo ). For other operating systems, such as Windows XP, EFI is not supported yet, so we have to use CSM for boot purposes.

2, framework

2.1 Framework overview Architecture Overview
To put it simply, framework is an implementation of EFI, which is completed by Intel. Fully implement the features mentioned in EFI specification revisions 1.10. Developers can develop various EFI applications based on the framework. You can also add new functions to the framework.

2.2 benefits of using advantages of the framework
The biggest benefit can greatly reduce our labor workload. We only focus on what needs to be paid attention to. Since the implementation of EFI already exists and is an open-source implementation, we do not need to implement it again. In addition, other benefits of the framework include:
1) cross-platform cross platform currently supports intel ia32/64, XScale, and other hardware platforms. At the same time, we noticed that the Framework does not exclude other platforms, and it has extremely high portability features.
2) all features of the modular design model design framework are implemented in the driver. The framework itself provides efficient methods to manage these drivers. For example, you can load a driver without restarting the computer. to update a driver that has been loaded, you just need to unload it, then load the new driver. For our developers, we can write our own drivers to provide the functions required by the framework.
3) Fast Start Time: as required by EFI, fast start time of framework is very fast. At this point, it is not inferior to those of traditional BIOS.
In addition, because the framework is the implementation of EFI, all advantages of EFI should be said that the framework also has.

2.3 The life cycle of the Framework framework Lifecycle
The framework is executed in the following order:
1) sec: security. This is a phase that enters immediately after the system is powered on. At this stage, Intel does not provide much instructions. On the contrary, they say that this phase can be used by everyone according to their own needs. That is to say, we can arrange any code we want at this stage, such as some identity verification. In short, the SEC can be said to bring the developers a full set of services.
2) pre-EFI: This is a status that enters before the real EFI environment, just like its name. This status is so important that intel has spent a lot of time explaining it to us. According to the current information, this phase will probably do a lot of initialization work, will initialize the CPU, initialize some controllers and chipset on the motherboard, and more importantly, in this phase, A technique is used to quickly establish the C code execution environment, that is, a stack is created. In this way, the machine will be able to run the software written in C language. Finally, the PEI kernel loads all the peim (pre-EFI module) in one way ). Peim is a modular program that can run at this stage. Anyone can develop their own peim, and the load is completed by peim dispatcher. After all the data is loaded, Pei calls dxe main and gives control of the system to the next stage dxe.
3) dxe: driver execution environment. This should be said to be the most exciting stage. At this stage, EFI actually provides something similar to OS. In the last phase of PEI, the system has established a C code execution environment. From this stage, everything is done in advanced languages. After entering dxe, various drivers will be called first, such as video driver, NIC Driver, soundcards driver, USB driver, and PCI Controller Driver. After that, start boot. This is the next stage.
4) BDS: boot device select. Here, there should be a choice, which is to enter the OS? Or do I execute those EFI applications? After the selection is complete, it enters the next stage.
5) TSL: transient system load. In this phase, different tasks will be performed based on the results selected in the BDS phase. If you select to enter the OS, the control will be passed to the final OS loader. If you want to run the EFI applications, the control is handed over to the transient OS boot loader, so that an execution environment is established and those EFI applications can be executed. At present, a program called EFI shell should be executed. The traditional BIOS setup is also written as an EFI application.
6) RT: run time. This stage is the operating stage of the OS.
7) Al: after life. This is the stage after the operating system, such as shutdown. However, after the OS crashes, it also belongs to this phase. That is to say, if the system crashes and EFI is used, many things can be done.
The above is the execution cycle of the framework. We can see that the framework has completed a lot of work in addition to the traditional BIOS. For example, you can set up an advanced language execution environment and call a device driver. It is worth noting that there is even a chance to execute a specific application.

3. Development Tools
3.1 Summary of overview
What development tools are currently used. In this training, Microsoft Visual Studio. NET 2003 is used for demonstration. However, an emulator program is compiled to simulate the real EFI environment. Moreover, because EFI is a system software, it is unlikely to directly use advanced development tools such as vs. net.
Later, in the EFI Driver development course, an HP engineer thought that as long as it was a C compiler, it could be developed theoretically. However, if you want to compile the code into EBC (EFI byte code), you have to purchase the appropriate compiler from Intel. (I checked the price. A license is worth $900! Depend !) The benefit of compiling code into EBC code is that different hardware architectures can use the same set of final binary code together. For example, if the program in the option ROM of a device is compiled into EBC, the device can directly support ia32/64 without any modification. In fact, we know that Intel's 64-bit Teng processor and 32-bit pentium4 processor are incompatible with the instruction set. So why? Because intel provides a protocols called EBC Virtual Machine driver in the framework. It is through it that such a function is implemented.
However, some third-party vendors have shown a lot of good development tools. It mainly includes visual ebios, h2oddt, insyde, hardware debugging tool of American arium, and supporting software sourcepoint.

3.2 AMI visual ebios
VEB is an excellent development tool provided by the famous BIOS venders Ami. He provides a large number of value add tools for EFI. Ami believes that Intel's EFI is only a skeleton (skeleton ). Their VEB put on their clothes and made a lot of personalized development for different purposes.

3.3 insyde h2oddt
Since insyde rarely entered the Chinese market before, we don't know much about its products. From the introduction, this software seems to be specially used for debugging the framework. The remaining details are to be further discussed.

3.4 American arium
American arium is a veteran hardware regulator vendor who this time brings ECM-50 with ECM-XDP. The difference between it seems that only ECM-XDP supports processors that use XDP interfaces. The ECM-50 supports the interface between the API and XDP. The supporting software sourcepoint is also demonstrated. From the presentation, this seems to be the best debugging tool currently, which can be directly tuned from the hardware for full tracking. Debugging of C source level is also supported. However, we guess that this debugging tool is expensive.

4, EFI development: Applications & drivers
EFI development: Applications and drivers

One of the major advantages of using EFI is the EFI application and EFI drivers. I will discuss it separately. In fact, Intel also thinks that app and driver are essentially no different. They are all programs, but their focus is different. The app needs to interact with users, while the driver mainly provides certain services.

4.1 EFI applications EFI Application

4.1.1 module of the EFI applications EFI Application Type
At present, there are several methods for compiling EFI applications, which are based on EFI, EFI library, C library, and C standard library. According to Intel, the size of the compiled application is bigger than one, so if you want to obtain the smallest size, you should use the EFI-based method, this is also recommended by Intel.

4.1.2 A *** EFI applications based on EFI: A simple EFI-based application
The simplest way is to look at an EFI app. Next we will show you the simplest EFI app.

# Include <EFI. h>

Efi_status
Initializedemoapp (
In efi_handle imagehandle,
In efi_system_table * systemtable
)
{
Systemtable-> conout-> outputstring (systemtable-> conout, l "demo application ");
Return efi_success;
}

The job of this program is very simple. It is to print a string to the terminal device. Similar to our common helloworld. From this program, we can see the following points:
1) All EFI-based applications in Chengdu must contain the header file EFI. h
2) The main function must be declared as efi_status.
3) You must add in, out, or optional before the parameter to describe the parameter type. These modifiers are defined by Intel in efidef. h. Currently, it is empty, but it is better for future compatibility.
It can be seen that the entry level is very low because the C language is used for development, and most engineers can easily join the development team. Other programming models are similar to the EFI-based method, except that the libraries used are different.

4.2 EFI drivers EFI Driver
Now, let's briefly introduce the EFI drivers. In fact, the driver is no different from the general application, but the driver cannot be executed directly, but is executed in the background under the scheduling of EFI, at the same time, the driver can access the hardware. Of course, there are drivers that do not touch the hardware. Service driver is used to provide certain services. For example, efi ebc virtual machine is a service driver. EFI provides powerful and efficient methods to manage these drivers. When a driver is needed, we can load it, when a new version or the hardware managed by the driver is no longer needed, we can easily unload it. Intel has provided a tool called dww, which can easily generate a Driver Model Based on EFI.

5, EFI Shell

5.1 EFI shell overview EFI shell Overview
What is EFI shell? First, it is an EFI-based application, and secondly it is very similar to the CMD we encountered in Windows or the shell in Linux. In fact, this is an operating environment, a shell program, which is responsible for receiving user input, interpreting user input, telling kernel to execute, and displaying the execution result. It completes the interaction with the user. Therefore, EFI shell is a very important application.

5.2 EFI shell commands EFI shell command
The EFI shell uses the character interface to interact with users. The following lists some possible commands for reference.
1) PCI: displays PCI device or PCI configuration information
2) mm: displays or modifies memory, I/O, and PCI resources.
3) MEm: displays the system memory or device memory.
4) memmap: displays the memory map created by EFI environment.
5) Drivers: displays all installed drivers one by one based on the EFI Driver type.
6) Devices: displays all devices controlled by the EFI Driver.
7) devtree: display the Device Tree according to the EFI Driver type.
8) DH: displays all handles in the EFI environment.
9) Connect: bind a driver to a device and start the device.
10) load: Read a driver into the memory.
11) unload: detaches a driver from the memory.