uboot nand驱动说说UBOOT的几个核心问题

发布时间 : 2024-11-24

作者 : 小编

访问数量 : 23

扫码分享至微信

说说UBOOT的几个核心问题

本文目的，有助于嵌入式新手对uboot有个大概的了解，方便老手回忆，复习。

为什么需要U-BOOT?

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

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

典型的计算机系统有：

PC机（台式机+笔记本）

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

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

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

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

2、PC机的启动过程

（1）部署：

典型的PC机的BIOS程序部署在PC机主板上（随主板出厂时已经预制了），操作系统部署在硬盘上，内存在掉电时无作用，CPU在掉电时不工作。

（2）启动过程：

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

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。

4、android系统启动过程

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

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

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

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

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

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

5、总结：uboot到底是干嘛的?

（1）uboot主要作用是用来启动操作系统内核。

（2）uboot还要负责部署整个计算机系统。

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

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

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都支持多种启动方式，比如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就是提供人机交互的一个界面。

注意：

shell并不是操作系统，和操作系统一点关系都没有。linux中打开一个终端后就得到了一个shell，可以输入命令回车执行。uboot中的shell工作方式和linux中的终端shell非常像（其实几乎是一样的，只是命令集不一样。譬如linux中可以ls，uboot中ls就不识别）。

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

（1）uboot启动后大部分时间和工作都是在shell下完成的（譬如uboot要部署系统要在shell下输命令、要设置环境变量也得在命令行下，要启动内核也要在命令行底下敲命令）。

（2）命令就是uboot的shell中可以识别的各种命令。uboot中有几十个命令，其中有一些常用另一些不常用（我们还可以自己给uboot添加命令）。

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

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

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

（5）环境变量就是运行时的配置属性。

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覆盖掉。

下一篇讲讲<uboot的常用命令和用法>

「新品首发」STM32MP157开发板火爆预售！首批仅300套

Linux 的启动流程

本篇的重点是讲解设备和驱动的启动流程，设备和驱动的流程是整个内核启动的核心，也是工作中最常面对的问题。出于知识点的系统性考虑，在进入主题之前我们先看下整个 Linux 在 ARM 中的启动流程如何。

Uboot 的启动流程

ARM Linux 的启动流程大致为：Uboot → Kernel → Root filesystem。Uboot 在上电的时候就拿到 CPU 的控制权，实现了硬件的初始化。具体是怎么实现的呢？一起来看一下，CPU 的内部集成了小容量的 Sram，而 PC 指针一上电就指向 Sram 的起始地址 0x00000000，所以一上电 Uboot 代码就得到了运行。

Uboot 拿到 CPU 使用权就开始做初始化工作，比如关闭看门狗、设置 CPU 运行模式、设置堆栈、初始化内存、网卡、nand flash 等，最后把 Linux 内核加载到内存中。

初始化 RAM

因为内核要在 RAM 中运行，所以在调用内核之前必须初始化和设置 RAM，为调用内核做好准备。

初始化串口

内核在启动过程中可以将信息通过串口输出，这样就可以清楚的知道内核启动信息。虽然串口不是 Uboot 必须要完成的工作，但是通过串口可以方便调试 Uboot 和内核的各种信息。

检测处理器类型

Uboot 在调用内核前需要检测系统的处理器类型，并将其保存在某个变量中提供给内核，内核在启动过程中会根据该处理器的类型调用相应的初始化程序。

设置内核启动参数

内核在启动过程中会根据该启动参数进行相应的初始化工作。

调用内核镜像

值得注意的是存储 Uboot 的存储器不同，Uboot 的执行过程也并不相同，一般来讲 Flash 分为 nor Flash 和 nand Flash 两种：nor Flash 支持芯片内执行（XIP，eXecute In Place），这样代码可以在 Flash 上直接执行而不必复制到 RAM 中去执行。

但是 nand Flash 并不支持 XIP，所以要想执行 nand Flash 上的代码，必须先将其复制到 RAM 中去，然后跳到 RAM 中去执行。如果内核存放在 nor Flash 中，那么可直接跳转到内核中去执行。但通常由于在 nor Flash 中执行代码会有种种限制，而且速度也远不及 RAM 快，所以一般的嵌入式系统都是将内核复制到 RAM 中，然后跳转到 RAM 中去执行。不论哪种情况，在跳到内核执行之前 CPU 的寄存器必须满足以下条件：r0 ＝ 0，r1 ＝处理器类型，r2 ＝标记列表在 RAM 中的地址。

Linux 内核的启动流程（设备和驱动的加载）

关于 Uboot 的启动本课程不做详细介绍，因为本课程的主要内容是内核。在讲述内核启动之前让我们先了解下内核的组成结构：

其中，

（1）vmlinusx 是 ELF 格式的 Object 文件，这种文件只是各个源代码经过连接以后得到的文件，并不能在 ARM 平台上运行。

（2）经过 objcopy 这个工具转换以后，得到了二进制格式文件 Image，Image 文件相比于 vmlinusx 文件，除了格式不同以外，还被去除了许多注释和调试的信息。

（3）Image 文件经过压缩以后得到了 piggy.gz，这个文件仅仅是 Image 的压缩版，并无其他不同。

（4）接着编译生成另外几个模块文件 misc.o、big_endian.o、head.o、head-xscale.o，这几个文件组成一个叫 Bootstrap Loader 的组件，又叫引导程序，编译生成 piggy.o 文件。

（5）最后 piggy.o 文件和 Bootstrap Loader 组成一个 Bootable Kernel Image 文件（可启动文件）。

经过上面的分析不难知道 piggy.o 就是内核镜像，而剩下的几个文件就组成了引导程序。知道了内核的组成结构，Uboot 就是按照内核的组成结构一层一层剥开然后引导内核的：

可以说 start_kernel之前的所有工作都是为了将环境准备好，满足start_kernel的要求，然后由start_kernel开始进行内核的加载：

关于 start_kernl函数的内容太多，可以通过红色回调函数看出，start_kernel函数基本是在回调很多对应的注册函数。为了本系列课程的结构性这里就不展开所有知识点讲解，本篇内容接着前一篇设备树的内容重点讲解下设备和驱动的匹配过程。

还记得上一篇讲到的设备树三大作用吗？

平台标识；

运行时配置；

设备信息集合。

接下来我们就看看内核在启动的时候是如何寻找设备，驱动又如何和设备绑定的。

首先在平台目录下可以看到有很多平台描述的文件，如图：

有那么多的平台，我们到底要执行哪个平台是首先要考虑的事情。这也是设备三大功能的第一个功能——平台标识。

设备树里有对设备根节点的 Compatible 描述，平台文件里有对 __initconst的描述，如果两个字段一致则找到了对应的板级文件，这样就通过设备树把要用的设备平台与其他平台区分开来了，如图：

找到平台后就可以根据回调函数的指针调用该平台的注册函数。这里以飞思卡尔 imx.6dl 平台为例，回调的时候会调用 imx6q_init_machine函数，如下：

这里补充一个知识点，细心的读者也许发现了在 Compatible 字段里用逗号分隔了两个字符串。板级匹配的时候用的是哪个字符串，另外一个字符串又是做什么用？首先后面的字段 "fsl,imx6dl" 是抽象共用平台描述符，前面的字段 "fsl,imx6dl-sabresd" 是通用平台下的具体平台描述符，可以理解为母板和子板的区别。在具体的子板文件中我们可以通过前面的字段进行设备信息的获取，如图：

接着是运行时配置，让内核在启动的时候根据参数设置进行不同的处理。有经验的读者清楚在 Uboot 里也有对 Bootargs 的配置，这里为什么多此一举呢，是为了在 Uboot 中更灵活的对内核启动进行配置。

最后的作用就是设备信息集合，这是设备和驱动匹配的核心，也是工作中面对最多的情况。出于这一作用的内容是工作中经常遇到的重点也是难点，我们专门用一篇内容来详细讲解各级设备是如何展开的，并且手把手教你如何定制一套自己的开发板全新案例。