2013年1月20日 星期日
2009年8月5日 星期三
英文練習
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
FPSWA(Floating-Point Software Assist)驅動程式是EFI 1.02式驅動程式常見的例子，其他的EFI 1.02式驅動程式都可以從EFI Application Toolkit
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)。
2009年8月4日 星期二
英文練習
| 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)。 |
2009年8月3日 星期一
英文練習
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)類型與不同層級之間的關聯性。
