最后再整一篇多核的引导，称热打铁
Linux内核的引导
引导Linux系统的过程包括很多阶段，这里将以引导ARM Linux为例来进行讲解（见图3.11）。
一般的SoC内嵌入了bootrom，上电时bootrom运行。
对于CPU0而言，bootrom会去引导bootloader，而其他CPU则判断自己是不是CPU0，不是就进入WFI的状态等待CPU0来唤醒它。
CPU0引导bootloader，bootloader引导Linux内核，在内核启动阶段，CPU0会发中断唤醒CPU1，之后CPU0和CPU1都投入运行。
CPU0导致用户空间的init程序被调用，init程序再派生其他进程，派生出来的进程再派生其他进程。
CPU0和CPU1共担这些负载，进行负载均衡。（这里的运行策略可能不是这么简单，除非核的配置是一样的，一般都不是。）
bootrom是各个SoC厂家根据自身情况编写的，目前的SoC一般都具有从SD、eMMC、NAND、USB等介质启动的能力，这证明这些bootrom内部的代码具备读SD、NAND等能力。（读取这些介质上的文件到RAM去运行）
嵌入式Linux领域最著名的bootloader是U-Boot，其代码仓库位于http://git.denx.de/u-boot.git/。
早前，bootloader需要将启动信息以ATAG的形式封装，并且把ATAG的地址填充在r2寄存器中，机型号填充在r1寄存器中，详见内核文档Documentation/arm/booting。
在ARM Linux支持设备树（Device Tree）后，bootloader则需要把dtb的地址放入r2寄存器中。（所以现在不用那个tag符号表了）
当然，ARM Linux也支持直接把dtb和zImage绑定在一起的模式 （内核ARM_APPENDED_DTB选项“Use appended device tree blob to zImage”），这样 r2寄存器就不再需要填充dtb地址了。
类似zImage的内核镜像实际上是由没有压缩的解压算法和被压缩的内核组成，所以在bootloader跳入zImage以后，它自身的解压缩逻辑就把内核的镜像解压缩出来了。
关于内核启动，与我们关系比较大的部分是每个平台的设备回调函数和设备属性信息，它们通常包装在DT_MACHINE_START和MACHINE_END之间，包含reserve（）、map_io（）、init_machine（）、init_late（）、smp等回调函数或者属性。
这些回调函数会在内核启动过程中被调用。后续章节会进一步介绍。
用户空间的init程序常用的有busybox init、SysVinit、systemd等，它们的职责类似，把整个系统启动，最后形成一个进程树，比如Ubuntu上运行的pstree：
init─┬─NetworkManager─┬─dhclient │ └─2*[{NetworkManager}] ├─VBoxSVC─┬─VirtualBox───29*[{VirtualBox}] │ └─11*[{VBoxSVC}] ├─VBoxXPCOMIPCD ├─accounts-daemon───{accounts-daemon} ├─acpid ├─apache2───5*[apache2] ├─at-spi-bus-laun───2*[{at-spi-bus-laun}] ├─atd ├─avahi-daemon───avahi-daemon ├─bluetoothd ├─cgrulesengd ├─colord───2*[{colord}] ├─console-kit-dae───64*[{console-kit-dae}] ├─cpufreqd───{cpufreqd} ├─cron ├─cupsd ├─2*[dbus-daemon] ├─dbus-launch ├─dconf-service───2*[{dconf-service}] ├─dnsmasq
这一顿操作，结合前面在bootloader方面从粗到细，从浅到深到浅写了很多。
真的让人对这个bootloader这个部分，起码说宏观上的理解，应该算是比较清晰了。
参考资料：
《Linux设备驱动开发详解》
