当前位置:首页 > > IOT物联网小镇
[导读]作 者:道哥,10年的嵌入式开发老兵。公众号:【IOT物联网小镇】,专注于:C/C、Linux操作系统、应用程序设计、物联网、单片机和嵌入式开发等领域。 公众号回复【书籍】,获取Linux、嵌入式领域经典书籍。转 载:欢迎转载文章,转载需注明出处。目录bootloader跳转到操...

作  者:道哥,10 年的嵌入式开发老兵。


公众号:【IOT物联网小镇】,专注于:C/C 、Linux操作系统应用程序设计、物联网、单片机和嵌入式开发等领域。 公众号回复【书籍】,获取 Linux、嵌入式领域经典书籍。


转  载:欢迎转载文章,转载需注明出处。


目录


  • bootloader 跳转到操作系统


  • 操作系统跳转到应用程序


  • 应用程序调用操作系统中的函数


不论是在x86平台上,还是在嵌入式平台上,系统的启动一般都经历了 bootloader操作系统,再到应用程序,这样的三级跳过程。


每一个相互交接的过程,都是我们学习的重点。


这篇文章,我们仍然以x86平台为例,一起来看一下:从上电之后,系统是如何一步一步的进入应用程序的入口地址


bootloader 跳转到操作系统

在上一篇文章中,讨论了bootloader在进入保护模式之后,在地址0x0001_0000处创建了全局描述符表(GDT),表中创建了3个段描述符:


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序只要在GDT中创建了这3个描述符,然后把GDT的地址(eg: 0x0001_0000)设置到GDTR寄存器中,此时就可以进入保护模式工作了(设置CR0寄存器的bit0为1)。


之前的第6篇文章中Linux从头学06:16张结构图,彻底理解【代码重定位】的底层原理,我们是假设bootloader把操作系统程序读取到内存0x0002_0000的位置,这里继续使用这个示例:


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序关于文件头header的内容,与实模式下是不同的。


在实模式下,header的布局如下图:


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序bootloader在把操作系统,从硬盘加载到内存中之后,从header中取得3个段的汇编地址(即:段的开始地址相对于文件开始的偏移量),然后计算得到段的基地址,最后把段基地址写回到header的这3个段地址空间中。


这样的话,操作系统开始执行时,就可以从header中准确的获取到每一个段的基地址了,然后就可以设置相应的段寄存器,进入正确的执行上下文了。


那么在保护模式下呢,操作系统需要的就不是段的基地址了,而是要获取到每一个段的描述符才行。


很显然,需要借助bootloader才可以完成这个目标,也就是:


  1. 在 GDT 中为操作系统程序中的三个段,建立相应的描述符;


  2. 把每一个段的描述符索引号,写回到操作系统程序的 header 中;


注意:


这里描述的仅仅是一个可能的过程,主要用来理解原理。


有些系统可以用不同的实现方式,例如:在进入操作系统之后,在另外一个位置存放GDT,并重新创建其中的段描述符。


操作系统的 header 布局

既然header需要作为媒介,来接收bootloader往其中写入段索引号,所以bootloader与OS就要协商好,写在什么位置?


可以按照之前的方式,直接覆写在每个段的汇编地址位置,也可以写在其他的位置,例如:


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序其中,最后的3个位置可以用来接收操作系统的三个段索引号。


建立操作系统的三个段描述符

bootloader把OS加载到内存中之后,会解析OS的header中数据,得到每个段的基地址以及界限


虽然header中没有明确的记录每个段的界限,可以根据下一个段的开始地址,来计算得到上一个段的长度。


我们可以联想一下:


现代Linux系统中ELF文件的格式,在文件头部中记录了每一个段的长度,具体解析请参考这篇文章:Linux系统中编译、链接的基石-ELF文件:扒开它的层层外衣,从字节码的粒度来探索。


此时,bootloader就可以利用这几个信息:段基地址、界限、类型以及其他属性,来构造出相应的段描述符了(下图橙色部分):


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序
PS:这里的示例只为操作系统创建了 3 个段描述符,实际情况也许有更多的段。


OS段描述符建立之后,bootloader再把这3个段描述符在GDT中的索引号,填写到OS的header中相应的位置:


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序上图中,“入口地址”下面的那个4,本质上是不需要的,加上更有好处,好处如下:


当从bootloader跳入到操作系统的入口地址时,需要告诉处理器两件事情:


  1. 代码段的索引号;


  2. 代码的入口地址;


因此,把入口地址和索引号放在一起,有助于bootloader直接使用跳转语句,进入到OS的start标记处开始执行。


操作系统跳转到应用程序

从现代操作系统来看,这个标题是有错误的:


操作系统是应用程序的下层支撑,相当于是应用程序的runtime,怎么能叫做跳转到应用程序呢?


其实我想表达的意思是:操作系统是如何加载、执行一个应用程序的。


既然是保护模式,那么操作系统就承担起重要的职责:保护系统不会受到每一个应用程序的恶意破坏!


因此,操作系统:把应用程序从硬盘上复制到内存中之后,跳入应用程序的第一条指令之前,需要为应用程序分配好内存资源:


  1. 代码段的基地址、界限、类型和权限等信息;


  2. 数据段的基地址、界限、类型和权限等信息;


  3. 栈段的基地址、界限、类型和权限等信息;


以上这些信息,都以段描述符的形式,创建在GDT中。


PS: 在现代操作系统中,应用程序都会有一个自己私有的局部描述符表 LDT,专门存储应用程序自己的段描述符。


还记得之前讨论过的下面这张图吗?


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序段寄存器的bit2位TI标志,就说明了需要到GDT中查找段描述符?还是到LDT中去查找?


为了方便起见,我们就把所有的段描述符都放在GDT中。


就犹如bootloader为OS创建段描述符一样,OS也以同样的步骤为应用程序来创建每一个段描述符。


此时的GDT就是下面这样:


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序从这张图中已经可以看出一个问题了:


如果所有应用程序的段描述符都放在全局的GDT中,当应用程序结束之后,还得去更新GDT,势必给操作系统的代码带来很多麻烦。


因此,更合理的方式应该是放在应用程序私有的LDT中,这个问题,以后还会进一步讨论到。


不管怎样,OS 启动应用程序的整体流程如下:


  1. 操作系统把应用程序读取到内存中的某个空闲位置;


  2. 操作系统分析应用程序 header 部分的信息;


  3. 操作系统为应用程序创建每一个段描述符,并且把索引号写回到 header 中;


  4. 跳转到应用程序的入口地址,应用程序从 header 中获取到每个段索引号,设置好自己的执行上下文(即:设置好各种寄存器);


应用程序调用操作系统中的函数

这里的函数可以理解成系统调用,也就是操作系统为所有的应用程序提供的公共函数。


在Linux系统中,系统调用是通过中断来实现的,在中断处理器程序中,再通过一个寄存器来标识:当前应用程序想调用哪一个系统函数,也就是说:每一个系统函数都有一个固定的数字编号


再回到我们当前讨论的x86处理器中,操作系统提供系统函数的最简单的方法就是:


把所有的系统函数都放在一个单独的代码段中,把这个段的索引号以及每一个系统函数的偏移地址告诉应用程序。


这样的话,应用程序就可以通过这2个信息调用到系统函数了。


假如:有2个系统函数os_func1和os_func2,放在一个独立的段中:


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序既然OS中多了一个代码段,那么bootloader就需要帮助它在GDT中多创建一个段描述符:


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序在应用程序的header中,预留一个足够大的空间来存放每一个系统函数的跳转信息(系统函数的段索引号和函数的偏移地址):


Linux从头学10:三级跳过程详解-从 bootloader 到 操作系统,再到应用程序应用程序有了这个信息之后,当需要调用os_func1时,就直接跳转到相应的 段索引号:函数偏移地址,就可以调用到这个系统函数了。


这里同样的会引出2个问题:


  1. 如果操作系统提供的系统函数很多,应用程序也很多,那么操作系统在加载每一个应用程序时,岂不是要忙死了?而且应用程序也不知道应该保留多大的空间来存放这些系统函数的跳转信息;


  2. 在执行系统函数时,此时代码段、数据段都是属于操作系统的势力范围,但是栈基址和栈顶指针使用的仍然是应用程序拥有的栈,这样合理吗?


对于第一个问题,所以Linux中通过中断,提供一个统一的调用入口地址,然后通过一个寄存器来区分是哪一个函数。


对于第二个问题,Linux在加载每一个应用程序时,会在内核中建立与该应用程序相关的数据结构,并且在内核中创建一块内存空间,专门用作:从这个应用程序跳转到内核中执行代码时,所使用的栈空间。


但是,还有一些问题依然存在,例如:


  1. 应用程序虽然可以调用操作系统提供的函数了,但是操作系统如何对内核代码进行保护?;


  2. Linux 为应用程序建立内部栈的底层支撑是什么


这就涉及到 x86 中复杂的特权级相关内容了,下一篇文章,我们就向这些细节问题继续探索。


------ End ------
bootloader到操作系统,再到应用程序,这个三级跳的最简流程就讨论结束了。


希望对你有小小的帮助,谢谢!


方便的话,也请你转发给身边的技术小伙伴,让我们一块进步!


本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除。
换一批
延伸阅读

LED驱动电源的输入包括高压工频交流(即市电)、低压直流、高压直流、低压高频交流(如电子变压器的输出)等。

关键字: 驱动电源

在工业自动化蓬勃发展的当下,工业电机作为核心动力设备,其驱动电源的性能直接关系到整个系统的稳定性和可靠性。其中,反电动势抑制与过流保护是驱动电源设计中至关重要的两个环节,集成化方案的设计成为提升电机驱动性能的关键。

关键字: 工业电机 驱动电源

LED 驱动电源作为 LED 照明系统的 “心脏”,其稳定性直接决定了整个照明设备的使用寿命。然而,在实际应用中,LED 驱动电源易损坏的问题却十分常见,不仅增加了维护成本,还影响了用户体验。要解决这一问题,需从设计、生...

关键字: 驱动电源 照明系统 散热

根据LED驱动电源的公式,电感内电流波动大小和电感值成反比,输出纹波和输出电容值成反比。所以加大电感值和输出电容值可以减小纹波。

关键字: LED 设计 驱动电源

电动汽车(EV)作为新能源汽车的重要代表,正逐渐成为全球汽车产业的重要发展方向。电动汽车的核心技术之一是电机驱动控制系统,而绝缘栅双极型晶体管(IGBT)作为电机驱动系统中的关键元件,其性能直接影响到电动汽车的动力性能和...

关键字: 电动汽车 新能源 驱动电源

在现代城市建设中,街道及停车场照明作为基础设施的重要组成部分,其质量和效率直接关系到城市的公共安全、居民生活质量和能源利用效率。随着科技的进步,高亮度白光发光二极管(LED)因其独特的优势逐渐取代传统光源,成为大功率区域...

关键字: 发光二极管 驱动电源 LED

LED通用照明设计工程师会遇到许多挑战,如功率密度、功率因数校正(PFC)、空间受限和可靠性等。

关键字: LED 驱动电源 功率因数校正

在LED照明技术日益普及的今天,LED驱动电源的电磁干扰(EMI)问题成为了一个不可忽视的挑战。电磁干扰不仅会影响LED灯具的正常工作,还可能对周围电子设备造成不利影响,甚至引发系统故障。因此,采取有效的硬件措施来解决L...

关键字: LED照明技术 电磁干扰 驱动电源

开关电源具有效率高的特性,而且开关电源的变压器体积比串联稳压型电源的要小得多,电源电路比较整洁,整机重量也有所下降,所以,现在的LED驱动电源

关键字: LED 驱动电源 开关电源

LED驱动电源是把电源供应转换为特定的电压电流以驱动LED发光的电压转换器,通常情况下:LED驱动电源的输入包括高压工频交流(即市电)、低压直流、高压直流、低压高频交流(如电子变压器的输出)等。

关键字: LED 隧道灯 驱动电源
关闭