朱勇洪

摘要：由于UEFI框架下没有提供数据传输的模块，使得测试或者调试开发时需要经常对数据文件进行人工拷贝，导致了实现测试自动化或远程调试的不便。采用Socket数据传输方式设计并实现了UEFI下数据传输的工具，通过使用串口线来连接Host端和UEFI端，实现UEFI下的Application和Hostt端协同工作来达到Host端和uEFI端通信的目的，从而使得从Host端編译出来的文件可以直接传输到UEFI端的设备中去，减少人工操作方便实现测试自动化。最后本文通过Intel 945G Express Chioset平台来验证工具的正确性。

关键词：UEFI;数据传输;Application;串口;Socket

中图分类号：TP311.56 文献标识码：A 文章编号：1006-8228（2020）07-26-04

0引言

数据传输，顾名思义，就是要将数据从一个地方传送到另一个地方的通信过程。目前，UEFI框架下并没有提供数据传输的工具，导致开发人员、测试人员将UEFIBIOS文件编译出来之后，需要手动拷贝该文件到UEFI主板设备中，大量的人工操作导致了实现自动化测试或者远程调试的不便。基于这样的实用背景，本文通过采用Socket的数据传输方式，实现UEFI端的Application协同Host端进行工作，达到Host端和UEFI端之间的通信的功能，从而可以轻松的将文件在两端互传，避免了手动操作，为远程调试和测试自动化提供基础。

1UEFl Application简介

UEFI的Application指系统的核心应用和调用程序，如BIOS的设置、一些应用程式以及配置管理等等，它与UEFI库函数结合在一起，可以提供基本控制台I/O，基本磁盘I/O，内存管理以及字符串操作的功能。它是不依赖于系统软硬件的跨平台扩展Firmware，以.eft文件形式存在，它在执行完成后会返回控制权，不会驻留在系统内存中，因而能够方便地移植到各个不同的平台上（例如，IA32、IA64、Intel-64、Apple*，Duet模拟器等等）。UEFI Application的编程模型主要分为两大类，一类是基于EFI模型的，它的代码比较小，因为它仅仅需要使用EFI的数据结构;另一类是基于便携式模型开发的，与前一类相比较，它是一种更容易导入ANSI/POSIX编程模型的程序，并且它拥有常用的c语言的Library和c语言编程接口程序。

UEFI Application的执行流程分为三个部分，首先它必须经过UEFI Loader来进行加载，然后进入到Application的入口函数处，最后通过Exit（）退出应用并返回Application的UEFI Component。

2基于UEFl的数据传输工具的研发

数据传输的方式一般有以下几种：最简单交互的socket方式，适合大数据量交互的邱/文件共享服务器方式，数据库共享数据方式以及Message数据传输方式。本文采用socket方式，因为该方式通用性比较强，且易于编程实现，通过传输层协议容易加密传输的数据，使得安全性更高，同时UEFI下需要传输的文件量很小，数据交互量少，也比较适用该方式。

2.1设计架构分析

通过使用串口线缆来连接Host端和UEFI端，Host端使用Windows 10 Enterprise系统，通过标准的c++语言开发程序，UEFI端使用支持UEFI启动的主板，使用c语言编写并通过编译产生一个备数据传输功能的UEFI Application的应用程序，此处所使用的c语言在库函数、框架结构、调用的服务类型等方面需参照Platform Initialization Spec。

Host端主要由以下四个部分组成：基本信息部分、串口控制部分、线程控制部分、文件传输部分。

（1）基本信息部分：通过运行ReadSetuplnfo（）函数来读取串口的相关配置信息，主要包括串口的名称、波特率和串口的流控信息，并将这些信息存入到指定的数据结构中。

（2）串口控制部分：创建一个CSerial类来负责串口的初始化并获得句柄进行串口的读写操作。在该类中封装了初始化串口和控制串口运行过程中需要使用的一些变量以及读写串口时需要的相关函数。

（3）线程控制部分：设计主线程、读线程和写线程。主线程主要负责创建读写线程，后续将不再进行其他操作，可留作后续开发的拓展使用。在使用串口进行数据的读写传输时，读线程负责读取UEFI端通过串口线缆发送过来的信息，并将这些信息显示在屏幕上;写线程则负责将用户输入的信息（例如，需要传输的文件名）通过串口线缆发送到UEFI端。

（4）文件传输部分：包括从Host端发送单个文件到UEFI端和从UEFI端接收单个文件两部分，这个过程需要UEFI端的Application配合使用。

UEFI端是一个基于UEFI的Application应用程序，参考EDKIIINFSpec、DSCSpec、DECspec提供该程序所需要的模块文件（.inf）及c文件，平台描述文件（.dsc）和平台声明文件（.dec），其功能是为了配合Host端的文件传输部分，其中UEFI端主要实现了从Host端接收单个文件和发送单个文件到Host端这两个部分的功能。

2.2数据传输实现过程分析

对于数据的传输，其实现过程主要包括四个部分：Host端发送单个文件，Host端接收单个文件，UEFI端发送单个文件以及UEFI端接收单个文件。以Host端发送单个文件为例，其过程主要包括①读取用户输入的文件名，并将文件打开;②将读取到的文件名转换成传输至UEFI端的路径、文件名组合;③计算该文件名的长度以及文件的长度;④调用TestSpeed H to_T（）函数来测试Host端向UEFI端传输数据的速度;⑤按照上一步获得的数据来设置传输包的长度以及包的传输时间间隔;⑥按照包封装的形式发送包含文件名、文件名长度、文件长度的数据包至UEFI端;⑦按照包封装的形式发送文件内容至UEFI端;⑧释放所使用的相关资源，从Host端到UEFI端的数据传输到此结束。在该过程中，主函数TransferHostFile（）首先调用SafeSendData（）函数来发送包含文件名、文件名长度、文件长度的数据包至UEFI端，然后再次调用SafeSendData（）函数来发送文件内容至UEFI端。而SafeSendData（）函数则会将所得到的所有数据分装成数据包的形式，然后将数据包进行Md5 CheckSum的计算来检验在传输过程中数据包的正确性。图1显示了Host端传输文件至UEFI端的流程。

在UEFI端的Application其实现过程需要将其代码添加到UEFI的源代码结构中进行编译，首先需要建立一个存放该Application源代码的子目录和一個与Application源代码相关的.inf文件，对于Application的源文件，可以放在工作目录的任何地方，而该文件的存放路径则需要在所开发模块的.inf文件中指出。一个模块的.inf文件主要是为了定义单个项目所需要的所有信息，包括了一些源文件，库或者库类，以及一些编译相关的组件等，用它来产生的二进制文件要么是原始的二进制文件，要么是具有PE32/PE32+/COFF格式的可以在UEFIShell环境下执行的文件。

3数据传输工具的测试检验

该检验过程分别以Windows 10 Enterprise系统和Intel 945G Express Chipset平台作为实验检测的Host端和UEFI端，通过串口连接两端，同时在UEFI端配备有外围设备u盘。将Intel 945G Express Chipset平台启动到UEFI Shell的模式下，运行处于Host端的程序，在弹出的运行窗口中运行处于UEFI端u盘中的UEFI Application-FDTTargetWithShell.efi，此时便可以进行Host端和UEFI端的相互通信功能，进行单个文件的收发功能。

在Host端执行数据传输工具，首先会获得串口相关信息，然后进）kUEFI端的Shell环境，由此可进入处于UEFI端的外围设备u盘中，在运行了u盘中的FDTTargetWithShell.eft这个Application之后便可以在Host端和UEFI端进行数据传输了。此时状态如图3。

数据传输工具提供了单个文件的收发功能，可以通过输入操作数1、2分别进行选择。图4给出了选择单个文件从Host端发送到UEFI端的过程，图5给出了文件成功传输时的状态。最后通过检查u盘中的文件来确认文件已经从Host端传输到UEFI端，同时对接收到的文件与Host端的发送的文件进行比较，来确认数据在传输过程中的完整性。

在选择输入操作功能2的情况下，实现了从UEFI端发送单个文件到Host端的功能。图6给出了选择单个文件从UEFI端发送到Host端的过程，而图7则给出了双端通信过程中文件传输成功时的状态。

4结束语

本文采用Socket数据传输的方式设计了UEFI下的数据传输工具进行UEFI端和Host端的单个文件的传输功能，可以方便开发人员进行远程调试的工作，也可以方便测试人员使用该工具实现测试自动化。下一步可以尝试对数据传输的图形化界面的设计与实现，尝试支持丰富的窗口创建、控件的支持和显示颜色特效的添加。目前图形化界面仅仅负责对配置选项进行简单的控制，当然选用的图形化界面语言范围可以再进一步扩展，不仅仅局限于UEFI BIOS系统当前支持的VFR语言。