0
点赞
收藏
分享

微信扫一扫

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析


​​GreyZhang/g_unix: some basic learning about unix operating system. (github.com)​​

         其实这个过程在前面的笔记梳理过程中基本上已经打过照面了,但是这个过程中的一些起承转合的过程没有完全串起来。这一次整理只是整理一个启动过程的大概,具体细节则不去关注。通过这个过程的整理,希望能够梳理清楚一个机器启动起来的过程以及有什么约束条件。

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_linux

         首先,这个地址信息是启动的默认信息。因此,如果想要接下来的系统能够全都启动起来得借助于这个启动点。

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_6.828_02

         而这个启动点的实现是由工具来保证的,这个工具就是链接器。链接器识别了传递过去的参数之后,把start标记开始的代码分配到这一块空间。由此,上面的汇编代码便可以启动。

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_6.828_03

         而继续往后执行,中间经过一个从16bit模式到32bit模式的转换后,在32bit的寻址模式下调用了bootmain。而这个bootmain则是BootLoader的C代码启动入口。

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_JOS_04

         继续下去,在这个C代码中先是读取了磁盘信息,接着根据读取的C盘信息调用了一个函数,正式进入到了kernel。这里面发生了大概的什么动作过程呢?调用意味着什么?可以参考一下反汇编的代码。

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_MIT_05

         这里是通过call指令直接调用了一个地址的信息,而这个地址信息其实是之前从ELF文件中读取出来的。为什么会是这么一个数值呢?其实是读取后的存储开始地址加了一点偏移量。这个开始地址信息是代码里面定义的。

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_MIT_06

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_MIT_07

         结合这个存储分布的图示可以知道,这个地址是Low Memory中的一个地址信息,属于内存部分。没有找到为什么非得用着一个地址的原因,感觉上采用其他的地址应该也没有大问题。接下来采用0x11000以及0x20000的地址进行测试。测试下来,两个地址都可以完成相同的启动效果。

         根据代码简单分析,bootmain中其实是读取了磁盘最开始的几个扇区映射到了指定的存储上。而这个指定的存储在目前的设计中就是上面的0x10000地址。如此,如果软件想要能够成功启动OS的内核需要做什么呢?首先就得把内核的镜像存储到磁盘扇区最开始的位置上,这样bootmain才可以读取到。此外,bootmain中是按照elf格式进行内容解析的,因此还得保证存储的信息格式是elf格式。

         那么,这个内核的镜像又是如何生成的呢?这个是通过dd工具来实现的,在makefile中有一个关于镜像的依赖信息。

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_6.828_08

         而上面的子makefile其实就包含了镜像文件的生成操作。

1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析_unix_09

         上面便是dd生成镜像的过程。

         这样,整个启动过程的大概环节以及中间的一些依赖以及约束,还有用到的简单工具基本也就梳理出来一个框架了。之前,关于这部分的混沌感也终于消散了。

举报

相关推荐

0 条评论