【电源点播源码】【论坛 源码 .net】【seetaface源码下载】uefi源码

时间:2024-11-26 21:31:31 编辑:源码分销 来源:wikipedia源码

1.UEFI开发探索18 – 使用HII显示汉字3
2.LoongArch平台UEFI交叉编译环境搭建
3.UEFI之 Secure boot
4.UEFI开发探索15 – 图形模式下文字显示
5.UEFI开发环境搭建
6.UEFI之edk2 目录说明

uefi源码

UEFI开发探索18 – 使用HII显示汉字3

       在UEFI开发的源码探索之旅中,我们深入探讨了如何在HII环境中以汉字形式呈现,源码尤其是源码在罗冰博主(这里)的精彩分享中。首先,源码我们聚焦于两种模式——Text模式和Graphics模式,源码Text模式从B:起步,源码电源点播源码相对简单,源码而Graphics模式则遵循VESA标准,源码展现出了更高的源码复杂性。在UEFI shell的源码世界里,Text模式支持中文显示,源码但其背后的源码实现原理还需要通过源码的解读来揭示。Print函数巧妙地运用了SimpleFont来展现汉字的源码魅力,而Font格式则更为复杂,源码包含点阵信息结构、源码索引机制以及Font包头,想要深入了解,可以参考MdkModulePkg中的显示模块和Font.c里的FindGlyphBlock函数。

       在理解Unicode字符方面,我们参考了《UEFI原理与编程》的第页和第页内容,这些理论图表提供了深入洞察的窗口。在实际操作中,我们遇到了一些挑战,比如C标准的差异、变量定义位置和结构体初始化的问题。博主将其解决策略部分移植到了Luo2.c中,巧妙地解决了FontName外部变量的困扰。

       图5揭示了一个有趣的现象,运行结果显示的文字出现在左上角,这似乎暗示UEFI Shell的Text模式并非我们常见的传统文本模式。尽管如此,这并未阻碍我们的探索,我们继续前行。

       然而,期待中的字体并未如愿以偿,UEFI Shell选择使用SimpleFont字库。在此过程中,我们还尝试调整了盘符的显示颜色,通过Print和ConOut的SetAttribute方法,实验结果可见图6,这些微调带来了显著的视觉效果提升。

       如果你对这段UEFI汉字显示的探索之旅感兴趣,可以查看罗冰博主的开源项目代码:这里,那里充满了实践经验和详细代码,定会让你收获满满。在UEFI的世界里,每一个字符的呈现都是一次技术的跨越,值得我们深入探究。论坛 源码 .net

LoongArch平台UEFI交叉编译环境搭建

       LoongArch平台UEFI固件编译支持两种方法:X平台交叉编译与LoongArch平台本地编译。本文将详细介绍X平台交叉编译的搭建与使用。

       首先,选择支持的编译工具GCC8.3。基线版本为基于TianoCore的UDK。

       接着,下载并解压适合的交叉编译器到/opt目录。环境变量的配置至关重要,可以通过创建脚本文件env.sh进行临时设置,或永久写入.bashrc文件。

       临时设置方法包括创建脚本文件env.sh,输入环境变量设置内容,添加可执行权限,并执行脚本以验证是否生效。永久设置则是在.bashrc文件末尾写入配置内容,以实现环境变量的永久生效。

       编译方法包括解压源码,进入编译目录,修改配置文件,执行编译命令。生成的LS3AA.fd文件用于调试和正式产品。切换编译方式,DEBUG版本提供调试便利,RELEASE版本则去除调试信息,加快启动速度。

       编译过程中可能会遇到错误,解决方法包括确认环境变量是否生效,执行清理中间文件的命令,或安装缺失的依赖库,如iasl。

       LoongArch平台UEFI固件的烧写方式与MIPS平台UEFI一致,可通过JTAG、编程器、UEFI在线烧写以及PMON下更新UEFI和UEFI下更新PMON。注意LS3AA.fd文件大小,确保Flash大小至少为4MB,且使用正确型号的Flash芯片。

       编程器烧写方法需要将Flash芯片放入编程器座内,选择对应型号,导入二进制文件,完成烧写。UEFI在线烧写步骤包括准备U盘,插入板卡USB口,启动板卡并进入UEFI Shell,执行烧写命令,重启后更新UEFI固件。PMON下更新UEFI和UEFI下更新PMON步骤则分别涉及将文件放入U盘,seetaface源码下载启动板卡至PMON shell,执行烧写命令,重启更新。

       通过以上步骤,可以完成LoongArch平台UEFI固件的编译与烧写。

UEFI之 Secure boot

       UEFI Secure Boot详解

       Secure Boot的目标在于防范恶意软件入侵,其核心机制是通过UEFI固件内置的公钥进行软件验证。主板出厂时预装的公钥,确保只有经过私钥签名的操作系统和驱动才能加载,从而阻止未授权软件侵入引导过程,确保Boot的安全性。

       证书颁发机构,如OEM或其授权的Microsoft,会生成密钥对,并使用私钥对合法的启动模块和固件服务进行签名。UEFI固件内置的公钥则负责验证这些操作,确保其来源的可信性。

       密钥生成和签名过程涉及私钥PK.key、公钥PK.crt,以及用于UEFI setupUI的.cer证书。对于Hello.efi这类EFI文件,需要使用私钥db.key及其对应公钥db.crt进行签名,如需对内核vmlinuz进行签名,同样采用上述步骤,但vmlinuz因其非启动EFI文件,签名影响不大。

       sbsigntools工具是用于签名.efi文件的,可能需要针对Loongarch架构进行源码编译以解决不支持问题。在UEFI中,验证流程按照grub加载kernel,kernel加载module的顺序进行,确保每个文件都通过验证。

       开启Secure Boot后,BIOS会使用内置的公钥验证启动文件,如未签名,会导致无法加载。要在Secure Boot启用后仍能访问U盘shell,需对bootx.efi进行签名,并将签名私钥的公钥包含在BIOS设置中。

       在EDK源码中,通过SECURE_BOOT_ENABLE编译选项启用Secure boot功能,并在LibraryClasses中添加相关依赖。开启后,需确保Variable空间足够大以存储证书。

       Secure boot的实现涉及多个关键组件,如PlatformSecureLib、TpmMeasurementLib、股票底部源码AuthVariableLib等,它们通过一系列接口和验证逻辑来确保启动流程的安全。不同的二进制文件策略根据PcdFixedMediaImageVerificationPolicy等配置进行处理。

       最后,为了支持Secure boot,硬件需支持UEFI,操作系统则需提供相应的证书/密钥支持。Linux内核模块签名机制确保模块的安全性,而UEFI系统如Ubuntu和Red Hat会检查内核映像的签名以启用安全启动。

UEFI开发探索 – 图形模式下文字显示

       UEFI中利用HII(Human Interface Infrastructure)进行图形界面的文字显示,是一种处理方式。然而,作者之前在进行开发时,没有深入研究这一方法。在项目中,作者采用的是自定义方法,比如在测试样卡界面的实现中,英文和汉字的显示并非通过HII,而是通过Foxdisk中的显示方法,这方法简单直接,将汉字和英文字符看作一个个字模,使用画点函数进行绘制。

       HII的使用方式可能不那么直观,作者在面临时间紧迫的开发任务时,决定采用Foxdisk中的显示方法,因为这方法可以快速实现所需功能。对于汉字和英文字符的显示,作者使用了8×像素的英文字符,直接拷贝到程序中编译,而对于汉字,作者编写了一个工具程序来提取字模,这个工具程序只能在位dos下运行,通常在位winxp的cmd环境中使用,理论上在win7 位环境也应该可以运行,因为它主要处理文件内容,并未涉及硬件相关代码,使用Borland C++ 3.1编译。

       为了适配不同操作系统和环境,作者近期考虑使用Python重写这些工具软件,以方便在位操作系统下直接运行。尽管作者对这项目持开放态度,但是否会实际进行还未能确定。

       作者使用的工具程序主要包括DistillHZ和DisTillLOGO。DistillHZ可以自动生成UEFI程序所需字符串的字模文件,并转换为UEFI程序可使用的格式,而DisTillLOGO则直接从Foxdisk的工具程序中拿来使用,但Logo的充值返利 源码提取功能还需手动调整大小,并未完全考虑各种情况,如bmp文件的对齐问题等。

       在显示汉字方面,作者采用与Foxdisk中相似的原理和方法,通过DistillHZ提取汉字字模和字符串,然后将字模文件复制到Font.c中,与Font.h中的数据结构和显示函数结合使用,以实现汉字的显示。对于Logo的显示,作者采用从色bmp图中提取像素点,然后逐点显示的简单方法。

       最终,UEFI程序的显示效果良好,通过代码列表可以看到,其中的源代码名称与Foxdisk中的保持一致,汉字显示函数以及各种图形的显示函数与Foxdisk中的实现完全相同,因此,Foxdisk中的某些有趣效果,如渐隐和透明效果等,也可以直接应用于UEFI中。

UEFI开发环境搭建

       UEFI开发环境搭建涉及软件安装、源码编译与UEFI固件运行。首先,需要安装Visual Studio ,并确保选择了合适的开发组件。接着,下载并解压IASL和NASM至根目录,注意修改edk2中的conf/tools_def.txt以适应不同路径。至此,构建EDK2的环境搭建完成。

       接下来,从gitcode.com/tianocore/edk2下载源码,切换至稳定版本进行编译。过程中,可能会遇到edksetup.bat脚本报错问题,这是因为Base Tools未生成。需手动编译Base Tools,注意下载并放置brotli工具源码至BaseTools/Source/C/BrotliCompreaa/brotli目录下。再次执行rebuild操作,通常能解决报错问题。

       对于新版本EDK2,build工具不再使用exe版本,而是Python版本。因此,需设置Python相关变量。完成后,构建UEFI固件(如选择OVMF)二进制,通常结果为成功。

       最后,将OVMF.fd文件复制至QEMU的固件库中。在相应目录下,打开CMD命令行,使用指定命令启动虚拟机,即可进入UEFI模拟环境。至此,UEFI开发环境搭建完成。

UEFI之edk2 目录说明

       UEFI之edk2:探索核心组件与功能目录

AppPkg:开发者的乐园

       UEFI Application Development Kit (AppPkg) 是一套全面的工具集,旨在降低UEFI应用程序开发的门槛。它包含标准依赖库、实用工具和示范项目,助力高效开发。

MdePkg:模块开发的基础

       MdePkg,全称为Module Development Environment Package,是所有模块开发的基石。所有模块都依赖于此,它提供了模块开发所需的最小环境,并确保模块间的兼容性。

MdeModulePkg:标准与环境的载体

       MdeModulePkg不仅包含了符合UEFI/PI工业标准的模块,还提供开发环境,包括PPIs(Protocol Providers Interfaces)、PROTOCOLs(协议)和GUIDs(全局唯一标识符),以及必要的依赖库。

ArmPkg与ArmPlatformPkg:ARM架构的力量

       ArmPkg提供了ARM架构特有的PROTOCOLs,为ARM平台通用代码提供支持。ArmPlatformPkg则针对ARM开发板,集成通用组件,方便不同板型之间的移植。

从BaseTools到实战

       BaseTools包内含一系列编译工具,如AutoGen、Build等,为EDK和EDK2的构建提供必需的辅助。比如,GenSec、GenFV等工具助力安全和固件生成。

BeagleBoardPkg:入门开发者的友好选择

       BeagleBoardPkg针对BeagleBoard,这是一款经济实惠的开发板,搭载了Cortex-A8处理器。包内包含对这款板子的定制化支持代码,便于开发者快速上手。

CorebootModulePkg:连接硬件与UEFI的桥梁

       CorebootModulePkg让Coreboot与UEFI标准融合,开发者可以借此轻松从Coreboot环境过渡到UEFI。它包括解析Coreboot表单、内存/IO资源报告等关键模块,位于硬件和UEFI环境的中间层。

CryptoPkg:加密防护的守护者

       CryptoPkg在UEFI 2.2版本后加入了安全特性,专为加密支持而设计,确保HLOS和平台固件间的通信安全可靠。

DuetPkg:模拟UEFI环境的开发助手

       DuetPkg是一款UEFI模拟器,基于Legacy BIOS,让开发者在BIOS环境中也能体验到UEFI的模拟环境,便于传统系统上的UEFI开发。

EdkCompatibilityPkg:跨代框架的兼容保证

       EdkCompatibilityPkg确保UEFI 2.0+ Framework 0.9x模式下的EDK编译兼容性,简化了不同版本的整合工作。

Shell世界的变化:EdkShellPkg与Shell 2.x

       EdkShellPkg和EdkShellBinPkg曾是Shell开发的主导,但已被Shell 2.x版本的包所取代,后者提供了官方的UEFI Shell实现。

EmbeddedPkg:内存映射控制器的协议实现

       EmbeddedPkg专为内存映射控制器提供协议支持,同时包含一个简单的EFI shell(EBL),简化开发流程。

EmulatorPkg:跨平台虚拟环境的革新

       EmulatorPkg作为虚拟环境的替代,取代了NtPkg和UnixPkg,支持跨平台编译和运行,提高开发的灵活性。

NtPkg与UnixPkg:逐渐式微的虚拟器

       NtPkg和UnixPkg作为UEFI在特定环境下的虚拟器,已被EmulatorPkg全面超越,不再推荐使用。

OvmfPkg:虚拟机的UEFI引导者

       OVMF Package (OvmfPkg) 提供对虚拟机的UEFI支持,配合QEMU和KVM,能引导HLOS在虚拟环境中运行。

NetworkPkg:网络功能的全方位支持

       NetworkPkg包含IPv6协议栈、IPsec驱动、PXE驱动和iSCSI驱动,以及网络配置相关的shell应用程序,为UEFI环境提供全面的网络服务。

Texas Instrument专有:OmapxxPkg

       OmapxxPkg是专为Texas Instrument OMAPxx平台设计的支持包,针对特定硬件的优化集成。

OptionRomPkg:PCI兼容Option ROM的支持

       OptionRomPkg是为了编译和加载PCI兼容Option ROM image而设计的,确保硬件扩展的兼容性。

SecurityPkg:强化安全特性

       SecurityPkg包含TPM(Trusted Platform Module)、用户身份验证、安全启动和认证变量等关键安全功能,为UEFI环境提供强大的防护。

StdLib与私有文件:标准库的基石

       StdLib是标准库的实现,而StdLibPrivateInternalFiles是其内部使用的专有包,仅限于StdLib内部引用。

UefiCpuPkg:CPU模块与库的UEFI兼容性

       UefiCpuPkg确保CPU模块和库与UEFI规范保持一致,为不同处理器架构提供支持。

SourceLevelDebugPkg:调试能力的提升

       SourceLevelDebugPkg提供强大的调试工具,帮助开发者深入到源代码层面进行问题排查和优化。

SignedCapsulePkg:安全升级与恢复的关键

       SignedCapsulePkg提供了一套签名和校验方案,确保固件更新的安全性和可恢复性,支持UEFI环境下的安全升级与恢复。

PcAtChipsetPkg:符合PcAt标准的接口实现

       PcAtChipsetPkg为符合PcAt标准的芯片组提供接口和实现,确保兼容性和稳定性。

FatPkg与FatBinPkg:FAT文件系统的支持

       FatPkg和FatBinPkg为UEFI环境下的FAT文件系统提供支持,方便数据存储和管理。

UEFI开发探索 – Protocol的使用2

       今天探索如何开发UEFI服务中的Protocol。在《UEFI原理与编程》一书中,已有关于UEFI服务开发的介绍,以视频解码为例,提供了完整的解码库。考虑到视频解码的兴趣不高,我将构建一个用于在屏幕上绘制几何图形的简单框架型代码,以熟悉Protocol开发。

       UEFI驱动大致分为两类:符合UEFI驱动模型的驱动和不遵循UEFI驱动模型的驱动。服务型驱动不管理设备,产生协议,初始化操作后即从系统内存中卸载;初始化驱动不产生任何句柄,仅进行初始化并返回错误代码;根桥驱动产生句柄,包含设备路径协议和I/O资源抽象协议;UEFI驱动模型驱动包含多个句柄、协议实例,支持子句柄和额外I/O协议。

       服务型驱动作为开发Protocol的起点,比较简单,主要用于生产协议。实例包括AcpiTableDxe、DebugSupportDxe等。这类驱动在模块初始化时安装所需协议。以HiiResourcesSampleDxe为基础,构建了一个服务型驱动框架,修改了*.inf文件,调整为UEFI_DRIVER类型,并加入UefiDriverEntryPoint。构建好Protocol后,在驱动入口函数中安装。

       构建Protocol需准备三个部分:Protocol GUID(使用微软工具或在线生成)、协议成员函数与结构体、实例化协议。成员函数需EFIAPI修饰,第一个参数为This指针。构造好的Protocol源代码展示了其结构。可以通过This指针传递内部私有数据,实现函数间的共享。

       为了测试,编写了服务驱动提供Protocol与测试程序。服务驱动中提供的Protocol包含三个成员函数,用于演示。通过命令加载服务驱动并测试协议,结果验证了自定义Protocol的正确性。

       具体实现与测试代码在文末提供下载链接。服务驱动中提供的Protocol具有简单的打印功能,用于展示。测试结果显示,安装自制协议后,测试程序能正确调用成员函数。

       Gitee项目地址:gitee.com/luobing/u...,项目代码位于FF RobinPkg下的Applications目录和Drivers目录,包括TestServiceDrvSample和ServiceDrvSample。

UEFI开发探索 – EDK2模拟器搭建网络环境

       搭建EDK2开发环境与网络测试环境的详细步骤如下:

       1. 搭建环境:

       安装必要的开发工具:Visual Studio、Python、ASL和Nasm。

       下载EDK2和StdLib代码库,使用Git将代码下载到本地。

       在C盘新建目录edk,使用特定命令下载代码库。

       更新子模块,确保所有依赖库均可用。

       复制AppPkg、StdLib和StdLibPrivateInternalFiles到edk2目录,方便后续编译。

       使用Visual Studio的Native命令行编译BaseTools及其他工具。

       测试开发环境,通过检查编译结果是否成功。

       2. 搭建网络测试环境:

       安装Winpcap,用于在模拟器中提供访问网络底层的能力。

       下载并编译SnpNtIo,获取SnpNtIo.dll。

       在C盘创建NetNtIo文件夹,将源代码和Winpcap开发包放入其中。

       使用Visual Studio命令行编译SnpNtIo,生成Release_IA目录。

       编译位EDK2模拟器。

       配置模拟器网络环境,将SnpNtIo.dll复制到模拟器目录,并创建批处理文件loadnetwork.nsh加载相关驱动。

       启动模拟器并加载网络配置。

       3. 测试网络程序:

       使用已编译的EchoServerTCP4.exe和EchoTcp4.efi进行网络通信测试。

       运行服务器程序于宿主机,客户端程序于模拟器。

       使用网络调试助手辅助测试。

       注意防火墙设置、DHCP配置及网络通信的局域网限制。

       搭建完毕后,可进行网络程序测试,以验证环境搭建的正确性。遇到的问题包括防火墙影响、DHCP配置的不稳定性、服务端软件通信限制等,可参照实验记录和提供资源进行进一步分析与解决。

UEFI开发探索-如使用最新的EDK2搭建编译环境

       在探索UEFI开发过程中,作者注意到EDK2的发布方式发生了变化,不再提供定期打包的源代码。这影响了作者的开发流程,因为打包的源码通常包含整理好的API文档和预配置的环境。因此,作者决定直接从github的EDK2主线仓库下载并搭建最新的编译环境。

       首先,需要将github上的EDK2、edk2-platforms、edk2-libc等关键项目导入到gitee仓库,并关注一些必要的子模块,如openssl、berkeley-softfloat-3等。确保安装好Visual Studio、Python、ASL和Nasm等编译工具后,通过Git Bash下载并克隆私有仓库中的源代码。

       具体步骤包括:新建工作目录,克隆仓库,修改.edkmodules文件指向gitee仓库地址,然后更新submodules。编译环境搭建完成后,通过edksetup.bat命令编译BaseTools,接着使用mybuild.bat批处理文件保持目录结构清晰并编译UEFI程序。值得注意的是,新版本的EDK2(如年3月)移除了NTPkg,增加了位程序支持的EmulatorPkg,这使得调试位代码变得更加方便。

       通过以上操作,开发者可以了解到如何使用最新的EDK2搭建和维护自己的编译环境,以便进行UEFI开发。