【整理】EFI/UEFI BIOS 入门 : All For Beginners

EFI/UEFI BIOS 入门 : All For Beginners


写在前面

      我们已经使用BIOS超过了二十年.可是直到今天还有许多朋友不知道BIOS到底是什么,以及它主要做些什么事情,它在整个个人计算机之中所处的地位如何.事实上,BIOS是整个计算机系统中最重要的底层系统软件.二十多年来,中国的程序员们纷纷忽略了BIOS,或者由BIOS衍生出的开发技术,相反,我们对如何调整一两个BIOS设置津津乐道.今天,BIOS业界开始悄悄的变革,EFI或者UEFI的到来即将改变世界,从而彻底改变我们对过去的计算机启动过程的认识.但是我们中国的开发者们仍然在谈论JAVA或者.NET,我想,是到了清晰的研究BIOS的时候了.

       小生不才,但也愿意就我所学,贡献成一篇简短的入门文章,带领大家进入BIOS这个有趣而又充满了神秘的地域,我们一起来探究BIOS,尤其是探究下一代个人计算机的基础系统软件,或者说基础固件:UEFI bios的方方面面.由于类似的文章网上也比较多,所以我就重点谈些别人一般忽略的部分吧.

BIOS Definitions

BIOS -- Basic Input and Output System,is used for initializing,testing and putting the PC into the ready state so that an OS may be started.Part of the BIOS remains in the system main memory after POST,or Power On Self Test.BIOS provides a consistent software interface to varying types of the hardware devices.It also provides the basic system level services to OS.The BIOS is also used for helping IHV to fix their hardware design bugs by using the SMM mode of the IA architechture.


    上面这句话是我在初学BIOS的时候,我的老师,一位受到整个业界尊敬的杰出BIOS Engineer对我说的,这段话虽然短,但是却清楚的道出了BIOS的基本功能,那就是:

1) 检测硬件,又叫POST.

2) 初始化硬件,设置其基本状态,使得整个计算机达到所谓的"可用状态"(Ready State).

3) 启动OS Loader加载操作系统.

4) 在操作系统启动起来以后,一部分继续驻留内存,向操作系统以及其他软件提供基本的系统级的服务.如磁盘读写等.

5) 修复硬件缺陷.

      下面我们一个一个的来看这些功能.第一个检测硬件可能比较好理解一点,就是看看你的硬件是否还正常的工作,但是从软件的角度看.其中最重要的就是对内存的检测的.大家都还对刚开机的时候内存的大小一直在跳的屏幕有记忆吧,那就是在做Memory Test,或者说Memory Sizing.

       第二个功能是初始化硬件,可能有不少朋友问:为什么我的硬件还需要初始化?问的好,硬件的设计厂家往往为了通用市场的考虑,不愿意将硬件设计成定制的状态,可能一个网卡,可以安装在PC,同样也可以安装在嵌入式系统上.所以为了使得硬件能够按照PC的架构工作,BIOS必须要按照由 IHV(Indenpendent Hardware Vendor)提供的手册将硬件设置好,比如写几个必须的寄存器之类的,做一些enable的工作.这点非常重要,如果一个硬件没有enable,那么在 OS下将不可见.

      第三个功能是启动操作系统,这也是BIOS必须要做的事情之一.启动的方式是由BIOS规定,操作系统必须按照BIOS的要求来设计.这也是为什么操作系统从DOS一直到Vista,都只能把自己的loader放在MBR,因为BIOS只读MBR.强大的微软都必须要按照这个不成标准的标准来:)当然,在 EFI时代,这一点有所改变,EFI支持的Boot From File不在需要MBR.

       第四个功能可能之前作过DOS开发的朋友比较熟悉吧,还记得INT 10基本屏幕服务,INT 13磁盘服务吗?多少病毒正是靠INT 13来传播.又有朋友曾经试图绕过INT 10来直接写屏?Windows时代,这些东西事实上仍然存在,并且继续发挥着基本的核心作用,只是他们被Windows包装起来了,一般的程序无法接触到,但这并不能说明他们就没有用处了.MS的开发人员不久前还表示,事实上甚至就是开发中的Longhorn的安装程序,目前仍然有许多code是基于 INT 10来写屏的.

       第五个功能估计一般的朋友可能就不知道了,就是之前稍微接触过BIOS的朋友们可能也是第一次听说吧!Intel在它的CPU里专门留了个模式叫 System Managment Mode,拥有最高的权限.SMM中断的时候,就连号称无所不能的Windows的也不知道,这样就可以给CPU扑bug了,举个例子,比如某天 Intel的一个CPU对ADD指令给出错误操作结果,那么就可以利用SMM在每次执行这个指令的时候,中断一下,由BIOS软件给出正确的执行结果.这就达到了给硬件修复缺陷的目的.这样Intel也不用招回它的CPU了,呵呵.此外,每次BIOS开机的时候,事实上都会更新CPU Microcode,同样是用来给CPU补bug的.所以很多时候,刷BIOS刷出问题,事实上某个CPU的bug没有补上导致出了问题出现.
 

BIOS在哪里

   上面罗嗦了一大堆的BIOS Basics,那么BIOS到底在哪里呢?答案是在你的计算机里:)的确有些无聊,事实上BIOS有三种状态,分别是:

1) Before Build

2) BIOS Image

3) BIOS Runtime


       第一种呢,这个时候BIOS表现为BIOS开发者硬盘上的一堆源代码. 处于第二种的时候,BIOS则是沉睡在Flash里的一段image.BIOS真正发挥作用是在第三种模式下,哪个时候BIOS执行,控制系统,与操作系统交互.

EFI BIOS

       EFI是由Intel提出的,目的在于为下一代的BIOS开发树立全新的框架。EFI是英文Extensible Firmware Interfaces的缩写。正如它的名字一样,EFI不是一个具体的软件,而是在操作系统与平台固件(platform firmware)之间的一套完整的接口规范。EFI定义了许多重要的数据结构以及系统服务,如果完全实现了这些数据结构与系统服务,也就相当于实现了一个真正的BIOS核心。

       EFI最早是在Spring 2000 IDF(Intel Developer’s Forum)上提出的,当时Intel认为,随着IBM在80年代初推出了第一台个人计算机开始,直到今天为止,个人计算机硬件平台已经发生了翻天覆地的变化,相关的系统软件如操作系统等也从最早的MS DOS1.0到今天的Windows XP,而作为整个系统的最底层也最为关键的系统软件之一的BIOS却基本上保持了架构二十年不变。这在整个软件史上都是一件不可思议的事情。如今,BIOS已经变成了严重阻碍IT产业前进的绊脚石,必须通过对BIOS的革新来为下一代的操作系统(如Windows Server Longhorn)提供更加强大的支持。

       上面是我很早之前写的一段对EFI的介绍,现在看来,难免有些错误,不过大致意思非常明确,EFI就是用来替换传统BIOS.作为更好的BIOS,EFI可以提供过去无法在BIOS中作到的许多事情.后面的文章我会逐步展现给大家.

下面是一些深入学习bios的资源汇总:

1. BIOS Boot Specification
业内一般叫BBS,详细描述bios启动时必须要做的所有事情,如何区分启动设备,如何选择启动设备等等.
http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdf

2. UEFI Specification
UEFI规范,详细描述了UEFI bios必须支持的接口.以及UEFI bios的模型,提供的服务等等. 开发UEFI必备的.
http://www.uefi.org

3. Ralf Brown's Interrupt List

这个人似乎就一辈子都都在收集中断的东西,对legacy bios学习很有用.
http://www.ctyme.com/rbrown.htm

4. El Torito CD-ROM Boot

描述了bios如何从光驱上boot的细节.
http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdf

5. USB Specification
USB设备规范
http://www.usb.org

6. Plug-and-Play Specifications
MS的PnP规范
http://www.microsoft.com/hwdev/tech/pnp/default.asp

7. BIOS Writer's Guide
bios开发的圣经,由cpu厂商给出.Intel的绝对看不到,Intel的是绝密级的文档.AMD的倒是可以看到,不同的cpu有不同的BWG.这里给出一个amd比较新的cpu的BWG:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf

还有很多很多相关的文档.其实编写bios最难的在于同时支持业界几乎所有的通用规范.

一些常见的关于BIOS/EFI的问题以及我的简短回答:

1) BIOS一般有多大?

      传统bios(以后说legacy bios)一般都是512KB,而早期的EFI bios也是512KB.现在EFI基本上是1MB了.

2) BIOS用什么工具开发?

       legacy bios一般用MASM 6.11开发,同时还会配上一些厂商自己写的buid tools. EFI则使用Viusal Studio.NET 2003以及MASM 6.11开发(没想到吧~)

3) EFI boot是怎么一回事?

       EFI有自己独特的boot方式,完全抛弃掉了传统的0磁道0扇区的MBR概念.EFI的boot方式与文件系统息息相关.过去的legacy bios由于不带文件系统,不得已选择从硬盘上特定空间装载程序的办法,而EFI则附带了完整的文件系统支持,所以不再对硬盘有特定的要求,EFI下的操作系统加载程序事实上存储在boot\ia32\bootia32.efi文件里.(假定是IA32架构).这是一个EFI应用程序.

4)EFI如何支持传统操作系统如Windows XP?

      EFI通过一个叫CSM的东西来支持.CSM是Compatibility Support Module,包括CSM32和CSM16,是EFI里面定义的一种用来对传统技术,如MBR,legacy PCI OpRom等支持的模块.包含32位代码和16位的代码,通过一种叫Thunk和Reverse Thunk的技术来切换CPU执行模式.目前世界上有能力提供CSM的公司只有三家,分别是:Insyde,AMI以及我国南京的百敖软件(Nanjing Byosoft)。CSM是efi bios最核心的模块之一。

5)原生支持EFI的操作系统出现了吗?

      当然,Linux内核再2.4.0以上,就可以再编译的内核的时候选择EFI支持。Windows Vista也再SP1的时候提供了对EFI的支持,同时Windows Server 2008将直接支持EFI。

6)支持EFI的主板上市了吗?

       很早就有了,只是你不知道而已。保守估计,全世界使用EFI的主板,出货量已经超过了五千万片。只不过绝大多数的EFI enabled的主板,都没有把EFI接口做出来。这些EFI主板仍然将自己“伪装”成传统主板。如Intel 945GC等。

7) 有能力提供EFI bios的厂家都有哪些?

由于Intel并支持提供bios,所以我们只能通过IBV来获得efi bios,目前得到Intel官方授权的bios供应商(以后说IBV)列表如下:

1. Phoenix -- 早先主推CSS,现在开始逐渐转行EFI。不过它的动作最慢,已经不为业界看好。
2. Insyde -- 主推H2O。最早的EFI解决方案,也同时卖legacy bios,但是质量一般。
3. AMI -- EFI的方案叫Aption,特色是自己的开发工具VEB。
4. Byosoft -- 刚成立一年半的一家IBV,拿到了Intel的授权。目前如长城等OEM的一些特殊机器上的bios开始由Byosoft提供。也是俺的东家 :)
5. General Software -- 专做x86 embedded bios的公司。国内很少见。

以上是世界上可提供EFI bios的六家厂家,有一家Byosoft在国内。

8)我过去是做汇编的legacy bios的,现在想转行做EFI.该从何下手?

       首先你再legacy bios里获得关于计算机架构以及硬件方面的知识完全可以100%继续在EFI中发挥重要的作用.你需要强化自己的C语言能力,以及对大型软件项目构建的知识.整个迁移过程将费时半年左右.但考虑到EFI的未来的必然的普及,迁移是值得的.也是必须的.不要将EFI看的过于神秘,它只不过用规范的形式把过去legacy bios做的所有事情重新做一边.同时做了些新东西.

9)用什么工具制作的GPT分区有不同吗?有没有一个各种系统通用的标准?Apple的GPT分区在Windows上显示不正常。

      GPT分区在UEFI spec的第五章<GUID Partition Table(GPT) Format>里详细定义好的,所以用什么工具制作,应该问题不大,不过我们都是在EFI Shell下,用Diskpart制作.在Windows下也有一样的工具.打开一个console box,运行diskpart.exe.

10)我的主板不是EFI BIOS,所以我想将Windows Vista SP1/Windows Server 2008安装到GPT分区应该是不行。能否通过刷BIOS的方法使那些非EFI BIOS主板变成EFI BIOS主板?OpenFirmware/OpenBIOS/TianoCore这些东西有没有帮助?

      当然可以.但前提是你要有适合你主板的EFI BIOS,但我不认为你能找到 :) 你上面说的只有Tiano有帮助,事实上TianoCore维护的项目EDK正是所有EFI BIOS的核心代码.但是Tiano社区只维护其核心代码,BIOS厂商会在Tiano代码的基础之上引入大量的与实际平台相关的东西.或者说,Tiano只做与硬件无关的通用核心结构.真正的硬件代码由BIOS厂商完成.至于其他两个,与EFI社群完全没有关系.

11)EFI技术我觉得目前还不大成熟,技术(标准)不成熟应该是一方面吧,另外跟Intel的策略肯定有很大关系。EFI的目标是达到什么?Intel推广EFI的目的又是什么?业界目前看法如何?

        EFI都用了快六年了!!怎么会不成熟呢?EFI推广的最大阻力正是像ASUS这样的台湾厂商以及像Phoenix这样"不听话"公司.技术与标准都相当的成熟,ASUS等台湾公司拒绝EFI,完全是处于成本的考虑.EFI达到的目标就是统一固件标准,为今后的发展奠定方向.要知道,标准统一了才能有发展.Intel的目的其实很简单,用一句Intel公司内部某高层人士的话说"Intel做的每一件事都是为了多卖出一块CPU!"想想下面的推理:

EFI是Intel发明-->EFI必然首先在Intel平台实现-->业界普遍采用EFI-->主板厂商迁移到EFI-->每一片主板都对应一颗CPU-->那么每一片EFI主板必然对应一颗Intel CPU!

牢记,主板厂商每销售一片Intel芯片组的主板,就意味着拉动Intel销售一个CPU!!!Intel通过EFI可以彻底控制整个PC业界.

12)这个EFI策略是不是和OLPC或UMPC之类的策略/产品有关?以后的主板是否都会内置操作系统?这对PC操作系统,特别是Windows会有怎样的影响?

       别的不敢说,至少新出来的MID,就全是EFI bios,而且Intel从Santa Rosa开始,根本不提供legacy bios的支持,迫使业界只能转EFI.对于Windows没有明显的影响,EFI对Windows的兼容性是业界必须首先要解决的问题,目前看来解决的相当不错.但是ACPI仍然有很大的问题,EFI上的Windows Server 2008/Vista从S3状态恢复几乎100%失败.

13)EFI生成的映像能不能反汇编?

EFI Image当然可以反汇编,事实上他们就是把DLL文件改了后缀名罢了.所有能反汇编DLL文件的工具都可以反汇编EFI文件.

或者使用BIOS厂家提供的专用调试工具,也都可以反汇编的.至少我们公司的调试工具就可以反汇编,具体请咨询你的BIOS厂商的技术支持吧.

 

This Unified Extensible Firmware Interface (hereafter known as UEFI) Specification describes an interface between the operating system (OS) and the platform firmware. UEFI was preceded by the Extensible Firmware Interface Specification 1.10 (EFI). As a result, some code and certain protocol names retain the EFI designation. Unless otherwise noted, EFI designations in this specification may be assumed to be part of UEFI. The interface is in the form of data tables that contain platform-related information, and boot and runtime service calls that are available to the OS loader and the OS. Together, these provide a standard environment for booting an OS. This specification is designed as a pure interface specification. As such, the specification defines the set of interfaces and structures that platform firmware must implement. Similarly, the specification defines the set of interfaces and structures that the OS may use in booting. How either the firmware developer chooses to implement the required elements or the OS developer chooses to make use of those interfaces and structures is an implementation decision left for the developer. The intent of this specification is to define a way for the OS and platform firmware to communicate only information necessary to support the OS boot process. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the OS by the platform and firmware. Using this formal definition, a shrink-wrap OS intended to run on platforms compatible with supported processor specifications will be able to boot on a variety of system designs without further platform or OS customization. The definition will also allow for platform innovation to introduce new features and functionality that enhance platform capability without requiring new code to be written in the OS boot sequence. Furthermore, an abstract specification opens a route to replace legacy devices and firmware code over time. New device types and associated code can provide equivalent functionality through the same defined abstract interface, again without impact on the OS boot support code. The specification is applicable to a full range of hardware platforms from mobile systems to servers. The specification provides a core set of services along with a selection of protocol interfaces. The selection of protocol interfaces can evolve over time to be optimized for various platform market segments. At the same time, the specification allows maximum extensibility and customization abilities for OEMs to allow differentiation. In this, the purpose of UEFI is to define an evolutionary path from the traditional “PC-AT”- style boot world into a legacy-API free environment.
This Unified Extensible Firmware Interface (UEFI) Specification describes an interface between the operating system (OS) and the platform firmware. UEFI was preceded by the Extensible Firmware Interface Specification 1.10 (EFI). As a result, some code and certain protocol names retain the EFI designation. Unless otherwise noted, EFI designations in this specification may be assumed to be part of UEFI. The interface is in the form of data tables that contain platform-related information, and boot and runtime service calls that are available to the OS loader and the OS. Together, these provide a standard environment for booting an OS. This specification is designed as a pure interface specification. As such, the specification defines the set of interfaces and structures that platform firmware must implement. Similarly, the specification defines the set of interfaces and structures that the OS may use in booting. How either the firmware developer chooses to implement the required elements or the OS developer chooses to make use of those interfaces and structures is an implementation decision left for the developer. The intent of this specification is to define a way for the OS and platform firmware to communicate only information necessary to support the OS boot process. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the OS by the platform and firmware. Using this formal definition, a shrink-wrap OS intended to run on platforms compatible with supported processor specifications will be able to boot on a variety of system designs without further platform or OS customization. The definition will also allow for platform innovation to introduce new features and functionality that enhance platform capability without requiring new code to be written in the OS boot sequence. Furthermore, an abstract specification opens a route to replace legacy devices and firmware code over time. New device types and associated code can provide equivalent functionality through the same defined abstract interface, again without impact on the OS boot support code. The specification is applicable to a full range of hardware platforms from mobile systems to servers. The specification provides a core set of services along with a selection of protocol interfaces. The selection of protocol interfaces can evolve over time to be optimized for various platform market segments. At the same time, the specification allows maximum extensibility and customization abilities for OEMs to allow differentiation. In this, the purpose of UEFI is to define an evolutionary path from the traditional “PC-AT”- style boot world into a legacy-API free environment.
随着国家十四五新战略规划的推出,众多国内企业都参与到国产芯片替代浪潮中来,可以预测未来越多的国产芯片会被设计、生产和使用在我们日常所使用的电子产品中,国产芯片拥有巨大的市场前景。 目前国产芯片采用的体系架构主要有X86、ARM、MIPS、RISC V、PowerPC、Alpha等。我们知道电子产品正常工作必须要有操作系统和各种应用软件,没有操作系统和应用软件的芯片就是一堆废铁,而大多数人并不知道的是没有系统固件来加载操作系统的电脑亦是一堆废铁, UEFI就是由UEFI行业协会提出和维护一种行业标准的系统固件,它支持目前市面上的大多数芯片体系结构和操作系统,随着标准的不断演进相信越来越多的体系结构的芯片和操作系统会被支持。 笔者从事BIOS开发已有十余年的时间,见证了Legacy BIOS辉煌与隐退,也有幸了参与了新世纪初系统固件从Legacy BIOSUEFI BIOS的迁移的全过程。科技行业风起云涌新技术新架构日新月异,每每回望不禁感慨我辈可谓是“眼见着他起高楼,眼见着他宴宾客”的那一波BIOS人。曾经系统固件江湖还是Legacy BIOS的天下,BIOS人使用汇编语言编码、通过中断来与操作系统沟通。自UEFI框架被广泛使以来开我们的发环境从纯汇编变成了99%的C语言加1%的汇编语言的模式,开发效率大大的加强了。 虽然UEFI框架大大加快了开发效率,但是由于系统固件开发属于比较偏门和专业的领域,学习和入门门槛比较高,现有的BIOS工程师又分布在大大小小的各个公司内部缺乏有效沟通和交流,同时BIOS源码又属于敏感和机密数据受到各种NDA限制,市面上对UEFI框架介绍的资料少之又少,因此笔者从2000左右开始就陆续以Cstyle_0x007为ID在https://blog.csdn.net/CStyle_0x007发布一系列博文,现已有数十篇原创文章。刚开始的想法是把博文当作工作笔记方便自己随时查阅,后来慢慢发展成了与业内外感兴趣的朋友的沟通交流的平台。 随手写的博文难免有错误与纰漏为了避免误导大众,准备把博文重新整理在纠正谬误同时也会补充一些新的内容,尽量做到所写的每句话都是无误的,也欢迎有兴趣的朋友踊跃提出意见和建议。组建了微信公众号,目的在于方便有兴趣的朋友一起交流,名字初步定为“固件C字营”,其中“固件”泛指一切固化的软件,这里主要指UEFI BIOS系统固件,“C”泛指“China“,我们可以把这里当作大家沟通交流的营地,我们会不定时发布一些行业资讯、工作、学习心得,感兴趣扫描下面二维码就可以加入,也可以发邮件到CstyleFirmWareCamp@outlook.com投稿分享你的想法。 本文取名《UEFI内核的导读》这里的UEFI专指“UEFI BIOS”,全文专注于对UEFI内核的梳理与分享,同时兼顾对X86系统固件生态中常用的工程技术的介绍,主要包含以下内容:UEFI启动流程以及各个阶段主要完成的任务及参考的实现方式导读UEFI及PI规范中的常见Protocol的实现与使用技巧UEFI固件生态中常见外设、总线、行业标准的协议内容及使用方法 雄关漫道真如铁,而今迈步从头越,系统固件雄起之路道阻且长,相信我们的BIOS人一定可以为国产芯片的起飞助力、为系统固件团队的壮大贡献自己的一份微薄之力,为每一个不畏艰难、不惧寂寞坚守在工作岗位的BIOS人加油,好样的。
In file included from /home/chen-docker/bin/boot/boot_images/edk2/MdePkg/Include/Uefi.h:18: In file included from /home/chen-docker/bin/boot/boot_images/edk2/MdePkg/Include/Uefi/UefiSpec.h:2222: /home/chen-docker/bin/boot/boot_images/edk2/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h +1755:12: error: field Guid within 'EFI_HII_KEYBOARD_LAYOUT' is less aligned than 'EFI_GUID' (aka 'GUID') and is usually due to 'EFI_HII_KEYBOARD_LAYOUT' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] EFI_GUID Guid; ^ 1 error generated. In file included from /home/chen-docker/bin/boot/boot_images/edk2/MdeModulePkg/Library/UefiHiiLib/HiiLib.c:1: In file included from <built-in>:1: In file included from /home/chen-docker/bin/boot/boot_images/Build/LeMansAU/Core/RELEASE_CLANG140LINUX/AARCH64/MdeModulePkg/Library/UefiHiiLib/UefiHiiLib/DEBUG/AutoGen.h:16: In file included from /home/chen-docker/bin/boot/boot_images/edk2/MdePkg/Include/Uefi.h:18: In file included from /home/chen-docker/bin/boot/boot_images/edk2/MdePkg/Include/Uefi/UefiSpec.h:2222: /home/chen-docker/bin/boot/boot_images/edk2/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h +1755:12: error: field Guid within 'EFI_HII_KEYBOARD_LAYOUT' is less aligned than 'EFI_GUID' (aka 'GUID') and is usually due to 'EFI_HII_KEYBOARD_LAYOUT' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] EFI_GUID Guid; ^ GNUmakefile:366: recipe for target '/home/chen-docker/bin/boot/boot_images/Build/LeMansAU/Core/RELEASE_CLANG140LINUX/AARCH64/MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib/OUTPUT/UefiHiiServicesLib.obj' failed make: *** [/home/chen-docker/bin/boot/boot_images/Build/LeMansAU/Core/RELEASE_CLANG140LINUX/AARCH64/MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib/OUTPUT/UefiHiiServicesLib.obj] Error 1 什么错误?
07-20
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值