Intel Platform Innovation Framework的uEFI CSM规格修订0.97：兼容支持模块详解

5星 · 超过95%的资源需积分: 9 56 浏览量更新于2024-07-28 2 收藏 576KB PDF 举报

本文档是Intel Platform Innovation Framework for EFI（Intel®平台创新框架）中的Compatibility Support Module (CSM) 规范的修订版0.97，发布日期为2007年9月4日。这个规格说明书旨在提供一个关于如何在基于UEFI（Unified Extensible Firmware Interface，统一可扩展固件接口）的现代系统中实现兼容旧式BIOS（Basic Input/Output System）应用程序的方法。 Intel Platform Innovation Framework是一个框架，它允许在支持UEFI的硬件上运行不同类型的软件，包括那些依赖于传统BIOS功能的应用程序。CSM规范的作用是作为一个桥梁，使这些传统应用能够在UEFI环境中运行，同时保持向后兼容性。本规范强调了“AS IS”提供，意味着Intel不对其任何形式的担保负责，包括但不限于商品质量、非侵权性、特定用途适用性或由建议、规格或示例产生的任何其他保修。用户在设计和实现时必须明确了解，Intel不对基于该规范的实施可能导致的知识产权侵犯或未来变化可能引发的冲突和不兼容性承担责任。值得注意的是，文档中提到的“保留”或“未定义”的特性，设计师应避免依赖，因为Intel保留了对这些特征进行未来定义的权利，并不对由此产生的任何问题承担义务。这意味着随着技术的发展，这些区域可能会有变动，开发者需要密切关注更新以确保他们的设计与未来标准相符合。 Intel CSM spec Rev 0.97提供了构建兼容性支持模块的关键指导，让开发者能够在过渡期间平稳地将传统的BIOS应用迁移到UEFI架构，同时也明确了责任范围和预期的使用限制。理解和遵循此规范对于确保系统兼容性和避免潜在法律风险至关重要。

Several pieces of code make up the CSM, as listed in the table below.

Table 1 Components of CSM

Component Description

EfiCompatibility 32-bit code that interfaces with EFI EfiCompatibility is comprised of

several EFI drivers. These drivers fall into the following four

categories:

• Drivers that are platform and hardware neutral. They

provide the foundation of the CSM and do not change from

platform to platform.

• Drivers that are platform and chipset neutral They control

traditional hardware such as the 8259 PIC.

• Drivers that are chipset dependant. They control chipset

hardware that changes from platform to platform. An

example is the code to perform PCI IRQ steering.

• Drivers that are platform specific.

Compatibility16 Stripped-down, traditional IBV, 16-bit real-mode code consisting

mainly of the traditional software INT runtime support.

CompatibilitySmm Optional code in SMM to perform traditional functions that are not

taken over by the EFI SMM.

Thunk and Reverse Thunk Thunk code is used to switch from EfiCompatibility (32-bit) to

Compatibility16 or traditional OpROMs (16-bit). Reverse thunk code

is used to switch from Compatibility16 code or traditional OpROMs

(16-bit) to EfiCompatibility (32-bit).

Outside the CSM, but still part of a traditional system, are the traditional 16-bit real-

mode OpROMs.

The CSM operates in two distinct environments:

• Booting a traditional or non-EFI-aware OS.

• Loading an EFI-aware OS a device that is controlled by a traditional OpROM.

The first operation, booting a traditional or non-EFI-aware OS, is the traditional

environment.

It is expected that traditional OpROMs will be around long after traditional OSs have

been replaced by EFI-aware OSs. The code that is required to load an EFI-aware OS is a

subset of the code that is required to boot a traditional (non-EFI-aware) OS. The

Framework architecture reflects this split to allow removing unneeded code in the future.

See Steps in CSM Driver Interactions for additional details on how the various CSM

components interconnect with each other and how external drivers interconnect with the

CSM.

2.4.2 EfiCompatibility

The EfiCompatibility consists of the protocols listed in the table below. This

EfiCompatibility code is written in C and exists in the EFI environment.

Design Discussion

Table 2 EfiCompatibility Protocols

Protocol Description

Legacy BIOS Protocoll The primary protocol of the CSM. This protocol is platform and

hardware neutral.

Legacy BIOS Platform

Protocol

Provides the information that makes this platform unique compared

to another platform using the same chipset. This protocol is platform

specific.

Legacy Region Protocol Manages the hardware that allows the region from physical address

0xC0000 to 0xFFFFF to be made read only or read-write. It can

optionally manage the hardware that prevents a write in the above

region propagating to any aliased memory regions This protocol is

chipset specific.

Legacy 8259 Protocol Manages the hardware controlling the 8259 PIC in 32-bit protected

mode and in 16-bit real mode. It keeps track of the interrupt masks

and edge/level programming for both modes. This protocol is

platform and chipset neutral.

Legacy Interrupt Protocol Manages the hardware for assigning IRQs to PCI. EFI is polled rather

than interrupt driven. This protocol is chipset specific.

Each of the above protocols is described in more detail in the following sections. See

EfiCompatibility Code

in Code Definitions for the definitions of these protocols.

2.4.2.1 Legacy BIOS Protocol

2.4.2.1.1 LegacyBios Module

The LegacyBios module constitutes the CSM skeleton. The other CSM modules are

support modules. The LegacyBios initialization code consists of the following elements:

• Code to initialize itself and to load the Compatibility16 code

• Code to determine the boot device

• Code to load other EfiCompatibility drivers

• Code to load the thunk and reverse thunk code

• Code to interface with Compatibility16 functions

• Code to load and invoke traditional OpROMs, including code to find baseboard

traditional OpROMs and to load them

• Code to load a traditional OS

The BDS code, as part of its normal functions, binds a device with a traditional OpROM,

but it uses the LegacyBios code to dispatch and initialize the traditional OpROM. The BDS

code also generates the various boot device paths, but it uses the LegacyBios code to

boot to a traditional OS. The LegacyBios code that is used to boot a traditional OS

performs the following actions:

• Extracts EFI data into standard EfiCompatibility structures

• Updates standard BDS, EBDA, and CMOS locations

• Updates hardware with traditional resources (IRQs)

The LegacyBios code parses the data hub or invokes EFI APIs to gather data that is

required by Compatibility16 and translates it into a series of standard Compatibility16

data structures. That data is used to update standard traditional data values in the BDA,

EBDA, and CMOS. The data is also used by Legacy BIOS Protocol APIs to reprogram

traditional devices to traditional resources.

Compatibility16 does not configure low-level device hardware and instead leaves that

operation to EFI. EFI does not assign IRQs to devices such as serial ports, but

Compatibility16 requires them to be configured with the appropriate IRQs. The

LegacyBios code must reconfigure any traditional devices that were configured by EFI

into a valid Compatibility16 configuration.

It is expected that there will be a light and full version of the Legacy BIOS Protocol. The

light version is for environments where the OS is always an EFI-aware OS that might

have traditional OpROMS. The full version is for environments where a traditional OS

might be invoked.

2.4.2.1.2 Legacy BIOS Protocol

The Legacy BIOS Protocol, along with the initialization of the LegacyBios driver, provides

the foundation of the CSM code. The table below lists the functions that are included in

the Legacy BIOS Protocol. See EFI_LEGACY_BIOS_PROTOCOL in Code Definitions

for the definitions of these functions.

Table 3 Functions in Legacy BIOS Protocol

Functions Description

BootUnconventionalDevice() Allows the user to boot off of an unconventional device such as a

PARTIES partition.

CheckPciRom() Checks if a device has a traditional OpROM associated with it. It is used

to determine valid traditional OS boot devices, or if a traditional OpROM

exists for a device that has no EFI OpROM support.

CopyLegacyRegion() Allows EFI to copy data to the area specified by

GetLegacyRegion(). It may be invoked multiple times. This

function performs boundary checking via information passed into

GetLegacyRegion().

FarCall86() Allows the 32-bit protected-mode code to perform a far call to 16-bit

real-mode code. It is analogous to the

Int86() function, but a far

call is patched instead.

GetBbsInfo() Allows external drivers to access the internal EfiCompatibility BBS data

structures. This function is normally used by BIOS Setup.

GetLegacyRegion() Allows EFI to reserve an area in the 0xE0000 or 0xF0000 block. This

function may be invoked only once.

Int86() Allows the 32-bit protected-mode code to perform a traditional 16-bit

real-mode software interrupt. The function invokes the thunk code to

switch to 16-bit real mode, patches an INT instruction with the required

software interrupt, loads the IA-32 registers from data in the passed-in

interrupt, it updates the register file and switches back to 32-bit

protected mode.

InstallPciRom() Installs a traditional OpROM in the 0xC0000 to 0xFFFFF region.

LegacyBoot() Initiates booting from a traditional OS. The majority of the CSM work is

done within this function, because the final commitment to boot from a

traditional OS has been made and the boot process will destroy EFI

code. This function returns to the caller only in the exceptional condition

in which a traditional INT19 failed but control was never passed to an

OS first-stage loader. If control was ever passed to an OS first-stage

loader, then the Compatibility16 code must issue a reset, because

memory may have been written over and EFI corrupted.

Design Discussion

PrepareToBootEfi() Allows an external agent to prepare for booting to an EFI-aware OS. It

is a subset of actions taken by

LegacyBoot(). It causes legacy

drive numbers to be assigned.

ShadowAllLegacyOproms() Allows an external agent to force the loading of legacy OpROMs. A side

affect of this function is that all EFI drivers are disconnected and must

be reconnected for proper EFI functioning.

UpdateKeyboardLedStatus() Allows the EfiCompatibility code to synchronize the traditional BIOS BDA

with the state that EFI has programmed the keyboard LEDs. This

function does not touch hardware. The Compatibility16 code is invoked

with the state of the LEDs in case any proprietary information needs to

be updated.

2.4.2.1.3 GetBbsInfo(), LegacyBoot(), ShadowAllLegacyOproms(), and

PrepareToBootEfi()

BDS and BIOS Setup require certain information to intelligently determine boot devices

and require different actions to occur depending upon the type of OS being booted.

Determining what boot devices are available

Both BDS and BIOS Setup need to know the complete list of boot devices to

present a comprehensive list to the user. It is possible that a device

controller by both an EFI and legacy OpROM may report different results. EFI

drivers generate a list of boot devices and then the

EFI_LEGACY_BIOS_PROTOCOL.ShadowAllLegacyOproms() call is

issued. The internal CSM BBS table information is updated during the OpROM

initializations. The

EFI_LEGACY_BIOS_PROTOCOL.ShadowAllLegacyOproms()

function will disconnect all EFI devices so a reconnect must be performed

after the invocation.

EFI_LEGACY_BIOS_PROTOCOL.GetBbsInfo()

returns the list of legacy boot devices that were discovered. Note that at this

time no legacy drive numbers 0x8y have been assigned because the

Compatibility16 code has not been issued the

EFI_LEGACY_BIOS_PROTOCOL.PrepareToBootEfi() function.

Determining the boot OS type

Once the list of boot devices is available, the user selects the boot device. If

booting to a traditional OS, BDS issues the

EFI_LEGACY_BIOS_PROTOCOL.LegacyBoot() function. If booting to

an EFI-aware OS and any legacy OpROMs have been initialized, then

EFI_LEGACY_BIOS_PROTOCOL.PrepareToBootEfi() is issued.

2.4.2.2 Legacy BIOS Platform Protocol

The Legacy BIOS Platform Protocol provides the customization of CSM for both platform

configuration and for OEM differentiation. The table below lists the functions that are

included in the Legacy BIOS Platform Protocol. See

EFI_LEGACY_BIOS_PLATFORM_PROTOCOL in Code Definitions for the definitions of

these functions.

Table 4 Functions in the Legacy BIOS Platform Protocol

Function Description

GetPlatformHandle() Finds all handles for the requested entity and returns them sorted

by priority. Handle[0] is highest priority.

剩余178页未读，继续阅读

fox853028

粉丝: 0
资源: 4

Intel Platform Innovation Framework的uEFI CSM规格修订0.97：兼容支持模块详解

0.97以脱壳的MAIN

UEFI启动流程图

win7关闭csm，纯uefi启动

UEFI2.1 Spec

uefi dec spec

UEFI 2.2 spec

uefi 2.0 spec

uefi dsc spec

UEFI PI SPEC 1.7英文版本

UEFI规范 UEFI_Spec_2_9NEW可编辑.pdf

最新资源