内核引导过程

BROM引导
ARM CPU刚上电时,它的PC寄存器指针指向IC内嵌的一片ROM的起始位置处,这片ROM称之为BROM(boot rom),系统就是通过这片BROM引导起来的。BROM的空间比较小,一般是32/64KB,IC上的ShareRAM大小也不尽相同,所以IC引导过程也是会有所不同。
BROM中会存储上电引导程序,这段程序也一般会包括以下几个内容:

1.  CPU上电初始化操作。
2.  启动介质的驱动操作。
3.  固件下载操作,用来进入刷机模式,更新时固件使用。
4.  BROM引导程序,主要功能是用来从从启动介质中读取和加载第二阶段引导程序。
5.  签名验证操作。

BROM中的引导程序由IC厂商自己定制开发。它会根据硬件上不同,来判断要进入刷机模式还是启动模式,并且还要判断是从哪种介质中引导启动。接下来要从启动介质中读取MBREC上的引导程序到ShareRAM中,并跳转执行。BROM属于read only的,在SOC流片的时候就固定下来了,所以拿到SOC以后基本上就不会去修改了,而可定制化的东西都放在bootloader中实现。

bootloader引导(第二阶段引导)
ARM架构下使用的BROM引导,有点类似于X86下的BIOS引导,BROM内的引导固件一般是不会改变的,从第二阶段这里开始就进入了可定制的阶段,第二阶段的引导程序一般会单独放在启动介质的一个分区,我们叫它boot分区或者MBR分区(主引导分区)。
我们可以把第二阶段引导分为多级引导:
比如分为如下所示的三级引导过程:
(1) firstMBRC
第一级引导程序需要符合BROM引导所需要的格式,会调用BROM中的驱动函数把secondMBRC拷贝到shareRAM中校验,并跳转执行,这个都是独立代码,一般使用汇编来做。
(2) secondMBRC(uboot-spl)
第二级引导程序的功能是调用BROM中的驱动函数把mainMBRC拷贝到DDR 中校验,并跳转执行。第二阶段可以使用uboot中的spl来实现,也可以由自己独立代码实现。
(3) mainMBRC(uboot)
第三级是主要的引导程序,前面的两级引导都是为了加载mainMBRC,它的主要功能是显示启动logo,加载kernel、dtb、rootfs文件系统,并且启动kernel。一般使用uboot来做。
所以在boot分区,我们要烧写入这三部分的引导代码,mbrc、uboot-spl、uboot。

uboot引导
采用uboot来启动的内核为uImage,这种内核包括两部分,一个是头部,一个是真正的内核,可以这样来表示uImage=uboot header+zImage。
头部的定义为:

typedef struct image_header {
uint32_t ih_magic; /* Image Header Magic Number */
uint32_t ih_hcrc; /* Image Header CRC Checksum */
uint32_t ih_time; /* Image Creation Timestamp */
uint32_t ih_size; /* Image Data Size */
uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
uint32_t ih_dcrc; /* Image Data CRC Checksum */
uint8_t ih_os; /* Operating System */
uint8_t ih_arch; /* CPU architecture */
uint8_t ih_type; /* Image Type */
uint8_t ih_comp; /* Compression Type */
uint8_t ih_name[IH_NMLEN]; /* Image Name */
} image_header_t;
我们需要关心的是:
uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
ih_load是内核加载地址,即内核开始运行前应该位于的地方 ,ih_ep是内核入口地址,入口地址和加载地址可以相同。

Uboot启动内核的过程是通过读取环境变量env中的bootcmd来决定如何启动kernel,比如uboot想从nand flash上读取kernel分区到内存地址的0x30007FC0上并且启动kernel,可以使用如下命令:bootcmd = nand read.jffs2 0x30007FC0 kernel; bootm 0x30007FC0。启动kernel的关键是bootm命令。
bootm命令的实现在uboot中是do_bootm()函数中:
源文件:cmd_bootm.c

int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
…
 if (argc < 2) {
            addr = load_addr; 
} else {
            addr = simple_strtoul(argv[1], NULL, 16);
}
/*从加载地址处读取uboot header并进行解析*/
……

   switch (hdr->ih_comp) { 
    case IH_COMP_NONE: 
             if(ntohl(hdr->ih_load) == addr) { /
                   printf ("   XIP %s ... ", name);
             } else {//
                   memmove ((void *) ntohl(hdr->ih_load), (uchar *)data, len);
              }
……

}

首先判断bootm命令后面是否带了加载地址,若没有加载地址的参数,则将默认加载地址赋值给addr,否则将使用bootm命令后附带的地址作为加载地址。然后的关键是从加载地址处读取uboot header并且解析。从上面的代码逻辑我们可以看到,会判断ubootheader中的ih_load和bootm传入的加载地址是否一致,并由此区分了两种情况:
(1)如果不同的话会把去掉头部(64Byte)的内核(zImage)复制到ih_load指定的地址中,并从ih_ep处开始启动内核。因此这种情况下,ih_load和ih_ep要相同。
(2)如果相同的话那就让其原封不同的放在那,并从ih_ep处开始启动内核(zImage)。因此这种情况下,执行入口函数地址要和加载地址之间相差了一个uboot header。因此 ih_ep= ih_load+64Byte。

有了上面的知识,那么我们如何去设置uboot header中的地址呢,其实这一步是在制作uImage的时候,使用mkimage工具指定的加载地址和运行地址。

mkimage -A arm -O linux -C none -a 0x30008000 -e 0x30008000 -d zImage uImage
-A:CPU类型
-O:操作系统
-C:采用的压缩方式
-a:内核加载地址
-e:内核入口地址

制作镜像头以及下载地址就有两种情况:
(1)mkimage -A arm -O linux -C none -a 0x30008000 -e 0x30008000 -d zImage uImage
tftp 0x31000000 uImage
bootm 0x31000000
加载地址和入口地址相同,tftp和bootm后面的地址是任意地址(除了-a指定的地址外)。

这种情况下uboot会对内核进行搬运的动作,搬运的是不包括uboot header的zImage,所以加载地址和入口地址要设置为相同。如果tftp和bootm后面的地址也是0x30008000,会出现什么情况呢?从上面的代码可以看出,如果相同,将不执行搬运动作,只打印除了一条信息,然后跳到入口地址进行执行,此时入口地址是一个uboot header,这里并不是可执行的zImage,所以将会报错。

(2) mkimage -A arm -O linux -C none -a 0x30008000 -e 0x30008040 -d zImage uImage
tftp 0x30008000 uImage
bootm 0x30008000
入口地址在加载地址后面64个字节,tftp和bootm后面的地址一定要在-a指定的加载地址上。

我们一般习惯于使用第二种方法,并下载到–a所指定的地址上,这样就不用劳烦uboot进行搬运了,节省了启动时间。

在上面的do_bootm 中,我们通过解析uboot header,已经获得了内核镜像相关的信息,其中就包括了内核入口地址,在引导的最后阶段,将跳转到内核中去执行。这一步是在do_bootm_linux()函数中实现的。通过一个函数指针 thekernel()带三个参数跳转到内核( zImage )入口点开始执行,此时, u-boot 的任务已经完成,控制权完全交给内核( zImage )。

do_bootm_linux(),在arch\arm\lib\bootm.c定义,因为我们已经知道入口地址了,所以只需跳到入口地址就可以启动linux内核了。

theKernel = (void (*)(int, int, uint))ntohl(hdr->ih_ep);
theKernel (0, bd->bi_arch_number, bd->bi_boot_params);

hdr->ih_ep—-Entry Point Address ,uImage 中指定的内核入口点,还记得ih_ep吗?其中第二个参数为机器 ID, 内核所设置的机器码和uboot所设置的机器码必须一致才能启动内核,第三参数为 u-boot 传递给内核参数存放在内存中的首地址。

内核启动
经过uboot引导以后,系统开始进入到zImage中执行。zImage是包括了解压缩代码和vmlinux的镜像,所以它的执行可以分为三部分,分别是zImage解压缩,vmlinux内核启动汇编阶段,vmlinux内核启动C语言阶段。

(1) zImage解压缩
(2) 内核启动汇编阶段
(3) 内核启动c语言阶段(start_kernel到创建第一个进程)

zImage解压缩
这一阶段所涉及的文件也只有三个:
(1)arch/arm/boot/compressed/vmlinux.lds
(2)arch/arm/boot/compressed/head.S
(3)arch/arm/boot/compressed/misc.c
首先跳转到head.S中的start函数开始执行,结合lds文件可以看下具体流程,这一部分不做过多介绍。

内核启动汇编阶段
(这个阶段参考链接文件:arch/arm/kernel/vmlinux.lds)
启动汇编阶段的代码是从arch/arm/kernel/head.S开始的,执行起点是stext函数。
隔了一段时间回头来看,发现这里写的不够清楚,很容易造成歧义,需要注意的是lds文件中定义的_text/_stext仅仅是一个地址,并不和代码中的stext函数匹配,stext是函数名,它存在于.head.text段中。

而lds文件中,_text标号存在于.head.text段中,_stext标号存在与.text段中,ENTRY入口点定义为stext,实际上是跑到了.head.text段中的stext函数里了。这里尤其需要注意区分概念。注意函数名和标号的区别,别搞混淆了。

这部分主要完成的工作有cpu ID检查,machine ID检查,创建初始化页表,设置C代码运行环境,跳转到内核第一个真正的C函数start_kernel开始执行。
这一阶段涉及到两个重要的结构体:
(1) 一个是struct proc_info_list 主要描述CPU相关的信息,结构定义在文件arch/arm/include/asm/procinfo.h中,与其相关的函数及变量在文件arch/arm/mm/proc_xxx.S中被定义和赋值,比如arch/arm/mm/proc-v7.S文件是armv7使用的。
(2) 另一个结构体是描述开发板或者说机器信息的结构体struct machine_desc,结构定义在arch/arm/include/asm/mach/arch.h文件中,其函数的定义和变量的赋值在板极相关文件arch/arm/mach-s3c2410/mach-smdk2410.c中实现,这也是内核移植非常重要的一个文件。
该阶段一般由前面的解压缩代码调用,进入该阶段要求:
MMU = off, D-cache = off, I-cache = dont care,r0 = 0, r1 = machine id.
所有的机器ID列表保存在arch/arm/tools/mach-types 文件中,在编译时会生成相应的头文件在kernel/include/generated/ mach-types.h中。Kernel会根据传入的machine id查找到匹配的struct machine_desc结构,并使用其中的回调函数来启动kernel。

在编译时,上面定义的两种结构体变量,struct proc_info_list会被链接到内核映像文件vmlinux的__proc_info_begin和__proc_info_end之间的段中。struct machine_desc会被链接到内核映像文件vmlinux的__arch_info_begin和__arch_info_end之间的段中。分别对应(.proc.info.init)和(.arch.info.init),可以参考下面的连接脚本vmlinux.lds。

__proc_info_begin = .;
*(.proc.info.init)
__proc_info_end = .;
__arch_info_begin = .;
*(.arch.info.init)
__arch_info_end = .;

在汇编阶段执行的最后,会跳转到C语言阶段继续启动,在head-common.S中通过指令b start_kernel跳转到C代码中执行。

内核启动C语言阶段
C语言的入口函数定义在kernel/init/main.c中,通过函数start_kernel开始执行,它会调用到很多跟平台相关的函数,这部分函数的定义依然在kernel/arch/arm/mach-XXX目录中。

比如machine的定义,在start_kernel就可以使用匹配的machine所定义的函数:

对于平台smdk2410 来说其对应 machine_desc 结构在文件linux/arch/arm/mach-s3c2410/mach-smdk2410.c中初始化:

MACHINE_START(SMDK2410, "SMDK2410")  
.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 

对于宏MACHINE_START 在文件 arch/arm/include/asm/mach/arch.h 中定义:

#define MACHINE_START(_type,_name) / 
static const struct machine_desc __mach_desc_##_type / 
 __used / 
 __attribute__((__section__(".arch.info.init"))) = { / 
.nr = MACH_TYPE_##_type, / 
.name = _name, 
#define MACHINE_END / 
}; 
__attribute__((__section__(".arch.info.init")))表明该结构体在并以后存放的位置。

还记得上面提到的vmlinux.lds中的信息吗?
__arch_info_begin = .;
*(.arch.info.init)
__arch_info_end = .;
所以上面定义的内容将被放到这个__arch_info_begin和__arch_info_end之间的段内。这样就使得在汇编文件中也可以显式查找到这个结构了。

接下来就简单介绍一下CPU启动过程,如下所示:
对于SMP,bootstrap CPU会在系统初始化的时候执行cpu_init函数,进行本CPU的初始化设定,具体调用序列是:

start_kernel--->setup_arch--->setup_processor--->cpu_init--->rest_init-->cpu_startup_entry(parent thread)-->idle。

对于系统中其他的CPU,bootstrap CPU会在系统初始化的最后,对每一个online的CPU进行初始化,具体的调用序列是:

rest_init--->kernel_init(child thread)--->kernel_init_freeable-->smp_init--->cpu_up--->_cpu_up--->__cpu_up

__cpu_up函数是和CPU architecture相关的。对于ARM,其调用序列是

__cpu_up-->boot_secondary-->smp_ops.smp_boot_secondary
-->secondary_startup-->__secondary_switched
-->secondary_start_kernel-->cpu_init-->cpu_startup_entry

其中涉及到的关键代码目录有:
Kernel/init/—————————C语言启动入口
Kernel/arch/arm/kernel/———-arm架构通用代码
Kernel/arch/arm/mach-xxx/—–平台相关代码,移植重点

你可能感兴趣的:(内核笔记)