温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

比较EFI和BIOS

发布时间:2020-06-21 09:32:15 来源:网络 阅读:417 作者:维度2018 栏目:移动开发


       文章太长,有很多人会看不进去。在这个浮躁的社会里,能够把一本书逐字阅读已经变成了一种奢侈,尤其是现在大行其道的速读阅读法,讲究快即是美。而技术来不得半点取巧,需要一点点的读,一点点的思考和吸收,浮躁了,你就变成啥也懂,啥也不精的伪专家。
      
     一个显著的区别就是EFI是用模块化,C语言风格的参数堆栈传递方式,动态链接的形式构建的系统,较BIOS而言更易于实现,容错和纠错特性更强,缩短了系统研发的时间。
      
      它运行于32位或64位模式,乃至未来增强的处理器模式下,突破传统16位代码的寻址能力,达到处理器的最大寻址。它利用加载EFI驱动的形式,识别及操作硬件,不同于BIOS利用挂载实模式中断的方式增加硬件功能。后者必须将一段类似于驱动的16位代码,放置在固定的0x000C0000至
0x000DFFFF之间存储区中,运行这段代码的初始化部分,它将挂载实模式下约定的中断向量向其他程序提供服务。例如,VGA图形及文本输出中断(INT 10h),磁盘存取中断服务(INT 13h)等等。


       由于这段存储空间有限(128KB),BIOS对于所需放置的驱动代码大小超过空间大小的情况无能为力。另外,BIOS的硬件服务程序都已16位代码的形式存在,这就给运行于增强模式的操作系统访问其服务造成了困难。因此BIOS提供的服务在现实中只能提供给操作系统引导程序或MS-DOS类操作系统使用。而EFI系统下的驱动并不是由可以直接运行在CPU上的代码组成的,而是用EFI Byte Code编写而成的。这是一组专用于EFI驱动的虚拟机器指令,必须在EFI驱动运行环境(Driver Execution Environment,或DXE)下被解释运行。

        这就保证了充分的向下兼容性,打个比方说,一个带有EFI驱动的扩展设备,既可以将其安装在安腾处理器的系统中,也可以安装于支持EFI的新PC系统中,而它的EFI驱动不需要重新编写。这样就无需对系统升级带来的兼容性因素作任何考虑。另外,由于EFI驱动开发简单,所有的PC部件提供商都可以参与,情形非常类似于现代操作系统的开发模式,这个开发模式曾使Windows在短短的两三年时间内成为功能强大,性能优越的操作系统。


        基于EFI的驱动模型可以使EFI系统接触到所有的硬件功能,在操作操作系统运行以前浏览万维网站不再是天方夜谭,甚至实现起来也非常简单。这对基于传统BIOS的系统来说是件不可能的任务,在BIOS中添加几个简单的USB设备支持都曾使很多BIOS设计师痛苦万分,更何况除了添加对无数网络硬件的支持外,还得凭空构建一个16位模式下的TCP/IP协议栈。

      一些人认为BIOS只不过是由于兼容性问题遗留下来的无足轻重的部分,不值得为它花费太大的升级努力。而反对者认为,当BIOS的出现制约了PC技术的发展时,必须有人对它作必要的改变。 

EFI和操作系统 

           EFI在概念上非常类似于一个低阶的操作系统,并且具有操控所有硬件资源的能力。不少人感觉它的不断发展将有可能代替现代的操作系统。事实上,EFI的缔造者们在第一版规范出台时就将EFI的能力限制于不足以威胁操作系统的统治地位。

       首先,它只是硬件和预启动软件间的接口规范;其次,EFI环境下不提供中断的访问机制,也就是说每个EFI驱动程序必须用轮询的方式来检查硬件状态,并且需要以解释的方式运行,较操作系统下的驱动效率更低;再则,EFI系统不提供复杂的存储器保护功能,它只具备简单的存储器管理机制,具体来说就是指运行在x86处理器的段保护模式下,以最大寻址能力为限把存储器分为一个平坦的段,所有的程序都有权限存取任何一段位置,并不提供真实的保护服务。

        当EFI所有组件加载完毕时,系统可以开启一个类似于操作系统Shell的命令解释环境,在这里,用户可以调入执行任何EFI应用程序,这些程序可以是硬件检测及除错软件,引导管理,设置软件,操作系统引导软件等等。理论上来说,对于EFI应用程序的功能并没有任何限制,任何人都可以编写这类软件,并且效果较以前MS-DOS下的软件更华丽,功能更强大。
    
一旦引导软件将控制权交给操作系统,所有用于引导的服务代码将全部停止工作,部分运行时代服务程序还可以继续工作,以便于操作系统一时无法找到特定设备的驱动程序时,该设备还可以继续被使用。 


EFI的组成 
一般认为,EFI由以下几个部分组成: 
1. Pre-EFI初始化模块
2. EFI驱动执行环境
3. EFI驱动程序
4. 兼容性支持模块(CSM)
5. EFI高层应用
6. GUID 磁盘分区 
在实现中,EFI初始化模块和驱动执行环境通常被集成在一个只读存储器中。
   
    Pre-EFI初始化程序在系统开机的时候最先得到执行,它负责最初的CPU,主桥及存储器的初始化工作,紧接着载入EFI驱动执行环境(DXE)。当DXE被载入运行时,系统便具有了枚举并加载其他EFI驱动的能力。在基于PCI架构的系统中,各PCI桥及PCI适配器的EFI驱动会被相继加载及初始化;这时,系统进而枚举并加载各桥接器及适配器后面的各种总线及设备驱动程序,周而复始,直到最后一个设备的驱动程序被成功加载。

        正因如此,EFI驱动程序可以放置于系统的任何位置,只要能保证它可以按顺序被正确枚举。例如一个具PCI总线接口的ATAPI大容量存储适配器,其EFI驱动程序一般会放置在这个设备的符合PCI规范的扩展只读存储器(PCI Expansion ROM)中,当PCI总线驱动被加载完毕,并开始枚举其子设备时,这个存储适配器旋即被正确识别并加载它的驱动程序。
     
     部分EFI驱动程序还可以放置在某个磁盘的EFI专用分区中,只要这些驱动不是用于加载这个磁盘的驱动的必要部件。在EFI规范中,一种突破传统MBR磁盘分区结构限制的GUID磁盘分区系统(GPT)被引入,新结构中,磁盘的分区数不再受限制(在MBR结构下,只能存在4个主分区),并且分区类型将由GUID来表示。在众多的分区类型中,EFI系统分区可以被EFI系统存取,用于存放部分驱动和应用程序。
    
      很多人担心这将会导致新的安全性因素,因为EFI系统比传统的BIOS更易于受到计算机病毒的***,当一部分EFI驱动程序被破坏时,系统有可能面临无法引导的情况。实际上,系统引导所依赖的EFI驱动部分通常都不会存放在EFI的GUID分区中,即使分区中的驱动程序遭到破坏,也可以用简单的方法得到恢复,这与操作系统下的驱动程序的存储习惯是一致的。

       CSM是在x86平台EFI系统中的一个特殊的模块,它将为不具备EFI引导能力的操作系统提供类似于传统BIOS的系统服务。


向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI