Android系统启动流程 -- linux kernel

  第二部分：linux启动

 

一、zImage是怎样炼成的？

    zImage是linux内核编译之后产生的最终文件，它的生成过程比较复杂，这里不谈编译过程，只聊聊编译的最后阶段：

    1.  arm-linux-gnu-ld用arch/arm/kernel/vmlinux.lds、arch/arm/kernel/head.o、

arch/arm/kernel/init_task.o、各子目录下的built-in.o、lib/lib.a 、arch/arm/lib/lib.a生成顶层目录下的vmlinux （根据arch/arm/kernel/vmlinux.lds来链接 0xc0008000）

 

    2. 生成system.map, 置于顶层目录之下。

    3. arm-linux-gnu-objcopy，去掉顶层vmlinux两个段-R .note -R .comment

的调试信息，减小映像文件的大小，此时大概3M多，生成arch/arm/boot/Image。

 

4. gzip -f -9 < arch/arm/boot/compressed/../Image > arch/arm/boot/compressed/piggy.gz，读入arch/arm/boot/Image的内容，以最大压缩比进行压缩，生成arch/arm/boot/compressed/目录下的piggy.gz。

 

5. arm-linux-gnu-gcc，在arch/arm/boot/compressed/piggy.S文件中是直接引入piggy.gz的内容（piggy.gz其实已经是二进制数据了），然后生成arch/arm/boot/compressed/piggy.o文件。下面是piggy.S的内容

其中所选择的行就是加入了piggy.gz的内容，通过编译生成piggy.o文件，以备后面接下来的ld链接。

 

6. arm-linux-gnu-ld，在arch/arm/boot/compressed/piggy.o的基础上，加入重定位地址和参数地址的同时，加入解压缩的代码（arch/arm/boot/compressed/head.o、misc.o）,最后生成arch/arm/boot/compressed目录的vmlinux，此时在解压缩代码中还含有调试信息（根据arch/arm/boot/compressed/vmlinux.lds来链接 0x0）vmlinux.lds开始处。

注意到了27行的吗？*(.piggydata)就表示需要将piggydata这个段放在这个位置，而piggydata这个段放的是什么呢？往后翻翻，看看第五步的图片，呵呵，其实就是将按最大压缩比压缩之后的Image，压缩之后叫piggy.gz中的二进制数据。

 

    7. arm-linux-gnu-objcopy，去掉解压缩代码中的调试信息段，最后生成arch/arm/boot/目录下的zImage。

   

8. /bin/sh

/home/farsight/Resources/kernel/linux-2.6.14/scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x30008000 -e 0x30008000 -n 'Linux-2.6.14' -d arch/arm/boot/zImage arch/arm/boot/uImage

调用mkimage在arch/arm/boot/zImage的基础上加入64字节的uImage头，和入口地址，装载地址， 最终生成arch/arm/boot/目录下的uImage文件。

   

   

    实际上zImage是经过了高压缩之后在和解压缩程序合并在一起生成的。知道了这些之后，我们就可以给linux的启动大致分成3段：zImage解压缩、kernel的汇编启动阶段、kernel的c启动阶段。

    前两个阶段因为都是汇编写成的，代码读起来晦涩难懂，内存分布复杂，涉及MMU、解压缩等众多知识。如果有对这部分感兴趣的，可以自行分析，遇到问题可以上网查资料或者找我，这里就不详细分析了。下面是第二阶段汇编启动的主线，可以了解下：

1. 确定 processor type

    2. 确定 machine type

    3. 手动创建页表 

    4. 调用平台特定的cpu setup函数,设置中断地址，刷新Cache，开启Cache

                         (在struct proc_info_list中,in proc-arm920.S)

    5. 开启mmu I、D cache ，设置cp15的控制寄存器，设置TTB寄存器为0x30004000

    6. 切换数据（根据需要赋值数据段，清bss段，保存processor ID 和 machine type

        和 cp15的控制寄存器值）

7. 最终跳转到start_kernel   

(在__switch_data的结束的时候,调用了 b start_kernel)

 

二、linux的c启动阶段

    经过解压缩和汇编启动两个阶段，将会进入init/Main.c中的start_kernel()函数去继续执行。(2.6.1x、2.6.2x和2.6.3x之间的差异比较大，下面的分析基于2.6.14)

    1. printk(linux_banner)打印内核的一些信息，版本，作者，编译器版本，日期等信

息。

 

    2. 接下来执行是一个及其重要的函数setup_arch(),主要做一些板级初始化，cpu初始

化，tag参数解析，u-boot传递的cmdline解析，建立mmu工作页表(memtable_init)，初始化内存布局，调用mmap_io建立GPIO,IRQ,MEMCTRL,UART，及其他外设的静态映射表，对时钟,定时器，uart进行初始化, cpu_init():{打印一些关于cpu的信息，比如cpu id，cache 大小等。另外重要的是设置了IRQ、ABT、UND三种模式的stack空间，分别都是12个字节。最后将系统切换到svc模式}。

 

3. sched_init():初始化每个处理器的可运行队列，设置系统初始化进程即0号进程。

 

4. 建立系统内存页区(zone)链表  build_all_zonelists()。

 

5.printk(KERN_NOTICE "Kernel command line: %s\n", saved_command_line);打印出从uboot传递过来的command_line字符串，在setup_arch函数中获得的。

 

6. parse_early_param()，这里分析的是系统能够辨别的一些早期参数（这个函数甚至可以去掉，__setup的形式的参数），而且在分析的时候并不是以setup_arch（&command_line）传出来的command_line为基础，而是以最原生态的saved_command_line为基础的。

 

7. parse_args("Booting kernel", command_line, __start___param,

                __stop___param - __start___param,

                &unknown_bootoption);

    对于比较新的版本真正起作用的函数，与parse_early_param()相比，此处对解析列表的处理范围加大了，解析列表中除了包括系统以setup定义的启动参数，还包括模块中定义的param参数以及系统不能辨别的参数。

    __start___param是param参数的起始地址，在System.map文件中能看到

    __stop___param - __start___param是参数个数

    unknown_bootoption是对应与启动参数不是param的相应处理函数（查看parse_one()就知道怎么回事）。

 

8. 在前面的setup_arch-àpaging_init-à memtable_init函数中为系统创建页表的时候，中断向量表的虚地址init_maps,是用alloc_bootmem_low_pages分配的，ARM规定中断向量表的地址只能是0或0xFFFF0000，所以该函数里有部分代码的作用就是映射一个物理页到0或0xFFFF0000。

trap_init函数做了以下的工作：把放在.Lcvectors处的系统8个意外入口跳转指令搬到高端中断向量0xffff0000处，再将__stubs_start到__stubs_end之间的各种意外初始化代码搬到0xffff0200处，等。

 

9. init_IRQ()

    初始化系统中所有的中断描述结构数组：irq_desc[NR_IRQS]。接着执行init_arch_irq函数，该函数是在setup_arch函数最后初始化的一个全局函数指针，指向了smdk2410_init_irq函数（in mach-smdk2410.c）,实际上是调用了s3c24xx_init_irq函数。在该函数中，首先清除所有的中断未决标志，之后就初始化中断的触发方式和屏蔽位，还有中断句柄初始化，这里不是最终用户的中断函数，而是do_level_IRQ或者do_edge_IRQ函数，在这两个函数中都使用过__do_irq函数来找到真正最终驱动程序注册在系统中的中断处理函数。

 

10. softirq_init():内核的软中断机制初始化函数。

 

12.      console_init():

初始化系统的控制台结构，该函数执行后调用printk函数将log_buf中所有符合打印级别的系统信息打印到控制台上。

 

13. profile_init()函数

/* 对系统剖析做相关初始化， 系统剖析用于系统调用*/

//profile是用来对系统剖析的，在系统调试的时候有用

//需要打开内核选项，并且在bootargs中有profile这一项才能开启这个功能/*

    profile只是内核的一个调试性能的工具，这个可以通过menuconfig中profiling support打开。

   

14.      vfs_caches_init()

该函数主要完成的是文件系统相关的初始化，cache、inode等高速缓存的建

立，在mnt_init()函数中有注册并初始化sysfs、rootfs文件系统，这里只是在内存中建立他们的架构，创建了超级块，并没有真正挂载上去。关于这个rootfs需要说明的是，这个文件系统生命期更加短暂的，为什么？之前说的ramdisk大家是否还记得，ramdisk即将在后面释放到内存空间，来代替这里的rootfs出现在根目录之下，而这个rootfs则退居二线，隐藏在一个二级目录中。本来在非android的系统上，这个ramdisk也是一个暂时的文件系统，之后也会被真正的yaffs2之类的文件系统替换。不过呢，在android上，这个ramdisk还是挂载在根目录下的，只是将system、userdata等真实文件系统挂载了对应的二级目录下。

       

        关于这部分ramdisk内容，有兴趣的下来可以继续探讨。

       

15.      mem_init():

最后内存初始化，释放前边标志为保留的所有页面,这个函数结束之后就不能再使

用alloc_bootmem(),alloc_bootmem_low(),alloc_bootmem_pages()等申请低端内存的函数来申请内存，也就不能申请大块的连续物理内存了。

   

16.     中间还省略了很多内容，涉及到很多东西，这里也没有时间详细讨论，有兴趣的自

己研究代码吧！下面直接跳到start_kernel()函数的最后的一个重要函数:rest_init()。

   

17.     rest_init函数创建了两个线程之后，自己调用cpu_idle()函数隐退了。

创建的第一个线程，习惯上我们将其叫做1号内核线程，第二个线程叫2号内核线程，因为创建它们的父进程叫0号启动进程。

说明一下：2.6.14的内核这里只创建了一个内核线程叫init线程，而上面创建两

个线程的内核版本至少都是2.6.2x了，所以为了后面能和android的启动接上，所以这里开始linux转到2.2.29去。

 

static noinline void __init_refok rest_init(void) __releases(kernel_lock)

{

int pid;

 

…

kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);

pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);

kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);

…

cpu_idle();

}

kthreadd这个线程之前的部门交流会上讨论过，新版本的linux将线程创建这个艰巨的工作专门交给了这个叫kthreadd的线程来完成。

接下来既然0号启动进程idle了，那么剩下的工作就都转移到线程kernel_init中去了。

 

18.     kernel_init()

这个线程的任务还是比较艰巨的，第一个重要任务就是调用函数

do_basic_setup()，先调用driver_init()来构建sysfs的目录架构，然后调用do_initcalls()函数来一次执行linux编译时设置的系统函数。

    这里主要工作就是注册系统设备的驱动程序，关于driver和device的注册顺序，是可以互相交换，例如通常的三星平台都有一个struct machine_desc结构体来描述平台相关的启动代码：

    MACHINE_START(SMDK2410, "SMDK2410") /* @TODO: request a new identifier and switch

                    * to SMDK2410 */

    /* Maintainer: Jonas Dietsche */

    .phys_io    = S3C2410_PA_UART,

    .io_pg_offst    = (((u32)S3C24XX_VA_UART) >> 18) & 0xfffc,

    .boot_params    = S3C2410_SDRAM_PA + 0x100,

    .map_io     = smdk2410_map_io,

    .init_irq   = s3c24xx_init_irq,

    .init_machine   = smdk2410_init,

    .timer      = &s3c24xx_timer,

MACHINE_END

    所有devices的注册都是在smdk2410_init()函数中调用函数：

    platform_add_devices(smdk2410_devices, ARRAY_SIZE(smdk2410_devices));

    来完成，所以drivers的注册就放在后面了。不过这样注册是有一个坏处的，就是不能准确地控制driver代码中probe的执行先后顺序。

    现在mtk平台上的devices和drivers注册顺序想法，也就是先注册上drivers，然后再注册devices，这样的话，就可以控制probe函数的执行先后。

   

include/linux/init.h文件中有这些优先级的定义：

#define pure_initcall(fn)        __define_initcall("0",fn,0)

 

#define core_initcall(fn)        __define_initcall("1",fn,1)

#define core_initcall_sync(fn)       __define_initcall("1s",fn,1s)

#define postcore_initcall(fn)        __define_initcall("2",fn,2)

#define postcore_initcall_sync(fn)   __define_initcall("2s",fn,2s)

#define arch_initcall(fn)        __define_initcall("3",fn,3)

#define arch_initcall_sync(fn)       __define_initcall("3s",fn,3s)

#define subsys_initcall(fn)      __define_initcall("4",fn,4)

#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)

#define fs_initcall(fn)          __define_initcall("5",fn,5)

#define fs_initcall_sync(fn)     __define_initcall("5s",fn,5s)

#define rootfs_initcall(fn)      __define_initcall("rootfs",fn,rootfs)

#define device_initcall(fn)      __define_initcall("6",fn,6)

#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)

#define late_initcall(fn)        __define_initcall("7",fn,7)

#define late_initcall_sync(fn)       __define_initcall("7s",fn,7s)

当然函数的执行属性从1~7，通常我们见到的设备都是6、7级的。另外系统中所有的initcalll函数都是可以从linux根目录下的system.map中查看得到。

 

接下来的一段代码就是来释放前面提到的ramdisk.img的：

if (!ramdisk_execute_command)

     ramdisk_execute_command = "/init";

 

if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {

     ramdisk_execute_command = NULL;

     prepare_namespace();

}

释放出来的ramdisk呈现出来的目录就是android编译出来之后，在out/…/root的目录一样了，这个目录下有一个init可执行程序，下面就准备启动它。

 

接着调用init_post()函数，来打开console设备，这个时候我们的控制台就可以操作了，最后会执行以下代码来寻找和启动init程序：

if (execute_command) {

     run_init_process(execute_command);

     printk(KERN_WARNING "Failed to execute %s.  Attempting "

                 "defaults...\n", execute_command);

}

run_init_process("/sbin/init");

run_init_process("/etc/init");

run_init_process("/bin/init");

run_init_process("/bin/sh");

 

panic("No init found.  Try passing init= option to kernel.");

 

这里执行的init程序需要我们在u-boot传给kernel的cmdline中使用init=/init

来告知kernel，或者kernel启动代码中直接写死。否则在上面的那些目录中找不到init的话，系统就用panic机制将这个警告信息保存在nand的panic分区，在下次启动的时候，会自动将这个分区的信息输出。

 

init进程是linux起来之后启动的第一个用户进程，android系统也就是在这个进

程的基础上启动的。进程号是1。