当PC启动时,Intel系列的CPU首先进入的是实模式,并开始执行位于地址0xFFFF0处
的代码,也就是ROM-BIOS起始位置的代码。BIOS先进行一系列的系统自检,然后初始化位
于地址0的中断向量表。最后BIOS将启动盘的第一个扇区装入到0x7C00,并开始执行此处
的代码。这就是对内核初始化过程的一个最简单的描述。
最初,linux核心的最开始部分是用8086汇编语言编写的。当开始运行时,核心将自
己装入到绝对地址0x90000,再将其后的2k字节装入到地址0x90200处,最后将核心的其余
部分装入到0x10000。
当系统装入时,会显示Loading...信息。装入完成后,控制转向另一个实模式下的汇
编语言代码boot/Setup.S。Setup部分首先设置一些系统的硬件设备,然后将核心从
0x10000处移至0x1000处。这时系统转入保护模式,开始执行位于0x1000处的代码。
接下来是内核的解压缩。0x1000处的代码来自于文件Boot/head.S,它用来初始化寄
存器和调用decompress_kernel( )程序。decompress_kernel( )程序由Boot/inflate.c,
Boot/unzip.c和Boot../misc.c组成。解压缩后的数据被装入到了0x100000处,这也是
linux不能在内存小于2M的环境下运行的主要原因。
解压后的代码在0x1010000处开始执行,紧接着所有的32位的设置都将完成： IDT、
GDT和LDT将被装入,处理器初始化完毕,设置好内存页面,最终调用start_kernel过程。
这大概是整个内核中最为复杂的部分。
[系统开始运行]
linux kernel 最早的C代码从汇编标记startup_32开始执行
startup_32:
start_kernel
lock_kernel
trap_init
init_IRQ
sched_init
softirq_init
time_init
console_init
#ifdef CONFIG_MODULES
init_modules
#endif
kmem_cache_init
sti
calibrate_delay
mem_init
kmem_cache_sizes_init
pgtable_cache_init
fork_init
proc_caches_init
vfs_caches_init
buffer_init
page_cache_init
signals_init
#ifdef CONFIG_PROC_FS
proc_root_init
#endif
#if defined(CONFIG_SYSVIPC)
ipc_init
#endif
check_bugs
smp_init
rest_init
kernel_thread
unlock_kernel
cpu_idle
startup_32 [arch/i386/kernel/head.S] start_kernel [init/main.c] lock_kernel [include/asm/smplock.h] trap_init [arch/i386/kernel/traps.c] init_IRQ [arch/i386/kernel/i8259.c] sched_init [kernel/sched.c] softirq_init [kernel/softirq.c] time_init [arch/i386/kernel/time.c] console_init [drivers/char/tty_io.c] init_modules [kernel/module.c] kmem_cache_init [mm/slab.c] sti [include/asm/system.h] calibrate_delay [init/main.c] mem_init [arch/i386/mm/init.c] kmem_cache_sizes_init [mm/slab.c] pgtable_cache_init [arch/i386/mm/init.c] fork_init [kernel/fork.c] proc_caches_init vfs_caches_init [fs/dcache.c] buffer_init [fs/buffer.c] page_cache_init [mm/filemap.c] signals_init [kernel/signal.c] proc_root_init [fs/proc/root.c] ipc_init [ipc/util.c] check_bugs [include/asm/bugs.h] smp_init [init/main.c] rest_init kernel_thread [arch/i386/kernel/process.c] unlock_kernel [include/asm/smplock.h] cpu_idle [arch/i386/kernel/process.c]start_kernel( )程序用于初始化系统内核的各个部分,包括：
*设置内存边界,调用paging_init( )初始化内存页面。
*初始化陷阱,中断通道和调度。
*对命令行进行语法分析。
*初始化设备驱动程序和磁盘缓冲区。
*校对延迟循环。
最后的function'rest_init' 作了以下工作:
开辟内核线程'init' 调用unlock_kernel 建立内核运行的cpu_idle环, 如果没有调度,就一直死循环实际上start_kernel永远不能终止.它会无穷地循环执行cpu_idle.
最后,系统核心转向move_to_user_mode( ),以便创建初始化进程（init）。此后,进程0开始进入无限循环。
初始化进程开始执行/etc/init、/bin/init 或/sbin /init中的一个之后,系统内核就不再对程序进行直接控制了。之后系统内核的作用主要是给进程提供系统调用,以及提供异步中断事件的处理。多任务机制已经建立起来,并开始处理多个用户的登录和fork( )创建的进程。
[init]
init是第一个进程,或者说内核线程
init
lock_kernel
do_basic_setup
mtrr_init
sysctl_init
pci_init
sock_init
start_context_thread
do_init_calls
(*call())-> kswapd_init
prepare_namespace
free_initmem
unlock_kernel
execve
[目录]
--------------------------------------------------------------------------------
启动步骤
系统引导：
涉及的文件
./arch/$ARCH/boot/bootsect.s
./arch/$ARCH/boot/setup.s
bootsect.S
这个程序是linux kernel的第一个程序,包括了linux自己的bootstrap程序,
但是在说明这个程序前,必须先说明一般IBM PC开机时的动作(此处的开机是指
"打开PC的电源"):
一般PC在电源一开时,是由内存中地址FFFF:0000开始执行(这个地址一定
在ROM BIOS中,ROM BIOS一般是在FEOOOh到FFFFFh中),而此处的内容则是一个
jump指令,jump到另一个位於ROM BIOS中的位置,开始执行一系列的动作,包
括了检查RAM,keyboard,显示器,软硬磁盘等等,这些动作是由系统测试代码
(system test code)来执行的,随着制作BIOS厂商的不同而会有些许差异,但都
是大同小异,读者可自行观察自家机器开机时,萤幕上所显示的检查讯息。
紧接着系统测试码之后,控制权会转移给ROM中的启动程序
(ROM bootstrap routine),这个程序会将磁盘上的第零轨第零扇区读入
内存中(这就是一般所谓的boot sector,如果你曾接触过电脑病
毒,就大概听过它的大名),至於被读到内存的哪里呢? --绝对
位置07C0:0000(即07C00h处),这是IBM系列PC的特性。而位在linux开机
磁盘的boot sector上的正是linux的bootsect程序,也就是说,bootsect是
第一个被读入内存中并执行的程序。现在,我们可以开始来
看看到底bootsect做了什么。
第一步
首先,bootsect将它"自己"从被ROM BIOS载入的绝对地址0x7C00处搬到
0x90000处,然后利用一个jmpi(jump indirectly)的指令,跳到新位置的
jmpi的下一行去执行,
第二步
接着,将其他segment registers包括DS,ES,SS都指向0x9000这个位置,
与CS看齐。另外将SP及DX指向一任意位移地址( offset ),这个地址等一下
会用来存放磁盘参数表(disk para- meter table )
第三步
接着利用BIOS中断服务int 13h的第0号功能,重置磁盘控制器,使得刚才
的设定发挥功能。
第四步
完成重置磁盘控制器之后,bootsect就从磁盘上读入紧邻着bootsect的setup
程序,也就是setup.S,此读入动作是利用BIOS中断服务int 13h的第2号功能。
setup的image将会读入至程序所指定的内存绝对地址0x90200处,也就是在内存
中紧邻着bootsect 所在的位置。待setup的image读入内存后,利用BIOS中断服
务int 13h的第8号功能读取目前磁盘的参数。
第五步
再来,就要读入真正linux的kernel了,也就是你可以在linux的根目录下看
到的"vmlinuz" 。在读入前,将会先呼叫BIOS中断服务int 10h 的第3号功能,
读取游标位置,之后再呼叫BIOS 中断服务int 10h的第13h号功能,在萤幕上输
出字串"Loading",这个字串在boot linux时都会首先被看到,相信大家应该觉
得很眼熟吧。
第六步
接下来做的事是检查root device,之后就仿照一开始的方法,利用indirect
jump 跳至刚刚已读入的setup部份
第七步
setup.S完成在实模式下版本检查,并将硬盘,鼠标,内存参数写入到 INITSEG
中,并负责进入保护模式。
第八步
操作系统的初始化。
与其它操作系统相比，Linux最大的特点：它是一款遵循GPL的操作系统，我们可以自由
地使用、修改、和扩展它。正是由于这一特色，Linux受到越来越多人士的青睐。于是，
一个经常会被探讨的问题出现了，即关于Linux系统的移植。对于操作系统而言，这种移
植通常是跨平台的、与硬件相关的，即硬件系统结构、甚至CPU不同。下面就让我们来看
看在Linux系统移植方面，我们都需要做些什么。
一、Linux系统移植的两大部分
对于系统移植而言，Linux系统实际上由两个比较独立的部分组成，即内核部分和系
统部分。通常启动一个Linux系统的过程是这样的：一个不隶属于任何操作系统的加载程
序将Linux部分内核调入内存，并将控制权交给内存中Linux内核的第一行代码。加载程
序的工作就完了，此后Linux要将自己的剩余部分全部加载到内存（如果有的话，视硬件
平台的不同而不同），初始化所有的设备，在内存中建立好所需的数据结构（有关进程
、设备、内存等）。到此为止Linux内核的工作告一段落，内核已经控制了所有硬件设备
。至于操作和使用这些硬件设备，则轮到系统部分上场了。内核加载根设备并启动init
守护进程，init守护进程会根据配置文件加载文件系统、配置网络、服务进程、终端等
。一旦终端初始化完毕，我们就会看到系统的欢迎界面了。小结一下：
(1)内核部分初始化和控制所有硬件设备（严格说不是所有，而是绝大部分），为内存
管理、进程管理、设备读写等工作做好一切准备。
(2)系统部分加载必需的设备，配置各种环境以便用户可以使用整个系统。
二、系统移植所必需的环境
在进一步叙述之前，我们有必要提一下做系统移植所必需的环境。
首先，需要一个新版本的gcc。对于一个准备系统移植的程序员而言，“新”到什么
程度应该心里有数。做跨平台编译，gcc也许是最好的选择。另外，Linux内核依赖许多
gcc特有的特性，非它不可。如果你已经会使用gcc并实地操练过多回，那你只需要再进
一步巩固一下跨平台编译的操作即可。两种编译环境是可用的：非目标平台上的Linux或
目标平台上的非Linux系统，除非你的开发平台过于特殊，否则你一定能够找到你能用的
gcc。
其次，编译链接库是必需的，而且必须是目标平台的编译链接库。通常这是一个枯
燥、繁琐、又丝毫没有成就感的过程。幸运的话，会有现成的链接库可以用。否则，你
需要自己用gcc建立它。
最后，需要目标平台的所有文档，越多越好。如果有一定的开发支持/仿真环境，L
oader（加载程序）则最好，这些可以帮助你减少移植过程中浪费在琐事上的时间。
三、Linux系统移植
接下来我们从内核和系统两个方面描述一下移植中的关键。
(1) 内存移植
Linux系统采用了相对来说并不是很灵活的单一内核机制，但这丝毫没有影响Linux
系统的平台无关性和可扩展性。Linux使用了两种途径分别解决这些问题，很干净利落，
丝毫不拖泥带水，而且十分清晰易懂。分离硬件相关代码和硬件无关代码，使上层代码
永远不必关心低层换用了什么代码，如何完成了操作。不论对x86上还是在Alpha平台上
分配一块内存，对上层代码而言没什么不同。硬件相关部分的代码不多，占总代码量的
很少一部分。所以对更换硬件平台来说，没有什么真正的负担。另一方面，Linux使用内
核机制很好地解决了扩展的问题，一堆代码可以在需要的时候轻松地加载或卸下，象随
身听，需要的时候带上，不需要时则锁在抽屉里。
Linux内核可以视为由五个功能部分组成：进程管理（包括调度和通信）、内存管理
、设备管理、虚拟文件系统、网络。它们之间有着复杂的调用关系，但幸运的是，在移
植中不会触及到太多，因为Linux内核良好的分层结构将硬件相关的代码独立出来。何谓
硬件相关，何谓无关？以进程管理为例，对进程的时间片轮转调度算法在所有平台的Li
nux中都是一样的，它是与平台无关的；而用来在进程中切换的实现在不同的CPU上是不
同的，因此需要针对该平台编写代码，这就是平台相关的。上面所讲的五个部分的顺序
不是随便排的，从前到后分别代表着它们与硬件设备的相关程度。越靠前越高，后面的
两个虚拟文件系统和网络则几乎与平台无关，它们由设备管理中所支持的驱动程序提供
底层支持。因此，在做系统移植的时候，需要改动的就是进程管理、内存管理和设备管
理中被独立出来的那部分即硬件相关部分的代码。在Linux代码树下，这部分代码全部在
arch目录下。
如果你的目标平台已经被Linux核心所支持的话，那么你是幸运的，因为已经没有太
多的工作让你去做。只要你的交叉编译环境是正确的，你只需要简单的配置、编译就可
以得到目标代码。否则，需要你去编写，或修改一些代码。只需修改平台相关部分的代
码即可。但需要对目标平台，主要是对CPU的透彻理解。在Linux的代码树下，可以看到
，这部分的典型代码量为：2万行左右C代码和2千行左右的汇编（C代码中通常包含许多
伪汇编指令，因此实际上纯C代码要少很多），这部分工作量是不可小看的。它包含了对
绝大多数硬件的底层操作，涉及IRQ、内存页表、快表、浮点处理、时钟、多处理器同步
等问题，频繁的端口编程意味着需要你将目标平台的文档用C语言重写一遍。这就是为什
么说目标平台的文档极其重要。
代码量最大的部分是被核心直接调用的底层支持部分，这部分代码在arch/xxx/ker
nel下(xxx是平台名称)。这些代码重写了内核所需调用的所有函数。因为接口函数是固
定的，所以这里更象是为硬件平台编写API。不同的系统平台，主要有以下几方面的不同
进程管理底层代码：从硬件系统的角度来看，进程管理就是CPU的管理。在不同的硬
件平台上，这有很大的不同。CPU中用的寄存器结构不同，上下文切换的方式、现场的保
存和恢复、栈的处理都不同，这些内容主要由CPU开发手册所描述。通常来说，CPU的所
有功能和状态对于Linux不一定有意义。实现时，需要在最小的开发代价和最好的系统性
能之间加以权衡。
* BIOS接口代码：这一名称似乎并不太准确，因为它沿用了PC一贯的叫法。但在不致引
起混淆的情况下我们还是这么叫它。在通用平台上，通常有基本输入输出系统供操作系
统使用，在PC上是BIOS，在SPARC上是PROM，在很多非通用系统上甚至并没有这样的东西
。多数情况下，Linux不依赖基本输入输出系统，但在某些系统里，Linux需要通过基本
输入输出系统中得到重要的设备参数。移植中，这部分代码通常需要完全改写。
* 时钟、中断等板上设备支持代码：即使在同一种CPU的平台上，也会存在不同的板上外
设，异种CPU平台上更是如此。不同的系统组态需要不同的初始化代码。很典型的例子就
是MIPS平台，看看arc/mips/的代码，与其它系统比较一下就知道。因为MIPS平台被OEM
得最广，在嵌入式领域应用最多（相对其它几种CPU而言）。甚至同一种MIPS芯片被不同
厂家封装再配上不同的芯片组。因此要为这些不同的MIPS平台分别编写不同的代码。
* 特殊结构代码：如多处理器支持等。其实每一种CPU都是十分特殊的，熟悉x86平台的
人都知道x86系列CPU著名的实模式与虚模式的区别，而在SPARC平台上根本就没有这个概
念。这就导致了很大的不同：PC机上的Linux在获得控制权后不久就开始切换到虚模式，
SPARC机器上则没有这段代码。又如电源管理的支持更是多种多样，不同的CPU有着不同
的实现方式（特殊的电源管理方式甚至被厂商标榜）。在这种情况下，除非放弃对电源
管理的支持，否则必须重写代码。
还有一部分代码量不多，但不能忽视的部分是在arch/xxx/mm/下的内存管理部分。
所有与平台相关的内存管理代码全部在这里。这部分代码完成内存的初始化和各种与内
存管理相关的数据结构的建立。Linux使用了基于页式管理的虚拟存储技术，而CPU发展
的趋势是：为了提高性能，实现内存管理的功能单元统统被集成到CPU中。因此内存管理
成为一个与CPU十分相关的工作。同时内存管理的效率也是最影响系统性能的因素之一。
内存可以说是计算机系统中最频繁访问的设备，如果每次内存访问时多占用一个时钟周
期，那就有可能将系统性能降低到不可忍受。在Linux系统里，不同平台上的内存管理代
码的差异程度是令人吃惊的，可以说是差异最大的。不同的CPU有不同的内存管理方式，
同一种CPU还会有不同的内存管理模式。Linux是从32位硬件平台上发展起来的操作系统
，但是现在已经有数种64位平台出现。在64位平台上，可用内存范围增大到原来的232倍
，其间差异可略窥一斑了。鉴于这部分代码的重要性和复杂性，移植工作在这里变得相
当谨慎。有些平台上甚至只是用最保守的内存管理模式。如在SPARC平台上的页面大小可
以是多种尺寸，为了简单和可靠起见，SPARC版的Linux只是用了8K页面这一种模式。这
一状况直到2.4版才得以改善。
除了上面所讲的之外，还有一些代码需要考虑，但相对来说次要一些。如浮点运算
的支持。较完美的做法是对FPU编程，由硬件完成浮点运算。但在某些时候，浮点并不重
要，甚至CPU根本就不支持浮点。这时候就可以根据需求来取舍。
对于内核移植的讨论到此为止。实际上，还有一些移植工作需要同时考虑，但很难
说这是属于内核范畴还是属于驱动程序范畴，比如说显示设备的支持，和内核十分相关
，但在逻辑上又不属于内核，并且在移植上也更像是驱动程序的开发。因此不在这里讨
论。
(2)系统移植
当内核移植完毕后，可以说所有的移植工作就已经完成大半了。就是说，当内核在
交叉编译成功后，加载到目标平台上正常启动，并出现类似VFS: Can抰 mount root fi
le system的提示时，则表示可以开始系统移植方面的工作了。系统移植实际上是一个最
小系统的重建过程。许多Linux爱好者有过建立Linux系统应急盘的经验，与其不同的是
，你需要使用目标平台上的二进制代码生成这个最小系统。包括：init、libc库、驱动
模块、必需的应用程序和系统配置脚本。一旦这些工作完成，移植工作就进入联调阶段
了。
一个比较容易的系统部分移植办法是：先着手建立开发平台上的最小系统，保证这
套最小系统在开发平台上正确运行。这样可以避免由于最小系统本身的逻辑错误而带来
的麻烦。由于最小系统中是多个应用程序相互配合工作，有时出现的问题不在代码本身
而在系统的逻辑结构上。
Linux系统移植工作至少要包括上述的内容，除此之外，有一些看不见的开发工作也
是不可忽视的，如某个特殊设备的驱动程序，为调试内核而做的远程调试工作等。另外
，同样的一次移植工作，显然符合最小功能集的移植和完美移植是不一样的；向16位移
植和向64位移植也是不一样的。
在移植中通常会遇见的问题是试运行时锁死或崩溃，在系统部分移植时要好办些，
因为可以容易地定位错误根源，而在核心移植时确实很让人头疼。虽然可以通过串口对
运行着的内核进行调试，但是在多任务情况下，有很多现象是不可重现的。又如，在初
始化的开始，很多设备还没法确定状态，甚至串口还没有初始化。对于这种情况没有什
么很好的解决办法，好的开发/仿真平台很重要，另外要多增加反映系统运行状态的调试
代码；再者要吃透硬件平台的文档。硬件平台厂商的专业支持也是很重要的。
还有一点很重要：Linux本身是基于GPL的操作系统，移植时，可以充分发挥GPL的优
势，让更多的爱好者参与进来，向共同的目标前进。
