英文練習

Drivers(驅動程式)

EFI drivers differ from EFI applications in that the driver stays resident in memory unless an error is returned from the driver’s entry point.

EFI驅動程式(EFI drivers)不同於EFI應用程式(EFI applications)是在於驅動程式會

The EFI core firmware, the boot manager, or other EFI applications may load drivers.

EFI核心系統(EFI core)韌體、開機管理器(boot manager)或其他的EFI應用程式(EFI application)都可能會載入驅動程式。

EFI 1.02 Drivers(EFI 1.02型驅動程式)

Several types of EFI drivers exist, having evolved with subsequent levels of the specification.

現存的幾種EFI驅動程式(EFI drivers)，是發展於隨後版本的EFI規範。

In EFI 1.02, drivers were constructed without a defined driver model.

在EFI 1.02版規範中，驅動程式是建構於已定義好的驅動模型(driver model)之外。

The EFI 1.10 Specification provides a driver model that replaces the way drivers were built in EFI 1.02 but that still maintains backward compatibility with EFI 1.02 drivers.

EFI 1.10規範中有提供一種驅動模型(driver model)取代這種建立在EFI 1.02規範的驅動程式，但仍會維持EFI 1.02型驅動程式可以向上相容。

EFI 1.02 immediately started the driver inside the entry point.

EFI 1.02規範驅動程式的開始位置是在進入點函式(entry point)。

Following this method meant that the driver searched immediately for supported devices, installed the necessary I/O protocols, and started the timers that were needed to poll the devices.

按照這種方式意味著驅動程式會直接搜尋到所支援的裝置、需要安裝的I/O protocols與已開始的計時器，它需要輪尋這個裝置。

However, this method did not give the system control over the driver loading and connection policies, so the EFI Driver Model was introduced in section 1.6 of the EFI 1.10 Specification to resolve these issues.

然而，這種方式使驅動程式在載入與連結的策略上不會去拿到系統控制權，所以在EFI 1.10版的規範書的第1.6章節中所介紹的EFI驅動模型(EFI Driver Model)可以解決此問題。

The Floating-Point Software Assist (FPSWA) driver is a common example of an EFI 1.02 driver; other EFI 1.02 drivers can be found in the EFI Application Toolkit 1.02.12.38.

FPSWA(Floating-Point Software Assist)驅動程式是EFI 1.02式驅動程式常見的例子，其他的EFI 1.02式驅動程式都可以從EFI Application Toolkit 1.02.12.38找到。

For compatibility, EFI 1.02 drivers can be converted to EFI 1.10 drivers that follow the EFI Driver Model.

為了顧及相容性，所以EFI 1.02式驅動程式都可以由符合EFI驅動模型(EFI Driver Model)的EFI 1.10式驅動程式來取代。

英文練習

OS Loader(作業系統載入器)

A special type of EFI application, called an OS boot loader, calls the ExitBootServices() function when the OS loader has set up enough of the OS infrastructure to be ready to assume ownership of the system resources.

這是一種特殊的EFI應用程式(EFI application)，稱之為作業系統開機載入器(OS boot loader)，呼叫在作業系統載入器(OS loader)中的ExitBootServices()函式，設立合適的OS實體以作為系統資源的管理者。

At ExitBootServices(), the EFI core frees all of its boot time services and drivers, leaving only the run-time services and drivers.

在ExitBootServices()函式中，EFI核心會釋放所有系統開機時期的系統服務與驅動程式，只留下系統運行時期的系統服務與驅動程式。

英文練習

Applications(應用程式)

An EFI application starts execution at its entry point, then continues execution until it reaches a return from its entry point or it calls the Exit() boot service function.

EFI應用程式(EFI application)是從它的進入點函式(entry point)開始執行，它會持續執行到它從進入點函式(entry point)返回，或是呼叫開機時期系統服務(boot service)的Exit()函式為止。

When done, the image is unloaded from memory.

完成後，這種映像檔就會從記憶體中卸載。

Some examples of common EFI applications include the EFI shell, EFI shell commands, flash utilities, and diagnostic utilities.

EFI應用程式(EFI application)的一些常見例子有EFI shell、EFI shell commands、flash utilities與diagnostic utilities。

It is perfectly acceptable to invoke EFI applications from inside other EFI applications.

它可以從其他的EFI應用程式(EFI application)內部去調用EFI應用程式(EFI application)。

英文練習

Type of Image(映像檔類型)	Description(註解)
Application(應用程式)	An EFI image of type EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION. 一種EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION類型的EFI映像檔(EFI image)。 This image is executed and automatically unloaded when the image exits or returns from its entry point. 這種映像檔會被執行，以及在結束或是它的進入點函式(entry point)回傳結果後被卸載。
OS loader(作業系統載入器)	A special type of application that normally does not return or exit. 這是一種特殊的應用程式，通常不會回傳結果或是結束。 Instead, it calls the EFI Boot Service gBS->ExitBootServices() to transfer control of the platform from the firmware to an operating system. 相反地，它會呼叫開機時期系統服務gBS->ExitBootServices()，將系統平台的控制權從韌體轉移到OS。
Driver(驅動程式)	An EFI image of type EFI_IMAGE_SUBSYSTEM_BOOT_SERVICE_DRIVER or EFI_IMAGE_SUBSYSTEM_RUNTIME_DRIVER. EFI_IMAGE_SUBSYSTEM_BOOT_SERVICE_DRIVER或EFI_IMAGE_SUBSYSTEM_RUNTIME_DRIVER類型的EFI映像檔(EFI image)。 If this image returns EFI_SUCCESS, then the image is not unloaded. 如果這個映像檔回傳EFI_SUCCESS，那麼此映像檔不會被卸載。 If the image returns an error code other than EFI_SUCCESS, then the image is automatically unloaded from system memory. 如果這個映像檔回傳EFI_SUCCESS之外的其他錯誤代碼，那麼此映像檔會自動從系統記憶體中被卸載。 The ability to stay resident in system memory is what differentiates a driver from an application. 驅動程式與應用程式的不同在於，常駐於系統記憶體的能力。 Because drivers can stay resident in memory, they can provide services to other drivers, applications, or an operating system. 因為驅動程式可以常駐於系統記憶體，所以可以提供系統服務其他的驅動程式、應用程式或作業系統。 Only the services produced by runtime drivers are allowed to persist past gBS->ExitBootServices(). 只有運行時期的驅動程式所產生的系統服務，允許保留到gBS->ExitBootServices()執行之後。
Service driver(系統驅動程式)	A driver that produces one or more protocols on one or more new service handles and returns EFI_SUCESS from its entry point. 驅動程式會產生一個以上的protocols在一個以上的新的service handles，以及在它的進入點函式(entry point)回傳EFI_SUCESS。
Initializing driver(初始化驅動程式)	A driver that does not create any handles and does not add any protocols to the handle database. 一個驅動程式不能創建任何的handles，也不能將任何的protocols加入到handle database中。 Instead, this type of driver performs some initialization operations and returns an error code so the driver is unloaded from system memory. 相反地，驅動程式之類會運行一些初始化操作，以及回傳錯誤代碼，如此驅動程式就會從系統記憶體中被卸載。
Root bridge driver(根源橋接器驅動程式)	A driver that creates one or physical controller handles that contain a Device Path Protocol and a protocol that is a software abstraction for the I/O services provided by a root bus produced by a core chipset. 一個驅動程式創建一個或物理的控制器資源表(controller handles)，它包含了Device Path Protocol，以及軟體抽象化核心晶片組所產生的源頭匯流排所提供的I/O 系統服務的protocol。 The most common root bridge driver is one that creates handles for the PCI root bridges in the platform that support the Device Path Protocol and the PCI Root Bridge I/O Protocol. 最普遍的源頭橋接器驅動程式(root bridge driver)就是在支援Device Path Protocol與PCI Root Bridge I/O Protocol的系統平台上的PCI源頭橋接器(PCI root bridges)。
EFI 1.02 driver	A driver that follows the EFI 1.02 Specification. 遵守EFI 1.02版規範的驅動程式。 This type of driver does not use the EFI Driver Model. 不使用EFI Driver Model的驅動程式類型。 These types of drivers are not discussed in detail in this document. 在本書中不會討論這種驅動程式的細節。 Instead, this document presents recommendations on converting EFI 1.02 drivers to drivers that follow the EFI Driver Model. 相反地，本書會建議將EFI 1.02 驅動程式轉換為符合EFI驅動模型(EFI Driver Model)的驅動程式
EFI Driver Model(EFI驅動模組) driver	A driver that follows the EFI Driver Model that is described in detail in the EFI 1.10 Specification. 這種驅動程式是遵循定義在EFI 1.10規範中的EFI驅動模組(EFI Driver Model)。 This type of driver is fundamentally different from service drivers, initializing drivers, root bridge drivers, and EFI 1.02 drivers because a driver that follows the EFI Driver Model is not allowed to touch hardware or produce device-related services in the driver entry point. 這種驅動程式基本上與系統服務(service drivers)、初始化驅動程式(initializing drivers)、來源橋接器(root bridge drivers)以及EFI 1.02版驅動程式(EFI 1.02 drivers)不同，因為它是遵循EFI驅動模組(EFI Driver Model)的規範，它不被允許在進入點函式(entry point)中直接接觸硬體或是產生與裝置相關的系統服務。 Instead, the driver entry point of a driver that follows the EFI Driver Model is allowed only to register a set of services that allow the driver to be started and stopped at a later point in the system initialization process. 相反地，按照EFI驅動模組(EFI Driver Model)的規範，驅動程式的進入點函式(entry point)只可以註冊系統服務，它允許驅動程式在系統初始化的過程的晚期可以被啟動或停止。 Note: 1.看來EFI Driver Model就像是一層抽象層的驅動程式，企圖抽象化硬體層，使得整體系統的上層可以與實體層脫勾。
Device driver(設備驅動程式)	A driver that follows the EFI Driver Model. 這是一種遵守EFI驅動模組(EFI Driver Model)規範的驅動程式。 This type of driver produces one or more driver handles or driver image handles by installing one or more instances of the Driver Binding Protocol into the handle database. 這種類型的驅動程式會產生一個以上的驅動程式資源表(driver handles)或是驅動程式映像檔資源表(driver image handles)，透過安裝一個以上的Driver Binding Protocol，存入系統資源庫(handle database)中。 This type of driver does not create any child handles when the Start() service of the Driver Binding Protocol is called. 這種類型的驅動程式在Driver Binding Protocol的Start()系統服務被呼叫時，不會產生任何的子端系統資源表(child handles)。 Instead, it only adds additional I/O protocols to existing controller handles. 相反地，它只會附加上I/O protocols到目前的控制器資源表上。
Bus driver(匯流排驅動程式)	A driver that follows the EFI Driver Model. 這是一種遵守EFI驅動模組(EFI Driver Model)規範的驅動程式。 This type of driver produces one or more driver handles or driver image handles by installing one or more instances of the Driver Binding Protocol in the handle database. 這種類型的驅動程式會產生一個以上的驅動程式資源表(driver handles)或是驅動程式映像檔資源表(driver image handles)，透過安裝一個以上的Driver Binding Protocol，存入系統資源庫(handle database)中。 This type of driver creates new child handles when the Start() service of the Driver Binding Protocol is called. 這種類型的驅動程式在Driver Binding Protocol的Start()系統服務被呼叫時，會產生新的子端系統資源表(child handles)。 It also adds I/O protocols to these newly created child handles. 同時會將I/O protocols加入到新創建的子端系統資源表(child handles)中。
Hybrid driver(混合式驅動程式)	A driver that follows the EFI Driver Model and shares characteristics with both device drivers and bus drivers. 這是一種遵守EFI驅動模組(EFI Driver Model)規範的驅動程式，而且同時擁有設備驅動程式(device drivers)與匯流排驅動程式(bus drivers)兩者的特性。 This distinction means that the Start() service of the Driver Binding Protocol will add I/O protocols to existing handles and it will create child handles. 它的不同之處在於Driver Binding Protocol的Start()系統服務被呼叫時，會將I/O protocols加到目前的資源表中，同時會創建新的子端系統資源表(child handles)。

英文練習

EFI Images(EFI映像檔)

All EFI images contain a PE/COFF header that defines the format of the executable code as required by the Microsoft Portable Executable and Common Object File Format Specification (Microsoft 1997).

所有的映像檔(EFI images)都包含PE/COFF表頭，它定義了微軟可攜式執行檔(Microsoft Portable Executable)與物件檔案格式(Object File Format)所要求的可執行程式碼的規格。

The target for this code can be an IA-32 processor, an ItaniumR processor, or a processor agnostic, generic EFI Byte Code.

目的是為了讓這個程式碼可以在IA-32處理器、ItaniumR處理器或是與處理器無關的通用EBC(EFI Byte Code)上執行。

The header defines the processor type and the image type.

此表頭定義了處理器的類型與映像檔的類型。

Presently there are three processor types and the following three image types defined:

目前有這三種的處理器與下列所定義的三種映像檔類型：

■ EFI applications(應用程式) - images that have their memory and state reclaimed upon exit.

這種映像檔有它自己的記憶體空間與狀態，會在程式結束時被回收。

■ EFI Boot Service drivers(開機時期提供系統服務的驅動程式) - images that have their memory and state preserved throughout the pre-operating system flow.

這種映像檔有它自己的記憶體空間與狀態，會一直保持到OS啟動之前。

Their memory is reclaimed upon invocation of ExitBootServices() by the OS loader.

它的記憶體會在作業系統載入器(OS loader)調用ExitBootServices()函式的時候被回收。

■ EFI Runtime drivers(作業系統運行時期的驅動程式) – images whose memory and state persist throughout the evolution of the machine.

映像檔的記憶體與狀態，會隨著機器的發展而持續。

These images coexist with and can be invoked by an EFI-aware operating system.

此映像檔與可以被EFI識別的OS共存。

The value of the EFI Image format is that various parties can create binary executables that interoperate.

FFI映像檔(EFI Image)格式的值是可創建二進制可執行檔的各種部份所組成的。

For example, the operating system loader for Microsoft Windows and Linux for an EFI-aware OS build is simple an EFI application.

例如：EFI所知的OS建造的Microsoft Windows與Linux的作業系統載入器，就是一個簡單的應用程式。

In addition, third parties can create EFI drivers to abstract their particular hardware, such as a networking interface host bus adapter (HBA) or other device.

此外，第三方廠商可以建立驅動程式(EFI drivers)以抽象化特定的硬體，例如：網路介面主機匯流排轉換卡(networking interface host bus adapter)或是其他的裝置。

EFI images are loaded and relocated into memory with the Boot Service gBS->LoadImage().

EFI映像檔(EFI images)是用開機時期的系統服務，gBS->LoadImage() 將其載入與重置到記憶體中。

Several supported storage locations for EFI images are available, including the following:

幾個可用的支援EFI映像檔的儲存場所，包含如下：

■ Expansion ROMs on a PCI card

PCI卡上的擴充ROM。

■ System ROM or system flash

系統ROM或是系統flash

■ A media device such as a hard disk, floppy, CD-ROM, or DVD

媒體裝置，例如：硬碟機、軟碟機、CD-ROM或是DVD。

■ A LAN boot server

網路開機伺服器

In general, EFI images are not compiled and linked at a specific address.

一般而言，EFI映像檔(EFI images)不會編譯與連結特定的記憶體位址。

Instead, the EFI image contains relocation fix-ups so the EFI image can be placed anywhere in system memory.

相反地，EFI映像檔(EFI images)含有再定位修正，如此EFI映像檔(EFI images)就可以被放置在系統記憶體中的任何位址上。

The Boot Service gBS->LoadImage() does the following:

開機時期系統服務gBS->LoadImage()的工作如下：

■ Allocates memory for the image being loaded

分配記憶體給正在被載入的映像檔。

■ Automatically applies the relocation fix-ups to the image

自動運用再定位修正給映像檔

■ Creates a new image handle in the handle database, which installs an instance of the EFI_LOADED_IMAGE_PROTOCOL

在handle database建立新的映像檔handle，這需要安裝EFI_LOADED_IMAGE_PROTOCOL的實體。

This instance of the EFI_LOADED_IMAGE_PROTOCOL contains information about the EFI image that was loaded.

EFI_LOADED_IMAGE_PROTOCOL的實體包含已被載入的EFI映像檔(EFI image)相關的資訊。

Because this information is published in the handle database, it is available to all EFI components.

因為這些資訊是被發布在handle database中，它可提拱給所有的EFI組件。

After an EFI image is loaded with gBS->LoadImage(), it can be started with a call to gBS->StartImage.

在EFI映像檔(EFI image)被gBS->LoadImage()載入後，就可以藉由gBS->StartImage()來起始它。

The header for an EFI image contains the address of the entry point that is called by gBS->StartImage().

EFI映像檔(EFI image)的標頭包含進入點函式(entry point)的記憶體位址，進入點函式(entry point)是由gBS->StartImage()做呼叫。

The entry point always receives the following two parameters:

進入點函式(entry point)通常會收到以下兩種參數：

■ The image handle of the EFI image being started

正在被啟動的EFI映像檔(EFI image)的映像檔資源表(image handle)。

■ A pointer to the EFI System Table

指向EFI系統表格(EFI System Table)的指標

These two items allow the EFI image to do the following:

這兩個參數允許EFI映像檔(EFI image)作到下列事項：

■ Access all of the EFI services that are available in the platform.

存取所有在平台上有效的EFI系統服務(EFI services)。

■ Retrieve information about where the EFI image was loaded from and where in memory the image was placed.

？？

The operations that the EFI image performs in its entry point vary depending on the type of EFI image.

EFI映像檔(EFI image)執行它的進入點函式(entry point)的這個操作是相當取決於EFI映像檔(EFI image)的類型。

Figure 2.4 shows the various EFI image types and the relationships between the different levels of images.

圖2.4所顯示，不同EFI映像檔(EFI image)類型與不同層級之間的關聯性。

英文練習

Tag GUID(GUID標籤)

A protocol may be nothing more than a GUID.

protocol可能只有一組GUID。

In such cases, the GUID is called a tag GUID.

在這種情況之下，這個GUID就被稱為GUID標籤(tag GUID)。

Such protocols can serve useful purposes such as marking a device handle as special in some way or allowing other EFI images to easily find the device handle by querying the system for the device handles with that protocol GUID attached.

這類的protocols可以提供十分有用的用途，例如標記某一裝置資源表(device handle)有某種意義上的特性，或是讓其他的EFI映像檔(EFI images)可以很容易的用GUID向系統查詢到這個裝置資源表(device handle)。

The EDK uses the HOT_PLUG_DEVICE_GUID in this way to mark device handles that represent devices from a hot-plug bus such as USB.

EDK使用HOT_PLUG_DEVICE_GUID來標記裝置資源表(device handle)所代表的設備為hot-plug(熱插拔)匯流排，例如USB。

英文練習

Working with Protocols(使用Protocol)

Any EFI code can operate with protocols during boot time.

任何EFI的程式碼都可以在開機時期運用protocol。

However, af-ter ExitBootServices() is called, the handle database is no longer available.

然而，在ExitBootServices()被呼叫之後，handle database就不再可用。

Several EFI boot time services work with EFI protocols.

一些EFI開機時期的系統服務是使用protocol來運作的。

Multiple Protocol Instances

A handle may have many protocols attached to it.

一個handle可能有需許多protocol附加在它身上。

However, it may have only one protocol of each type.

然而，每一種類型的protocol只能有一個。

In other words, a handle may not have more than one instance of the exact same protocol.

換句話說，一個handle不能有多個完全一樣的protocol。

Otherwise, it would make requests for a particular protocol on a handle nondeterministic.

否則，它將會使得對某一個protocol的請求，處於不確定的處理狀態。

However, drivers may create multiple instances of a particular protocol and attach each instance to a different handle.

然而，驅動程式可以產生多組特定protocol的實體，並將它們附加於不同的handle中。

The PCI I/O Protocol fits this scenario, where the PCI bus driver installs a PCI I/O Protocol instance for each PCI device.

PCI I/O Protocol就適用於此狀況，在PCI bus驅動程式裡，會安裝每一個PCI裝置的PCI I/O Protocol實體。

Each instance of the PCI I/O Protocol is configured with data values that are unique to that PCI device, including the location and size of the EFI Option ROM (OpROM) image.

每一個PCI I/O Protocol的實體會配置屬於PCI裝置的資料，包含EFI OpROM映像檔的位址與大小。

Also, each driver can install customized versions of the same protocol as long as they do not use the same handle.

而且，每個驅動程式可以安裝相同protocol的客製化版本，只要它們不是使用相同的handle。

For example, each EFI driver installs the Component Name Protocol on its driver image handle, yet when the EFI_COMPONENT_NAME_PROTOCOL.GetDriverName() function is called, each handle returns the unique name of the driver that owns that image handle.

例如，每一個驅動程式(EFI driver)都會安裝在驅動程式映像檔資源表(driver image handle)的Component Name Protocol，在EFI_COMPONENT_NAME_PROTOCOL.GetDriverName()函式被呼叫時，每一個handle都會回傳驅動程式自身的映像檔資源表(image handle)上的名稱。

The EFI_COMPONENT_NAME_PROTOCOL.GetDriverName() function on the USB bus driver handle returns “USB bus driver” for the English language, but on the PXE driver handle it returns “PXE base code driver.”

在USB匯流排驅動程式資源表(USB bus driver handle)上的EFI_COMPONENT_NAME_PROTOCOL.GetDriverName()函式，就會回傳“USB bus driver”的英文字，但是在PXE階段的驅動程式資源表(PXE driver handle)卻會回傳“PXE base code driver.”。