背景
我需要在高通平台上学习点亮LCD，目前通过同事在别的平台的配置代码，我已经将kernel部分的屏幕点亮了；剩余的工作量就在BP侧，也就是系统刚开机的那一段时间。在开发过程中，我发现我对BP侧的开发有点不太熟悉，因此我需要搞清楚有关的概念。只有搞清楚了这些基本概念，我才能够在后续的工作中不留下隐患。
有关文档：
- https://www.cnblogs.com/we-hjb/p/9800627.html
- https://blog.csdn.net/u014089131/article/details/73617716
- https://blog.csdn.net/weixin_41803132/article/details/107692862
- 高通UEFI、XBL及ABL的详细介绍： 《80_P2484_37_LINUX_ANDROID_UEFI_OVERVIEW.pdf》。
UEFI 介绍
UEFI(Unified extensible firmware interface)统一的可扩展固件接口，是一种详细描述类型接口的标准。
可扩展固件接口（Extensible Firmware Interface，EFI）是 Intel 为 PC 固件的体系结构、接口和服务提出的建议标准。其主要目的是为了提供一组在 OS 加载之前（启动前）在所有平台上一致的、正确指定的启动服务，被看做是有近20多年历史的 BIOS 的继任者。
BIOS是汇编实现的，采用的是16bit 实模式寻址方式，最大支持的内存只有1M，代码易读性以及实现的功能都受到限制，而且移植起来不方便。BIOS支持的最大磁盘空间不超过2TB。
UEFI克服了上述的所有缺点，采用C语言实现，分层，模块化设计，实现了CPU以及驱动的无关性。UEFI可以理解为一个完整的系统，包含了上电时序，驱动实现，os环境建立(这个os可以理解为UEFI运行独有的os，非linux，windows)，应用程序。其中应用程序支持网络配置，类shell环境，fastboot，linux loader等。
UEFI启动阶段
UEFI从上电到关机，一共有七个阶段：
- SEC（安全验证）
其功能包括：接受处理系统启动与重启信号、初始化临时RAM区、作为可信系统的根、以及传递系统参数到下一阶段。
其执行流程是：
上电 -> ResetVector -> SEC函数入口 -> PEI函数入口 - PEI
主要功能是为DXE准备执行环境，将HOB列表传递给DXE。此阶段到后期内存才被初始化，所以资源相当有限，尚未可进行复杂的工作。 - DXE
此阶段执行大部分系统初始化工作，内存已被初始化，可以进行大量复杂工作。当所有的Driver都执行完毕，说明系统初始化完成，接着通过EFI_BDS_ARCH_PROTOCAL找到BDS并调用BDS的入口函数，进入BDS阶段。 - BDS
此阶段主要功能是执行启动策略，等OS Loader启动后，系统进入TSL阶段。 - TSL
TSL是OS Loader执行的第一阶段，OS Loader在这个阶段作为UEFI APPLICATION运行，当ExitBootServices服务被调用后，进入RT（RunTime）阶段。 - RT
系统进入此阶段后，系统控制权从UEFI内核转交到OS Loader上。随着OS Loader的执行，OS最终取得对系统的 控制权。 - AL
在RT阶段，如果系统遇到灾难性错误，系统固件需要提供错误处理和灾难恢复机制，而这种机制运行在AL阶段。
其中UEFI中涉及的名词缩写 ：
| 缩写 | 意义 |
|---|---|
| UEFI | Unified extensible firmware interface |
| SEC | Security |
| PEI | Pre EFI initialization |
| DXE | Driver execution Environment |
| BDS | Boot Dev Select |
| TSL | Transient System Loa |
| RT | Runtime |
| AL | After life |
| GUID | Globally Unique Identifier |
| CSM | Compatibility Support Modul |
| TCG | Trusted Computing Group |
| PE | Portable executable |
| COFF | Common object file format |
| FV | Firmware Volume |
UEFI有关文件格式
fdf：flash definitionfile，描述flash分区地址范围
dec：package declarationfile，定义了不同模块的GUID信息
dsc：description file，主要包含需要用到的所有inf文件
inf：单个模块的编译信息，类似makefile
efi ：最终编译生成的UEFI可执行文件
高通平台的UEFI设计
高通在MSM8998上引入了UEFI，用来代替LK(Little Kernel)。
而高通UEFI由XBL和ABL两部分组成。
在老版本中，LK的设备驱动都放在了XBL核心，Linux加载启动及fastboot等功能组件则作为独立的UEFI应用存在。
XBL
XBL负责芯片驱动及充电等核心应用功能。
XBL核心是none-HLOS boot_image代码的一部分，属于高通私有代码。
代码路径为：BP侧的BOOT.XX/boot_images
tree -L 2
.
├── about.html
├── ADSP.VT.5.4.1
│ ├── adsp_proc
│ ├── BuildProducts.txt
│ └── HY11_1.txt
├── Agatti.LA.1.0.1
│ ├── common
│ └── contents.xml
├── BOOT.XF.4.1
│ ├── BOOT.XF.4.1-00200-KAMORTALAZ-1.brfx
│ ├── BOOT.XF.4.1-00200-KAMORTALAZ-1_notes.txt
│ ├── boot_images ▲
│ │ ├── ArmPkg
│ │ ├── ArmPlatformPkg
│ │ ├── BaseTools
│ │ ├── Build
│ │ ├── Conf
│ │ ├── EmbeddedPkg
│ │ ├── FatPkg
│ │ ├── IntelFrameworkModulePkg
│ │ ├── IntelFrameworkPkg
│ │ ├── MdeModulePkg
│ │ ├── MdePkg
│ │ ├── NetworkPkg
│ │ ├── OptionRomPkg
│ │ ├── QcomPkg
│ │ └── ShellPkg
│ ├── BuildProducts.txt
│ ├── copyrightmod.xml
│ ├── CRM_BOOT.XF.4.1-00200-KAMORTALAZ-1.cs
│ ├── si
│ └── VerifySrc.log
├── BTFM.CHE.2.1.5
│ └── btfm_proc
├── BTFM.CMC.1.2.0
│ └── btfm_proc
├── build_sdm6115.bat
├── CDSP.VT.2.4.1
│ ├── BuildProducts.txt
│ ├── cdsp_proc
│ └── HY11_1.txt
├── env.bat
├── Kamorta.LA.1.0.1
│ ├── common
│ └── contents.xml
├── LA.QSSI.11.0
│ └── LINUX
├── LA.UM.9.15
│ └── LINUX
├── MPSS.HA.1.0
│ └── modem_proc
├── RPM.BF.1.10
│ └── rpm_proc
├── TZ.APPS.1.1
│ └── qtee_tas
├── TZ.APPS.2.0
│ └── qtee_tas
├── TZ.XF.5.1
│ └── trustzone_images
├── VIDEO.VE.6.0
│ ├── manifest.xml
│ └── venus_proc
└── WLAN.HL.3.2.4
└── wlan_proc
UEFI代码中大量使用了protocol概念，这个protocol其实指的是驱动，包含了驱动函数指针和数据。我们会在附录中介绍这一部分。
总之，记住：XBL实现的protocol，在ABL中可以直接调用。
ABL
ABL包括芯片无关的应用如fastboot。ABL则在开源Linux Android代码树里。
ABL的编译非常简单，依次执行命令：
source build/envsetup.sh
lunch 32
make aboot
不同的厂商对UEFI有不同的实现，一种比较常用的开源实现是EDK2；EDK2是一个遵循UEFI标准和PI标准的跨平台固件开发环境，EDK2支持多种操作系统, 也支持跨平台编译。
确切来讲，高通所使用的edk2即为ABL部分的代码。
高通UEFI有关源码
对于高通平台启动过程依次为：PBL->XBL->ABL。
一般用户定制化主要集中在ABL中，这部分代码树如下：
这部分里面主要是作为linux-loader 用来加载linux，以及fastboot。
用户修改主要集中在这两个部分，入口函数LinuxLoaderEntry。
${Andrioid源码树}/bootable/bootloader/edk2/QcomModulePkg
├── Application
│ └── LinuxLoader
│ ├── LinuxLoader.c
│ └── LinuxLoader.inf
├── Include
│ ├── Library
│ │ ├──BoardCustom.h
│ │ ├── Board.h
│ │ ├──BootImage.h
│ │ ├──BootLinux.h
│ │ ├──BootStats.h
│ │ ├──Decompress.h
│ │ ├──DeviceInfo.h
│ │ ├── DrawUI.h
│ │ ├──FastbootMenu.h
│ │ ├── Fonts.h
│ │ ├── KeyPad.h
│ │ ├──LinuxLoaderLib.h
│ │ ├── list.h
│ │ ├──LocateDeviceTree.h
│ │ ├──MenuKeysDetection.h
│ │ ├──PartitionTableUpdate.h
│ │ ├── Recovery.h
│ │ ├── Reg.h
│ │ ├──ShutdownServices.h
│ │ ├──StackCanary.h
│ │ ├──UnlockMenu.h
│ │ ├──UpdateCmdLine.h
│ │ ├──UpdateDeviceTree.h
│ │ └──VerifiedBootMenu.h
│ └── Protocol
│ ├── EFICardInfo.h
│ ├── EFIChargerEx.h
│ ├── EFIChipInfo.h
│ ├── EFIChipInfoTypes.h
│ ├── EFIEraseBlock.h
│ ├── EFILimits.h
│ ├── EFIMdtp.h
│ ├── EFIPlatformInfo.h
│ ├── EFIPlatformInfoTypes.h
│ ├── EFIPmicPon.h
│ ├── EFIPmicVersion.h
│ ├── EFIQseecom.h
│ ├── EFIRamPartition.h
│ ├── EFIResetReason.h
│ ├── EFIRng.h
│ ├── EFIScmModeSwitch.h
│ ├── EFIUsbDevice.h
│ ├── EFIUsbEx.h
│ ├── EFIVerifiedBoot.h
│ └── UsbEx.h
├── Library
│ ├── BootLib
│ │ ├── Board.c
│ │ ├──BootLib.inf
│ │ ├──BootLinux.c
│ │ ├──BootStats.c
│ │ ├──Decompress.c
│ │ ├──DeviceInfo.c
│ │ ├── DrawUI.c
│ │ ├──FastbootMenu.c
│ │ ├── KeyPad.c
│ │ ├──LinuxLoaderLib.c
│ │ ├──LocateDeviceTree.c
│ │ ├──MenuKeysDetection.c
│ │ ├──PartitionTableUpdate.c
│ │ ├── Recovery.c
│ │ ├──ShutdownServices.c
│ │ ├──UnlockMenu.c
│ │ ├──UpdateCmdLine.c
│ │ ├──UpdateDeviceTree.c
│ │ └──VerifiedBootMenu.c
│ ├── FastbootLib
│ │ ├──FastbootCmds.c
│ │ ├──FastbootCmds.h
│ │ ├──FastbootLib.inf
│ │ ├──FastbootMain.c
│ │ ├──FastbootMain.h
│ │ ├──MetaFormat.h
│ │ ├──SparseFormat.h
│ │ ├──UsbDescriptors.c
│ │ └──UsbDescriptors.h
│ ├── StackCanary
│ │ ├──StackCanary.c
│ │ └──StackCanary.inf
│ └── zlib
│ ├── adler32.c
│ ├── inffast.c
│ ├── inffast.h
│ ├── inffixed.h
│ ├── inflate.c
│ ├── inflate.h
│ ├── inftrees.c
│ ├── inftrees.h
│ ├── zconf.h
│ ├── zlib.h
│ ├── zlib.inf
│ ├── zutil.c
│ └── zutil.h
├──QcomModulePkg.dec
├──QcomModulePkg.dsc
├──QcomModulePkg.fdf
└── Tools
├── app_path_set.cmm
├── check_paths.cmm
├── debug_app.cmm
├── elf_tools.py
├── image_header.py
├── load_uefi_dump.cmm
├── log_save.cmm
├── symbol_Load.cmm
└── uefi_core_path_set.cmm
附录：为什么android 默认bootloader选择lk?
reference：https://blog.csdn.net/leo_wdls/article/details/45173643
结论：用于移动通信的android设备（如手机平板）：软件小巧，架构简单，满足android bootloader的基本需求。
lk源码目录位置：
bootable/bootloader/lk
Android bootloader需求：
加载引导
linux kernel需要驱动
Display、Usb、Keypad、Pmic、Vibrator
Uboot 的特点：
加载引导linux kernel
发展早，软件成熟稳定，功能完备；
支持的多个CPU 体系
支持复杂驱动，如Fs/Network等等;
Little Kernel特点：
加载引导linux kernel
轻量级、不支持复杂的驱动
附录：关于UEFI的Protocol概念
为什么要有Protocol？
大家都知道，UEFI的英文翻译过来应该叫“可扩展固件接口”。这个名词中最重要的事实上是“可扩展”这三个字。换言之，相比传统的系统固件而言，UEFI固件具备了完善的可扩展支持。这个概念对软件行业不是一个新概念，但是对bios这样一个陈旧腐朽的东西而言，的确是一个创新的思想。
所谓可扩展的含义就是可以在系统完成后（编译为binary）之后，再次为系统增加新的功能，而不用重新rebuild整个系统。在这个大的需求的前提下，还有一些其他的重要的含义，比如必须支持不同的组件的独立开发。
比如A厂商今天针对某硬件开发了一个驱动，他们发布了一个二进制包APackage；而B厂商则针对另一个硬件开发了一个驱动，他们发布了一个二进制包BPackage；现在APackage和BPackage都需要集成到bios内。且必须以二进制的形式集成。因为A和B厂商的知识产权需要得到尊重。或者像OS下那样，可以通过某种方法在系统已经运行起来后加载到内存。
更好玩的是，A厂商并不希望自己需要重新从车轮开始发明。比如他们针对的硬件是一个PCI的适配器，他们希望希望系统里已经有了诸如ReadPci()或者WritePci()这样调用来简化他们编程上的工作。换言之，他们希望目标系统能够支持不同的二进制组件之间的运行时通讯。
支持二进制组件的运行时通讯是一个十分复杂的技术。这里所谓的通讯，包括但不限于如下的含义：
1、互操作。A组件自由可以调用B组件实现的函数。反过来也一样。
2、数据传递。双方可以通过某种方法（shared memory, pipes and etc）互相交换数据。
3、可探测。某组件必须具备探测另一个组件是否存在的能力。
4、组件的开发必须是独立的。开发A组件不需要B组件的源代码，反之亦然。
这可以说是现代操作系统的一个核心概念。
熟悉Windows的朋友可能十分清楚Windows下的COM组件，所有的COM组件都可以互相通讯的。且应用程序可以自由的使用任何一个组件提供的服务。
只有具备了这样的能力的系统才可以被叫做“可扩展”的。而UEFI为了达到可扩展的能力，必须提供一种机制来提供支持，于是UEFI领域的专家们发明了Protocol。
从约定到接口
Protocol从本质上说是一种调用者与被调用者之间的“约定”。而这种“约定”在软件开发领域有另一个更形象化的名字叫接口（Interface)。
为了做到二进制间的互操作，那么参与操作的双方（调用者与被调用者）都必须做出一定的让步，这个让步就是双方必须遵循实现商量好的调用方法（接口）。而这种事先的约定的接口就是protocol的定义。而这种定义尤以.h文件的形式加以实现。
由于目前UEFI还是几乎是用C语言开发，基本上不存在跨语言的问题，所以Protocol才可以表达成.h文件。
而Windows下的COM的Interface，由于考虑到跨语言的问题，才专门有了一个新的通用语言叫接口定义语言（IDL，Interface Definiton Language），使用时候专门有一个IDL的compiler将IDL翻译成各个其他语言专用的表达方法（对于C语言，就是生成对应的.h文件）。
具体实现
定义
我们现在来看一个.h文件，看看一个protocol到底是怎样定义出来的。
用任意一个编辑器打开一个.h的接口文件，无论是什么样的接口，都必定是遵循UEFI规范所定义的标准而实现的。
以rampatition为例：boot_images/QcomPkg/Include/Protocol/EFIRamPartition.h中声明了rampatition protocol：
/**
@file EFIRamPartition.h
@brief RamPartition EFI protocol interface.
*/
/*=============================================================================
Copyright (c) 2015,2018 Qualcomm Technologies, Incorporated.
All rights reserved.
Qualcomm Technologies, Confidential and Proprietary.
=============================================================================*/
/*=============================================================================
EDIT HISTORY
when who what, where, why
-------- --- -----------------------------------------------------------
06/05/18 daisond Added GetMinPasrSize module in rampartition protocol
09/30/15 vk Initial Revision
=============================================================================*/
#ifndef __EFIRAMPARTITION_H__
#define __EFIRAMPARTITION_H__
/** @cond */
typedef struct _EFI_RAMPARTITION_PROTOCOL EFI_RAMPARTITION_PROTOCOL;
/** @endcond */
/** @addtogroup efi_ramPartition_constants
@{ */
/**
Protocol version.
*/
#define EFI_RAMPARTITION_PROTOCOL_REVISION 0x0000000000010001
/** @} */ /* end_addtogroup efi_ramPartition_constants */
/* Protocol GUID definition */
/** @ingroup efi_ramPartition_protocol */
#define EFI_RAMPARTITION_PROTOCOL_GUID
{ 0x5172FFB5, 0x4253, 0x7D51, { 0xC6, 0x41, 0xA7, 0x01, 0xF9, 0x73, 0x10, 0x3C } }
/** @cond */
/**
External reference to the RAMPARTITION Protocol GUID defined
in the .dec file.
*/
extern EFI_GUID gEfiRamPartitionProtocolGuid;
/** @endcond */
typedef struct _RamPartition
{
UINT64 Base;
UINT64 AvailableLength;
}RamPartitionEntry;
/** @} */ /* end_addtogroup efi_ramPartition_data_types */
/*==============================================================================
API IMPLEMENTATION
==============================================================================*/
/* ============================================================================
** Function : EFI_RamPartition_GetRamPartitionVersion
** ============================================================================
*/
/** @ingroup efi_ramPartition_getRamVersion
@par Summary
Gets the RAM Partition table version.
@param[in] This Pointer to the EFI_RAMPARTITION_PROTOCOL instance.
@param[out] MajorVersion Pointer to UINT32 which returns RAM partition table version
@param[out] MinorVersion Pointer to UINT32 which returns RAM partition table version
@return
EFI_SUCCESS -- Function completed successfully.
EFI_PROTOCOL_ERROR -- Error occurred during the operation.
*/
typedef
EFI_STATUS
(EFIAPI *EFI_RAMPARTITION_GETRAMPARTITIONVERSION)(
IN EFI_RAMPARTITION_PROTOCOL *This,
OUT UINT32 *MajorVersion,
OUT UINT32 *MinorVersion
);
/* ============================================================================
** Function : EFI_RamPartition_GetHighestBankBit
** ============================================================================
*/
/** @ingroup efi_ramPartition_getHighestBankBit
@par Summary
Gets the RAM Partition table version.
@param[in] This Pointer to the EFI_RAMPARTITION_PROTOCOL instance.
@param[out] HighestBankBit Pointer to Highest Bank Bit
@return
EFI_SUCCESS -- Function completed successfully.
EFI_PROTOCOL_ERROR -- Error occurred during the operation.
*/
typedef
EFI_STATUS
(EFIAPI *EFI_RAMPARTITION_GETHIGHESTBANKBIT)(
IN EFI_RAMPARTITION_PROTOCOL *This,
OUT UINT32 *HighestBankBit
);
/* ============================================================================
** Function : EFI_RamPartition_GetMinPasrSize
** ============================================================================
*/
/** @ingroup EFI_RamPartition_GetMinPasrSize
@par Summary
Gets the MinPasrSize
@param[in] This Pointer to the EFI_RAMPARTITION_PROTOCOL instance.
@param[out] MinPasrSize Pointer to MinPasrSize
@return
EFI_SUCCESS -- Function completed successfully.
EFI_PROTOCOL_ERROR -- Error occurred during the operation.
*/
typedef
EFI_STATUS
(EFIAPI *EFI_RAMPARTITION_GETMINPASRSIZE)(
IN EFI_RAMPARTITION_PROTOCOL *This,
OUT UINT32 *MinPasrSize
);
/* ============================================================================
** Function : EFI_RamPartition_GetRamPartitions
** ============================================================================
*/
/** @ingroup efi_ramPartition_getRamPartitions
@par Summary
Gets the Ram version as read from the hardware register.
@param[in] This Pointer to the EFI_RAMPARTITION_PROTOCOL instance.
@param[out] pnVersion Pointer to a UINT32 passed by the caller that
will be populated by the driver.
@return
EFI_SUCCESS -- Function completed successfully.
EFI_BUFFER_TOO_SMALL -- Returns number of partitions available
EFI_PROTOCOL_ERROR -- Error occurred during the operation.
*/
typedef
EFI_STATUS
(EFIAPI *EFI_RAMPARTITION_GETRAMPARTITIONS)(
IN EFI_RAMPARTITION_PROTOCOL* This,
OUT RamPartitionEntry *RamPartitions,
IN OUT UINT32 *NumPartition
);
/*===========================================================================
PROTOCOL INTERFACE
===========================================================================*/
/** @ingroup efi_ramPartition_protocol
@par Summary
Ram Information Protocol interface.
@par Parameters
*/
struct _EFI_RAMPARTITION_PROTOCOL {
UINT64 Revision;
EFI_RAMPARTITION_GETRAMPARTITIONVERSION GetRamPartitionVersion;
EFI_RAMPARTITION_GETHIGHESTBANKBIT GetHighestBankBit;
EFI_RAMPARTITION_GETRAMPARTITIONS GetRamPartitions;
EFI_RAMPARTITION_GETMINPASRSIZE GetMinPasrSize;
};
#endif /* __EFIRAMPARTITION_H__ */
我们注意到这些相同的形式：
typedef
EFI_STATUS
(EFIAPI *EFI_RAMPARTITION_GETRAMPARTITIONS)(
IN EFI_RAMPARTITION_PROTOCOL* This,
OUT RamPartitionEntry *RamPartitions,
IN OUT UINT32 *NumPartition
);
这是一个指向函数的指针类型的定义，它定义了一个新的指针类型叫EFI_RAMPARTITION_GETRAMPARTITIONS，如此是希望今后的系统能直接使用EFI_RAMPARTITION_GETRAMPARTITIONS类型，这样做主要希望能够提高代码的可读性。
这个指针类型指向了一个函数，这个函数有3个输入参数：This、RamPartitions、NumPartition
其他函数也是通过同样的方法定义出来的，下面会用到。
再看看文末最后的那一个结构体：
/*===========================================================================
PROTOCOL INTERFACE
===========================================================================*/
/** @ingroup efi_ramPartition_protocol
@par Summary
Ram Information Protocol interface.
@par Parameters
*/
struct _EFI_RAMPARTITION_PROTOCOL {
UINT64 Revision;
EFI_RAMPARTITION_GETRAMPARTITIONVERSION GetRamPartitionVersion;
EFI_RAMPARTITION_GETHIGHESTBANKBIT GetHighestBankBit;
EFI_RAMPARTITION_GETRAMPARTITIONS GetRamPartitions;
EFI_RAMPARTITION_GETMINPASRSIZE GetMinPasrSize;
};
这里又定义了一个大的结构类型_EFI_RAMPARTITION_PROTOCOL，注意到这个结构几乎是由之前提及的指针函数所构成的。
这样定义是显而易见的，既然是约定的定义，那么自然需要约定的函数的定义。
这个结构体是对应的Protocol的最主要的组成部分。
GUID
除此之外，一个Protocol还有一些其他的组成部分。
/* Protocol GUID definition */
/** @ingroup efi_ramPartition_protocol */
#define EFI_RAMPARTITION_PROTOCOL_GUID
{ 0x5172FFB5, 0x4253, 0x7D51, { 0xC6, 0x41, 0xA7, 0x01, 0xF9, 0x73, 0x10, 0x3C } }
/** @cond */
/**
External reference to the RAMPARTITION Protocol GUID defined
in the .dec file.
*/
extern EFI_GUID gEfiRamPartitionProtocolGuid;
/** @endcond */
首先是GUID，正如Windows下的COM Interfaces一样，每一个Protocol也有一个定义好的，唯一的标识符。这个标识符就用GUID来表达。这样一来每个Protocol都有了自己的名字，那么使用者可以方便的通过指明不同的GUID来得到不同的Protocol。
其次是一个指向GUID的全局指针变量，比如这里提到的这个_EFI_RAMPARTITION_PROTOCOL，就有一个全局的指针叫gEfiRamPartitionProtocolGuid的指针，它是EFI_GUID *结构的。
这样做事实上完全是为了方便，他的变量名的命名规则是统一的，即g + Efi + Protocol 名称 + ProtocolGuid。这样一来，程序员就不需记住相应GUID具体的值，而只在需要GUID作为参数的时候，使用这个全局变量即可，这有点类似Windows下的UUID宏。
实现
在boot_images/QcomPkg/Drivers/EnvDxe/EnvDxe.c中实现了上文提到的协议：
STATIC EFI_RAMPARTITION_PROTOCOL RamPartitionProtocol =
{
EFI_RAMPARTITION_PROTOCOL_REVISION,
EFI_GetRamPartitionVersion,
EFI_GetHighestBankBit,
EFI_GetRamPartitions,
EFI_GetMinPasrSize
};
EFI_STATUS
SetupRamPartitionProtocol ()
{
EFI_STATUS Status;
STATIC EFI_HANDLE ImageHandle;
Status = InitRamPartitionTableLib();
if (Status != EFI_SUCCESS)
return EFI_UNSUPPORTED;
Status = gBS->InstallMultipleProtocolInterfaces (&ImageHandle,
&gEfiRamPartitionProtocolGuid,
&RamPartitionProtocol,
NULL, NULL);
return Status;
}
具体的内容我们就不再往下看，但是可以推测，在这里绑定了对应的函数；之后只要得到gEfiRamPartitionProtocolGuid的地址，就可以访问到有关的接口。
这也就是所谓的：在XBL中实现了protocol，也就是驱动，在ABL中可以直接调用。