EFI Shell开发者指南：构建应用程序

需积分: 9 62 浏览量更新于2024-07-21 1 收藏 317KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"EFI_Shell_Developer_Guide_Ver0-91." EFI Shell Developer's Guide Version 0.91 是一份面向开发者的详细文档，旨在介绍如何在EFI（Extensible Firmware Interface）环境中开发Shell应用程序，即所谓的“shell下面的ap”。这份指南详细阐述了Shell库（Shell Lib）中的各种库函数及其调用方法，是理解UEFI（统一可扩展固件接口）Shell编程的关键参考资料。 UEFI Shell是一种基于EFI的命令行界面，它提供了一种用户与系统硬件和固件交互的方式。开发者可以利用这个Shell来创建自己的命令行工具或应用程序。EFI Shell Developer's Guide涵盖了以下关键知识点： 1. **EFI Shell 库**：这个库包含了一系列用于开发EFI Shell应用的函数和结构体。开发者可以通过这些库函数来访问系统服务、处理文件、管理设备等，简化了UEFI环境下的编程工作。 2. **Shell命令接口**：文档详细解释了如何定义和实现新的Shell命令，这包括如何处理命令行参数、执行操作以及返回结果。 3. **UEFI环境**：EFI是BIOS的一种替代，它提供了更现代、更灵活的固件接口。开发者需要了解EFI模型，包括EFI系统表、协议、驱动模型等，以便在EFI Shell下编写程序。 4. **Driver开发**：EFI Shell应用程序可能需要与硬件设备交互，因此文档会涉及如何开发UEFI驱动程序，以及如何在Shell环境下加载和使用这些驱动。 5. **编程接口（APIs）**：文档详述了各种APIs，如EFI Boot Services、EFI Runtime Services等，这些都是构建EFI Shell应用的基础。 6. **错误处理和调试**：在EFI Shell开发中，理解和处理错误是必不可少的。指南会提供关于如何有效地报告和调试问题的信息。 7. **版本控制**：由于EFI标准和库可能会随着时间不断更新，开发者需要关注版本变更，以确保代码的兼容性和最佳实践。 8. **保留和未定义的功能**：文档警告开发者不要依赖于标记为“保留”或“未定义”的功能，因为这些可能会在未来的版本中改变或移除。 9. **法律和责任声明**：Intel作为EFI技术的提供者，在文档中明确了其产品销售条款，包括知识产权、保修和责任限制等，提醒开发者注意相关的法律风险。 EFI Shell Developer's Guide Version 0.91是一份全面的开发资源，对那些希望在UEFI环境中构建高效、可靠的Shell应用的开发者来说非常有价值。通过深入学习这份指南，开发者能够熟练地运用EFI Shell库和APIs，开发出能够在不同平台上运行的命令行工具和系统级应用。

资源详情

资源推荐

Building an EFI Shell Application

Version 0.91 June 27, 2005 16

2. To build an Itanium® architecture version of HelloWorld:

Open the description file C:\EDK\Sample\Platform\Ipf\Build\Ipf.dsc

Add:

“Other\Maintained\Application\Shell\Library\EfiShellLib.inf”

To the [Libraries.Platform] section, like this:

[Libraries.Platform]

Other\Maintained\Application\Shell\Library\EfiShellLib.inf

……

Add:

“Other\Maintained\Application\Shell\HelloWorld\HelloWorld.inf FV=NULL”

To the [Components] section, like this:

[Components]

……

Other\Maintained\Application\Shell\HelloWorld\HelloWorld.inf

FV=NULL

……

Type the command:

Cd C:\EDK\Sample\Platform\Ipf\Build

Set the environment variable:

C:\EDK\Sample\Platform\Ipf\Build>Set EDK_SOURCE=C:\EDK

Build:

C:\EDK\Sample\Platform\Ipf\Build>nmake

The application’s binary is:

C:\EDK\Sample\Platform\Ipf\Build\Ipf\HelloWorld.efi

All the applications built in this way are external commands. They are individual images. If you

want to build your application as an EFI Shell internal command, you need to re-build the EFI Shell

to include your applications as an internal command. Please refer to section 4.5.1, External to

Internal for detailed instructions.



NOTE

It is highly recommended that you do a cleanup before building the EFI Shell or applications. The

cleanup will help assure the building process is successful.

Version 0.9 February, 2005 17

Composing an EFI Shell Application

This section describes how to compose the following files to create an EFI Shell application.

• C header file(s)

• C source file(s)

• A string resource .uni file (This is optional; it depends on whether the application uses its

own strings.)

• A component description .inf file that describes how to build the application.

It is assumed that an application developer already knows the purpose of C header and C source

files, so no explanation is given here.

4.1 String Resource .uni File

The string resource file is where string resources are stored in a Unicode text format with a file

suffix of .uni. Applications that will not use string resources do not need a string resource file. An

example of a .uni file is shown below.

// HelloWorldStrings.uni

// String resources for HelloWorld application

/=#

#langdef eng “English”

#langdef fra “Français”

#string STR_HELLOWORLD #language eng “Hello, world!\n”

#language fra “Hello, world!\n”

#string STR_GOODBYE #language eng “Goodbye, cruel world!\n”

#language fra “Goodbye, cruel world!\n”

The contents of this .uni file must start with a line of “/=#” and use #langdef to define which

languages are supported. In the example above of a string resource file, eng and fra respectively

are defined for English and French. The key word #string defines a string token and its

corresponding string resource for each supported language. String tokens, such as

STR_HELLOWORLD, are used in applications to refer to the string associated with it. Application

developers can use the key word #string to define their own string tokens and associated strings.

All the strings in the .uni file are compiled to produce a C source file that contains a formatted

array. In this array all the strings are stored in a specific format. This C source file will be built with

the application’s source code. How this array is referenced in the application’s source code is

discussed later.

Composing an EFI Shell Application

Version 0.91 June 27, 2005 19

FILE_GUID specifies the GUID associated with the application.

COMPONENT_TYPE specifies the type of application. For EFI Shell applications it should be

APPLICATION.

4.2.2 SOURCES.COMMON Section

This section lists the files that should be compiled to produce an .efi file of the application. The

order of the files in this list can be arbitrary, except when there are .uni files. When there are

.uni files, they must be put ahead of any other program files.

4.2.3 INCLUDES.COMMON Section

This section lists the directories where the .h files referenced by the application can be found. You

must add entries in this section for the directories containing .h files that will be referenced by

your application. If you do not, the compiler will report an error saying it can not open the .h file.

These macros are very useful:

EDK_SOURCE refers to the root directory of the EDK.

DEST_DIR refers to the working directory when building.

4.2.4 LIBRARIES.COMMON Section

This section lists the libraries that normally should be linked to an application. Since the libraries in

this example file are exhaustive enough for most applications, you should be able to copy the list to

your own .inf file.

4.2.5 NMAKE.COMMON Section

This section contains information that is passed to the compiler to enable compiling. You must

specify the entry point name for the variable IMAGE_ENTRY_POINT. The entry point name must

be the same as the entry function name in your application.

The last two lines define the variables STRING_ARRAY_NAME and STRING_DEFINES_FILE

that are used in applications that need string resources. They are replaced by the compiler with

values from the NMAKE.COMMON

section to enable the application to find the string token

definition .h file and .c file (containing all the strings in an array as mentioned earlier). The

EFI_BOOTSHELL is defined to enable the declaration of an entry point in the source code file.

4.3 Writing an EFI Shell Application

This section describes how to write an EFI Shell Application.

How-to-write examples are provided in sections

4.3.7, 4.3.8, and 4.3.9.

4.3.1 Required .h Files

Initially, an application must include EfiShellLib.h.

EfiShellLib.h contains definitions of library functions the application is able to use.

Composing an EFI Shell Application

Version 0.91 June 27, 2005 20

4.3.2 Strings

If the application will use strings, include these two lines of code:

#include STRING_DEFINES_FILE

extern UINT8 STRING_ARRAY_NAME[];

STRING_DEFINES_FILE and STRING_ARRAY_NAME are replaced by the building tool when

the .inf file has been processed. Afterwards, the STRING_DEFINES_FILE refers to the .h file

that contains definitions of all the string tokens used in the application. STRING_ARRAY_NAME

will be the array name in the .c file mentioned in

4.2.5.

4.3.3 Declaring the Entry Point

The entry point of an application must be declared as shown below:

#ifdef EFI_BOOTSHELL

EFI_APPLICATION_ENTRY_POINT (HelloMain)

#endif

EFI_STATUS

EFIAPI

HelloMain (

IN EFI_HANDLE ImageHandle,

IN EFI_SYSTEM_TABLE *SystemTable

)

{

……

}

The entry point must be declared by the macro EFI_APPLICATION_ENTRY_POINT. In the

example above, HelloMain is the name of the entry point function. For your application, you

may choose any leagal name that you like as long as it is consistent with the value specified in the

variable IMAGE_ENTRY_POINT in your .inf file.

The declaration must be put in the block #ifdef EFI_BOOTSHELL …#endif and the symbol

EFI_BOOTSHELL must be defined in the application’s .inf file. If it is not, and the application is

built as an internal command of the EFI Shell, and the declaration is at the entry point of the

application, link conflict will occur. Putting the declaration in the #ifdef

EFI_BOOTSHELL…#endif block avoids this conflict since, when building the EFI Shell, the

EFI_BOOTSHELL is not defined.

4.3.4 Initializing the Execution Environment

The application must call LibInitializeShellApplication() to initialize the execution

environment before starting to use the library’s global variables and services. It is highly

recommended that you use the macro EFI_SHELL_APP_INIT() to initialize applications. This

macro just wraps around LibInitializeShellApplication().

剩余132页未读，继续阅读

biosdebuger

粉丝: 44
资源: 12

EFI Shell开发者指南：构建应用程序

EFI_SHELL.zip

EFI_SHELL64.rar

EFI_Shell_Developer_Guide_Ver0-91

启动efi_linux内核启动流程分析 efi_main

EFI_EDID_DISCOVERED_PROTOCOL_GUID

EFI_EDID_OVERRIDE_PROTOCOL_GUID

EFI_PEI_BLOCK_DEVICE_TYP

EFI_DRIVER_BINDING_PROTOCOL

EFI_FV_FILETYPE_FREEFORM

typedef UINTN EFI_STATUS 使用举例

高通EFI_QCOM_PMIC_PON_PROTOCOL

qemu_kylin_efi.fd

高通EFI_CHARGER_EX_PROTOCOL

EFI_FVH_SIGNATURE

extern EFI_SYSTEM_TABLE *gST;

#define EFI_CPUID_VERSION_INFO 0x1 #define BROADWELL_CPUID 0x406f0 #define MAX_CPUS 16 详细解释

eeupdate64e.efi

typedef UINTN EFI_STATUS

最新资源