UCore实验一：系统软件启动过程

练习1：理解通过make生成执行文件的过程。

• 操作系统镜像文件ucore.img是如何一步一步生成的？

首先在Ubuntu里面运行lab1_result，我们可以看到在启动操作系统之前，电脑对一系列文件进行了编译，通过make qemu我们可以看到，电脑首先针对kern文件下的.c和.S文件进行了编译，然后通过ld把kern文档下的所有程序和bin文件连接起来，并重定位他们的数据，然后生成kernel程序。
其次电脑针对boot文件夹下面的.c和.S文件进行了编译，并且将tools文件夹下面的sign.c也进行了编译，然后通过ld生成bootblock程序。
因此通过make qemu我们可以了解到在生成ucore.img之前，需要先通过编译链接，生成kernel和bootblock的ELF文件。

接下来我们可以看到通过dd指令，将上面我们生成的kernel和bootblock的ELF文件拷贝到ucore.img当中，根据拷贝的顺序我们可以看到，首先是将bootblock拷贝进了ucore.img，然后才是将kernel拷贝进ucore.img，所以可以得出bootblock是引导区，kernel是操作系统内核。
除此之外，在上文我们看到电脑还对sign.c进行了编译，然而在接下来的链接中并没有对其进行进一步操作，所以我们打开sign.c文件进行查看。

在这里我们看到给sign.c传进去了3个参数，其中通过输出，我们可以了解到argv[1]传入的是obj/bootblock.out：

紧接着在下面定义了一个长度为512的字符串，然后从obj/bootblock.out中读取500个字符存到buf里面，接下来在buf的结尾加上0x55AA，并且将其写到argv[2]里面，由于在运行中看不出来argv[2]是哪里，所以针对sign.c文件进行了修改，输出了argv[2]：

可以看到我们将更改后的buf存入了bin/bootblock当中，即我们的sign.c文件，在引导区内做了个0x55AA的标记，然后将其存入了bin/bootblock当中，然后拷贝到ucore.img里面。
自此，我们的ucore.img文件正式生成。

• 一个被系统认为是符合规范的硬盘主引导扇区的特征是什么？

由此可知，我们的sign.c文件是用来给主引导扇区做标记的，因此我们可以通过sign.c的报错信息可以得到主引导扇区的两个特征，首先主引导扇区的大小必须是512个字节，其次主引导扇区的最后两个字节必须是0x55AA，否则就会报错。

练习2：使用qemu执行并调试lab1中的软件。

• 从CPU加电后执行的第一条指令开始，单步跟踪BIOS的执行。

  首先在CPU加电之后，CPU里面的ROM存储器会将其里面保存的初始值传给各个寄存器，其中CS:IP = 0Xf000 : fff0（CS：代码段寄存器；IP：指令寄存器），这个值决定了我们从内存中读数据的位置，PC = 16*CS + IP。

此时系统处于实模式，并且截止到目前为止系统的总线还不是我们平常的32位，这时的地址总线只有20位，所以地址空间的总大小只有1M，而我们的BIOS启动固件就在这个1M的空间里面。
BIOS启动固件需要提供以下的一些功能：
☆基本输入输出的程序
☆系统设置信息
☆开机后自检程序
☆系统自启动程序
在此我们需要找到CPU加电之后的第一条指令的位置，然后在这里break，单步跟踪BIOS的执行，根据PC = 16*CS + IP，我们可以得到PC = 0xffff0，所以BIOS的第一条指令的位置为0xffff0（在这里因为此时我们的地址空间只有20位，所以是0xffff0）。
在这里我们利用make debug来观察BIOS的单步执行，所以我们首先通过Makefile文件来查看make debug的相关操作：

通过debug的定义，我们可以看到，在debug里首先是对qemu进行的操作，然后等待一段时间之后，再进行针对gdbinit文件进行的调试，所以，我们继续观察gdbinit文件：

在gdbinit文件里我们可以看到电脑在运行到kern_init是会触发break，然后又紧接着在下一步continue，所以会继续执行，再根据第一问的编译顺序：

我们可以看到电脑CPU在加电之后第一步要执行的就是对kern_init进行编译，同时这也是BIOS的第一条指令，所以我们需要在这里break，然后通过gdb一步一步针对BIOS进行运行，因此，我们将gdbinit中的continue删除，从而使得电脑停在这里。

然后进行make debu