本系统中，head.S首先配置S3C4510B的系统寄存器SYSCFG、初始化系统的Flash、SDRAM以及总线控制寄存器，将Flash和SDRAM的地址范围分别设置为0x0-0x1fffff和0x1000000-0x1ffffff；根据本系统的功能特点，重新定义了中断优先级以及I/O口的配置；为了提高内核的运行速度，将2M的内核映像文件从Flash拷贝到SDRAM；通过操作一些系统寄存器，进行系统的存储器重映射，将Flash和SDRAM的地址区间分别重映射为0x1000000-0x11fffff和0x0-0xffffff；然后初始化系统堆栈；接着调用misc.c中的函数decompress_kernel，对拷贝到SDRAM的内核映像文件进行解压缩；最后跳转到执行调用内核函数call_kernel，调用call_kernel函数实际上是执行main.c中的start_kernel函数，该函数完成的功能包括处理器结构的初始化、中断的初始化、定时器的初始化、进程相关的初始化以及内存初始化等初始化工作；最后内核创建一个init线程，在该线程中调用init进程，完成系统的启动

 当用户打开PC的电源，BIOS开机自检，按BIOS中设置的启动设备(通常是硬盘)启动，接着启动设备上安装的引导程序lilo或grub开始引导Linux，Linux首先进行内核的引导，接下来执行init程序，init程序调用了rc.sysinit和rc等程序，rc.sysinit和rc当完成系统初始化和运行服务的任务后，返回init；init启动了mingetty后，打开了终端供用户登录系统，用户登录成功后进入了Shell，这样就完成了从开机到登录的整个启动过程。

-->power on-->BIOS-->Lilo/Grub-->Kernerl boot-->init(rc.sysinit, rc)
-->mingetty(login)-->Shell---->

下面就将逐一介绍其中几个关键的部分：

　　第一部分：内核的引导(核内引导)

　　Red Hat9.0可以使用lilo或grub等引导程序开始引导Linux系统，当引导程序成功完成引导任务后，Linux从它们手中接管了CPU的控制权，然后CPU就开始执行Linux的核心映象代码，开始了Linux启动过程。这里使用了几个汇编程序来引导Linux，这一步泛及到Linux源代码树中的“arch/i386/boot”下的这几个文件：bootsect.S、setup.S、video.S等。

　　其中bootsect.S是生成引导扇区的汇编源码，它完成加载动作后直接跳转到setup.S的程序入口。setup.S的主要功能就是将系统参数（包括内存、磁盘等，由BIOS返回）拷贝到特别内存中，以便以后这些参数被保护模式下的代码来读取。此外，setup.S还将video.S中的代码包含进来，检测和设置显示器和显示模式。最后，setup.S将系统转换到保护模式，并跳转到 0x100000。

　　那么0x100000这个内存地址中存放的是什么代码？而这些代码又是从何而来的呢？

　　0x100000这个内存地址存放的是解压后的内核，因为Red Hat提供的内核包含了众多驱动和功能而显得比较大，所以在内核编译中使用了“makebzImage”方式，从而生成压缩过的内核，在RedHat中内核常常被命名为vmlinuz，在Linux的最初引导过程中，是通过"arch/i386/boot/compressed/"中的head.S利用misc.c中定义的decompress_kernel()函数，将内核vmlinuz解压到0x100000的。

　　当CPU跳到0x100000时，将执行"arch/i386/kernel/head.S"中的startup_32，它也是vmlinux的入口，然后就跳转到start_kernel()中去了。start_kernel()是"init/main.c"中的定义的函数，start_kernel()中调用了一系列初始化函数，以完成kernel本身的设置。start_kernel()函数中，做了大量的工作来建立基本的Linux核心环境。如果顺利执行完start_kernel()，则基本的Linux核心环境已经建立起来了。

　　在start_kernel()的最后，通过调用init()函数，系统创建第一个核心线程，启动了init过程。而核心线程init()主要是来进行一些外设初始化的工作的，包括调用do_basic_setup()完成外设及其驱动程序的加载和初始化。并完成文件系统初始化和root文件系统的安装。

　　当do_basic_setup()函数返回init()，init()又打开了/dev/console设备，重定向三个标准的输入输出文件stdin、stdout和stderr到控制台，最后，搜索文件系统中的init程序（或者由init=命令行参数指定的程序），并使用 execve()系统调用加载执行init程序。到此init()函数结束，内核的引导部分也到此结束了，

第二部分：运行init

　　init的进程号是1，从这一点就能看出，init进程是系统所有进程的起点，Linux在完成核内引导以后，就开始运行init程序，。init程序需要读取配置文件/etc/inittab。inittab是一个不可执行的文本文件，它有若干行指令所组成。在Redhat系统中，inittab的内容如下所示(以“###"开始的中注释为笔者增加的)：

　　#
　　# inittab       This file describes how the INIT process should set up
　　#               the system in a certain run-level.
　　#
　　# Author:       Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
　　#               Modified for RHS Linux by Marc Ewing and Donnie Barnes
　　#

　　# Default runlevel. The runlevels used by RHS are:
　　#   0 - halt (Do NOT set initdefault to this)
　　#   1 - Single user mode
　　#   2 - Multiuser, without NFS (The same as 3, if you do not havenetworking)
　　#   3 - Full multiuser mode
　　#   4 - unused
　　#   5 - X11
　　#   6 - reboot (Do NOT set initdefault to this)
　　#
　　###表示当前缺省运行级别为5(initdefault)；
　　id:5:initdefault:

　　###启动时自动执行/etc/rc.d/rc.sysinit脚本(sysinit)
　　# System initialization.
　　si::sysinit:/etc/rc.d/rc.sysinit

　　l0:0:wait:/etc/rc.d/rc 0
　　l1:1:wait:/etc/rc.d/rc 1
　　l2:2:wait:/etc/rc.d/rc 2
　　l3:3:wait:/etc/rc.d/rc 3
　　l4:4:wait:/etc/rc.d/rc 4
　　###当运行级别为5时，以5为参数运行/etc/rc.d/rc脚本，init将等待其返回(wait)
　　l5:5:wait:/etc/rc.d/rc 5
　　l6:6:wait:/etc/rc.d/rc 6

　　###在启动过程中允许按CTRL-ALT-DELETE重启系统
　　# Trap CTRL-ALT-DELETE
　　ca::ctrlaltdel:/sbin/shutdown -t3 -r now

　　# When our UPS tells us power has failed, assume we have a few minutes
　　# of power left.  Schedule a shutdown for 2 minutes from now.
　　# This does, of course, assume you have powerd installed and your
　　# UPS connected and working correctly.
　　pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

　　# If power was restored before the shutdown kicked in, cancel it.
　　pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

　　###在2、3、4、5级别上以ttyX为参数执行/sbin/mingetty程序，打开ttyX终端用于用户登录，
　　###如果进程退出则再次运行mingetty程序(respawn)
　　# Run gettys in standard runlevels
　　1:2345:respawn:/sbin/mingetty tty1
　　2:2345:respawn:/sbin/mingetty tty2
　　3:2345:respawn:/sbin/mingetty tty3
　　4:2345:respawn:/sbin/mingetty tty4
　　5:2345:respawn:/sbin/mingetty tty5
　　6:2345:respawn:/sbin/mingetty tty6

　　###在5级别上运行xdm程序，提供xdm图形方式登录界面，并在退出时重新执行(respawn)
　　# Run xdm in runlevel 5
　　x:5:respawn:/etc/X11/prefdm -nodaemon

以上面的inittab文件为例，来说明一下inittab的格式。其中以#开始的行是注释行，除了注释行之外，每一行都有以下格式：

　　id:runlevel:action:process

　　对上面各项的详细解释如下：

　　1. id

　　id是指入口标识符，它是一个字符串，对于getty或mingetty等其他login程序项，要求id与tty的编号相同，否则getty程序将不能正常工作。

　　2. runlevel

　　runlevel是init所处于的运行级别的标识，一般使用0－6以及S或s。0、1、6运行级别被系统保留：其中0作为shutdown动作，1作为重启至单用户模式，6为重启；S和s意义相同，表示单用户模式，且无需inittab文件，因此也不在inittab中出现，实际上，进入单用户模式时，init直接在控制台（/dev/console）上运行/sbin/sulogin。在一般的系统实现中，都使用了2、3、4、5几个级别，在Redhat系统中，2表示无NFS支持的多用户模式，3表示完全多用户模式（也是最常用的级别），4保留给用户自定义，5表示XDM图形登录方式。7－9级别也是可以使用的，传统的Unix系统没有定义这几个级别。runlevel可以是并列的多个值，以匹配多个运行级别，对大多数action来说，仅当runlevel与当前运行级别匹配成功才会执行。

　　3. action

　　action是描述其后的process的运行方式的。action可取的值包括：initdefault、sysinit、boot、bootwait等：

　　initdefault是一个特殊的action值，用于标识缺省的启动级别；当init由核心激活以后，它将读取inittab中的initdefault项，取得其中的runlevel，并作为当前的运行级别。如果没有inittab文件，或者其中没有initdefault项，init将在控制台上请求输入runlevel。

　　sysinit、boot、bootwait等action将在系统启动时无条件运行，而忽略其中的runlevel。

　　其余的action（不含initdefault）都与某个runlevel相关。各个action的定义在inittab的man手册中有详细的描述。

　　4. process

　　process为具体的执行程序。程序后面可以带参数。

　　第三部分：系统初始化

　　在init的配置文件中有这么一行：

　　si::sysinit:/etc/rc.d/rc.sysinit

　　它调用执行了/etc/rc.d/rc.sysinit，而rc.sysinit是一个bash shell的脚本，它主要是完成一些系统初始化的工作，rc.sysinit是每一个运行级别都要首先运行的重要脚本。它主要完成的工作有：激活交换分区，检查磁盘，加载硬件模块以及其它一些需要优先执行任务。

　　rc.sysinit约有850多行，但是每个单一的功能还是比较简单，而且带有注释，建议有兴趣的用户可以自行阅读自己机器上的该文件，以了解系统初始化所详细情况。由于此文件较长，所以不在本文中列出来，也不做具体的介绍。

　　当rc.sysinit程序执行完毕后，将返回init继续下一步。

第四部分：启动对应运行级别的守护进程

　　在rc.sysinit执行后，将返回init继续其它的动作，通常接下来会执行到/etc/rc.d/rc程序。以运行级别3为例，init将执行配置文件inittab中的以下这行：

　　l5:5:wait:/etc/rc.d/rc 5

　　这一行表示以5为参数运行/etc/rc.d/rc，/etc/rc.d/rc是一个Shell脚本，它接受5作为参数，去执行/etc/rc.d/rc5.d/目录下的所有的rc启动脚本，/etc/rc.d/rc5.d/目录中的这些启动脚本实际上都是一些链接文件，而不是真正的rc启动脚本，真正的rc启动脚本实际上都是放在/etc/rc.d/init.d/目录下。而这些rc启动脚本有着类似的用法，它们一般能接受start、stop、restart、status等参数。

　　/etc/rc.d/rc5.d/中的rc启动脚本通常是K或S开头的链接文件，对于以以S开头的启动脚本，将以start参数来运行。而如果发现存在相应的脚本也存在K打头的链接，而且已经处于运行态了(以/var/lock/subsys/下的文件作为标志)，则将首先以stop为参数停止这些已经启动了的守护进程，然后再重新运行。这样做是为了保证是当init改变运行级别时，所有相关的守护进程都将重启。

　　至于在每个运行级中将运行哪些守护进程，用户可以通过chkconfig或setup中的"System Services"来自行设定。常见的守护进程有：

　　amd：自动安装NFS守护进程
　　apmd:高级电源管理守护进程
　　arpwatch：记录日志并构建一个在LAN接口上看到的以太网地址和IP地址对数据库
　　autofs：自动安装管理进程automount，与NFS相关，依赖于NIS
　　crond：Linux下的计划任务的守护进程
　　named：DNS服务器
　　netfs：安装NFS、Samba和NetWare网络文件系统
　　network：激活已配置网络接口的脚本程序
　　nfs：打开NFS服务
　　portmap：RPC portmap管理器，它管理基于RPC服务的连接
　　sendmail：邮件服务器sendmail
　　smb：Samba文件共享/打印服务
　　syslog：一个让系统引导时起动syslog和klogd系统日志守候进程的脚本
　　xfs：X Window字型服务器，为本地和远程X服务器提供字型集
　　Xinetd：支持多种网络服务的核心守护进程，可以管理wuftp、sshd、telnet等服务

　　这些守护进程也启动完成了，rc程序也就执行完了，然后又将返回init继续下一步。

第五部分：建立终端

　　rc执行完毕后，返回init。这时基本系统环境已经设置好了，各种守护进程也已经启动了。init接下来会打开6个终端，以便用户登录系统。通过按Alt+Fn(n对应1-6)可以在这6个终端中切换。在inittab中的以下6行就是定义了6个终端：

　　1:2345:respawn:/sbin/mingetty tty1
　　2:2345:respawn:/sbin/mingetty tty2
　　3:2345:respawn:/sbin/mingetty tty3
　　4:2345:respawn:/sbin/mingetty tty4
　　5:2345:respawn:/sbin/mingetty tty5
　　6:2345:respawn:/sbin/mingetty tty6

　　从上面可以看出在2、3、4、5的运行级别中都将以respawn方式运行mingetty程序，mingetty程序能打开终端、设置模式。同时它会显示一个文本登录界面，这个界面就是我们经常看到的登录界面，在这个登录界面中会提示用户输入用户名，而用户输入的用户将作为参数传给login程序来验证用户的身份。

　　第六部分：登录系统，启动完成

　　对于运行级别为5的图形方式用户来说，他们的登录是通过一个图形化的登录界面。登录成功后可以直接进入KDE、Gnome等窗口管理器。而本文主要讲的还是文本方式登录的情况：

　　当我们看到mingetty的登录界面时，我们就可以输入用户名和密码来登录系统了。

　　Linux的账号验证程序是login，login会接收mingetty传来的用户名作为用户名参数。然后login会对用户名进行分析：如果用户名不是root，且存在/etc/nologin文件，login将输出nologin文件的内容，然后退出。这通常用来系统维护时防止非root用户登录。只有/etc/securetty中登记了的终端才允许root用户登录，如果不存在这个文件，则root可以在任何终端上登录。/etc/usertty文件用于对用户作出附加访问限制，如果不存在这个文件，则没有其他限制。

　　在分析完用户名后，login将搜索/etc/passwd以及/etc/shadow来验证密码以及设置账户的其它信息，比如：主目录是什么、使用何种shell。如果没有指定主目录，将默认为根目录；如果没有指定shell，将默认为/bin/bash。

　　login程序成功后，会向对应的终端在输出最近一次登录的信息(在/var/log/lastlog中有记录)，并检查用户是否有新邮件(在/usr/spool/mail/的对应用户名目录下)。然后开始设置各种环境变量：对于bash来说，系统首先寻找/etc/profile脚本文件，并执行它；然后如果用户的主目录中存在.bash_profile文件，就执行它，在这些文件中又可能调用了其它配置文件，所有的配置文件执行后后，各种环境变量也设好了，这时会出现大家熟悉的命令行提示符，到此整个启动过程就结束了。

1. Bootloader及内核解压
Bootloader将内核加载到内存中，设定一些寄存器，然后将控制权交由内核，该过程中，关闭MMU功能。通常，内核都是以压缩的方式存放，如zImage，这里有两种解压方法：
使用内核自解压程序。
arch/arm/boot/compressed/head.S或arch/arm/boot/compressed/head-xxxxx.S
arch/arm/boot/compressed/misc.c
在Bootloader中增加解压功能。
使用该方法时内核不需要带有自解压功能，而使用Bootloader中的解压程序代替内核自解压程序。其工作过程与内核自解压过程相似：Bootloader把压缩方式的内核解压到内存中，然后跳转到内核入口处开始执行。

2. 几种内核启动方式介绍
XIP (EXECUTE IN PLACE) 是指直接从存放代码的位置上启动运行。
2.1 非压缩，非XIP
非XIP方式是指在运行之前需对代码进行重定位。该类型的内核以非压缩方式存放在Flash中，启动时由Bootloader加载到内存后运行。
2.2 非压缩，XIP
该类型的内核以非压缩格式存放在ROM/Flash中，不需要加载到内存就能运行，Bootloader直接跳转到其存放地址执行。Data段复制和BSS段清零的工作由内核自己完成。这种启动方式常用于内存空间有限的系统中，另外，程序在ROM/Flash中运行的速度相对较慢。
2.3 RAM自解压
压缩格式的内核由开头一段自解压代码和压缩内核数据组成，由于以压缩格式存放，内核只能以非XIP方式运行。RAM自解压过程如下：压缩内核存放于ROM/Flash中，Bootloader启动后加载到内存中的临时空间，然后跳转到压缩内核入口地址执行自解压代码，内核被解压到最终的目的地址然后运行。压缩内核所占据的临时空间随后被Linux回收利用。这种方式的内核在嵌入式产品中较为常见。
2.4 ROM自解压
解压缩代码也能够以XIP的方式在ROM/Flash中运行。ROM自解压过程如下：压缩内核存放在ROM/Flash中，不需要加载到内存就能运行，Bootloader直接跳转到其存放地址执行其自解压代码，将压缩内核解压到最终的目的地址并运行。ROM自解压方式存放的内核解压缩速度慢，而且也不能节省内存空间。

3. 内核启动地址的确定
内核自解压方式
Head.S/head-XXX.S获得内核解压后首地址ZREALADDR，然后解压内核，并把解压后的内核放在ZREALADDR的位置上，最后跳转到ZREALADDR地址上，开始真正的内核启动。

arch/armnommu/boot/Makefile，定义ZRELADDR和 ZTEXTADDR。ZTEXTADDR是自解压代码的起始地址，如果从内存启动内核，设置为0即可，如果从Rom/Flash启动，则设置ZTEXTADDR为相应的值。ZRELADDR是内核解压缩后的执行地址。
arch/armnommu/boot/compressed/vmlinux.ld,引用LOAD_ADDR和TEXT_START。
arch/armnommu/boot/compressed/Makefile, 通过如下一行：
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/LOAD_ADDR/$(ZRELADDR)/;
使得TEXT_START = ZTEXTADDR，LOAD_ADDR = ZRELADDR。

说明：
执行完decompress_kernel函数后,代码跳回head.S/head-XXX.S中,检查解压缩之后的kernel起始地址是否紧挨着kernel image。如果是,beq call_kernel,执行解压后的kernel。如果解压缩之后的kernel起始地址不是紧挨着kernel image,则执行relocate,将其拷贝到紧接着kernel image的地方,然后跳转,执行解压后的kernel。

Bootloader解压方式
Bootloader把解压后的内核放在内存的TEXTADDR位置上，然后跳转到TEXTADDR位置上，开始内核启动。
arch/armnommu/Makefile，一般设置TEXTADDR为PAGE_OFF+0x8000，如定义为0x00008000, 0xC0008000等。
arch/armnommu/vmlinux.lds，引用TEXTADDR

4. arch/armnommu/kernel/head-armv.S
该文件是内核最先执行的一个文件，包括内核入口ENTRY(stext)到start_kernel间的初始化代码，主要作用是检查CPU ID，Architecture Type，初始化BSS等操作，并跳到start_kernel函数。在执行前，处理器应满足以下状态：
r0 - should be 0
r1 - unique architecture number
MMU - off
I-cache - on or off
D-cache – off

/* 部分源代码分析 */
/* 内核入口点 */
ENTRY(stext)
/* 程序状态，禁止FIQ、IRQ，设定SVC模式 */
mov r0, #F_BIT | I_BIT | MODE_SVC@ make sure svc mode
/* 置当前程序状态寄存器 */
msr cpsr_c, r0 @ and all irqs disabled
/* 判断CPU类型，查找运行的CPU ID值与Linux编译支持的ID值是否支持 */
bl __lookup_processor_type
/* 跳到__error */
teq r10, #0 @ invalid processor?
moveq r0, #'p' @ yes, error 'p'
beq __error
/* 判断体系类型，查看R1寄存器的Architecture Type值是否支持 */
bl __lookup_architecture_type
/* 不支持，跳到出错 */
teq r7, #0 @ invalid architecture?
moveq r0, #'a' @ yes, error 'a'
beq __error
/* 创建核心页表 */
bl __create_page_tables
adr lr, __ret @ return address
add pc, r10, #12 @ initialise processor
/* 跳转到start_kernel函数 */
b start_kernel

__lookup_processor_type这个函数根据芯片的ID从proc.info获取proc_info_list结构，proc_info_list结构定义在include/asm-armnommu/proginfo.h中，该结构的数据定义在arch/armnommu/mm/proc-arm*.S文件中，ARM7TDMI系列芯片的proc_info_list数据定义在arch/armnommu/mm/proc-arm6,7.S文件中。函数__lookup_architecture_type从arch.info获取machine_desc结构，machine_desc结构定义在include/asm-armnommu/mach/arch.h中，针对不同arch的数据定义在arch/armnommu/mach-*/arch.c文件中。
在这里如果知道processor_type和architecture_type,可以直接对相应寄存器进行赋值。

5. start_kernel()函数分析
下面对start_kernel()函数及其相关函数进行分析。
5.1 lock_kernel()
/* Getting the big kernel lock.
* This cannot happen asynchronously,
* so we only need to worry about other
* CPU's.
*/
extern __inline__ void lock_kernel(void)
{
if (!++current->lock_depth)
spin_lock(&kernel_flag);
}
kernel_flag是一个内核大自旋锁，所有进程都通过这个大锁来实现向内核态的迁移。只有获得这个大自旋锁的处理器可以进入内核，如中断处理程序等。在任何一对lock_kernel／unlock_kernel函数里至多可以有一个程序占用CPU。 进程的lock_depth成员初始化为-1，在kerenl/fork.c文件中设置。在它小于0时（恒为 -1），进程不拥有内核锁；当大于或等于0时，进程得到内核锁。

5.2 setup_arch()
setup_arch()函数做体系相关的初始化工作，函数的定义在arch/armnommu/kernel/setup.c文件中，主要涉及下列主要函数及代码。
5.2.1 setup_processor()
该函数主要通过
for (list = &__proc_info_begin; list < &__proc_info_end ; list++)
if ((processor_id & list->cpu_mask) == list->cpu_val)
break;
这样一个循环来在.proc.info段中寻找匹配的processor_id，processor_id在head_armv.S文件
中设置。

5.2.2 setup_architecture(machine_arch_type)
该函数获得体系结构的信息，返回mach-xxx/arch.c 文件中定义的machine结构体的指针，包含以下内容：
MACHINE_START (xxx, “xxx”)
MAINTAINER ("xxx")
BOOT_MEM (xxx, xxx, xxx)
FIXUP (xxx)
MAPIO (xxx)
INITIRQ (xxx)
MACHINE_END

5.2.3内存设置代码
if (meminfo.nr_banks == 0)
{
meminfo.nr_banks = 1;
meminfo.bank[0].start = PHYS_OFFSET;
meminfo.bank[0].size = MEM_SIZE;
}
meminfo结构表明内存情况，是对物理内存结构meminfo的默认初始化。 nr_banks指定内存块的数量，bank指定每块内存的范围，PHYS _OFFSET指定某块内存块的开始地址，MEM_SIZE指定某块内存块长度。PHYS _OFFSET和MEM_SIZE都定义在include/asm-armnommu/arch-XXX/memory.h文件中，其中PHYS _OFFSET是内存的开始地址，MEM_SIZE就是内存的结束地址。这个结构在接下来内存的初始化代码中起重要作用。

5.2.4 内核内存空间管理
init_mm.start_code = (unsigned long) &_text; 内核代码段开始
init_mm.end_code = (unsigned long) &_etext; 内核代码段结束
init_mm.end_data = (unsigned long) &_edata; 内核数据段开始
init_mm.brk = (unsigned long) &_end; 内核数据段结束

每一个任务都有一个mm_struct结构管理其内存空间，init_mm 是内核的mm_struct。其中设置成员变量* mmap指向自己， 意味着内核只有一个内存管理结构，设置 pgd=swapper_pg_dir，
swapper_pg_dir是内核的页目录，ARM体系结构的内核页目录大小定义为16k。init_mm定义了整个内核的内存空间，内核线程属于内核代码，同样使用内核空间，其访问内存空间的权限与内核一样。

5.2.5 内存结构初始化
bootmem_init(&meminfo)函数根据meminfo进行内存结构初始化。bootmem_init(&meminfo)函数中调用reserve_node_zero(bootmap_pfn, bootmap_pages) 函数，这个函数的作用是保留一部分内存使之不能被动态分配。这些内存块包括：
reserve_bootmem_node(pgdat, __pa(&_stext), &_end - &_stext); /*内核所占用地址空间*/
reserve_bootmem_node(pgdat, bootmap_pfn<<PAGE_SHIFT, bootmap_pages<<PAGE_SHIFT)
/*bootmem结构所占用地址空间*/

5.2.6 paging_init(&meminfo, mdesc)
创建内核页表，映射所有物理内存和IO空间，对于不同的处理器，该函数差别比较大。下面简单描述一下ARM体系结构的存储系统及MMU相关的概念。
在ARM存储系统中，使用内存管理单元(MMU)实现虚拟地址到实际物理地址的映射。利用MMU，可把SDRAM的地址完全映射到0x0起始的一片连续地址空间，而把原来占据这片空间的FLASH或者ROM映射到其他不相冲突的存储空间位置。例如，FLASH的地址从0x0000 0000～0x00FFFFFF，而SDRAM的地址范围是0x3000 0000～0x3lFFFFFF，则可把SDRAM地址映射为0x0000 0000～0xlFFFFFF，而FLASH的地址可以映射到0x9000 0000～0x90FFFFFF(此处地址空间为空闲，未被占用)。映射完成后，如果处理器发生异常，假设依然为IRQ中断，PC指针指向0xl8处的地址，而这个时候PC实际上是从位于物理地址的0x3000 0018处读取指令。通过MMU的映射，则可实现程序完全运行在SDRAM之中。在实际的应用中．可能会把两片不连续的物理地址空间分配给SDRAM。而在操作系统中，习惯于把SDRAM的空间连续起来，方便内存管理，且应用程序申请大块的内存时，操作系统内核也可方便地分配。通过MMU可实现不连续的物理地址空间映射为连续的虚拟地址空间。操作系统内核或者一些比较关键的代码，一般是不希望被用户应用程序访问。通过MMU可以控制地址空间的访问权限，从而保护这些代码不被破坏。
MMU的实现过程，实际上就是一个查表映射的过程。建立页表是实现MMU功能不可缺少的一步。页表位于系统的内存中，页表的每一项对应于一个虚拟地址到物理地址的映射。每一项的长度即是一个字的长度(在ARM中，一个字的长度被定义为4Bytes)。页表项除完成虚拟地址到物理地址的映射功能之外，还定义了访问权限和缓冲特性等。
MMU的映射分为两种，一级页表的变换和二级页表变换。两者的不同之处就是实现的变换地址空间大小不同。一级页表变换支持1 M大小的存储空间的映射，而二级可以支持64 kB，4 kB和1 kB大小地址空间的映射。

动态表(页表)的大小＝表项数＊每个表项所需的位数，即为整个内存空间建立索引表时，需要多大空间存放索引表本身。
表项数＝虚拟地址空间/每页大小
每个表项所需的位数＝Log(实际页表数)+适当控制位数
实际页表数 ＝物理地址空间/每页大小

下面分析paging_init（）函数的代码。
在paging_init中分配起始页（即第0页）地址：
zero_page = 0xCXXXXXXX

memtable_init(mi); 如果当前微处理器带有MMU，则为系统内存创建页表；如果当前微处理器不支持MMU，比如ARM7TDMI上移植uCLinux操作系统时，则不需要此类步骤。可以通过如下一个宏定义实现灵活控制，对于带有MMU的微处理器而言，memtable_init(mi)是paging_init()中最重要的函数。
#ifndef CONFIG_UCLINUX
/* initialise the page tables. */
memtable_init(mi);
……（此处省略若干代码）
free_area_init_node(node, pgdat, 0, zone_size,
bdata->node_boot_start, zhole_size);
}
#else /* 针对不带MMU微处理器 */
{
/*****************************************************/
定义物理内存区域管理
/*****************************************************/
unsigned long zone_size[MAX_NR_ZONES] = {0,0,0};

zone_size[ZONE_DMA] = 0;
zone_size[ZONE_NORMAL] = (END_MEM - PAGE_OFFSET) >> PAGE_SHIFT;

free_area_init_node(0, NULL, NULL, zone_size, PAGE_OFFSET, NULL);
}
#endif

uCLinux与其它嵌入式Linux最大的区别就是MMU管理这一块，从上面代码就明显可以看到这点区别。下面继续讨论针对带MMU的微处理器的内存管理。
void __init memtable_init(struct meminfo *mi)
{
struct map_desc *init_maps, *p, *q;
unsigned long address = 0;
int i;
init_maps = p = alloc_bootmem_low_pages(PAGE_SIZE);
/*******************************************************/
其中map_desc定义为：
struct map_desc {
unsigned long virtual;
unsigned long physical;
unsigned long length;
int domain:4, // 页表的domain
prot_read:1, // 读保护标志
prot_write:1, // 写保护标志
cacheable:1, // 是否使用cache
bufferable:1, // 是否使用write buffer
last:1; //空
};init_maps /* map_desc是区段及其属性的定义 */

下面代码对meminfo的区段进行遍历，在嵌入式系统中列举所有可映射的内存，例如32M SDRAM, 4M FLASH等，用meminfo记录这些内存区段。同时填写init_maps 中的各项内容。meminfo结构如下：
struct meminfo {
int nr_banks;
unsigned long end;
struct {
unsigned long start;
unsigned long size;
int node;
} bank[NR_BANKS];
};
/********************************************************/

for (i = 0; i < mi->nr_banks; i++)
{
if (mi->bank.size == 0)
continue;

p->physical = mi->bank.start;
p->virtual = __phys_to_virt(p->physical);
p->length = mi->bank.size;
p->domain = DOMAIN_KERNEL;
p->prot_read = 0;
p->prot_write = 1;
p->cacheable = 1; //使用Cache
p->bufferable = 1; //使用write buffer
p ++; //下一个区段
}

/* 如果系统存在FLASH,执行以下代码 */
#ifdef FLUSH_BASE
p->physical = FLUSH_BASE_PHYS;
p->virtual = FLUSH_BASE;
p->length = PGDIR_SIZE;
p->domain = DOMAIN_KERNEL;
p->prot_read = 1;
p->prot_write = 0;
p->cacheable = 1;
p->bufferable = 1;

p ++;
#endif

/***********************************************************/
接下来的代码是逐个区段建立页表
/***********************************************************/
q = init_maps;
do {
if (address < q->virtual || q == p) {

/*******************************************************************************/
由于内核空间是从某个地址开始，如0xC0000000，所以0xC000 0000 以前的页表项全部清空
clear_mapping在mm-armv.c中定义，其中clear_mapping()是个宏，根据处理器的不同，可以被展开为如下代码
cpu_XXX_set_pmd(((pmd_t *)(((&init_mm )->pgd+ (( virt) >> 20 )))),((pmd_t){( 0 )}));
其中init_mm为内核的mm_struct，pgd指向 swapper_pg_dir，在arch/arm/kernel/init_task.c中定义。cpu_XXX_set_pmd定义在proc_armXXX.S文件中，参见ENTRY(cpu_XXX_set_pmd) 处代码。
/*********************************************************************************/
clear_mapping(address);

/* 每个表项增加1M */
address += PGDIR_SIZE;
} else {

/* 构建内存页表 */
create_mapping(q);

address = q->virtual + q->length;
address = (address + PGDIR_SIZE - 1) & PGDIR_MASK;

q ++;
}
} while (address != 0);

/ * create_mapping函数也在mm-armv.c中定义 */
static void __init create_mapping(struct map_desc *md)
{
unsigned long virt, length;
int prot_sect, prot_pte;
long off;

/*******************************************************************************/
大部分应用中均采用1级section模式的地址映射，一个section的大小为1M，也就是说从逻辑地址到物理地址的转变是这样的一个过程：
一个32位的地址，高12位决定了该地址在页表中的index，这个index的内容决定了该逻辑section对应的物理section； 低20位决定了该地址在section中的偏移（index）。例如：从0x0～0xFFFFFFFF的地址空间总共可以分成0x1000（4K）个section（每个section大小为1M），页表中每项的大小为32个bit，因此页表的大小为0x4000（16K）。

每个页表项的内容如下:
bit: 31 20 19 12 11 10 9 8 5 4 3 2 1 0
content: Section对应的物理地址 NULL AP 0 Domain 1 C B 1 0
最低两位（10）是section分页的标识。
AP：Access Permission，区分只读、读写、SVC＆其它模式。
Domain：每个section都属于某个Domain，每个Domain的属性由寄存器控制。一般都只要包含两个Domain，一个可访问地址空间； 另一个不可访问地址空间。
C、B：这两位决定了该section的cache＆write buffer属性，这与该段的用途(RO or RW)有密切关系。不同的用途要做不同的设置。

C B 具体含义
0 0 无cache，无写缓冲，任何对memory的读写都反映到总线上。对 memory 的操作过程中CPU需要等待。
0 1 无cache，有写缓冲，读操作直接反映到总线上。写操作CPU将数据写入到写缓冲后继续运行，由写缓冲进行写回操作。
1 0 有cache，写通模式，读操作首先考虑cache hit；写操作时直接将数据写入写缓冲，如果同时出现cache hit，那么也更新cache。
1 1 有cache，写回模式，读操作首先考虑cache hit；写操作也首先考虑cache hit。

由于ARM中section表项的权限位和page表项的位置不同， 以下代码根据struct map_desc 中的保护标志，分别计算页表项中的AP, Domain和CB标志位。
/*******************************************************************************/

prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
(md->prot_read ? L_PTE_USER : 0) |
(md->prot_write ? L_PTE_WRITE : 0) |
(md->cacheable ? L_PTE_CACHEABLE : 0) |
(md->bufferable ? L_PTE_BUFFERABLE : 0);

prot_sect = PMD_TYPE_SECT | PMD_DOMAIN(md->domain) |
(md->prot_read ? PMD_SECT_AP_READ : 0) |
(md->prot_write ? PMD_SECT_AP_WRITE : 0) |
(md->cacheable ? PMD_SECT_CACHEABLE : 0) |
(md->bufferable ? PMD_SECT_BUFFERABLE : 0);

/********************************************************************/
设置虚拟地址，偏移地址和内存length
/********************************************************************/
virt = md->virtual;
off = md->physical - virt;
length = md->length;


/********************************************************************/
建立虚拟地址到物理地址的映射
/********************************************************************/
while ((virt & 0xfffff || (virt + off) & 0xfffff) && length >= PAGE_SIZE) {
alloc_init_page(virt, virt + off, md->domain, prot_pte);

virt += PAGE_SIZE;
length -= PAGE_SIZE;
}

while (length >= PGDIR_SIZE) {
alloc_init_section(virt, virt + off, prot_sect);

virt += PGDIR_SIZE;
length -= PGDIR_SIZE;
}

while (length >= PAGE_SIZE) {
alloc_init_page(virt, virt + off, md->domain, prot_pte);

virt += PAGE_SIZE;
length -= PAGE_SIZE;
}
/*************************************************************************/
create_mapping的作用是设置虚地址virt 到物理地址virt + off_set的映射页目录和页表。
/*************************************************************************/

/* 映射中断向量表区域 */
init_maps->physical = virt_to_phys(init_maps);
init_maps->virtual = vectors_base();
init_maps->length = PAGE_SIZE;
init_maps->domain = DOMAIN_USER;
init_maps->prot_read = 0;
init_maps->prot_write = 0;
init_maps->cacheable = 1;
init_maps->bufferable = 0;

create_mapping(init_maps);

中断向量表的虚地址init_maps，是用alloc_bootmem_low_pages分配的，通常是在PAGE_OFF+0x8000前面的某一页， vectors_base()是个宏，ARM规定中断向量表的地址只能是0或0xFFFF0000，所以上述代码映射一页到0或0xFFFF0000，中断处理程序中的部分代码也被拷贝到这一页中。

5.3 parse_options()
分析由内核引导程序发送给内核的启动选项，在初始化过程中按照某些选项运行，并将剩余部分传送给init进程。这些选项可能已经存储在配置文件中，也可能是由用户在系统启动时敲入的。但内核并不关心这些，这些细节都是内核引导程序关注的内容，嵌入式系统更是如此。

5.4 trap_init()
这个函数用来做体系相关的中断处理的初始化，在该函数中调用__trap_init((void *)vectors_base())函数将exception vector设置到vectors_base开始的地址上。__trap_init函数位于entry-armv.S文件中，对于ARM处理器，共有复位、未定义指令、SWI、预取终止、数据终止、IRQ和FIQ几种方式。SWI主要用来实现系统调用，而产生了IRQ之后，通过exception vector进入中断处理过程，执行do_IRQ函数。
armnommu的trap_init（）函数在arch/armnommu/kernel/traps.c文件中。vectors_base是写中断向量的开始地址，在include/asm-armnommu/proc-armv/system.h文件中设置，地址为0或0XFFFF0000。

ENTRY(__trap_init)
stmfd sp!, {r4 - r6, lr}

mrs r1, cpsr @ code from 2.0.38
bic r1, r1, #MODE_MASK @ clear mode bits /* 设置svc模式，disable IRQ,FIQ */
orr r1, r1, #I_BIT|F_BIT|MODE_SVC @ set SVC mode, disable IRQ,FIQ
msr cpsr, r1

adr r1, .LCvectors @ set up the vectors
ldmia r1, {r1, r2, r3, r4, r5, r6, ip, lr}
stmia r0, {r1, r2, r3, r4, r5, r6, ip, lr} /* 拷贝异常向量 */

add r2, r0, #0x200
adr r0, __stubs_start @ copy stubs to 0x200
adr r1, __stubs_end
1: ldr r3, [r0], #4
str r3, [r2], #4
cmp r0, r1
blt 1b
LOADREGS(fd, sp!, {r4 - r6, pc})
__stubs_start到__stubs_end的地址中包含了异常处理的代码，因此拷贝到vectors_base+0x200的位置上。

5.5 init_IRQ()
void __init init_IRQ(void)
{
extern void init_dma(void);
int irq;

for (irq = 0; irq < NR_IRQS; irq++) {
irq_desc[irq].probe_ok = 0;
irq_desc[irq].valid = 0;
irq_desc[irq].noautoenable = 0;
irq_desc[irq].mask_ack = dummy_mask_unmask_irq;
irq_desc[irq].mask = dummy_mask_unmask_irq;
irq_desc[irq].unmask = dummy_mask_unmask_irq;
}
CSR_WRITE(AIC_MDCR, 0x7FFFE); /* disable all interrupts */
CSR_WRITE(CAHCNF,0x0);/*Close Cache*/
CSR_WRITE(CAHCON,0x87);/*Flush Cache*/
while(CSR_READ(CAHCON)!=0);
CSR_WRITE(CAHCNF,0x7);/*Open Cache*/

init_arch_irq();
init_dma();
}
这个函数用来做体系相关的irq处理的初始化，irq_desc数组是用来描述IRQ的请求队列，每一个中断号分配一个irq_desc结构，组成了一个数组。NR_IRQS代表中断数目，这里只是对中断结构irq_desc进行了初始化。在默认的初始化完成后调用初始化函数init_arch_irq，先执行arch/armnommu/kernel/irq-arch.c文件中的函数genarch_init_irq()，然后就执行include/asm-armnommu/arch-xxxx/irq.h中的inline函数irq_init_irq，在这里对irq_desc进行了实质的初始化。其中mask用阻塞中断；unmask用来取消阻塞；mask_ack的作用是阻塞中断，同时还回应ack给硬件表示这个中断已经被处理了，否则硬件将再次发生同一个中断。这里，不是所有硬件需要这个ack回应，所以很多时候mask_ack与mask用的是同一个函数。
接下来执行init_dma（）函数，如果不支持DMA，可以设置include/asm-armnommu/arch-xxxx/dma.h中的MAX_DMA_CHANNELS为0，这样在arch/armnommu/kernel/dma.c文件中会根据这个定义使用不同的函数。

5.6 sched_init()
初始化系统调度进程，主要对定时器机制和时钟中断的Bottom Half的初始化函数进行设置。与时间相关的初始化过程主要有两步：（1）调用init_timervecs()函数初始化内核定时器机制；（2）调用init_bh()函数将BH向量TIMER_BH、TQUEUE_BH和IMMEDIATE_BH所对应的BH函数分别设置成timer_bh()、tqueue_bh()和immediate_bh()函数

5.7 softirq_init()
内核的软中断机制初始化函数。调用tasklet_init初始化tasklet_struct结构，软中断的个数为32个。用于bh的tasklet_struct结构调用tasklet_init()以后，它们的函数指针func全都指向bh_action()。bh_action就是tasklet实现bh机制的代码，但此时具体的bh函数还没有指定。

HI_SOFTIRQ用于实现bottom half，TASKLET_SOFTIRQ用于公共的tasklet。

open_softirq(TASKLET_SOFTIRQ, tasklet_action, NULL); /* 初始化公共的tasklet_struct要用到的软中断 */
open_softirq(HI_SOFTIRQ, tasklet_hi_action, NULL); /* 初始化tasklet_struct实现的bottom half调用 */

这里顺便讲一下软中断的执行函数do_softirq()。
软中断服务不允许在一个硬中断服务程序内部执行，也不允许在一个软中断服务程序内部执行，所以通过in_interrupt()加以检查。h->action 就是串行化执行软中断，当bh 的tasklet_struct 链入的时候，就能在这里执行，在bh里重新锁定了所有CPU，导致一个时间只有一个CPU可以执行bh 函数，但是do_softirq()是可以在多CPU 上同时执行的。而每个tasklet_struct在一个时间上是不会出现在两个CPU上的。另外，只有当Linux初始化完成开启中断后，中断系统才可以开始工作。

5.8 time_init()
这个函数用来做体系相关的timer的初始化，armnommu的在arch/armnommu/kernel/time.c。这里调用了在include/asm-armnommu/arch-xxxx/time.h中的inline函数setup_timer，setup_timer（）函数的设计与硬件设计紧密相关，主要是根据硬件设计情况设置时钟中断号和时钟频率等。
void __inline__ setup_timer (void)
{
/*----- disable timer -----*/
CSR_WRITE(TCR0, xxx);

CSR_WRITE (AIC_SCR7, xxx); /* setting priority level to high */
/* timer 0: 100 ticks/sec */
CSR_WRITE(TICR0, xxx);

timer_irq.handler = xxxxxx_timer_interrupt;
setup_arm_irq(IRQ_TIMER, &timer_irq); /* IRQ_TIMER is the interrupt number */

INT_ENABLE(IRQ_TIMER);
/* Clear interrupt flag */
CSR_WRITE(TISR, xxx);

/* enable timer */
CSR_WRITE(TCR0, xxx);
}

5.9 console_init()
控制台初始化。控制台也是一种驱动程序，由于其特殊性，提前到该处完成初始化，主要是为了提前看到输出信息，据此判断内核运行情况。很多嵌入式Linux操作系统由于没有在/dev目录下正确配置console设备，造成启动时发生诸如unable to open an initial console的错误。

/*******************************************************************************/
init_modules()函数到smp_init()函数之间的代码一般不需要作修改，
如果平台具有特殊性，也只需对相关函数进行必要修改。
这里简单注明了一下各个函数的功能，以便了解。
/*******************************************************************************/
5.10 init_modules()
模块初始化。如果编译内核时使能该选项，则内核支持模块化加载/卸载功能

5.11 kmem_cache_init()
内核Cache初始化。

5.12 sti()
使能中断，这里开始，中断系统开始正常工作。

5.13 calibrate_delay()
近似计算BogoMIPS数字的内核函数。作为第一次估算，calibrate_delay计算出在每一秒内执行多少次__delay循环，也就是每个定时器滴答（timer tick）―百分之一秒内延时循环可以执行多少次。这种计算只是一种估算，结果并不能精确到纳秒，但这个数字供内核使用已经足够精确了。
BogoMIPS的数字由内核计算并在系统初始化的时候打印。它近似的给出了每秒钟CPU可以执行一个短延迟循环的次数。在内核中，这个结果主要用于需要等待非常短周期的设备驱动程序――例如，等待几微秒并查看设备的某些信息是否已经可用。
计算一个定时器滴答内可以执行多少次循环需要在滴答开始时就开始计数，或者应该尽可能与它接近。全局变量jiffies中存储了从内核开始保持跟踪时间开始到现在已经经过的定时器滴答数， jiffies保持异步更新，在一个中断内——每秒一百次，内核暂时挂起正在处理的内容，更新变量，然后继续刚才的工作。

5.14 mem_init()
内存初始化。本函数通过内存碎片的重组等方法标记当前剩余内存, 设置内存上下界和页表项初始值。

5.15 kmem_cache_sizes_init()
内核内存管理器的初始化，也就是初始化cache和SLAB分配机制。

5.16 pgtable_cache_init()
页表cache初始化。

5.17 fork_init()
这里根据硬件的内存情况，如果计算出的max_threads数量太大，可以自行定义。

5.18 proc_caches_init();
为proc文件系统创建高速缓冲

5.19 vfs_caches_init(num_physpages);
为VFS创建SLAB高速缓冲

5.20 buffer_init(num_physpages);
初始化buffer

5.21 page_cache_init(num_physpages);
页缓冲初始化

5.22 signals_init();
创建信号队列高速缓冲

5.23 proc_root_init();
在内存中创建包括根结点在内的所有节点

5.24 check_bugs();
检查与处理器相关的bug

5.25 smp_init();

5.26 rest_init(); 此函数调用kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL)函数。

5.26.1 kernel_thread()函数分析
这里调用了arch/armnommu/kernel/process.c中的函数kernel_thread，kernel_thread函数中通过__syscall(clone) 创建新线程。__syscall(clone)函数参见armnommu/kernel目录下的entry-common.S文件。

5.26.2 init()完成下列功能：
Init()函数通过kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL)的回调函数执行，完成下列功能。
do_basic_setup()
在该函数里，sock_init()函数进行网络相关的初始化，占用相当多的内存，如果所开发系统不支持网络功能，可以把该函数的执行注释掉。
do_initcalls()实现驱动的初始化, 这里需要与vmlinux.lds联系起来看才能明白其中奥妙。
static void __init do_initcalls(void)
{
　　initcall_t *call;

　　call = &__initcall_start;
　　do {
　　　(*call)();
　　　call++;
　　} while (call < &__initcall_end);

　　/* Make sure there is no pending stuff from the initcall sequence */
　　flush_scheduled_tasks();
}

查看 /arch/i386/vmlinux.lds，其中有一段代码
　__initcall_start = .;
　.initcall.init : { *(.initcall.init) }
　__initcall_end = .;
其含义是__initcall_start指向代码节.initcall.init的节首，而__initcall_end指向.initcall.init的节尾。

do_initcalls所作的是系统中有关驱动部分的初始化工作，那么这些函数指针数据是怎样放到了.initcall.init节呢？在include/linux/init.h文件中有如下3个定义：
1. #define __init_call　　 __attribute__ ((unused,__section__ (".initcall.init")))
__attribute__的含义就是构建一个在.initcall.init节的指向初始函数的指针。
2. #define __initcall(fn) static initcall_t __initcall_##fn __init_call = fn
##意思就是在可变参数使用宏定义的时候构建一个变量名称为所指向的函数的名称，并且在前面加上__initcall_
3. #define module_init(x) __initcall(x);
很多驱动中都有类似module_init(usb_init)的代码，通过该宏定义逐层解释存放到.initcall.int节中。

blkmem相关的修改(do_initcalls()初始化驱动时执行此代码)
在blkmem_init()函数中，调用了blk_init_queue()函数，blk_init_queue()函数调用了blk_init_free_list()函数，blk_init_free_list()函数又调用了blk_grow_request_list()函数，在这个函数中会kmem_cache_alloc出nr_requests个request结构体。
这里如果nr_requests的值太大，则将占用过多的内存，将造成硬件内存不够，因此可以根据实际情况将其替换成了较小的值，比如32、16等。

free_initmem
这个函数在arch/armnommu/mm/init.c文件中，其作用就是对init节的释放，也可以通过修改代码指定为不释放。

5.26.3 init执行过程
在内核引导结束并启动init之后，系统就转入用户态的运行，在这之后创建的一切进程，都是在用户态进行。这里先要清楚一个概念：就是init进程虽然是从内核开始的，即在前面所讲的init/main.c中的init()函数在启动后就已经是一个核心线程，但在转到执行init程序（如/sbin/init）之后，内核中的init()就变成了/sbin/init程序，状态也转变成了用户态，也就是说核心线程变成了一个普通的进程。这样一来，内核中的init函数实际上只是用户态init进程的入口，它在执行execve("/sbin/init",argv_init,envp_init)时改变成为一个普通的用户进程。这也就是exec函数的乾坤大挪移法，在exec函数调用其他程序时，当前进程被其他进程“灵魂附体”。
　　除此之外，它们的代码来源也有差别，内核中的init()函数的源代码在/init/main.c中，是内核的一部分。而/sbin/init程序的源代码是应用程序。
init程序启动之后，要完成以下任务：检查文件系统，启动各种后台服务进程，最后为每个终端和虚拟控制台启动一个getty进程供用户登录。由于所有其它用户进程都是由init派生的，因此它又是其它一切用户进程的父进程。
　　init进程启动后，按照/etc/inittab的内容进程系统设置。很多嵌入式系统用的是BusyBox的init，它与一般所使用的init不一样，会先执行/etc/init.d/rcS而非/etc/rc.d/rc.sysinit。

小结：
本想多整理一些相关资料，无奈又要开始新项目的奔波，start_kernel()函数也刚好差不多讲完了，分析的不是很深入，希望对嵌入式Linux移植的网友们有一些帮助。最后列举下面几处未整理的知识点，有兴趣的网友可作进一步探讨。
text.init和data.init说明
__init标示符在gcc编译器中指定将该函数置于内核的特定区域。在内核完成自身初始化之后，就试图释放这个特定区域。实际上，内核中存在两个这样的区域，.text.init和.data.init――第一个是代码初始化使用的，另外一个是数据初始化使用的。另外也可以看到__initfunc和__initdata标志，前者和__init类似，标志初始化专用代码，后者则标志初始化专用数据。
System.map内核符号表
irq的处理过程
Linux内核调度过程