Linux内核启动工作流程初探

linux下的关机和重启流程对于一般的桌面应用和网络服务器来说并不重要，但是在用户自己定义的嵌入式系统内核中就有一定的研究意义，通过了解Linux 关机重启的流程，我们对它可以修改和自定义，甚至以此为基础开发出全新的功能来。

1.概述
在linux下的关机和重启可能由两种行为引发，一是通过用户编程，一是系统自己产生的消息。用户和系统进行交互的方式也有两个，一个是系统调用：sys_reboot，另一个就是apm或则acpi的设备文件，通过对其操作也可以使系统关机或者重启。 

2.通过系统调用sys_reboot的重启
这个系统调用定义了一系列的MAGIC_NUMBER，在调用的开始部分首先检查MAGIC_NUMBER是否正确，只有正确才继续向下运行。在重启的时候转向分支 
case LINUX_REBOOT_CMD_RESTART: 
首先使用notifier_call_chain向其它部分发出重启的消息，然后调用machine_restart函数完成重启。 
machine_restart函数的开始部分有一段SMP相关的代码，主要完成多CPU时由一个CPU完成重启操作，其它CPU处于等待状态。之后系统 根据一个变量reboot_thru_bios的内容判断重启方式，通过阅读reboot_setup我们可以得知，这个参数的内容是在系统启动时指定 的，决定了是否利用bios，事实上是系统复位后的入口(FFFF：0000)地址的程序进行重启。在不通过bios进行重启的情况下，系统首先设定了重 启标志，然后向端口0xfe写入数字0x64,这种重启的具体原理我还不大清楚，似乎是模拟了一次reset键的按下，希望大家和我讨论。在通过bios 重启的情况下，系统同样先设定了重启模式，然后切换到了实模式，通过一条ljmp $0xffff,$0x0完成了重启。 

3.通过系统调用sys_reboot进行关机
在系统调用的处理分支上，我们可以看到，首先同样是检查MAGIC_NUMBER，然后在 
case LINUX_REBOOT_CMD_POWER_OFF: 
的执行流程里面，又是使用notifier_call_chain发出了关闭计算机电源的消息，紧接着执行了machine_power_off函数。我 们在machine_power_off函数中可以看到，如果pm_power_off这个函数指针不为空，那么系统就会通过调用这个函数进行关机。在 apm已经加载的情况下(SMP除外)，实际上pm_power_off函数实际上指向了apm.c中的apm_power_off，在这个函数里系统通 过apm_info结构里的值，使用切换到实模式关机，或者使用apm_bios_call_simple函数调用保护模式下的apm接口关机两种方法。 

4.apm驱动本身的关机过程
apm使用其注册的设备的ioctl接口完成apm的操作，在apm.c的do_ioctl函数中可以看见处理的分支。这里只有suspend和standby的代码，所以我们不能通过ioctl这种方法使用apm关机。
当用户按下POWER开关的时候，如果有apm模块，那么关机流程是由apm来处理的。apm驱动在初始化的时候启动了一个apm内核线程： apm_mainloop，系统会在这里检测到POWEROFF按键消息并且将其命名为APM_SYS_SUSPEND，以区别apm -s设置的APM_USER_SUSPEND模式。紧接着进入了apm_event_handler函数，又从apm_event_handler函数进 入了check_events函数，处理函数对应的case分支上。系统同样使用了suspend函数进行关机，不过由于其它参数的原因，suspend 最后调用的是关机的流程。 

5.解决问题实例
1)按POWER键时某些主板死机
经查只有某些特定的驱动装载之后才会出现这样的情况，并且当使用关机系统调用sys_reboot的时候没有这样的问题。分析apm的处理流程，怀疑是在 关机前驱动程序没有正确处理apm发出的询问消息造成的。由于部分驱动程序没有源代码，决定hack掉apm.c的关机部分，让两种方式的关机走同样的流 程。于是把apm.c的check_events函数中对APM_SYS_SUSPEND部分改写为如下代码： 

ret = exec_usermodehelper(poweroff_helper_path, argv, envp); 
if (ret) { 
printk(KERN_ERR 
"apm.c: failed to exec %s , errno = %d\\n", 
poweroff_helper_path, errno); 
} 
break; 

For fast reboot support 
static unsigned char fast_reboot_switch [] = { 
0x66, 0x0f, 0x20, 0xc0, /* movl %cr0,%eax */ 
0x66, 0x25, 0x10, 0x11, 0x11, 0x11, /* andl $0x11111110,%eax */ 
0x66, 0x0f, 0x22, 0xc0, /* movl %eax,%cr0 */ 
0xea, 0x00, 0x00, 0x00, 0x70 /* ljmp $0x7000,$0x0000 */ 

}; 

系统就可以切换到实模式中，然后跳转到7000H:0位置开始执行。 

6.ACPI概述
在2.4.20内核中ACPI模块被注明为试验和未完成，里面有一部分功能也许没有实现。如果APM和APCI两个模块同时编译进内核，APM在ACPI 前被加载，APM起作用使ACPI退出。对于系统电量、电源实践一类的支持（主要是在笔记本上有用），靠的是acpid这个daemon程序。 
没有一个功能类似apm的应用程序切换状态，acpi的程序仅仅完成了对acpi状态的查询。用户实现S0-S4的功能可以直接向/proc/acpi/sleep文件中写入数字来实现。通过读出(cat)其中的内容可以知道系统到底支持那些模式。 
acpi模块的源代码主程序在linux/drivers/acpi/driver.c中，如果向sleep文件写东西，就转到了 linux/drivers/acpi/ospm/system/sm_osl.c文件的sm_osl_proc_write_sleep函数中，这个函 数后来调用了sm_osl_suspend函数。在这个函数里完成了各种功能，包括保护各种状态。最后真正的sleep是通过对 acpi_enter_sleep_state的调用完成的，这个函数在linux/drivers/acpi/hardware/hwsleep.c文 件中，这里写了acpi的寄存器使系统进入sleep状态。写寄存器的指令在这个目录下面的hwregs.c中。 

7.总结
本文对acpi的介绍非常简略，实际上ACPI必定会成为将来linux内核中首选的电源管理方式。由于目前官方代码中ACPI版本较低，所以没有太详细的论述，希望将来的内核能有所改变。 

参考资料 
linux-2.4.20源代码 

Linux启动过程(基于X86平台的redhat)
鉴于个人水平有限，本文仅以直观的角度，简单阐述从通电到用户登录界面出现的启动过程。从宏观来看，该过程可分为4个阶段：
1、开机加电
2、运行BIOS
3、启动引导程序
4、操作系统初始化

一、开机加电
机器上电后，如果电源系统工作正常，会发送低电平的"Power Good"到复位电路接口的#RES端，产生时钟同步的复位正脉冲RESET送到CPU的RESET引脚，脉冲的下降沿触发CPU执行初始化程序，设置CS和IP寄存器，进入实地址模式。而根据CS和IP的值得到的物理地址就是CPU执行的第一条指令地址。虽然知道了物理地址，但是内存还没有初始化，因此改物理地址指向BIOS ROM。

对于386前后，该物理地址是不同的，但都在内存的最高地址段。
386以前的CPU寻址范围为1M，即0x00000H~0xFFFFFH。此时CS=0xF000H，IP=0xFFF0H，段地址左移4位后，加上偏移地址得到物理地址0xFFFF0H。
而386的可寻址范围为4GB 即 0x00000000H~0xFFFFFFFFH。如果以0x000FFFF0H作为BIOS地址的话，系统内存不连续，因此，386使用硬件置1的方式将A20～A31地址线置1，就变成0xFFFFFFF0H，并以此作为BIOS地址。

二、运行BIOS
找到BIOS地址后，BIOS的第一条指令就是跳转，其跳转到BIOS的程序入口处，开始运行。比如jmp F000:E05B，跳到0xFE05BH处执行。
在1M的地址空间中，0x00000H~0x9FFFF为RAM，0xA0000H~0xBFFFFH为图形卡映射区，0xC0000H~0xFFFFFH为BIOS例程。其中0xA0000H~0xFFFFFH被称作Shadow RAM，BIOS在运行中会将自身从ROM中拷贝到RAM，以提高系统效率。
BIOS第一步是自检，即进行所谓的POST（Power On Self  Test），对硬件进行检测。第二步是进行本地设备的枚举和初始化。根据其不同功能，BIOS 由两部分组成：POST 代码和运行时服务。当 POST 完成之后，它被从内存中清理了出来，但是 BIOS 运行时服务依然保留在内存中，目标操作系统可以使用这些服务。
引导操作系统时，BIOS 运行时会按照 CMOS 的设置定义的顺序来搜索处于活动状态并且可以引导的设备。引导设备可以是软盘、CD-ROM、硬盘上的某个分区、网络上的某个设备，甚至是 USB 闪存。通常，Linux 都是从硬盘上引导的，其中主引导记录（MBR）中包含主引导加载程序。MBR 是一个 512 字节大小的扇区，位于磁盘上的第一个扇区中（0道0柱面1扇区）。当 MBR 被加载到 RAM（0x07C00H）中之后，BIOS 就会将控制权交给 MBR。

三、启动引导程序
MBR就是主引导记录（Master Boot Record），包括0柱0头1扇区的512个字节，它的任务是完成BIOS到操作系统的交接。0000H~01BDH为MBR代码区，负责装载并允许系统引导程序；01BEH~01FDH为分区表信息；01FEH~01FFH的2个字节值为结束标志55AA，如果该标志错误系统就不能启动。
在单一的MBR中只能存储一个操作系统的引导记录，当需要多个操作系统时就会出现问题，所以需要更灵活的引导加载程序。Linux下常见的引导程序有GRUB和LILO。LILO将操作系统位置信息写到MBR中，而GRUB的操作系统位置信息是配置在文件系统中的配置文件里。这里以GRUB为例，进行引导。
GRUB根据其启动过程的文件stage1、xxx_stage1_5、stage2，可分为三个过程。
stage1的大小为512字节，使用grub命令设置启动盘时，会将stage1写入到MBR中，用于引导xxx_stage1_5或stage2。
xxx_stage1_5的前缀为文件系统类型，其功能为确保识别到启动磁盘的文件系统类型。
stage2为GRUB引导的主要阶段，它读取/boot/grub/menu.list（实际指向grub.conf）文件并提供交互界面，根据用户选择和相关配置加载内核。

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-1.2798.fc6.img

这是FC8中menu.list的配置，每一项的内容不再一一解释，只对initrd作相关说明。
initrd（boot loader initialized RAM disk）就是由 boot loader 初始化的内存盘。在内核启动前，GRUB将存储介质中的 initrd 文件加载到内存，内核启动时会在访问真正的根文件系统前先访问该内存中的initrd文件系统。在GRUB配置了initrd的情况下，内核启动被分成了两个阶段，第一阶段先执行initrd文件系统中的“某个文件”，完成加载驱动模块等任务，第二阶段才会执行真正的根文件系统中的/sbin/init进程。第一阶段启动的目的是为第二阶段的启动扫清一切障碍，最主要的是加载根文件系统存储介质的驱动模块。initrd有cpio-initrd和 image-initrd 这两种格式，前者的制作方式和处理流程都更为清晰。

内核加载完成以后会启动/sbin/init，至此进入操作系统加载过程。

四、操作系统初始化
init进程是系统所有进程的起点，进程号是1。init进程是所有进程的发起者和控制者。init进程有两个作用。一是扮演终结父进程的角色。二是根据/etc/inittab来执行相应的脚本进行系统初始化。
inittab是以行为单位的描述性（非执行性）文本，每一个指令行都具有以下格式：

id:runlevel:action:process
其中id为入口标识符，runlevel为运行级别，action为动作代号，process为具体的执行程序。
通过inittab的内容，初始化过程为：
首先寻找initdefault，设置默认的启动级别，如果没有设置initdefault项，init将在控制台上请求输入runlevel。
运行脚本/etc/rc.d/rc.sysinit。该阶段主要进行各个运行级别中相同的初始化工作。完成后进入选定的运行级别中停止或运行相应的服务。
以ttyn为参数运行/sbin/mingetty，打开ttyn终端用于用户登录。如果进程退出则再运行mingetty。

至此，进入用户登录界面。启动完毕。