为什么需要U-BOOT?

一、计算机系统的主要部件

（1）计算机系统就是以CPU为核心来运行的系统。

        典型的计算机系统有：

                PC机（台式机+笔记本）

                嵌入式设备（手机、平板电脑、游戏机）

                单片机（家用电器像电饭锅、空调）

（2）计算机系统的组成部件非常多，不同的计算机系统组成部件也不同。但是所有的计算机系统运行时需要的主要核心部件都是3个东西：

        CPU+外部存储器（Flash/硬盘）+ 内部存储器（DDR SDRAM/SDRAM/SRAM）

二、计算机系统的启动过程

1、PC机的启动过程

（1）部署：

        典型的PC机的BIOS程序部署在PC机主板上（随主板出厂时已经预制了）；

        操作系统部署在硬盘上；

        内存在掉电时无作用，CPU在掉电时不工作。

（2）启动过程：

        PC上电后先执行BIOS程序（Basic Input Output System，基本输入输出系统）。实际上PC的BIOS就是NorFlash。BIOS程序负责初始化DDR内存，负责初始化硬盘，然后从硬盘上将OS镜像读取到DDR中，然后跳转到DDR中去执行OS直到启动（OS启动后BIOS就无用了）。

        （BIOS：一组固化到计算机内主板上一个ROM芯片上的程序，它保存着计算机最重要的基本输入输出的程序、开机后自检程序和系统自启动程序，它可从CMOS中读写系统设置的具体信息。其主要功能是为计算机提供最底层的、最直接的硬件设置和控制。）

        

2、典型嵌入式linux系统启动过程

（1）典型嵌入式系统的部署：

        uboot程序部署在Flash（能作为启动设备的Flash）上；

        OS部署在FLash（嵌入式系统中用Flash代替了硬盘）上；

        内存在掉电时无作用，CPU在掉电时不工作。

（2）启动过程：

        嵌入式系统上电后先执行uboot，然后uboot负责初始化DDR，初始化Flash，然后将OS从Flash中读取到DDR中，然后启动OS（OS启动后uboot就无用了）。

总结：

        嵌入式系统和PC机的启动过程几乎没有两样，只是BIOS成了uboot，硬盘成了Flash。

3、android系统启动过程

（1）Android系统的启动和Linux系统（前面讲的典型的嵌入式系统启动）几乎一样。

        即：前面完全一样，只是在内核启动后加载根文件系统后不同了。

        android的启动和linux的差别在第二阶段。

（2）可以认为启动分为2个阶段：

        第一个阶段是uboot到OS启动；

        第二个阶段是OS启动后到rootfs加载到命令行执行；

总结：uboot到底是干嘛的?

（1）启动操作系统内核。

（2）部署整个计算机系统。

（3）驱动一些外设比如Flash。lcd，触摸屏等。

（4）提供一个命令行界面供人来操作。

三、UBOOT是什么？

1、uboot从哪里来？

（1）uboot是SourceForge一 个德国人发起的的开源项目。

（2）uboot就是由一个人发起，然后由整个网络上所有感兴趣的人共同维护发展而来的一个bootloader。

2、uboot的发展历程

（1）自己使用的小开源项目。

（2）被更多人认可使用

（3）被很多SoC厂商默认支持。

总结：uboot经过多年发展，已经成为事实上的业内bootloader标准。现在大部分的嵌入式设备都会默认使用uboot来做为bootloader。

3、uboot的版本号问题

（1）早期的uboot的版本号类似于这样：uboot1.3.4。后来版本号便成了类似于uboot-2010.06。

（2）uboot的核心部分几乎没怎么变化，越新的版本支持的开发板越多而已，对于一个老版本的芯片来说，新旧版本的uboot并没有差异。

4、什么是uboot的可移植性？

（1）uboot（universal bootloader，通用的启动代码），通用的意思就是在各种地方都可以用。所以说uboot具有可移植性。

（2）uboot具有可移植性并不是说uboot在哪个开发板都可以随便用，而是说uboot具有在源代码级别的移植能力，可以针对多个开发板进行移植，移植后就可以在这个开发板上使用了。

四、UBOOT的功能

1、自身可开机直接启动

（1）一般的SoC（System on Chip，系统级芯片）都支持多种启动方式，譬如SD卡启动、NorFlash启动、NandFlash启动等·····uboot要能够开机启动，必须根据具体的SoC的启动设计来设计uboot。

（2）uboot必须进行和硬件相对应的代码级别的更改和移植，才能够保证可以从相应的启动介质启动。uboot中第一阶段的start.S文件中具体处理了这一块。

2、能够引导操作系统内核启动并给内核传参

（1）uboot的终极目标就是启动内核。

（2）linux内核在设计的时候，设计为可以被传参。

        在uboot中事先给linux内核准备一些启动参数放在内存中特定位置然后传给内核。

        内核启动后会到这个特定位置去取uboot传给他的参数，然后在内核中解析这些参数，这些参数将被用来指导linux内核的启动过程。

3、能提供系统部署功能

（1）uboot必须能够被人借助而完成整个系统（包括uboot、kernel、rootfs等的镜像）在Flash上的烧录下载工作。

4 、 能进行soc级和板级硬件管理

（1）uboot中实现了一部分硬件的控制能力（uboot中初始化了一部分硬件），因为uboot为了完成一些任务必须让这些硬件工作。

        譬如uboot要在刷机时LCD上显示进度条就必须能驱动LCD，譬如uboot能够通过串口提供操作界面就必须驱动串口。譬如uboot要实现网络功能就必须驱动网卡芯片。

（2）SoC级（譬如串口）就是SoC内部外设，板级就是SoC外面开发板上面的硬件（譬如网卡、iNand）

5、uboot的“生命周期”

（1）uboot的生命周期就：uboot什么时候开始运行，什么时候结束运行。

（2）uboot本质上是一个裸机程序（不是操作系统）。

 一旦uboot开始运行，SoC就会单纯运行uboot（即uboot运行时，别的程序不可能同时运行）；

 一旦uboot结束运行，则无法再回到uboot（所以uboot启动了内核后uboot自己本身就死了，要想再次看到uboot界面只能重启系统）。重启并不是复活了刚才的uboot，重启只是uboot的另一生。

（3）uboot的入口和出口。

        uboot的入口：开机自动启动；

        uboot的唯一出口：启动内核。

        uboot还可以执行很多别的任务（譬如烧录系统），但是其他任务执行完后都可以回到uboot的命令行继续执行uboot命令，而启动内核命令一旦执行就回不来了。

总结：一切都是为了启动内核。

五、uboot的工作方式

1、从裸机程序镜像uboot.bin说起

（1）uboot的本质就是一个裸机程序，和我们裸机全集中写的那些裸机程序xx.bin并没有本质区别。如果非说要有区别，那就是：我们写的大部分小于16KB，而uboot大于16KB（一般uboot在180k-400k之间)。

（2）uboot本身是一个开源项目，由若干个.c文件和.h文件组成，配置编译之后会生成一个uboot.bin，这就是uboot这个裸机程序的镜像文件。然后这个镜像文件被合理的烧录到启动介质中拿给SoC去启动。也就是说uboot在没有运行时表现为uboot.bin，一般躺在启动介质中。

（3）uboot运行时会被加载到内存中，然后一条指令一条指令的拿给CPU去运行。

2、uboot的命令式shell界面

（1）普通的裸机程序运行起来就直接执行了，执行时效果和代码有关。

（2）有些程序需要和人进行交互，于是乎程序中就实现了一个shell（shell就是提供人机交互的一个界面。

3、掌握uboot使用的2个关键点：命令和环境变量

（1）命令：uboot启动后大部分时间和工作都是在shell下完成的。譬如：

        uboot要部署系统要在shell下输入命令，

        要设置环境变量也得在命令行下，

        要启动内核也要在命令行底下敲命令。

（2）uboot的环境变量和操作系统的环境变量工作原理和方式几乎完全相同。uboot在设计时借助了操作系统的设计理念（命令行工作方式借鉴了linux终端命令行，环境变量借鉴了操作系统的环境变量，uboot的驱动管理几乎完全照抄了linux的驱动框架）。

        环境变量：可以被认为是系统的全局变量，运行时的配置属性。环境变量名都是系统内置的（认识就认识，不认识就不认识，这部分是系统自带的默认的环境变量，譬如PATH；但是也有一部分环境变量是自己添加的，自己添加的 系统就不认识 但是我们自己认识）。

        系统或者我们自己的程序在运行时可以通过读取环境变量来指导程序的运行。这样设计的好处就是灵活。譬如我们要让一个程序更改运行方法，不用去重新修改程序代码再重新编译运行，而只要修改相应的环境变量就可以了。

六、uboot中对Flash和DDR的管理

1、uboot阶段Flash的分区

（1）分区：对Flash进行分块管理。

（2）PC机等产品中，因为大家都是在操作系统下使用硬盘的，整个硬盘由操作系统统一管理。操作系统会使用文件系统帮我们管理硬盘空间（管理保证了文件之间不会互相堆叠），于是使用者不用自己太过在意分区问题。

（3）在uboot中是没有操作系统的，因此我们对Flash（相当于硬盘）的管理必须事先使用分区界定。实际上在uboot中和kernel中都有个分区表，分区表就是我们在做系统移植时对Flash的整体管理分配方法。有了这个界定后，我们在部署系统时按照分区界定方法来部署，uboot和kernel的软件中也是按照这个分区界定来工作，就不会错。

（4）分区方法不是一定的，不是固定的，是可以变动的。但是在一个移植中必须事先设计好定死，一般在设计系统移植时就会定好，定的标准是：

       ① uboot： uboot必须从Flash起始地址开始存放（也许是扇区0，也许是扇区1，也许是其他，取决于SoC的启动设计）。uboot分区的大小必须保证uboot肯定能放下，一般设计为512KB或者1MB（因为一般uboot肯定不足512KB，给再大其实也可以工作，但是浪费）；

       ② 环境变量：环境变量分区一般紧贴着uboot来存放，大小为32KB或者更多一点。

       ③ kernel：kernel可以紧贴环境变量存放，大小一般为3MB或5MB或其他。

       ④rootfs：······

        剩下的就是自由分区，一般kernel启动后将自由分区挂载到rootfs下使用。

总结：一般规律如下：

（1）各分区彼此相连，前面一个分区的结尾就是后一个分区的开头。

（2）整个flash充分利用，从开头到结尾。

（3）uboot必须在Flash开头，其他分区相对位置是可变的。

（4）各分区的大小由系统移植工程师自己来定，一般定为合适大小（不能太小，太小了容易溢出；不能太大，太大了浪费空间）。

（5）分区在系统移植前确定好，在uboot中和kernel中使用同一个分区表。将来在系统部署时和系统代码中的分区方法也必须一样。

2、uboot阶段DDR的分区

（1）DDR的分区和Flash的分区不同。主要是因为Flash是掉电存在的，而DDR是掉电消失。因此可以说DDR是每次系统运行时才开始部署使用的。

（2）内存的分区主要是在linux内核启动起来之前，linux内核启动后内核的内存管理模块会接管整个内存空间，那时候就不用我们来管了。

（3）注意内存分区关键就在于内存中哪一块用来干什么必须分配好，以避免各个不同功能使用了同一块内存造成的互相踩踏。

        譬如说我们tftp 0x23E00000 zImage去下载zImage到内存的0x23E00000处就会出错，因为这个内存处实际是uboot的镜像所在。这样下载会导致下载的zImage把内存中的uboot覆盖掉。