内核的启动过程分析

1 做好内核分析的准备工作

1.1 删除无用文件
(1)官方版本的kernel中是支持各种硬件架构、各种开发板的，因此有很多文件夹和文件和我们使用的X210开发板无关，在建立SI工程前应该删掉这些家伙。

(2)我们现在分析的是开发板厂商九鼎科技移植好的针对X210开发板的kernel，因此其中一些无用文件已经被删掉了。

1.2 使用SourceInsight软件建立SI工程并解析

1.3 Makefile分析
(1)kernel的Makefile写法和规则等和uboot的Makefile是一样的，甚至Makefile中的很多内容都是一样的。

(2)kernel的Makefile比uboot的Makefile要复杂，这里我们并不会一行一行的详细分析。

(3)Makefile中只有一些值得关注的我、会强调一下，其他不强调的地方暂时可以不管。

(4)Makefile中刚开始定义了kernel的内核版本号。这个版本号挺重要（在模块化驱动安装时会需要用到），要注意会查，会改。

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 35
EXTRAVERSION = .7
NAME = Yokohama

(5)在make编译内核时，也可以通过命令行给内核makefile传参（跟uboot配置编译时传参一样）。譬如make O=xxx可以指定不在源代码目录下编译，而到另外一个单独文件夹下编译。

(6)kernel的顶层Makefile中定义了2个变量很重要，一个是ARCH，一个是CROSS_COMPILE。ARCH决定当前配置编译的路径，譬如ARCH = arm的时候，将来在源码目录下去操作的arch/arm目录。CROSS_COMPILE用来指定交叉编译工具链的路径和前缀。

(7)CROSS_COMPILE = xxx和ARCH = xxx和O=xxx这些都可以在make时通过命令行传参的方式传给顶层Makefile。所以有时候你会看到别人编译内核时：

make O=/tmp/mykernel ARCH=arm CROSS_COMPILE=/usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-

1.4 链接脚本分析
(1)分析连接脚本的目的就是找到整个程序的entry

(2)kernel的连接脚本并不是直接提供的，而是提供了一个汇编文件vmlinux.lds.S，然后在编译的时候再去编译这个汇编文件得到真正的链接脚本vmlinux.lds。

(3)vmlinux.lds.S在arch/arm/kernel/目录下。

(4)思考：为什么linux kernel不直接提供vmlinux.lds而要提供一个vmlinux.lds.S然后在编译时才去动态生成vmlinux.lds呢？

猜测：.lds文件中只能写死，不能用条件编译。但是我们在kernel中链接脚本确实有条件编译的需求（但是lds格式又不支持），于是乎kernel工作者找了个投机取巧的方法，就是把vmlinux.lds写成一个汇编格式，然后汇编器处理的时候顺便条件编译给处理了，得到一个不需要条件编译的vmlinux.lds。

/* ld script to make ARM Linux kernel
 * taken from the i386 version by Russell King
 * Written by Martin Mares <mj@atrey.karlin.mff.cuni.cz>
 */

#include <asm-generic/vmlinux.lds.h>
#include <asm/thread_info.h>
#include <asm/memory.h>
#include <asm/page.h>
	
OUTPUT_ARCH(arm)
ENTRY(stext)

#ifndef __ARMEB__
jiffies = jiffies_64;
#else
jiffies = jiffies_64 + 4;
#endif

SECTIONS
{
#ifdef CONFIG_XIP_KERNEL
	. = XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR);
#else
	. = PAGE_OFFSET + TEXT_OFFSET;
#endif

	.init : {			/* Init code and data		*/
		_stext = .;
		_sinittext = .;
			HEAD_TEXT
			INIT_TEXT
		_einittext = .;
		__proc_info_begin = .;
			*(.proc.info.init)
		__proc_info_end = .;
		__arch_info_begin = .;
			*(.arch.info.init)
		__arch_info_end = .;
		__tagtable_begin = .;
			*(.taglist.init)
		__tagtable_end = .;

		INIT_SETUP(16)

		INIT_CALLS
		CON_INITCALL
		SECURITY_INITCALL
		INIT_RAM_FS

#ifndef CONFIG_XIP_KERNEL
		__init_begin = _stext;
		INIT_DATA
#endif
	}

	PERCPU(PAGE_SIZE)

#ifndef CONFIG_XIP_KERNEL
	. = ALIGN(PAGE_SIZE);
	__init_end = .;
#endif

	/*
	 * unwind exit sections must be discarded before the rest of the
	 * unwind sections get included.
	 */
	/DISCARD/ : {
		*(.ARM.exidx.exit.text)
		*(.ARM.extab.exit.text)
#ifndef CONFIG_HOTPLUG_CPU
		*(.ARM.exidx.cpuexit.text)
		*(.ARM.extab.cpuexit.text)
#endif
#ifndef CONFIG_HOTPLUG
		*(.ARM.exidx.devexit.text)
		*(.ARM.extab.devexit.text)
#endif
#ifndef CONFIG_MMU
		*(.fixup)
		*(__ex_table)
#endif
	}

	.text : {			/* Real text segment		*/
		_text = .;		/* Text and read-only data	*/
			__exception_text_start = .;
			*(.exception.text)
			__exception_text_end = .;
			TEXT_TEXT
			SCHED_TEXT
			LOCK_TEXT
			KPROBES_TEXT
#ifdef CONFIG_MMU
			*(.fixup)
#endif
			*(.gnu.warning)
			*(.rodata)
			*(.rodata.*)
			*(.glue_7)
			*(.glue_7t)
		*(.got)			/* Global offset table		*/
	}

	RO_DATA(PAGE_SIZE)

	_etext = .;			/* End of text and rodata section */

#ifdef CONFIG_ARM_UNWIND
	/*
	 * Stack unwinding tables
	 */
	. = ALIGN(8);
	.ARM.unwind_idx : {
		__start_unwind_idx = .;
		*(.ARM.exidx*)
		__stop_unwind_idx = .;
	}
	.ARM.unwind_tab : {
		__start_unwind_tab = .;
		*(.ARM.extab*)
		__stop_unwind_tab = .;
	}
#endif

#ifdef CONFIG_XIP_KERNEL
	__data_loc = ALIGN(4);		/* location in binary */
	. = PAGE_OFFSET + TEXT_OFFSET;
#else
	. = ALIGN(THREAD_SIZE);
	__data_loc = .;
#endif

	.data : AT(__data_loc) {
		_data = .;		/* address in memory */
		_sdata = .;

		/*
		 * first, the init task union, aligned
		 * to an 8192 byte boundary.
		 */
		INIT_TASK_DATA(THREAD_SIZE)

#ifdef CONFIG_XIP_KERNEL
		. = ALIGN(PAGE_SIZE);
		__init_begin = .;
		INIT_DATA
		. = ALIGN(PAGE_SIZE);
		__init_end = .;
#endif

		NOSAVE_DATA
		CACHELINE_ALIGNED_DATA(32)

		/*
		 * The exception fixup table (might need resorting at runtime)
		 */
		. = ALIGN(32);
		__start___ex_table = .;
#ifdef CONFIG_MMU
		*(__ex_table)
#endif
		__stop___ex_table = .;

		/*
		 * and the usual data section
		 */
		DATA_DATA
		CONSTRUCTORS

		_edata = .;
	}
	_edata_loc = __data_loc + SIZEOF(.data);

#ifdef CONFIG_HAVE_TCM
        /*
	 * We align everything to a page boundary so we can
	 * free it after init has commenced and TCM contents have
	 * been copied to its destination.
	 */
	.tcm_start : {
		. = ALIGN(PAGE_SIZE);
		__tcm_start = .;
		__itcm_start = .;
	}

	/*
	 * Link these to the ITCM RAM
	 * Put VMA to the TCM address and LMA to the common RAM
	 * and we'll upload the contents from RAM to TCM and free
	 * the used RAM after that.
	 */
	.text_itcm ITCM_OFFSET : AT(__itcm_start)
	{
		__sitcm_text = .;
		*(.tcm.text)
		*(.tcm.rodata)
		. = ALIGN(4);
		__eitcm_text = .;
	}

	/*
	 * Reset the dot pointer, this is needed to create the
	 * relative __dtcm_start below (to be used as extern in code).
	 */
	. = ADDR(.tcm_start) + SIZEOF(.tcm_start) + SIZEOF(.text_itcm);

	.dtcm_start : {
		__dtcm_start = .;
	}

	/* TODO: add remainder of ITCM as well, that can be used for data! */
	.data_dtcm DTCM_OFFSET : AT(__dtcm_start)
	{
		. = ALIGN(4);
		__sdtcm_data = .;
		*(.tcm.data)
		. = ALIGN(4);
		__edtcm_data = .;
	}

	/* Reset the dot pointer or the linker gets confused */
	. = ADDR(.dtcm_start) + SIZEOF(.data_dtcm);

	/* End marker for freeing TCM copy in linked object */
	.tcm_end : AT(ADDR(.dtcm_start) + SIZEOF(.data_dtcm)){
		. = ALIGN(PAGE_SIZE);
		__tcm_end = .;
	}
#endif

	BSS_SECTION(0, 0, 0)
	_end = .;

	STABS_DEBUG
	.comment 0 : { *(.comment) }

	/* Default discards */
	DISCARDS
}

/*
 * These must never be empty
 * If you have to comment these two assert statements out, your
 * binutils is too old (for other reasons as well)
 */
ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")

(5)入口在哪里？

从vmlinux.lds中ENTRY(stext)可以知道入口符号是stext，在SI中搜索这个符号，发现arch/arm/kernel/目录下的head.S和head-nommu.S中都有。

(6)head.S是启用了MMU情况下的kernel启动文件，相当于uboot中的start.S。head-nommu.S是未使用mmu情况下的kernel启动文件。

2 head.S文件分析

文件路径：kernel/arch/arm/kernel/head.S

由于sourceinsight中分析的这份文件是经过make distclean的，所以未经过配置，许多应有的宏定义在查看代码时并未显示定义，去linux下的那份代码查看.config文件，发现其中定义了许多所需的宏。CONFIG_开头的代码若未定义，可尝试去.config文件去寻找。

2.1 内核运行的物理地址与虚拟地址（head.S文件）

#define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET)
#define KERNEL_RAM_PADDR (PHYS_OFFSET + TEXT_OFFSET)

TEXT_OFFSET在sourceinsight中搜索搜不到，内核代码中没有，当出现这种情况，其可能出现在源码目录的配置文件中，可使用以下方法找到他：

在Linux那份代码中（目录为/x210v3_bsp/qt_x210v3/kernel/）使用命令搜索：grep “TEXT_OFFSET” * -nr

有数值赋值的应该是我们需要找的。

(1)KERNEL_RAM_VADDR（VADDR就是virtual address），这个宏定义了内核运行时的虚拟地址。值为0xC0008000

(2)KERNEL_RAM_PADDR（PADDR就是physical address），这个宏定义了内核运行时的物理地址。值为0x30008000

以上的值通过文件层层查找得到的。

(3)总结：内核运行的物理地址是0x30008000，对应的虚拟地址是0xC0008000。

2.2 内核的真正入口
(1)内核的真正入口就是ENTRY(stext)处(head.s 的 78 行)

#define __HEAD .section “.head.text”,“ax”

.section是伪指令，ax代表允许执行

(2)前面的__HEAD定义了后面的代码属于段名为.head .text的段

__proc_info_begin = .;  定义了段.proc.info.init的起始地址
	*(.proc.info.init)
__proc_info_end = .;    定义了段.proc.info.init的结束地址

head.s的59——76行的注释应该仔细研读。

2.3 内核运行的硬件条件
(1)内核的起始部分代码是被解压代码调用的。uboot启动内核后实际调用运行的是zImage前面的那段未经压缩的解压代码，解压代码运行时先将zImage后段的内核解压开，然后再去调用运行真正的内核入口。

(2)内核启动不是无条件的，而是有一定的先决条件，这个条件由启动内核的bootloader（我们这里就是uboot）来构建保证。

(3)ARM体系中，函数调用时实际是通过寄存器传参的（函数调用时传参有两种设计：一种是寄存器传参，另一种是栈内存传参）。所以uboot中最后：
theKernel (0, machid, bd->bi_boot_params)运行时实际把0放入r0中，machid放入到了r1中，bd->bi_boot_params放入到了r2中。ARM的这种处理技巧刚好满足了kernel启动的条件和要求。

(4)kernel启动时MMU是关闭的，因此硬件上需要的是物理地址。但是内核是一个整体（zImage）只能链接到一个地址（不能分散加载），这个链接地址肯定是虚拟地址。因此内核运行时前段head.S中尚未开启MMU之前的这段代码就很难受。所以这段代码必须是位置无关码，而且其中涉及到操作硬件寄存器等时必须使用物理地址。
__pa() 该宏的作用是输入虚拟地址会转换一个物理地址出来

（5）linux/arch/arm/tools/mach-types（2443行）查看机器码

smdkv210		MACH_SMDKV210		SMDKV210		2456

由于内核开始这块代码使用的是物理地址，所以我们尽可能不在这块添加代码。涉及到硬件的操作，必须使用物理地址

3 内核启动的汇编阶段

3.1 __lookup_processor_type

	mrc	p15, 0, r9, c0, c0		@ get processor id 
	bl	__lookup_processor_type		@ r5=procinfo r9=cpuid
	movs	r10, r5				@ invalid processor (r5=0)?
	beq	__error_p			@ yes, error 'p'

__lookup_processor_type:
	adr	r3, 3f
	ldmia	r3, {r5 - r7}
	add	r3, r3, #8
	sub	r3, r3, r7			@ get offset between virt&phys
	add	r5, r5, r3			@ convert virt addresses to
	add	r6, r6, r3			@ physical address space
1:	ldmia	r5, {r3, r4}			@ value, mask
	and	r4, r4, r9			@ mask wanted bits
	teq	r3, r4
	beq	2f
	add	r5, r5, #PROC_INFO_SZ		@ sizeof(proc_info_list)
	cmp	r5, r6
	blo	1b
	mov	r5, #0				@ unknown processor
2:	mov	pc, lr
ENDPROC(__lookup_processor_type)

(1)我们从cp15协处理器的c0寄存器中读取出硬件的CPU ID号，然后调用这个函数来进行合法性检验。如果合法则继续启动，如果不合法则停止启动，转向__error_p启动失败。

(2)该函数检验cpu id的合法性方法是：内核会维护一个本内核支持的CPU ID号码的数组，然后该函数所做的就是将从硬件中读取的cpu id号码和数组中存储的各个id号码依次对比，如果没有一个相等则不合法，如果有一个相等的则合法。

(3)内核启动时设计这个校验，也是为了内核启动的安全性着想。

3.2 __lookup_machine_type

	bl	__lookup_machine_type		@ r5=machinfo
	movs	r8, r5				@ invalid machine (r5=0)?
	beq	__error_a			@ yes, error 'a'

__lookup_machine_type:
	adr	r3, 4b           
	ldmia	r3, {r4, r5, r6}
	sub	r3, r3, r4			@ get offset between virt&phys
	add	r5, r5, r3			@ convert virt addresses to
	add	r6, r6, r3			@ physical address space
1:	ldr	r3, [r5, #MACHINFO_TYPE]	@ get machine type
	teq	r3, r1				@ matches loader number?
	beq	2f				@ found
	add	r5, r5, #SIZEOF_MACHINE_DESC	@ next machine_desc
	cmp	r5, r6
	blo	1b
	mov	r5, #0				@ unknown machine
2:	mov	pc, lr
ENDPROC(__lookup_machine_type)

该函数的设计理念和思路和上面校验cpu id的函数一样的。不同之处是本函数校验的是机器码。

3.3 __vet_atags

bl	__vet_atags

(1)该函数的设计理念和思路和上面2个一样，不同之处是用来校验uboot给内核的传参ATAGS格式是否正确。这里说的传参指的是uboot通过tag给内核传的参数（主要是板子的内存分布memtag、uboot的bootargs） 注意：这句话，简直是精华啊！uboot传参主要是memtag和bootargs，换而言之，硬件的初始化和内核的移植关系不大，所以内核移植时，只需要注意机器码和tag参数的传递就行，然后自己在machine_desc （ void (*init_machine)(void); ）里面修改需要更改的硬件初始化函数就行了，给内核memtag是为了让内核可以管理内存，bootargs内容：

set bootargs console=ttySAC2,115200 root=/dev/mmcblk0p2 rw init=/linuxrc rootfstype=ext2

bootargs是为了内核挂载根文件系统的时候使用，指定了挂载的扇区，和根文件系统的格式等。

大胆猜测：在uboot中，只需要初始化内核运行的最基础的硬件设施，并且按照内核的格式要求传递参数，就已经算完成自己的任务了（感觉自己可以从零开始手写一个bootloader，然后在代码里设置参数，这样也可以成功让内核运行，只不过可移植性差罢了）。内核的运行环境已经被简单的配置完成，内核就可以运行了，内核先校验CPU id，机器码 ，还有参数格式，然后就开始了自己的任务，
比如：给内存管理的模块代码传递硬件的DDR范围，对硬件设备进行详细的初始化等，在这里对硬件初始化，只是在进行功能的丰富，虽然驱动是内核的一部分，但是这里不进行详细的硬件初始化，内核也能正常工作，只不过是一个简单的内核，没有丰富的功能，所谓的内核裁剪，可能就是减少不必要的驱动模块，毕竟官网下载的内核应该是最简单的版本，慢慢的添加驱动，内核的代码量就庞大了。

(2)内核认为如果uboot给我的传参格式不正确，那么我就不启动。

(3)uboot给内核传参的部分如果不对，是会导致内核不启动的。譬如uboot的bootargs设置不正确内核可能就会不启动。

3.4 __create_page_tables

bl	__create_page_tables

(1)顾名思义，这个函数用来建立页表。

(2)**linux内核本身被链接在虚拟地址处，因此kernel希望尽快建立页表并且启动MMU进入虚拟地址工作状态。**但是kernel本身工作起来后页表体系是非常复杂的，建立起来也不是那么容易的。kernel想了一个好办法

(3)kernel建立页表其实分为2步。第一步，kernel先建立了一个段式页表（和uboot中之前建立的页表一样，页表以1MB为单位来区分的），这里的函数就是建立段式页表的。段式页表本身比较好建立（段式页表1MB一个映射，4GB空间需要4096个页表项，每个页表项4字节，因此一共需要16KB内存来做页表），坏处是比较粗不能精细管理内存；第二步，再去建立一个细页表（4kb为单位的细页表），然后启用新的细页表废除第一步建立的段式映射页表。

(4)内核启动的早期建立段式页表，并在内核启动前期使用；内核启动后期就会再次建立细页表并启用。等内核工作起来之后就只有细页表了。

3.5 __switch_data

	ldr	r13, __switch_data		@ address to jump to after
	__switch_data:
	.long	__mmap_switched
	.long	__data_loc			@ r4
	.long	_data				@ r5
	.long	__bss_start			@ r6
	.long	_end				@ r7
	.long	processor_id			@ r4
	.long	__machine_arch_type		@ r5
	.long	__atags_pointer			@ r6
	.long	cr_alignment			@ r7
	.long	init_thread_union + THREAD_START_SP @ sp

__mmap_switched:
	adr	r3, __switch_data + 4

	ldmia	r3!, {r4, r5, r6, r7}
	cmp	r4, r5				@ Copy data segment if needed
1:	cmpne	r5, r6
	ldrne	fp, [r4], #4
	strne	fp, [r5], #4
	bne	1b

	mov	fp, #0				@ Clear BSS (and zero fp)
1:	cmp	r6, r7
	strcc	fp, [r6],#4
	bcc	1b

 ARM(	ldmia	r3, {r4, r5, r6, r7, sp})
 THUMB(	ldmia	r3, {r4, r5, r6, r7}	)
 THUMB(	ldr	sp, [r3, #16]		)
	str	r9, [r4]			@ Save processor ID
	str	r1, [r5]			@ Save machine type
	str	r2, [r6]			@ Save atags pointer
	bic	r4, r0, #CR_A			@ Clear 'A' bit
	stmia	r7, {r0, r4}			@ Save control register values
	b	start_kernel
ENDPROC(__mmap_switched)

(1)建立了段式页表后进入了__switch_data部分，这东西是个函数指针数组。
(2)分析得知下一步要执行__mmap_switched函数
(3)复制数据段、清除bss段（目的是构建C语言运行环境）
(4)保存cpu id号、机器码、tag传参的首地址。
(5)b start_kernel跳转到C语言运行阶段。

总结：汇编阶段其实也没干啥，主要原因是uboot干了大部分活。汇编阶段主要就是校验启动合法性、建立段式映射的页表并开启MMU以方便使用内存、跳入C阶段。

4 内核启动的C语言阶段

4.1 这一块的学习思路
(1)抓大放小，不深究.
(2)感兴趣可以就某个话题去网上搜索资料学习
(3)重点局部深入分析

(4)补充一个概念：
何谓自旋锁？

它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放锁，"自旋"一词就是因此而得名。

4.2 具体学习方法
(1)顺着代码执行路径抓全。这是我们的学习主线。

(2)对照内核启动的打印信息进行分析。

Uncompressing Linux… done, booting the kernel.这个打印信息是zImage开头的那段解压代码打印出来的。（内核启动打印信息我记录在一个文件中）

文件阿里云网盘链接：https://www.aliyundrive.com/s/YhZ2M3CbiLB

4.3 几条学习线路
(1)分析uboot给kernel传参的影响和实现
(2)硬件初始化与驱动加载
(3)内核启动后的结局与归宿

4.4 知识补充
对称多处理器：具有相同的内核，如都是ARM
非对称多处理器：具有不同的核心，如一个ARM核，一个FPGA核，一个ARM，一个DSP核。Linux系统是最早支持多核心CPU的。

SMP系统的组建：
（1）CPU内部必须内置APIC （高级可编程中断控制器）
（2）相同的产品型号，同样类型的CPU核心。
（3）完全相同的运行频率。
（4）尽可能保持相同的产品序列编号。即使是同样核心的相同频率处理器，由于生产批次不同也会造成不可思议的问题

4.5 杂碎（main.c 539行开始）
kernel/init/main.c
(1)smp。smp就是对称多处理器（其实就是我们说的多核心CPU）
(2)lockdep。锁定依赖，是一个内核调试模块，处理内核自旋锁死锁问题相关的。
(3)cgroup。control group，内核提供的一种来处理进程组的技术。

cgroups，其名称源自控制组群（control groups）的简写，是Linux内核的一个功能，用来限制、控制与分离一个进程组的资源（如CPU、内存、磁盘输入输出等）。

以上属于操作系统原理的内容，是开发研究操作系统的人去深入的，我们只是用操作系统。

4.6 打印内核版本信息
printk(KERN_NOTICE “%s”, linux_banner);

(1)代码位于：kernel/init/main.c中的572行

(2)printk函数是内核中用来从console打印信息的，类似于应用层编程中的printf。内核编程时不能使用标准库函数，因此不能使用printf，其实printk就是内核自己实现的一个printf。

(3)printk函数的用法和printf几乎一样，不同之处在于可以在参数最前面用一个宏来定义消息输出的级别。

为什么要有这种级别？
主要原因是linux内核太大了，代码量太多，里面的printk打印信息太多了。如果所有的printk都能打印出来而不加任何限制，则最终内核启动后得到海量的输出信息。

#define	KERN_EMERG	"<0>"	/* system is unusable 致命错误，内核无法启动			*/
#define	KERN_ALERT	"<1>"	/* action must be taken immediately紧急情况必须处理、否则就死*/
#define	KERN_CRIT	"<2>"	/* critical conditions	非常危险，容易死*/
#define	KERN_ERR	"<3>"	/* error conditions	有错误，但不一定会死*/
#define	KERN_WARNING	"<4>"	/* warning conditions 警告，没事，但可能会出问题*/
#define	KERN_NOTICE	"<5>"	/* normal but significant condition	发布消息，没事*/
#define	KERN_INFO	"<6>"	/* informational 更低级别的消息，关不关注无所谓*/
#define	KERN_DEBUG	"<7>"	/* debug-level messages	用于调试，没问题不去看*/

(4)为了解决打印信息过多，无效信息会淹没有效信息这个问题，linux内核的解决方案是给每一个printk添加一个打印级别。级别定义0-7（注意编程的时候要用相应的宏定义，不要直接用数字）分别代表8种输出的重要性级别，0表示最重要，7表示最不重要。我们在printk的时候自己根据自己的消息的重要性去设置打印级别。

(5)linux的控制台监测消息的地方也有一个消息过滤显示机制，控制台实际只会显示级别比我的控制台定义的级别高的消息。譬如说控制台的消息显示级别设置为4，那么只有printk中消息级别为0-3（也可能是0-4）的才可以显示看见，其余的被过滤掉了。

(6)linux_banner的内容解析。

const char linux_banner[] =
	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
	LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
		
[    0.000000] Linux version 2.6.35.7 (root@ubuntu) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 PREEMPT Fri Nov 20 22:44:42 CST 2020	

[    0.000000]  表示代码执行的时间

以下文件可能是在编译过程中生成的，所以在sourceinsight软件中这份源码中找不到
include/generated/utsrelease.h:1:#define UTS_RELEASE "2.6.35.7"
include/generated/compile.h:6:#define LINUX_COMPILE_BY "root"
include/generated/compile.h:7:#define LINUX_COMPILE_HOST "ubuntu"
include/generated/compile.h:9:#define LINUX_COMPILER "gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) "
include/generated/compile.h:4:#define UTS_VERSION "#1 PREEMPT Sat Nov 21 22:40:27 CST 2020"

4.7 setup_arch函数简介

setup_arch(&command_line);

(1)从名字看，这个函数是CPU架构相关的一些创建过程。

(2)实际上这个函数是用来确定我们当前内核的机器（arch、machine）的。我们的linux内核会支持一种CPU的运行，CPU+开发板就确定了一个硬件平台，然后我们当前配置的内核就在这个平台上可以运行。之前说过的机器码就是给这个硬件平台一个固定的编码，以表征这个平台。

(3)当前内核支持的机器码以及硬件平台相关的一些定义都在这个函数中处理。

4.8 Machine查找（进入setup_arch函数开始分析）

(1)setup_processor函数用来查找CPU信息，可以结合串口打印的信息来分析。

printk("CPU: %s [%08x] revision %d (ARMv%s), cr=%08lx\n",
       cpu_name, read_cpuid_id(), read_cpuid_id() & 15,
       proc_arch[cpu_architecture()], cr_alignment);

对应内核启动打印出来的启动信息：

[    0.000000] CPU: ARMv7 Processor [412fc082] revision 2 (ARMv7), cr=10c53c7f
	
sprintf(init_utsname()->machine, "%s%c", list->arch_name, ENDIANNESS);
sprintf(elf_platform, "%s%c", list->elf_name, ENDIANNESS);	

sprintf(）函数这里用于格式化，并未打印信息

(2)setup_machine函数的传参是机器码编号，(机器码)machine_arch_type符号在include/generated/mach-types.h的32039-32050行定义了。经过分析后确定这个传参值就是2456.

(3)函数的作用是通过传入的机器码编号，找到对应这个机器码的machine_desc描述符，并且返回这个描述符的指针。

(4)其实真正干活的函数是lookup_machine_type，找这个函数发现在head-common.S中，真正干活的函数是__lookup_machine_type

(5)__lookup_machine_type函数的工作原理：内核在建立的时候就把各种CPU架构的信息组织成一个一个的machine_desc结构体实例，然后都给一个段属性.arch.info.init，链接的时候会保证这些描述符会被连接在一起。__lookup_machine_type就去那个那些描述符所在处依次挨个遍历各个描述符，比对看机器码哪个相同。

__lookup_machine_type:
	adr	r3, 4b           //b�������ϲ鿴��4��Ŀ��
	ldmia	r3, {r4, r5, r6}
	sub	r3, r3, r4			@ get offset between virt&phys
	add	r5, r5, r3			@ convert virt addresses to
	add	r6, r6, r3			@ physical address space
1:	ldr	r3, [r5, #MACHINFO_TYPE]	@ get machine type
	teq	r3, r1				@ matches loader number?
	beq	2f				@ found
	add	r5, r5, #SIZEOF_MACHINE_DESC	@ next machine_desc
	cmp	r5, r6
	blo	1b
	mov	r5, #0				@ unknown machine
2:	mov	pc, lr
ENDPROC(__lookup_machine_type)

struct machine_desc {//机器码的描述符，一个硬件平台所有相关的描述信息都在其中
	/*
	 * Note! The first four elements are used
	 * by assembler code in head.S, head-common.S
	 */
	unsigned int		nr;		/* architecture number机器码	*/
	unsigned int		phys_io;	/* start of physical io物理io起始地址	*/
	unsigned int		io_pg_offst;	/* byte offset for io 
						 * page tabe entry	*/

	const char		*name;		/* architecture name	硬件平台的名字*/
	unsigned long		boot_params;	/* tagged list	传参内容的起始地址	*/

	unsigned int		video_start;	/* start of video RAM	*/
	unsigned int		video_end;	/* end of video RAM	*/

	unsigned int		reserve_lp0 :1;	/* never has lp0	*/
	unsigned int		reserve_lp1 :1;	/* never has lp1	*/
	unsigned int		reserve_lp2 :1;	/* never has lp2	*/
	unsigned int		soft_reboot :1;	/* soft reboot		*/
	void			(*fixup)(struct machine_desc *,
					 struct tag *, char **,
					 struct meminfo *);
	void			(*map_io)(void);/* IO mapping function	*/
	void			(*init_irq)(void);
	struct sys_timer	*timer;		/* system tick timer	*/
	void			(*init_machine)(void);
};

4.9 setup_arch函数进行了基本的cmdline处理

(1)这里说的cmdline就是指的uboot给kernel传参时传递的命令行启动参数，也就是uboot的bootargs。

static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE;

(2)有几个相关的变量需要注意：
default_command_line：看名字是默认的命令行参数，实际是一个全局变量字符数组，这个字符数组可以用来存东西。

CONFIG_CMDLINE：在.config文件中定义的（可以在make menuconfig中去更改设置），这个表示内核的一个默认的命令行参数。

(3)内核对cmdline的处理思路是：内核中自己维护了一个默认的cmdline（就是.config中配置的这一个），然后uboot还可以通过tag给kernel再传递一个cmdline。如果uboot给内核传cmdline成功则内核会优先使用uboot传递的这一个；如果uboot没有给内核传cmdline或者传参失败，则内核会使用自己默认的这个cmdline。以上说的这个处理思路就是在setup_arch函数中实现的。

void __init setup_arch(char **cmdline_p)
{
	struct tag *tags = (struct tag *)&init_tags;
	struct machine_desc *mdesc;
	char *from = default_command_line;

	unwind_init();

	setup_processor();
	mdesc = setup_machine(machine_arch_type);
	machine_name = mdesc->name;

	if (mdesc->soft_reboot)
		reboot_setup("s");

	if (__atags_pointer)
	{
		tags = phys_to_virt(__atags_pointer);
		printk("@@@@@@@ atags_pointer not null\n");
		
	}
	else if (mdesc->boot_params)
	{
		tags = phys_to_virt(mdesc->boot_params);
		printk("@@@@@@@ boot params not null\n");
	}
	printk("@@@@@@@linter#####boot_params:%p,mdesc->boot_params:%p\n",tags);
	/*
	 * If we have the old style parameters, convert them to
	 * a tag list.
	 */
	if (tags->hdr.tag != ATAG_CORE)
		convert_to_tag_list(tags);
	if (tags->hdr.tag != ATAG_CORE)
		tags = (struct tag *)&init_tags;

	if (mdesc->fixup)
		mdesc->fixup(mdesc, tags, &from, &meminfo);

	if (tags->hdr.tag == ATAG_CORE) {
		if (meminfo.nr_banks != 0)
			squash_mem_tags(tags);
		save_atags(tags);
		parse_tags(tags);
	}

	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;

	/* parse_early_param needs a boot_command_line */
	strlcpy(boot_command_line, from, COMMAND_LINE_SIZE);

	/* populate cmd_line too for later use, preserving boot_command_line */
	strlcpy(cmd_line, boot_command_line, COMMAND_LINE_SIZE);
	*cmdline_p = cmd_line;

	printk("$$$$$$$$$cmdline:%s\n",cmd_line);
	parse_early_param();

	paging_init(mdesc);
	request_standard_resources(&meminfo, mdesc);

#ifdef CONFIG_SMP
	smp_init_cpus();
#endif

	cpu_init();
	tcm_init();

	/*
	 * Set up various architecture-specific pointers
	 */
	init_arch_irq = mdesc->init_irq;
	system_timer = mdesc->timer;
	init_machine = mdesc->init_machine;

#ifdef CONFIG_VT
#if defined(CONFIG_VGA_CONSOLE)
	conswitchp = &vga_con;
#elif defined(CONFIG_DUMMY_CONSOLE)
	conswitchp = &dummy_con;
#endif
#endif
	early_trap_init();
}

4.10 实验验证内核的cmdline确定
(1)验证思路：首先给内核配置时配置一个基本的cmdline，然后在uboot启动内核时给uboot设置一个bootargs，然后启动内核看打印出来的cmdline和uboot传参时是否一样。

(2)在uboot中去掉bootargs，然后再次启动内核看打印出来的cmdline是否和内核中设置的默认的cmdline一样。

注意：uboot给内核传递的cmdline非常重要，会影响内核的运行，所以要谨慎。有时候内核启动有问题，可以分析下是不是uboot的bootargs设置不对。

注意：这个传参在这里确定出来之后，还没完。后面还会对这个传参进行解析。解析之后cmdline中的每一个设置项都会对内核启动有影响。

思考：内核为什么要这样设计？
传不同的参数，运行出不同的结果，有助于内核的灵活性

4.11 setup_command_line（start_kernel函数中）
也是在处理和命令行参数cmdline有关的任务。

static void __init setup_command_line(char *command_line)
{
	saved_command_line = alloc_bootmem(strlen (boot_command_line)+1);
	static_command_line = alloc_bootmem(strlen (command_line)+1);
	strcpy (saved_command_line, boot_command_line);
	strcpy (static_command_line, command_line);
}

4.12 parse_early_param&parse_args（start_kernel函数中）
(1)解析cmdline传参和其他传参

(2)这里的解析意思是把cmdline的细节设置信息给解析出来。譬如cmdline：
console=ttySAC2,115200 root=/dev/mmcblk0p2 rw init=/linuxrc rootfstype=ext3，
则解析出的内容就是就是一个字符串数组，数组中依次存放了一个设置项目信息。

console=ttySAC2,115200  一个
root=/dev/mmcblk0p2 rw  一个
init=/linuxrc 			一个
rootfstype=ext3			一个

(3)这里只是进行了解析，并没有去处理。也就是说只是把长字符串解析成了短字符串，最多和内核里控制这个相应功能的变量挂钩了，但是并没有去执行。执行的代码在各自模块初始化的代码部分。

void __init parse_early_param(void)
{
	static __initdata int done = 0;
	static __initdata char tmp_cmdline[COMMAND_LINE_SIZE];

	if (done)
		return;

	/* All fall through to do_early_param. */
	strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
	parse_early_options(tmp_cmdline);
	done = 1;
}

int parse_args(const char *name,
	       char *args,
	       struct kernel_param *params,
	       unsigned num,
	       int (*unknown)(char *param, char *val))
{
	char *param, *val;

	DEBUGP("Parsing ARGS: %s\n", args);

	/* Chew leading spaces */
	args = skip_spaces(args);

	while (*args) {
		int ret;
		int irq_was_disabled;

		args = next_arg(args, &param, &val);
		irq_was_disabled = irqs_disabled();
		ret = parse_one(param, val, params, num, unknown);
		if (irq_was_disabled && !irqs_disabled()) {
			printk(KERN_WARNING "parse_args(): option '%s' enabled "
					"irq's!\n", param);
		}
		switch (ret) {
		case -ENOENT:
			printk(KERN_ERR "%s: Unknown parameter `%s'\n",
			       name, param);
			return ret;
		case -ENOSPC:
			printk(KERN_ERR
			       "%s: `%s' too large for parameter `%s'\n",
			       name, val ?: "", param);
			return ret;
		case 0:
			break;
		default:
			printk(KERN_ERR
			       "%s: `%s' invalid for parameter `%s'\n",
			       name, val ?: "", param);
			return ret;
		}
	}

	/* All parsed OK. */
	return 0;
}

4.13 杂碎（start_kernel函数中）
(1)trap_init 设置异常向量表
(2)mm_init 内存管理模块初始化
(3)sched_init 内核调度系统初始化
(4)early_irq_init&init_IRQ 中断初始化
(5)console_init
控制台初始化,这个函数之前的那些输出信息其实并未真正输出，而是输入到一个缓冲区了，这个函数初始化之后，才真正输出出去；

总结：start_kernel函数中调用了很多的xx_init函数，全都是内核工作需要的模块的初始化函数。这些初始化之后内核就具有了一个基本的可以工作的条件了。如果把内核比喻成一个复杂机器，那么start_kernel函数就是把这个机器的众多零部件组装在一起形成这个机器，让他具有可以工作的基本条件。

4.14 rest_init
(1)这个函数之前内核的基本组装已经完成。
(2)剩下的一些工作就比较重要了，放在了一个单独的函数中，叫rest_init。

总结：start_kernel函数做的主要工作：打印了一些信息、内核工作需要的模块的初始化被依次调用（譬如内存管理、调度系统、异常处理···）、我们需要重点了解的就是setup_arch中做的2件事情：机器码架构的查找并且执行架构相关的硬件的初始化、uboot给内核的传参cmdline。

static noinline void __init_refok rest_init(void)
	__releases(kernel_lock)
{
	int pid;

	rcu_scheduler_starting();
	/*
	 * We need to spawn init first so that it obtains pid 1, however
	 * the init task will end up wanting to create kthreads, which, if
	 * we schedule it before we create kthreadd, will OOPS.
	 */
	kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
	numa_default_policy();
	pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
	rcu_read_lock();
	kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);
	rcu_read_unlock();
	complete(&kthreadd_done);
	unlock_kernel();

	/*
	 * The boot idle thread must execute schedule()
	 * at least once to get things moving:
	 */
	init_idle_bootup_task(current);
	preempt_enable_no_resched();
	schedule();
	preempt_disable();

	/* Call into cpu_idle with preempt disabled */
	cpu_idle();
}

4.15 操作系统去哪了
(1)rest_init中调用kernel_thread函数启动了2个内核线程，分别是：kernel_init和kthreadd

(2)调用schedule函数开启了内核的调度系统，从此linux系统开始工作起来了。

(3)rest_init最终调用cpu_idle函数结束了整个内核的启动。也就是说linux内核最终结束了一个函数cpu_idle。这个函数里面肯定是死循环。

(4)简单来说，linux内核最终的状态是：有事干的时候去执行有意义的工作（执行各个进程任务），实在没活干的时候就去死循环（实际上死循环也可以看成是一个任务）。

(5)之前已经启动了内核调度系统，调度系统会负责考评系统中所有的进程，这些进程里面只有有哪个需要被运行，调度系统就会终止cpu_idle死循环进程（空闲进程）转而去执行有意义的干活的进程。这样操作系统就工作起来了。

void cpu_idle(void)
{
	local_fiq_enable();

	/* endless idle loop with no priority at all */
	while (1) {
		tick_nohz_stop_sched_tick(1);
		leds_event(led_idle_start);
		while (!need_resched()) {
#ifdef CONFIG_HOTPLUG_CPU
			if (cpu_is_offline(smp_processor_id()))
				cpu_die();
#endif

			local_irq_disable();
			if (hlt_counter) {
				local_irq_enable();
				cpu_relax();
			} else {
				stop_critical_timings();
				pm_idle();
				start_critical_timings();
				/*
				 * This will eventually be removed - pm_idle
				 * functions should always return with IRQs
				 * enabled.
				 */
				WARN_ON(irqs_disabled());
				local_irq_enable();
			}
		}
		leds_event(led_idle_end);
		tick_nohz_restart_sched_tick();
		preempt_enable_no_resched();
		schedule();
		preempt_disable();
	}
}

4.16 什么是内核线程
(1)进程和线程。简单来理解，一个运行的程序就是一个进程。所以进程就是任务、进程就是一个独立的程序。独立的意思就是这个程序和别的程序是分开的，这个程序可以被内核单独调用执行或者暂停。

(2)在linux系统中，线程和进程非常相似，几乎可以看成是一样的。

(3)进程/线程就是一个独立的程序。应用层运行一个程序就构成一个用户进程/线程，那么内核中运行一个函数（函数其实就是一个程序）就构成了一个内核进程/线程。

(4)所以我们kernel_thead函数运行一个函数，其实就是把这个函数变成了一个内核线程去运行起来，然后他可以被内核调度系统去调度。说白了就是去调度器注册了一下，以后人家调度的时候会考虑你。

4.17 进程0、进程1、进程2
(1)截至目前为止，我们一共涉及到3个内核进程/线程。

(2)操作系统是用一个数字来表示/记录一个进程/线程的，这个数字就被称为这个进程的进程号。这个号码是从0开始分配的。因此这里涉及到的三个进程分别是linux系统的进程0、进程1、进程2.

(3)在linux命令行下，使用ps命令可以查看当前linux系统中运行的进程情况。

(4)我们在ubuntu下ps -aux可以看到当前系统运行的所有进程，可以看出进程号是从1开始的。为什么不从0开始，因为进程0不是一个用户进程，而属于内核进程。有些进程虽然调用后死了，但进程号却依然保留，故而你会看到进程号3000之后就是几万的情况。

(5)三个进程
进程0：进程0其实就是刚才讲过的idle进程，叫空闲进程（内核进程），也就是死循环。其永远不会终止其可被调度，一会儿执行其，一会儿执行另一个进程。

进程1：kernel_init函数就是进程1，这个进程被称为init进程。

进程2：kthreadd函数就是进程2，这个进程是linux内核的守护进程。这个进程是用来保证linux内核自己本身能正常工作的。

总结4：分析到此，发现后续的料都在进程1.所以后面课程会重点从进程1出发，分析之后发生的事情。

5 init进程详解

5.1 init进程完成了从内核态向用户态的转变
(1)**一个进程2种状态。init进程刚开始运行的时候是内核态，它属于一个内核线程，然后他自己运行了一个用户态下面的程序后把自己强行转成了用户态。**因为init进程自身完成了从内核态到用户态的过度，因此后续的其他进程都可以工作在用户态下面了。

(2)内核态下做了什么？

重点就做了一件事情，就是挂载根文件系统并试图找到用户态下的那个init程序。init进程要把自己转成用户态就必须运行一个用户态的应用程序（这个应用程序名字一般也叫init），要运行这个应用程序就必须得找到这个应用程序，要找到它就必须得挂载根文件系统，因为所有的应用程序都在文件系统中。

内核源代码中的所有函数都是内核态下面的，执行任何一个都不能脱离内核态。应用程序必须不属于内核源代码，这样才能保证自己是用户态。也就是说我们这里执行的这个init程序和内核不在一起，他是另外提供的。提供这个init程序的那个人就是根文件系统。

(3)用户态下做了什么？

init进程大部分有意义的工作都是在用户态下进行的（但其是由内核态转换来的）。init进程对我们操作系统的意义在于：其他所有的用户进程都直接或者间接派生自init进程。

(4)如何从内核态跳跃到用户态？还能回来不？

init进程在内核态下面时，通过一个函数kernel_execve来执行一个用户空间编译连接的应用程序就跳跃到用户态了。注意这个跳跃过程中进程号是没有改变的，所以一直是进程1。这个跳跃过程是单向的，也就是说一旦执行了init程序转到了用户态下整个操作系统就算真正的运转起来了，以后只能在用户态下工作了，用户态下想要进入内核态只有走API这一条路了。
2、init进程构建了用户交互界面

(1)init进程是其他用户进程的老祖宗。linux系统中一个进程的创建是通过其父进程创建出来的。根据这个理论只要有一个父进程就能生出一堆子孙进程了。

(2)init启动了login进程（用户登陆）、命令行进程（提供命令行界面）、shell进程（对命令行的命令进行解析和执行）

(3)shell进程启动了其他用户进程。命令行和shell一旦工作了，用户就可以在命令行下通过./xx的方式来执行其他应用程序，每一个应用程序的运行就是一个进程。

总结：本节的主要目的是让大家认识到init进程如何一步步发展成为我们平时看到的那种操作系统的样子。

4、打开控制台
(1)linux系统中每个进程都有自己的一个文件描述符表，表中存储的是本进程打开的文件。

(2)linux系统中有一个设计理念：一切皆是文件。所以设备也是以文件的方式来访问的。我们要访问一个设备，就要去打开这个设备对应的文件描述符。譬如/dev/fb0这个设备文件就代表LCD显示器设备，/dev/buzzer代表蜂鸣器设备，/dev/console代表控制台设备。

kernel/init/main.c   kernel_init()函数
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
	printk(KERN_WARNING "Warning: unable to open an initial console.\n");

(void) sys_dup(0);  //复制文件描述符
(void) sys_dup(0);	//复制文件描述符

(3)这里我们打开了/dev/console文件，并且复制了2次文件描述符，一共得到了3个文件描述符。这三个文件描述符分别是0、1、2.这三个文件描述符就是所谓的：标准输入、标准输出、标准错误。

(4)进程1打开了三个标准输出输出错误文件，因此后续的进程1衍生出来的所有的进程默认都具有这3个三件描述符。

5、挂载根文件系统
(1)prepare_namespace函数（920行）中挂载根文件系统
kernel/init/main.c kernel_init()函数中

(2)根文件系统在哪里？根文件系统的文件系统类型是什么？ uboot通过传参来告诉内核这些信息。
uboot传参中的root=/dev/mmcblk0p2 rw 这一句就是告诉内核根文件系统在哪里
uboot传参中的rootfstype=ext3这一句就是告诉内核rootfs的类型。

(3)如果内核挂载根文件系统成功，则会打印出：VFS: Mounted root (ext3 filesystem) on device 179:2.

如果挂载根文件系统失败，则会打印：No filesystem could mount root, tried: yaffs2

(4)如果内核启动时挂载rootfs失败，则后面肯定没法执行了，肯定会死。内核中设置了启动失败休息5s自动重启的机制，因此这里会自动重启，所以有时候大家会看到反复重启的情况。

(5)如果挂载rootfs失败，可能的原因有：
最常见的错误就是uboot的bootargs设置不对。
rootfs烧录失败（fastboot烧录不容易出错，以前是手工烧录很容易出错）
rootfs本身制作失败的。（尤其是自己做的rootfs，或者别人给的第一次用）

6、执行用户态下的进程1程序
init_post()函数（main.c 929行）
(1)上面一旦挂载rootfs成功，则进入rootfs中寻找应用程序的init程序，这个程序就是用户空间的进程1.找到后用run_init_process去执行他（main.c 853行）

static void run_init_process(char *init_filename)
{
	argv_init[0] = init_filename;
	kernel_execve(init_filename, argv_init, envp_init);
}

(2)我们如果确定init程序是谁？

方法是：先从uboot传参cmdline中看有没有指定，如果有指定先执行cmdline中指定的程序。cmdline中的init=/linuxrc这个就是指定rootfs中哪个程序是init程序。这里的指定方式就表示我们rootfs的根目录下面有个名字叫linuxrc的程序，这个程序就是init程序。

如果uboot传参cmdline中没有init=xx或者cmdline中指定的这个xx执行失败，还有备用方案。第一备用：/sbin/init，第二备用：/etc/init，第三备用：/bin/init，第四备用：/bin/sh。
如果以上都不成功，则认命了，死了。

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");

六、cmdline常用参数

1、格式简介
(1)格式就是由很多个项目用空格隔开依次排列，每个项目中都是项目名=项目值

(2)整个cmdline会被内核启动时解析，解析成一个一个的项目名=项目值的字符串。这些字符串又会被再次解析从而影响启动过程。

2、root=
(1)这个是用来指定根文件系统在哪里的

(2)一般格式是root=/dev/xxx（一般如果是nandflash上则/dev/mtdblock2，如果是inand/sd的话则/dev/mmcblk0p2）

(3)如果是nfs的rootfs，则root=/dev/nfs。

3、rootfstype=
根文件系统的文件系统类型，一般是jffs2、yaffs2、ext3、ubi

4、console=
(1)控制台信息声明，譬如console=/dev/ttySAC0,115200表示控制台使用串口0，波特率是115200.

(2)正常情况下，内核启动的时候会根据console=这个项目来初始化硬件，并且重定位console到具体的一个串口上，所以这里的传参会影响后续是否能从串口终端上接收到内核的信息。

5、mem=
mem=用来告诉内核当前系统的内存有多少
6、init=
init=用来指定进程1的程序pathname，一般都是init=/linuxrc

7、常见cmdline介绍
(1)console=ttySAC2,115200 root=/dev/mmcblk0p2 rw init=/linuxrc rootfstype=ext3

第一种这种方式对应rootfs在SD/iNand/Nand/Nor等物理存储器上。这种对应产品正式出货工作时的情况。

(2)root=/dev/nfs nfsroot=192.168.1.141:/root/s3c2440/build_rootfs/aston_rootfs ip=192.168.1.10:192.168.1.141:192.168.1.1:255.255.255.0::eth0:off init=/linuxrc console=ttySAC0,115200

第二种这种方式对应rootfs在nfs上，这种对应我们实验室开发产品做调试的时候。

七、内核中架构相关代码简介
1、内核代码基本分为3块
(1)arch。 本目录下全是cpu架构有关的代码
(2)drivers 本目录下全是硬件的驱动
(3)其他 相同点是这些代码都和硬件无关，因此系统移植和驱动开发的时候这些代码几乎都是不用关注的。

2、架构相关的常用目录名及含义
kernel/arch/arm/下

(1)mach（mach就是machine architecture）

arch/arm目录下的一个mach-xx目录就表示一类machine的定义，这类machine的共同点是都用xx(如2440、210等)这个cpu来做主芯片。（譬如mach-s5pv210这个文件夹里面都是s5pv210这个主芯片的开发板machine）；mach-xx目录里面的一个mach-yy.c文件（smdkc110/goni/smdkv210）中定义了一个开发板（一个开发板对应一个机器码），这个是可以被扩展的。

(2)plat xx（plat是platform的缩写，含义是平台）

plat在这里可以理解为SoC，也就是说这个plat目录下都是SoC里面的一些硬件（内部外设）相关的一些代码。在内核中把SoC内部外设相关的硬件操作代码就叫做平台设备驱动。如plat-s5p

dev-mfc.c 视频编解码相关的文件

(3)include。这个include目录中的所有代码都是架构相关的头文件。（linux内核通用的头文件在内核源码树根目录下的include目录里,即kernel/include）

3、补充
(1)内核中的文件结构很庞大、很凌乱（不同版本的内核可能一个文件存放的位置是不同的），会给我们初学者带来一定的困扰。

(2)头文件目录include有好几个，譬如：
kernel/include 内核通用头文件
kernel/arch/arm/include 架构相关的头文件
kernel/arch/arm/include/asm
kernel\arch\arm\include\asm\mach
kernel\arch\arm\mach-s5pv210\include\mach
kernel\arch\arm\plat-s5p\include\plat

(3)内核中包含头文件时有一些格式

#include <linux/kernel.h> kernel/include/linux/kernel.h
#include <asm/mach/arch.h> kernel/arch/arm/include/asm/mach/arch.h
#include <asm/setup.h> kernel/arch/arm/include/asm/setup.h
#include <plat/s5pv210.h> kernel/arch/arm/plat-s5p/include/plat/s5pv210.h

(4)有些同名的头文件是有包含关系的，有时候我们需要包含某个头文件时可能并不是直接包含他，而是包含一个包含了他的头文件。

注：本资料大部分由朱老师物联网大讲堂课程笔记整理而来，如有侵权，联系删除！水平有限，如有错误，欢迎各位在评论区交流。