逐行分析u-boot..doc

逐行分析u-boot 15.1 Bootloader简介 [编辑] 15.1.1 Bootloader的概念 一。 Bootloader的引入 从前面的硬件实验可以知道，系统上电之后，需要一段程序来进行初始化：关闭WATCHDOG、改变系统时钟、初始化存储控制器、将更多的代码复制到内存中等等。如果它能将操作系统内核(无论从本地，比如Flash；还是从远端，比如通过网络)复制到内存中运行，就称这段程序为Bootloader。 简单地说，Bootloader就是这么一小段程序，它在系统上电时开始执行，初始化硬件设备、准备好软件环境，最后调用操作系统内核。 可以增强Bootloader的功能，比如增加网络功能、从PC上通过串口或网络下载文件、烧写文件、将Flash上压缩的文件解压后再运行等──这就是一个功能更为强大的Bootloader，也称为Monitor。实际上，在最终产品中用户并不需要这些功能，它们只是为了方便开发。 Bootloader的实现严重依赖于具体硬件，在嵌入式系统中硬件配置千差万别，即使是相同的CPU，它的外设(比如Flash)也可能不同，所以不可能有一个Bootloader支持所有的CPU、所有的电路板。即使是支持CPU架构比较多的U-Boot，也不是一拿来就可以使用的(除非里面的配置刚好与你的板子相同)，需要进行一些移植。 二。 Bootloader的启动方式 CPU上电后，会从某个地址开始执行。比如MIPS结构的CPU会从0xBFC00000取第一条指令，而ARM结构的CPU则从地址0x0000000开始。嵌入式单板中，需要把存储器件ROM或Flash等映射到这个地址，Bootloader就存放在这个地址开始处，这样一上电就可以执行。 在开发时，通常需要使用各种命令操作Bootloader，一般通过串口来连接PC和开发板，可以在串口上输入各种命令、观察运行结果等。这也只是对开发人员才有意义，用户使用产品时是不用接串口来控制Bootloader的。从这个观点来看，Bootloader可以分为两种操作模式(Operation Mode)： （1）启动加载(Boot loading)模式。 上电后，Bootloader从板子上的某个固态存储设备上将操作系统加载到RAM中运行，整个过程并没有用户的介入。产品发布时，Bootloader工作在这种模式下。 （2）下载(Downloading)模式。 在这种模式下，开发人员可以使用各种命令，通过串口连接或网络连接等通信手段从主机(Host)下载文件(比如内核映像、文件系统映像)，将它们直接放在内存运行或是烧入Flash类固态存储设备中。 板子与主机间传输文件时，可以使用串口的xmodem/ymodem/zmodem协议，它们使用简单，只是速度比较慢；还可以使用网络通过tftp、nfs协议来传输，这时，主机上要开启tftp、nfs服务；还有其他方法，比如USB等。 像Blob或U-Boot等这样功能强大的Bootloader通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进行切换。比如，U-Boot在启动时处于正常的启动加载模式，但是它会延时若干秒(这可以设置)等待终端用户按下任意键而将U-Boot切换到下载模式。如果在指定时间内没有用户按键，则U-Boot继续启动Linux内核。 [编辑] 15.1.2 Bootloader的结构和启动过程 1. 概述 在移植之前先了解Bootloader的一些通用概念，对理解它的代码会有所帮助。 在一个嵌入式Linux系统中，从软件的角度通常可以分为4个层次： （1）引导加载程序，包括固化在固件(firmware)中的 boot 代码(可选)和Bootloader两大部分。 有些CPU在运行Bootloader之前先运行一段固化的程序(固件，firmware)，比如x86结构的CPU就是先运行BIOS中的固件，然后才运行硬盘第一个分区(MBR)中的Bootloader。 在大多嵌入式系统中并没有固件，Bootloader是上电后执行的第一个程序。 （2）Linux内核。 特定于嵌入式板子的定制内核以及内核的启动参数。内核的启动参数可以是内核默认的，或是由Bootloader传递给它的。 （3）文件系统。 包括根文件系统和建立于Flash内存设备之上的文件系统。里面包含了Linux系统能够运行所必需的应用程序、库等，比如可以给用户提供操作Linux的控制界面的shell程序，动态连接的程序运行时需要的glibc或uClibc库，等等。 （4）用户应用程序。 特定于用户的应用程序，它们也存储在文件系统中。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用