UBOOT基础知识分析

U-boot分析与移植<1）----bootloader分析一、Boot Loader 概念就是在操作系统内核运行之前运行的一段小程序。

通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境，他就是所谓的引导加载程序<Boot Loader）。

嵌入式软件在Flash存储器中的分布图二、为什么需要BootLoader？BootLoader的终极任务是引导操作系统，所谓引导操作系统，就是启动内核，在启动内核之前所需要的环境<如初始化sdram，设置cpu模式等，下面会介绍）都是由BootLoader 来完成的。

试想一下，如果你要启动内核，让内核在内存上跑，但连sdram都没有初始化，这显然不行。

在s3c2440中，系统在上电或复位时通常都从地址 0x00000000 处开始执行，而在这个地址处安排的通常就是系统的Boot Loader 程序。

在x86的PC机上，Boot Loader = BIOS + GRUB/LILO。

三、BootLoader的选择有些人误认为BootLoader=U-Boot，其实BootLoader只是所有引导加载程序中的一个总称。

四、启动过程S3C2440 支持两种方式的启动：Nor Flash 启动和Nand Flash 启动。

Nor Flash 和Nand Flash 都是非易失性存储器，Nor Flash 的特点是芯片内执行和不能直接写操作，程序可以直接在其中运行，而不必将程序读取到RAM 中运行。

Nor Flash 虽然具有这个优点，但是它的性价比远低于Nand Flash，因而很多系统采用Nand Flash 启动。

Nand Flash 的特点是采用非线性存储模式，程序无法在其中运行，它只能作为程序或数据的存储载体，存储在其中的程序只能先拷贝到RAM 中才能运行。

刷入uboot和大分区的方法一、概念解释1.1 uboot是什么U-boot是一种开源的引导加载程序，它通常用于嵌入式系统的启动过程中，负责引导操作系统的启动和初始化硬件设备。

在嵌入式系统中，uboot扮演着非常重要的角色，它的稳定性和可靠性直接影响整个系统的稳定性。

1.2 分区的作用分区是将存储设备按照一定的规则划分成多个逻辑部分的过程。

对于嵌入式系统而言，合理的分区管理可以提高存储设备的利用率，同时也方便系统的管理和维护。

二、刷入uboot的步骤2.1 确定目标设备我们需要明确要刷入uboot的目标设备是什么，是一个嵌入式开发板还是其他类型的设备。

不同的设备可能需要不同的uboot版本和刷入方法。

2.2 获取uboot源码接下来，我们需要从冠方或者其他可靠渠道获取uboot的源码。

一般来说，冠方的源码是最稳定和可靠的选择，我们可以从冠方的仓库或者全球信息站上下载源码。

2.3 编译uboot获取源码之后，我们需要根据目标设备的硬件配置，对源码进行编译。

在编译之前，我们需要配置好交叉编译工具链和相关的环境变量，确保编译过程顺利进行。

2.4 刷入uboot当uboot源码编译完成之后，我们需要将编译生成的二进制文件刷入目标设备的存储设备中。

这个过程可能涉及到串口或者其他调试工具的使用，需要特别注意刷入过程中的各项参数和配置。

2.5 测试uboot刷入完成后，我们需要对uboot进行测试，确保它能够正常启动，并且能够正确识别硬件设备。

三、创建大分区的步骤3.1 确定分区方案在创建大分区之前，我们需要确定硬盘或者TF卡的分区方案，包括分区的数量、大小和格式等。

3.2 使用分区工具常用的分区工具有fdisk、parted等，我们可以使用这些工具来创建和调整分区。

在使用分区工具时，需要特别注意当前存储设备上是否有重要的数据，避免误操作导致数据丢失。

3.3 格式化分区创建完分区之后，我们需要对分区进行格式化，以便后续的数据存储和管理。

uboot命令U-boot基础现在为Linux开放源代码Bootloader有很多，blob、redboot 及U-BOOT等，其中U-BOOT是目前用来开发嵌入式系统引导代码使用最为广泛的Bootloader。

它支持POWERPC、ARM、MIPS和 X86等处理器，支持嵌入式操作系统有Linux、Vxworks及NetBSD等。

2.1 U-boot源代码目录结构|-- board 平台依赖，存放电路板相关的目录文件|-- common 通用多功能函数的实现|-- cpu 平台依赖，存放cpu相关的目录文件|-- disk 通用。

硬盘接口程序|-- doc 文档|-- drivers 通用的设备驱动程序，如以太网接口驱动|-- dtt|-- examples 应用例子|-- fs 通用存放文件系统的程序|-- include 头文件和开发板配置文件，所有开发板配置文件放在其configs 里|-- lib_arm 平台依赖，存放arm架构通用文件|-- lib_generic 通用的库函数|-- lib_i386 平台依赖，存放x86架构通用文件|-- lib_m68k 平台依赖|-- lib_microblaze 平台依赖|-- lib_mips 平台依赖|-- lib_nios 平台依赖|-- lib_ppc平台依赖，存放ppc架构通用文件|-- net 存放网络的程序|-- post 存放上电自检程序|-- rtc rtc的驱动程序`-- tools 工具详细实例：board：开发板相关的源码，不同的板子对应一个子目录，内部放着主板相关代码。

Board/at91rm9200dk/at91rm9200.c, config.mk, Makefile, flash.c ,u-boot.lds等都和具体开发板的硬件和地址分配有关。

common：与体系结构无关的代码文件，实现了u-boot所有命令，其中内置了一个shell脚本解释器(hush.c, a prototype Bourne shell grammar parser), busybox中也使用了它。

深度解析：嵌入式之uboot1.为什么要有uboot1.1、计算机系统的主要部件(1)计算机系统就是以CPU为核心来运行的系统。

典型的计算机系统有：PC机（台式机+笔记本）、嵌入式设备（手机、平板电脑、游戏机）、单片机（家用电器像电饭锅、空调）(2)计算机系统的组成部件非常多，不同的计算机系统组成部件也不同。

但是所有的计算机系统运行时需要的主要核心部件都是3个东西：CPU + 外部存储器（Flash/硬盘） + 内部存储器（DDR SDRAM/SDRAM/SRAM）1.2、PC机的启动过程(1)部署：典型的PC机的BIOS程序部署在PC机主板上（随主板出厂时已经预制了），操作系统部署在硬盘上，内存在掉电时无作用，CPU在掉电时不工作。

(2)启动过程：PC上电后先执行BIOS程序（实际上PC的BIOS就是NorFlash），BIOS程序负责初始化DDR内存，负责初始化硬盘，然后从硬盘上将OS镜像读取到DDR中，然后跳转到DDR中去执行OS直到启动（OS启动后BIOS 就无用了） 1.3、典型嵌入式linux系统启动过程(1)典型嵌入式系统的部署：uboot程序部署在Flash（能作为启动设备的Flash）上、OS部署在FLash（嵌入式系统中用Flash代替了硬盘）上、内存在掉电时无作用，CPU在掉电时不工作。

(2)启动过程：嵌入式系统上电后先执行uboot、然后uboot负责初始化DDR，初始化Flash，然后将OS从Flash中读取到DDR中，然后启动OS（OS启动后uboot就无用了）总结：嵌入式系统和PC机的启动过程几乎没有两样，只是BIOS 成了uboot，硬盘成了Flash。

1.4、android系统启动过程(1)Android系统的启动和Linux系统（前面讲的典型的嵌入式系统启动）几乎一样。

几乎一样意思就是前面完全一样，只是在内核启动后加载根文件系统后不同了。

(2)可以认为启动分为2个阶段：第一个阶段是uboot到OS启动；第二个阶段是OS启动后到rootfs加载到命令行执行；现在我们主要研究第一个阶段，android的启动和linux的差别在第二阶段。

1嵌入式Linux软件结构与分布一般情况下嵌入式Linux系统中的软件主要分为以下几部分：1)引导加载程序：其中包括内部ROM中的固化启动代码和BootLoader两部分。

内部固化ROM是厂家在芯片生产时候固化的，作用基本上是引导BootLoader。

有的芯片比较复杂，比如Omap3在flash中没有代码的时候有许多启动方式：USB、UART或以太网等等。

而S3C24x0则很简单，只有Norboot和Nandboot。

drive e rs。

2)Linux kernel和driv3)文件系统。

包括根文件系统和建立于Flash内存设备之上的文件系统（EXT4、UBI、CRAMFS等等）。

它是提供管理系统的各种配置文件以及系统执行用户应用程序的良好运行环境及载体。

4)应用程序。

用户自定义的应用程序，存放于文件系统之中。

在Flash存储器中，他们的分布一般如下：BootLoader(被挂载到根文件系统或者作为2在嵌入式Linux中BootBootL L o a d er的必要性Linux内核的启动除了内核映像必须在主存的适当位置，CPU还必须具备一定的条件：1．CPU寄存器的设置：R0＝0；R1＝Machine ID(即Machine Type Number，定义在linux/arch/arm/tools/mach-types)；R2＝内核启动参数在RAM中起始基地址；2．CPU模式：必须禁止中断（IRQs和FIQs）；CPU必须SVC模式；3．Cache和MMU的设置：MMU必须关闭；指令Cache可以打开也可以关闭；数据Cache必须关闭；但是在CPU刚上电启动的时候，一般连内存控制器都没有初始化过，根本无法在主存中运行程序，更不可能处在Linux内核启动环境中。

为了初始化CPU及其他外设，使得Linux内核可以在系统主存中运行，并让系统符合Linux内核启动的必备条件，必须要有一个先于内核运行的程序，他就是所谓的引导加载程序（Boot Loader）。

uboot命令解释与运行分析题记: 省略200字这一回来分析一下uboot中命令行的解释, 所以我们直接从main_loop开始分析.1. 从汇编阶段进入c阶段的第一个函数是start_xxx, 如/lib_unicore/board.c中的start_unicoreboot. 前半部分调用了若干初始化函数来进行部分硬件的初始化, 并设置一下环境. 这里不是我们本回要讨论的所以一一跳过. 在start_xxx的最后调用了main_loop(), 而且还是被一个死循环死死圈住了;2. 现在我们已经进入了这个圈套那么只能往里钻了. common/main.c文件中的main_loop().上面代码主要是对自启动部分的描述, 其中命令执行部分是在run_command中进行的, 这个等在后文分析. 如果我们没有bootcmd 或者在延时中被打断, 那么代码会继续向下执行3.read_line()读取到命令行后会调用common/main.c文件中的run_command().现在是分析run_command()的时候了,不管是从环境变量还是终端获得命令,都是由run_command()来处理的.中场休息,下面要进入处理cmdbuf的循环中了, 长征马上开始以;分割. 忽略'\;'for(inquotes = 0, sep = str;*sep; sep++){if((*sep=='\'')&&(*(sep-1)!='\\'))inquotes=!inquotes;if(!inquotes &&(*sep ==';')&&( sep != str)&&(*(sep-1)!='\\'))break;}//如果上面for循环找到一条以';'结束的命令, 那么sep指向命令末尾token = str;if(*sep){str = sep + 1;*sep ='\0';}elsestr = sep;process_macros (token, finaltoken);if((argc = parse_line (finaltoken, argv))== 0){rc =-1;4.就此打断一下, 我们要分析一下find_cmd了, 不能再跳过了. find_cmd()在.u_boot_cmd段中寻找该命令的cmd_tbl_t结构, 找到后返回该结构. 该命令的结构是通过定义在include/command.h中的宏定义U_BOOT_CMD登记进.u_boot_cmd段中的.5. 刚才我们在长征的半路翻越了一座雪山, 现在继续回到while循环中if(cmdtp->cmd == do_bootd){if(flag & CMD_FLAG_BOOTD){puts("'bootd' recursion detected\n");rc =-1;continue;}else{flag |= CMD_FLAG_BOOTD;}}#endif//长征马上结束, 胜利就在眼前! 调用结构体中注册的cmd函数, 何时注册的呢? 上面不远处介绍的U_BOOT_CMD!if((cmdtp->cmd)(cmdtp, flag, argc, argv)!= 0){ rc =-1;}repeatable &= cmdtp->repeatable;if(had_ctrlc ())return-1;}。

uboot源码分析2-启动第⼆阶段⼀、背景知识1、uboot第⼆阶段应该做什么？概括来讲uboot第⼀阶段主要就是初始化了SoC内部的⼀些部件（譬如看门狗、时钟），然后初始化DDR并且完成重定位。

由宏观分析来讲，uboot的第⼆阶段就是要初始化剩下的还没被初始化的硬件。

主要是SoC外部硬件（譬如iNand、⽹卡芯⽚····）、uboot本⾝的⼀些东西（uboot的命令、环境变量等····）。

然后最终初始化完必要的东西后进⼊uboot的命令⾏准备接受命令。

2、uboot中经常出现⼀种情况就是根据⼀个宏是否定义了来条件编译决定是否调⽤⼀个函数内部的代码。

uboot 中有2种解决⽅案来处理这种情况：⽅案⼀：在调⽤函数处使⽤条件编译，然后函数体实际完全提供代码。

⽅案⼆：在调⽤函数处直接调⽤，然后在函数体处提供2个函数体，⼀个是有实体的⼀个是空壳⼦，⽤宏定义条件编译来决定实际编译时编译哪个函数进去。

⼆、函数执⾏流程1、定义变量，gd，然后实例化2、给gd->bd赋值，内存间隔为了防⽌⾼版本的gcc的优化造成错误3、执⾏init_sequence函数，都是board级别的各种硬件初始化cpu_init（）：cpu内部的初始化，但在start.S初始化过，所以这⾥是空的。

board_init（）：⽹卡的GPIO和端⼝的配置、定义开发板的机器码、定义uboot给linux kernel启动时的传参的内存地址gd->bd->bi_boot_params=0x30000100注意：board_init中除了⽹卡的初始化之外，剩下的2⾏⽤来初始化DDR。

这⾥的初始化DDR和汇编阶段lowlevel_init中初始化DDR是不同的。

当时是硬件的初始化，⽬的是让DDR可以开始⼯作。

现在是软件结构中⼀些DDR相关的属性配置、地址设置的初始化，是纯软件层⾯的。

U-Boot启动流程（Linux内核）的分析（一）前面一段时间一直在移植U-Boot，Linux内核和构建根文件系统，其中有些地方还不是很明白，现在回过头来，理解一下U-boot的启动流程，以及u-Boot是如何加载引导内核启动的。

这里的分析也都是以U-Boot-2009.08版本为基础的，可能会和以前的版本有所不同。

在这里也不打算一句句分析U-Boot的源码，只是想把U-Boot一步一步怎么最终能够加载Linux内核的过程，分析一下。

首先，我们应该理解Bootloader是什么？它有什么作用？其实它就是系统上电后运行的和小段程序。

1 BootLoader的概念在系统上电后，需要一段程序来进行初始化：关闭WATCHDOG，改变系统时钟，初始化存储控制器，将更多的代码复制到内存中。

并将操作系统内核复制到内存中运行，这就段程序代码就叫做Bootloader。

没有一个Bootloader完全支持所有CPU，所以我们要想使用Bootloaser 一般情况下要自己进行修改，我们可以增强Bootloader的功能，让它具有网络功能，可以通过NFS远程下载Linux内核和根文件系统，可以烧写Linux内核和根文件系统到NandFlash中，而这些功能对于最终的用户来说是没有什么意义的，它们看到的只是Bootloader引导Linux内核启动这一个功能，而其余的功能只对开发人员很有用处。

也就是说在开发期间这些功能是必不可少的。

（1）启动加载模式：这种模式也称为“自主”模式。

也就是Bootloader从目标机上的某个固态存储设备上将操作系统加载到RAM中运行，整个过程并没有用户的介入，这种模式是在嵌入式产品发布里的通用模式。

（2）下载模式：在这种模式下，目标机上的Bootloader将通过串口连接或网络连接等通信手段从主机下载文件，例如：下载内核映像和根文件系统映像等。

从主机下载的文件通常首先被Bootloader保存到目标机的RAM中，然后再被Bootloader写到目标上的Flash类的固态存储设备中，Bootloader的这种模式是在在开发时使用的工作于这种模式的Bootloader通常都会向它的终端用户提供一个简单的命令行接口。

uboot一、uboot是ppcboot和armboot合并而成，现在主流的bootloader为uboot和redboot二、bootm addr_kernel addr_initrd三、移植uboot时最好（一定）要找到一个自己板子的原形（即自己的板子是在这个板子上做一些修改而来的）的版本，这样就可以事半功倍。

这样要修改的地方就比较少，也比较容易了。

uboot支持很多平台，与一个具体平台相关的主要有三个地方：1、./include/configs/xxxxx.h, 主要定义了flash、sdram的起始地址等信息，一般要修改flash的起始地址、大小，有时候会有位宽等。

2、./board/xxxxx/*，这个目录下主要有两三个.c文件，主要为该平台的初始化和flash操作的函数。

有时候flash的操作需要修改，不过一般都是找一个现有的支持该flash的驱动，一般情况在uboot 别的./board/平台下就会有现成的，拷贝过了就可以了。

3、./cpu/xxxxxx/arch_xxx/xxxxxx/*, 一般是此cpu的初始等函数。

四、具体移植的时候最多涉及到的会是./include/configs/xxxx.h，如果有现成的平台（uboot现在支持绝大部分我们常用的平台），可能只需要对着原来的xxxx.h文件，修改几个我们在硬件上修改了的地方，一般会是flash的起始地址、大小；内存大小（内存的起始地址应该都是0）；uboot设置信息保存的地址和长度；console 口和它的波特率；默认的设置；uboot的入口地址等（具体情况可能会有一些变化），如果不是从相同的平台移植，可能会比较麻烦，因为这时候要修改一些和此cpu相关的一些寄存器、频率和内存等硬件方面的东西了（也在这个xxxx.h中），虽然这时改动的地方也不多，但是会很痛苦，因为经常不知道要改哪里或者改为多少。

所以可能需要参考cpu的datasheet和到网上找一些资料了并且慢慢试了。

uboot分析BootLoader指系统启动后，在操作系统内核运行之前运行的一段小程序。

通过BootLoader，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。

通常，BootLoader是严重地依赖于硬件而实现的，特别是在嵌入式世界。

因此，在嵌入式世界里建立一个通用的BootLoader 几乎是不可能的。

尽管如此，我们仍然可以对BootLoader归纳出一些通用的概念来，以指导用户特定的BootLoader设计与实现。

BootLoader的操作模式一般分为自启动模式和交互模式。

自启动模式：BootLoaderd从目标机上的某个固态设备上将操作系统加载到RAM中运行，整个过程没有用户的介入；交互模式：目标机上的BootLoader将通过串口或网络等通信手段从开发板上下载内核映像和根文件系统映像等到RAM中，可以写到目标机上的固态存储介质中，或者直接进行系统的引导。

也可以通过串口接收用户的命令。

BootLoader基本功能：初始化相关硬件；把BootLoader自搬移到内存中；执行用户的命令(访问环境变量；通过网络/串口通信；读写RAM/Flash)；加载并执行内核。

一个嵌入式Linux系统从软件的角度看通常可以分为四个部分：BootLoader、Linux内核、跟文件系统及用户的应用程序。

BootLoader处于系统的最底层，运行于系统启动的最初阶段。

系统加电或复位后，所有CPU都会从某个地址开始执行，这是由处理器设计决定的。

比如，X86的复位向量在高地址端，ARM处理器在复位时从地址0x00000000取第一条指令。

嵌入式系统的开发板都要把板上ROM或Flash映射到这个地址。

因此，必须把Bootloader程序存储在相应的Flash位置。

系统加电后，CPU将首先执行它。

BootLoader的启动过程可以是单阶段的，也可以是多阶段的。

uboot的介绍及体系结构1.1 uboot的介绍Uboot是德国DENX小组的开发用于多种嵌入式CPU的bootloader程序, UBoot 不仅仅支持嵌入式Linux系统的引导，当前，它还支持NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS嵌入式操作系统。

UBoot除了支持PowerPC系列的处理器外，还能支持MIPS、 x86、ARM、NIOS、XScale等诸多常用系列的处理器。

1.2 uboot的体系结构目录树|--board|--common|--cpu|--disk|--doc|--drivers|--dtt|--examples|--fs|--include|--lib_arm|--lib_generic|--net|--post|--rtc|--tools2. board：和一些已有开发板有关的文件. 每一个开发板都以一个子目录出现在当前目录中，比如说: leopard2a子目录中存放与我们开发板相关的配置文件.3. common：实现uboot命令行下支持的命令，每一条命令都对应一个文件。

例如bootm命令对应就是cmd_bootm.c。

4. cpu：与特定CPU架构相关目录，每一款Uboot下支持的CPU在该目录下对应一个子目录，比如有子目录arm926ejs就是我们开发板上使用的cpu架构目录。

5. disk：对磁盘的支持。

5. doc：文档目录。

Uboot有非常完善的文档，推荐大家参考阅读。

6. drivers：Uboot支持的设备驱动程序都放在该目录，比如各种网卡、支持CFI 的Flash、串口和USB等。

7. fs: 支持的文件系统，Uboot现在支持cramfs、fat、fdos、jffs2和registerfs。

8. include：Uboot使用的头文件，还有对各种硬件平台支持的汇编文件，系统的配置文件和对文件系统支持的文件。

1.配置开发板查找当前使用开发板对应的配置头文件是否存在？根据REDEME文件可知，在编译uboot之前要配置开发板，通过以下命令：make 开发板名_config输入:make qq2440_config，显示如下错误：make: *** 没有规则可以创建目标“qq2440_config”。

停止。

显然uboot不支持qq2440开发板，我们要自己进行配置，QQ2400是山寨的三星的smdk2410的开发板输入:make smdk2410_config，配置成功2.分析Makefile文件1879行里是对应smdk2410开发板的配置参数，通过分析知道，其实执行make smdk2410_config就是调用mkconfig smdk2410 arm arm920t smdk2410 NULL s3c24x0 我们可以通过增加qq2440的选项方式来增加对qq2440开发板的支持：在1882行，添加复制smdk2410选项代码，修改为（红色部分为修改部分）：1882 qq2440_config : unconfig1883 @$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 NULL s3c24x03.分析mkconfigMkconfig是根据传递过来的6个参数sdmk2410 arm arm920t smdk2410 NULL s3c24x0做相关的一些配置，主要完成以下功能：1>打印配置信息：28 echo "Configuring for ${BOARD_NAME} board..."2>创建和指定开发板体系结构相关的引入头文件目录（33行至62行）3>生成include/config.mk1 ARCH = arm2 CPU = arm920t3 BOARD = smdk24104 SOC = s3c24x04>生成include/config.h1 /* Automatically generated - do not edit */2 #include <configs/smdk2410.h>最后一步生成的config.h里是行包含文件代码。

(一)U—Boot启动过程-—详细版的完全分析我们知道，bootloader是系统上电后最初加载运行的代码.它提供了处理器上电复位后最开始需要执行的初始化代码。

在PC机上引导程序一般由BIOS开始执行，然后读取硬盘中位于MBR(Main Boot Record，主引导记录）中的Bootloader(例如LILO或GRUB），并进一步引导操作系统的启动。

然而在嵌入式系统中通常没有像BIOS那样的固件程序,因此整个系统的加载启动就完全由bootloader来完成.它主要的功能是加载与引导内核映像一个嵌入式的存储设备通过通常包括四个分区：第一分区:存放的当然是u-boot第二个分区：存放着u-boot要传给系统内核的参数第三个分区：是系统内核（kernel）第四个分区：则是根文件系统如下图所示：u—boot是一种普遍用于嵌入式系统中的Bootloader。

Bootloader介绍Bootloader是进行嵌入式开发必然会接触的一个概念,它是嵌入式学院<嵌入式工程师职业培训班〉二期课程中嵌入式linux系统开发方面的重要内容。

本篇文章主要讲解Bootloader的基本概念以及内部原理，这部分内容的掌握将对嵌入式linux系统开发的学习非常有帮助！Bootloader的定义：Bootloader是在操作系统运行之前执行的一小段程序,通过这一小段程序,我们可以初始化硬件设备、建立内存空间的映射表,从而建立适当的系统软硬件环境，为最终调用操作系统内核做好准备.意思就是说如果我们要想让一个操作系统在我们的板子上运转起来，我们就必须首先对我们的板子进行一些基本配置和初始化，然后才可以将操作系统引导进来运行。

具体在Bootloader中完成了哪些操作我们会在后面分析到，这里我们先来回忆一下PC的体系结构：PC机中的引导加载程序是由BIOS和位于硬盘MBR 中的OS Boot Loader（比如LILO和GRUB等）一起组成的，BIOS在完成硬件检测和资源分配后,将硬盘MBR 中的Boot Loader读到系统的RAM中，然后将控制权交给OS Boot Loader。

uboot知识全知道转载自互联网•1 U-Boot简介•U-Boot，全称Universal Boot Loader，是遵循GPL条款的开放源码项目。

从FADSROM、8xxROM、PPCBOOT逐步发展演化而来。

其源码目录、编译形式与Linux内核很相似，事实上，不少U-Boot源码就是相应的Linux内核源程序的简化，尤其是一些设备的驱动程序，这从U-Boot源码的注释中能体现这一点。

但是U-Boot不仅仅支持嵌入式Linux系统的引导，当前，它还支持NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS嵌入式操作系统。

其目前要支持的目标操作系统是OpenBSD, NetBSD, FreeBSD,4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, LynxOS, pSOS, QNX, RTEMS, ARTOS。

这是U-Boot中Universal的一层含义，另外一层含义则是U-Boot除了支持PowerPC系列的处理器外，还能支持MIPS、x86、ARM、NIOS、XScale等诸多常用系列的处理器。

这两个特点正是U-Boot项目的开发目标，即支持尽可能多的嵌入式处理器和嵌入式操作系统。

就目前来看，U-Boot对PowerPC系列处理器支持最为丰富，对Linux的支持最完善。

其它系列的处理器和操作系统基本是在2002年11 月PPCBOOT改名为U-Boot后逐步扩充的。

从PPCBOOT 向U-Boot的顺利过渡，很大程度上归功于U-Boot的维护人德国DENX软件工程中心Wolfgang Denk[以下简称W.D]本人精湛专业水平和持着不懈的努力。

当前，U-Boot项目正在他的领军之下，众多有志于开放源码BOOT LOADER移植工作的嵌入式开发人员正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入，以支持更多的嵌入式操作系统的装载与引导。