uboot nand分析智能座舱之存储篇第三篇---NAND Flash 一眼就看明白了-资讯-上海羊羽卓进出口贸易有限公司

uboot nand分析智能座舱之存储篇第三篇---NAND Flash 一眼就看明白了

发布时间 : 2024-11-24

作者 : 小编

访问数量 : 23

扫码分享至微信

智能座舱之存储篇第三篇---NAND Flash 一眼就看明白了

上期内容我们重点说了NAND FLASH本身的一些特殊性，比如写之前要进行擦除，而且存在坏块的可能性性，所以很多车厂在评估NAND FLASH的时候，会评估目前容量的冗余量是多少，要保障有足够多的空间去预防坏块的产生后的数据搬移。

这期内容重点说说NAND FLASH的一些操作特性，怎么进行控制和读取的。这期的内容有点硬核，需要有一些专业知识的人进行阅读，科普类的文章咱们下期继续。

NAND FLASH的硬件特性介绍

上图是镁光 NAND FLASH MT29F1G08ABAEAH4的引脚（Pin）所对应的功能，简单翻译如下：

1. I/O0 ~ I/O7：用于输入地址/数据/命令，输出数据

2. CLE：Command Latch Enable，命令锁存使能，在输入命令之前，要先在模式寄存器中，设置CLE使能

3. ALE：Address Latch Enable，地址锁存使能，在输入地址之前，要先在模式寄存器中，设置ALE使能

4. CE#：Chip Enable，芯片使能，在操作Nand Flash之前，要先选中此芯片，才能操作

5. RE#：Read Enable，读使能，在读取数据之前，要先使CE＃有效。

6. WE#：Write Enable，写使能,在写取数据之前，要先使WE＃有效。

7. WP#：Write Protect，写保护

8. R/B#:Ready/Busy Output,就绪/忙,主要用于在发送完编程/擦除命令后,检测这些操作是否完成,忙,表示编程/擦除操作仍在进行中,就绪表示操作完成.

9. Vcc：Power，电源

10. Vss：Ground，接地

11. N.C：Non-Connection,未定义，未连接。

实际项目的NAND FLASH原理图

上图中我们可以发现有两个地方需要上拉电阻R/B#:、WP#，其他都是CPU同nand flash直接相连接。通过查询flash 的datasheet可以发现，这两个引脚是开漏极输出，需要上拉电阻。

而且可以看到电路设计中WP#引脚一端接上拉电阻，一端通过二极管和0欧姆电阻连接到CPU复位引脚，CPU主芯片平台的复位是低电平复位，WP#引脚是低电平的时候写保护有效，这样做的目的就是，在复位期间，即CPU复位引脚为低电平期间此时WP#引脚也为二极管电压（0.7V）为低电平，为写保护状态，在复位期间，CPU引脚状态不定，容易对flash进行误操作。这样做的目的就是硬件实现在CPU复位期间，flash是写保护状态，不允许写入的。

很多时候掉电产生的擦除数据，导致数据丢失无法开机、无法保存掉电记忆等等问题都可以使用这个方案来对策解决问题。

为何需要ALE和CLE

比如命令锁存使能(Command Latch Enable,CLE)和地址锁存使能(Address Latch Enable，ALE)，那是因为，Nand Flash就8个I/O，而且是复用的，也就是，可以传数据，也可以传地址，也可以传命令，为了区分你当前传入的到底是啥，所以，先要用发一个CLE（或ALE）命令，告诉nand Flash的控制器一声，我下面要传的是命令（或地址），这样，里面才能根据传入的内容，进行对应的动作。否则,nand flash内部,怎么知道你传入的是数据,还是地址,还是命令啊,也就无法实现正确的操作了。

Nand Flash只有8个I/O引脚的好处

1. 减少外围引脚：相对于并口(Parellel)的Nor Flash的48或52个引脚来说，的确是大大减小了引脚数目，这样封装后的芯片体积，就小很多。现在芯片在向体积更小，功能更强，功耗更低发展，减小芯片体积，就是很大的优势。同时，减少芯片接口，也意味着使用此芯片的相关的外围电路会更简化，避免了繁琐的硬件连线。

2. 提高系统的可扩展性，因为没有像其他设备一样用物理大小对应的完全数目的addr引脚，在芯片内部换了芯片的大小等的改动，对于用全部的地址addr的引脚，那么就会引起这些引脚数目的增加，比如容量扩大一倍，地址空间/寻址空间扩大一倍，所以，地址线数目/addr引脚数目，就要多加一个，而对于统一用8个I/O的引脚的Nand Flash，由于对外提供的都是统一的8个引脚，内部的芯片大小的变化或者其他的变化，对于外部使用者(比如编写nand flash驱动的人)来说，不需要关心，只是保证新的芯片，还是遵循同样的接口，同样的时序，同样的命令，就可以了。这样就提高了系统的扩展性。

片选无关(CE don’t-care)技术

Nand flash支持一个叫做CE don’t-care的技术，字面意思就是，不关心是否片选，那有人会问了，

如果不片选，那还能对其操作吗？答案就是，这个技术，主要用在当时是不需要选中芯片却还可以继续操作的这些情况：在某些应用，比如录音，音频播放等应用中，外部使用的微秒（us）级的时钟周期，此处假设是比较少的2us，在进行读取一页或者对页编程时，是对Nand Flash操作，这样的串行（Serial Access）访问的周期都是20/30/50ns，都是纳秒（ns）级的，此处假设是50ns，当你已经发了对应的读或写的命令之后，接下来只是需要Nand Flash内部去自己操作，将数据读取除了或写入进去到内部的数据寄存器中而已，此处，如果可以把片选取消，CE#是低电平有效，取消片选就是拉高电平，这样会在下一个外部命令发送过来之前，即微秒量级的时间里面，即2us－50ns≈2us，这段时间的取消片选，可以降低很少的系统功耗，但是多次的操作，就可以在很大程度上降低整体的功耗了。

总结起来简单解释就是：由于某些外部应用的频率比较低，而Nand Flash内部操作速度比较快，所以具体读写操作的大部分时间里面，都是在等待外部命令的输入，同时却选中芯片，产生了多余的功耗，此“不关心片选”技术，就是在Nand Flash的内部的相对快速的操作（读或写）完成之后，就取消片选，以节省系统功耗。待下次外部命令/数据/地址输入来的时候，再选中芯片，即可正常继续操作了。这样，整体上，就可以大大降低系统功耗了。

NAND FLASH 的读操作详细解读

以最简单的read操作为例，解释如何理解时序图，以及将时序图中的要求，转化为代码。解释时序图之前，让我们先要搞清楚，我们要做的事情：那就是，要从nand flash的某个页里面，读取我们要的数据。要实现此功能，会涉及到几部分的知识，至少很容易想到的就是：需要用到哪些命令，怎么发这些命令，怎么计算所需要的地址，怎么读取我们要的数据等等。

就好比你去图书馆借书，想想是一个什么样的流程，首先得告诉馆长你要要借书还是还书、然后把要借书的位置告诉馆长，最后是把图书卡或者借书证件给馆长，此时就耐心等待要借的书籍了。

下面，就一步步的解释，需要做什么，以及如何去做：

1.需要使用何种命令

首先，是要了解，对于读取数据，要用什么命令。

下面是datasheet中的命令集合：

很容易看出，我们要读取数据，要用到Read命令，该命令需要2个周期，第一个周期发0x00，第二个周期发0x30。

2.发送命令前的准备工作以及时序图各个信号的具体含义

知道了用何命令后，再去了解如何发送这些命令。

Nand Flash数据读取操作的时序图

注：此图来自镁光的型号MT29F1G08ABAEAH4:E的nand flash的数据手册(datasheet)。

我们来一起看看，我在图中的特意标注的①边上的红色竖线。

红色竖线所处的时刻，是在发送读操作的第一个周期的命令0x00之前的那一刻。让我们看看，在那一刻，其所穿过好几行都对应什么值，以及进一步理解，为何要那个值。

（1）红色竖线穿过的第一行，是CLE。还记得前面介绍命令所存使能（CLE）那个引脚吧？CLE，将CLE置1，就说明你将要通过I/O复用端口发送进入Nand Flash的，是命令，而不是地址或者其他类型的数据。只有这样将CLE置1，使其有效，才能去通知了内部硬件逻辑，你接下来将收到的是命令，内部硬件逻辑，才会将受到的命令，放到命令寄存器中，才能实现后面正确的操作，否则，不去将CLE置1使其有效，硬件会无所适从，不知道你传入的到底是数据还是命令了。

（2）而第二行，是CE#，那一刻的值是0。这个道理很简单，你既然要向Nand Flash发命令，那么先要选中它，所以，要保证CE#为低电平，使其有效，也就是片选有效。

（3）第三行是WE#，意思是写使能。因为接下来是往nand Flash里面写命令，所以，要使得WE#有效，所以设为低电平。

（4）第四行，是ALE是低电平，而ALE是高电平有效，此时意思就是使其无效。而对应地，前面介绍的，使CLE有效，因为将要数据的是命令，而不是地址。如果在其他某些场合，比如接下来的要输入地址的时候，就要使其有效，而使CLE无效了。

（5）第五行，RE#，此时是高电平，无效。可以看到，知道后面低6阶段，才变成低电平，才有效，因为那时候，要发生读取命令，去读取数据。

（6）第六行，就是我们重点要介绍的，复用的输入输出I/O端口了，此刻，还没有输入数据，接下来，在不同的阶段，会输入或输出不同的数据/地址。

（7）第七行，R/B#,高电平，表示R（Ready）/就绪，因为到了后面的第5阶段，硬件内部，在第四阶段，接受了外界的读取命令后，把该页的数据一点点送到页寄存器中，这段时间，属于系统在忙着干活，属于忙的阶段，所以，R/B#才变成低，表示Busy忙的状态的。

介绍了时刻①的各个信号的值，以及为何是这个值之后，相信，后面的各个时刻，对应的不同信号的各个值，大家就会自己慢慢分析了，也就容易理解具体的操作顺序和原理了。

3.如何计算出，我们要传入的地址

在介绍具体读取数据的详细流程之前，还要做一件事，那就是，先要搞懂我们要访问的地址，以及这些地址，如何分解后，一点点传入进去，使得硬件能识别才行。

此处还是以MT29F1G08ABAEAH4:E为例，此nand flash，一共有1024个块，每个块内有64页，每个页是2K+64 Bytes，假设，我们要访问其中的第1000个块中的第25页中的1208字节处的地址，此时，我们就要先把具体的地址算出来：

物理地址=块大小×块号+页大小×页号+页内地址=1000×128K+2K×25+1208=0x7D0CCB8,接下来，我们就看看，怎么才能把这个实际的物理地址，转化为nand Flash所要求的格式。

在解释地址组成之前，先要来看看其datasheet中关于地址周期的介绍：

图 Nand Flash的地址周期组成

结合时序图的2，3阶段，我们可以看出，此nand flash地址周期共有4个，2个列(Column)周期，2个行（Row）周期。

而对于对应的，我们可以看出，实际上，列地址CA0~CA10，就是页内地址，11位地址范围是从0到2047，即2K,而多出的A11，理论上可以表示2048～4095，但是实际上，上述规格书中说明当CA11为1时，CA【10：6】都必须为0，所以我们最多也只用到了2048～2112，用于表示页内的oob区域，其大小是64字节。

PA0～PA5，称作页号，页的号码，可以定位到具体是哪一个页。由6个位控制，最多寻址64页，符合规格书中的一块有64页。

而其中，BA6～BA15，表示对应的块号，即属于哪个块,有10个位控制，寻址范围为1024个块。

// 可见：地址的传输顺序是是页内地址，页号，块号。从小到大。

简单解释完了地址组成，那么就很容易分析上面例子中的地址了：

0x7D0CCB8 = 0111 1101 0000 1100 0000 1100 1011 1000，分别分配到4个地址周期就是：

1st 周期，CA7～CA0 ：1011 1000 = 0x B8

2nd周期，CA11～CA8 ：0000 1100 = 0x 0C

3rd周期，BA7～PA0 ：0000 1100 = 0x 0C

4th周期，A27～A20 ：0111 1101 = 0x 7D

注意，上图图中对应的，*L，意思是低电平，由于未用到那些位，datasheet中强制要求设为0，所以，才有上面的2nd周期中的高4位是0000.。因此，接下来要介绍的，我们要访问第1000个块中的第25页中的1208字节处的话，所要传入的地址就是分4个周期，分别传入2个列地址的：0xB8，0x0C，然后再传2个行地址的：0x0C，0x7D，这样硬件才能识别。

4.读操作过程的解释

准备工作终于完了，下面就可以开始解释说明，对于读操作的，上面图中标出来的，1-6个阶段，具体是什么含义。

（1）操作准备阶段：此处是读（Read）操作，所以，先发一个图5中读命令的第一个阶段的0x00,表示，让硬件先准备一下，接下来的操作是读。

（2）发送两个周期的列地址。也就是页内地址，表示，我要从一个页的什么位置开始读取数据。

（3）接下来再传入三个行地址。对应的也就是页号。

（4）然后再发一个读操作的第二个周期的命令0x30。接下来，就是硬件内部自己的事情了。

（5）Nand Flash内部硬件逻辑，负责去按照你的要求，根据传入的地址，找到哪个块中的哪个页，然后把整个这一页的数据，都一点点搬运到页缓存中去。而在此期间，你所能做的事，也就只需要去读取状态寄存器，看看对应的位的值，也就是R/B#那一位，是1还是0，0的话，就表示，系统是busy，仍在”忙“（着读取数据），如果是1，就说系统活干完了，忙清了，已经把整个页的数据都搬运到页缓存里去了，你可以接下来读取你要的数据了。

对于这里。估计有人会问了，这一个页一共2048+64字节，如果我传入的页内地址，就像上面给的1028一类的值，只是想读取1028到2011这部分数据，而不是页开始的0地址整个页的数据，那么内部硬件却读取整个页的数据出来，岂不是很浪费吗？答案是，的确很浪费，效率看起来不高，但是实际就是这么做的，而且本身读取整个页的数据，相对时间并不长，而且读出来之后，内部数据指针会定位到你刚才所制定的1208的那个位置。

（6）接下来，就是“窃取“系统忙了半天之后的劳动成果的时候了，呵呵。通过先去Nand Flash的控制器中的数据寄存器中写入你要读取多少个字节(byte)/字(word)，然后就可以去Nand Flash的控制器的FIFO中，一点点读取你要的数据了。

至此，整个Nand Flash的读操作就完成了。

对于其他操作，可以根据上面的分析，一点点自己去看datasheet，根据里面的时序图去分析具体的操作过程，然后对照代码，会更加清楚具体是如何实现的。

NAND FLASH 搭配NOR FLASH的优缺点

常见的应用组合就是，用小容量的Nor Flash存储启动代码，比如uboot，系统启动后,初始化对应的硬件，包括SDRAM等，然后将Nand Flash上的Linux 内核读取到内存中，做好该做的事情后，就跳转到SDRAM中去执行内核了。

这样的好处是由于NAND 本身有坏块的可能性，所以为了保障启动万无一失，很多要求高级安全的产品，标注必须从NOR Flash启动uboot，而且从NOR启动还有一个好处就是启动速度快，NAND Flash的优点是容量大，但是读取速度不快，比不上NOR Flash，比如一些对于开机速度有要求的产品应用，比如车载液晶仪表，这类产品为了快速启动一般都是NOR FLASH+EMMC的配置，当然像赛普拉斯平台直接上hyperflash那就更快了。

NAND Flash的ECC校验简单说明

我们先来说说为什么需要ECC校验这个事情，其实上一篇文章我们说过由于NAND flash的自身的不稳定性，存在位翻转的现象，所以就存在写入到flash中的数据和读出来的数据不一样的情况发生，此时就需要有一个检验的机制，防止读出来的不正确，还可以纠正过来。

其实这个就类似于去银行存钱，你存了1W，过几天去银行去取钱的时候发现只有9000了，这个时候你就会拿出存条找银行理论，上次明明存的就是1W啊，你少的1000必须跟我纠正过来，其实这个就是NAND flash的ECC检验原理，发现有读出来的数据和存进去的数据不正确，此时就需要去纠正回来，当然这里的纠正的数据是有限制的，不是所有数据出错都能纠正过来。

ECC 校验是在奇偶校验的基础上发展而来的，它将数据块看作一个矩阵，利用矩阵的行、列奇偶信息生成 ECC 校验码。它能够检测并纠正单比特错误和检测双比特错误，但对双比特以上的错误不能保证检测。它克服了传统奇偶校验只能检出奇数位出错、校验码冗长、不能纠错的局限性。每 nbit 的 Ecc 数值可满足 2的n次方bit 数据包的校验要求。

当往Nand Flash 的Page 中写入数据的时候，每256字节我们生成一个ECC 校验和，称之为原ECC校验和，保存到 PAGE 的OOB数据区中。当从Nand Flash 中读取数据的时候，每 256 字节我们生成一个ECC校验和，称之为新 ECC 校验和。

校验的时候，根据上述ECC生成原理不难推断：将从 OOB 区中读出的原 ECC校验和新ECC校验和按位异或，若结果为0，则表示不存在错（或是出现了ECC无法检测的错误）：若3个字节异或结果中存在11个比特位为1，表示存在一个比特错误，且可纠正；若3个字节异或结果中只存在1个比特位为1，表示OOB区出错：其他情况均表示出现了无法纠正的错误。

这两期我们基本上把NAND FLASH的相关设计和使用都完整讲了一遍，下期会讲讲车载DRAM和EMMC的相关内容，敬请期待。

为什么要有uboot带你全面分析嵌入式中uboot的作用

1.为什么要有uboot

1.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.5、总结：uboot到底是干嘛的

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

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

(3)uboot中还有操作Flash等板子上硬盘的驱动。

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

2.为什么是uboot

2.1、uboot从哪里来的？

(1)uboot是SourceForge上的开源项目

(2)uboot项目的作者：一个德国人最早发起的项目

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

2.2、uboot的发展历程

(1)自己使用的小开源项目。

(2)被更多人认可使用

(3)被SoC厂商默认支持。

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

2.3、uboot的版本号问题

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

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

2.4、uboot的可移植性的正确理解

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

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

3.uboot必须解决哪些问题

3.1、自身可开机直接启动

(1)一般的SoC都支持多种启动方式，譬如SD卡启动、NorFlash启动、NandFlash启动等·····uboot要能够开机启动，必须根据具体的SoC的启动设计来设计uboot。

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

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

(1)uboot的终极目标就是启动内核。

(2)linux内核在设计的时候，设计为可以被传参。也就是说我们可以在uboot中事先给linux内核准备一些启动参数放在内存中特定位置然后传给内核，内核启动后会到这个特定位置去取uboot传给他的参数，然后在内核中解析这些参数，这些参数将被用来指导linux内核的启动过程。

3.3、能提供系统部署功能

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

(2)裸机教程中刷机（ARM裸机第三部分）就是利用uboot中的fastboot功能将各种镜像烧录到iNand中，然后从iNand启动。

3.4能进行soc级和板级硬件管理

(1)uboot中实现了一部分硬件的控制能力（uboot中初始化了一部分硬件），因为uboot为了完成一些任务必须让这些硬件工作。譬如uboot要实现刷机必须能驱动iNand，譬如uboot要在刷机时LCD上显示进度条就必须能驱动LCD，譬如uboot能够通过串口提供操作界面就必须驱动串口。譬如uboot要实现网络功能就必须驱动网卡芯片。

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

3.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命令，而启动内核命令一旦执行就回不来了。

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

4.uboot的工作方式

4.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去运行。

4.2、uboot的命令式shell界面

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

(2)有些程序需要和人进行交互，于是乎程序中就实现了一个shell（shell就是提供人机交互的一个界面，回想ARM裸机全集第十六部分），uboot就实现了一个shell。

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

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

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

(2)命令就是uboot的shell中可以识别的各种命令。uboot中有几十个命令，其中有一些常用另一些不常用（我们还可以自己给uboot添加命令），后面会用几节课时间来依次学习uboot中常用命令。

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

(4)环境变量可以被认为是系统的全局变量，环境变量名都是系统内置的（认识就认识，不认识就不认识，这部分是系统自带的默认的环境变量，譬如PATH；但是也有一部分环境变量是自己添加的，自己添加的系统就不认识但是我们自己认识）。系统或者我们自己的程序在运行时可以通过读取环境变量来指导程序的运行。这样设计的好处就是灵活，譬如我们要让一个程序更改运行方法，不用去重新修改程序代码再重新编译运行，而只要修改相应的环境变量就可以了。

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

5.uboot的常用命令1

5.1、类似linux终端的行缓冲命令行

(1)行缓冲的意思就是：当我们向终端命令行输入命令的时候，这些命令没有立即被系统识别，而是被缓冲到一个缓存区（也就是系统认为我们还没有输入完），当我们按下回车键（换行）后系统就认为我们输入完了，然后将缓冲区中所有刚才输入的作为命令拿去分析处理。

(2)linux终端设计有3种缓冲机制：无缓冲、行缓冲、全缓冲

（3）有些命令有简化的别名，譬如printenv命令可以简化为print，譬如setenv可以简化为set

（4）有些命令会带参数（注意格式是固定的），uboot的每个命令都有事先规定好的各种格式。有些命令就是不带参数的，譬如printenv/print命令；有些命令带可选的参数（可以带也可以不带，当然带不带参数的执行结果是不同的）；有些命令带必须的参数（譬如setenv/set命令）

（5）采用“help+命令名”来查询命令的详细信息，只输入help时，则打印出命令列表。

5.2、命令中的特殊符号（譬如单引号）

(1)uboot的有些命令带的参数非常长，为了告诉uboot这个非常长而且中间有好多个空格的东西是给他的一整个参数，所以用单引号将这个很长且中间有空格隔开的参数引起来。

(2)别的符号也许也有，而且有特定的意义。当碰到uboot的命令行有特殊符号时要注意不是弄错了，而是可能有特别的含义。

5.3、有些命令是一个命令族（譬如movi）

(1)命令族意思就是好多个命令开头都是用同一个命令关键字的，但是后面的参数不一样，这些命令的功能和作用也不同。这就叫一个命令族。

(2)同一个命令族中所有的命令都有极大的关联，譬如movi开头的命令族都和moviNand（EMMC、iNand）操作有关。

5.4、第一个命令：printenv/print

(1)print命令不用带参数，作用是打印出系统中所有的环境变量。

(2)环境变量就好像程序的全局变量一样。程序中任何地方都可以根据需要去调用或者更改环境变量（一般都是调用），环境变量和全局变量不同之处在于：全局变量的生命周期是在程序的一次运行当中，开始运行时诞生程序结束时死亡，下次运行程序时从头开始；但是环境变量被存储在Flash的另一块专门区域（Flash上有一个环境变量分区），一旦我们在程序中保存了该环境变量，那么下次开机时该环境变量的值将维持上一次更改保存后的值。

6.uboot的常用命令2

1、设置（添加/更改）环境变量：setenv/set

用法：set name value

2、保存环境变量的更改：saveenv/save

saveenv/save命令不带参数，直接执行，作用是将内存中的环境变量的值同步保存到Flash中环境变量的分区。注意：环境变量的保存是整体的覆盖保存，也就是说内存中所有的环境变量都会整体的将Flash中环境变量分区中原来的内容整体覆盖。

总结：彻底更改一个环境变量的值，需要2步：

第一步：set命令来更改内存中的环境变量

第二步：用save命令将其同步到Flash中环境变量的分区。

有时候我们只是想测试下这个环境变量，不希望影响到下一次开机，那就只set不save，这样set后当前本次运行的uboot已经起效果了，只不过没save下一次开机还是会恢复到原来的状况。

3、网络测试指令：ping

(1)命令用法： ping ip地址

注意：ping是测试开发板和主机之间的网络链接，注意以下步骤：

1)首先要插上网线。

2)先试图ping通主机windows。注意Windows中有线网卡的地址设置（设置本地连接）。设置主机windows的本地连接IPv4地址为192.168.1.10

3)第三步确认开发板中uboot里几个网络相关的环境变量的值对不对。最重要的是ipaddr（这个环境变量表示当前开发板的IP地址），这个地址必须和主机windows的IP地址在同一个网段。

网段的概念：一个IP地址分为2部分，一部分是网段地址，另一部分是网段内的主机地址（由子网掩码来区分哪一部分是网段地址，哪一部分是IP地址）。在子网掩码是255.255.255.0的情况下，192.168.1.10这个IP地址的前三部分（192.168.1.）属于网段地址，第4部分（10）属于主机地址。

7.开发板和主机的ping通

上节课最后的结果是：uboot中的ipaddr和主机windows本地连接地址已经设置到一个网段，但是实际还ping不通。

还发现了这样的现象：1、我把2个的网段都从192.168.1.x改到192.168.0.x时会ping通一次，第二次开始就ping不通了；2、有同学说ping不通可能是因为uboot中gatewayip没设置，我就实际测试设置网管为同网段.1，再次测试结论是第一次ping通了，第二次开始又不通了。

7.1、开发板运行linux下和主机Windows的ping通

(1)先将开发板刷机成linux+QT镜像（刷机见裸机教程第三部分），然后启动进入linux命令行终端下。

(2)在linux下使用ifconfig命令将开发板中linux系统的IP地址设置为和主机windows同一网段（为了上课方便，以后就固定：主机windows地址192.168.1.10，开发板uboot或linux的地址为192.168.1.20，虚拟机ubuntu地址为192.168.1.141）

(3)此时开发板端ping windows通的。

(4)windows中ping开发板也是通的。

说明：首先开发板和主机的网络部分硬件都是好的，网络连接也是好的，主机windows中的网络软件设置是好的。

7.2、开发板运行linux下和虚拟机ubuntu的ping通

(1)在linux基础课中讲过：虚拟机的网卡设置可以选择好几种方式，常用的就是NAT和桥接（bridged）。

(2)虚拟机要和开发板进行网络通信，只能通过桥接方式连接。

(3)虚拟机要想被开发板ping通，设置步骤如下：

第一步：虚拟机设置成桥接方式。

第二步：虚拟机的菜单中有个“虚拟网络编辑器”，这里面要设置为桥接到有线网卡。（默认是自动的，自动的一般会影响ping通。因为电脑现在一般都有2个网卡：一个有线的一个无线的。如果选了自动，那么虚拟机会自动桥接到无线网卡上，但是我们却是通过有线网卡来连接开发板的，自然ping不通）

第三步：在虚拟机ubuntu中设置IP地址为192.168.1.141（可以通过/etc/network/interfaces文件来设置静态的然后重启；也可以直接命令行ifconfig去设置）

(4)此时开发板ping虚拟机ubuntu应该就通了。

(5)此时虚拟机ubuntu中ping开发板也是通的。

7.3、开发板运行uboot下和主机Windows的ping通

(1)刚才开发板运行linux时和主机windows、虚拟机ubuntu都ping通了，说明硬件和连接和主机设置没错。

(2)此时开发板重启进入uboot，设置好ipaddr、gatewayip，然后去ping windows发现还是不通。怀疑uboot本身网络驱动有问题。

(3)然后同样情况下尝试去ping通虚拟机ubuntu，理论分析应该也不通，但是实际发现是通的。

7.4、开发板运行uboot下和虚拟机ubuntu的ping通

uboot和虚拟机ubuntu互相ping通（前提是虚拟机ubuntu设置为桥接，且桥接到有线网卡，且ip地址设置正确的情况下）

结论：开发板中运行的uboot有点小bug，ping windows就不通，ping虚拟机ubuntu就通。

8.uboot常用命令3

8.1、tftp下载指令：tftp

(1)uboot本身主要目标是启动内核，为了完成启动内核必须要能够部署内核，uboot为了部署内核就需要将内核镜像从主机中下载过来然后烧录到本地flash中。uboot如何从主机（windows或者虚拟机ubuntu）下载镜像到开发板上？有很多种方式，主流方式是：fastboot和tftp。

fastboot的方式是通过USB线进行数据传输。

tftp的方式是通过有线网络的。典型的方式就是通过网络，fastboot是近些年才新发展的。

(2)tftp方式下载时实际上uboot扮演的是tftp客户端程序角色，主机windows或虚拟机ubuntu中必须有一个tftp服务器，然后将要下载的镜像文件放在服务器的下载目录中，然后开发板中使用uboot的tftp命令去下载即可。

(3)有些人习惯在windows中搭建tftp服务器，一般是用一些软件来搭建（譬如tftpd32，使用起来比较简单）；有些人习惯在linux下搭建tftp服务器，可以参考网盘中的虚拟机下载目录下的一个教程《嵌入式开发环境搭建-基于14.04.pdf》，这里面有ubuntu中搭建tftp服务器的教程，也可以自己上网搜索教程尝试。（如果你直接就用我的虚拟机，那就已经搭建好了，不用再搭建了；如果是自己新装的那就参考文档搭建；如果你的版本和我的不一样那搭建过程可能不一样）

(4)我的虚拟机搭建的时候设置的tftp下载目录是/tftpboot，将要被下载的镜像复制到这个目录下。

(5)检查开发板uboot的环境变量，注意serverip必须设置为虚拟机ubuntu的ip地址。（serverip这个环境变量的意义就是主机tftp服务器的ip地址）

(6)然后在开发板的uboot下先ping通虚拟机ubuntu，然后再尝试下载：tftp 0x30000000 zImage-qt（意思是将服务器上名为zImage-qt的文件下载到开发板内存的0x30000000地址处。）

(7)镜像下载到开发板的DDR中后，uboot就可以用movi指令进行镜像的烧写了。

注意：

如果你是用的windows下的tftp服务器，那uboot的serverip就要设置为和windwos下tftp服务器的ip地址一样（windows下的tftp服务器软件设置的时候就有个步骤是让你设置服务器的ip地址，这个ip地址和主机windows必须在一个网段）。

9.uboot的常用命令4

9.1、SD卡/iNand操作指令movi

(1)开发板如果用SD卡/EMMC/iNand等作为Flash，则在uboot中操作flash的指令为movi（或mmc）

(2)movi指令是一个命令集，有很多子命令，具体用法可以help movi查看。

(3)movi的指令都是movi read和movi write一组的，movi read用来读取iNand到DDR上，movi write用来将DDR中的内容写入iNand中。理解这些指令时一定要注意涉及到的2个硬件：iNand和DDR内存。

(4)movi read {u-boot | kernel} {addr} 这个命令使用了一种通用型的描述方法来描述：movi 和read外面没有任何标记说明每一次使用这个指令都是必选的；一对大括号{}括起来的部分必选1个；大括号中的竖线表是多选一；中括号[]表示可选参数

(5)指令有多种用法，譬如 movi read u-boot 0x30000000，意思就是把iNand中的u-boot分区读出到DDR的0x30000000起始的位置处。（uboot代码中将iNand分成了很多个分区，每个分区有地址范围和分区名，uboot程序操作中可以使用直接地址来操作iNand分区，也可以使用分区名来操作分区。）；注意这里的0x30000000也可以直接写作30000000，意思是一样的（uboot的命令行中所有数字都被默认当作十六进制处理，不管你加不加0x都一样）。

9.2、NandFlash操作指令nand

理解方法和操作方法完全类似于movi指令

9.3、内存操作指令：mm、mw、md

(1)DDR中是没有分区的（只听说过对硬盘、Flash进行分区，没听说过对内存进行分区····），但是内存使用时要注意，千万不能越界踩到别人了。因为uboot是一个裸机程序，不像操作系统会由系统整体管理所有内存，系统负责分配和管理，系统会保证内存不会随便越界。然后裸机程序中uboot并不管理所有内存，内存是散的随便用的，所以如果程序员（使用uboot的人）自己不注意就可能出现自己把自己的数据给覆盖了。（所以你思考下我们为什么把uboot放在23E00000地址处）

(2)md就是memory display，用来显示内存中的内容。

(3)mw就是memory write，将内容写到内存中

(4)mm就是memory modify，修改内存中的某一块，说白了还是写内存（如果需要批量的逐个单元的修改内存，用mm最合适）

9.4、启动内核指令：bootm、go

(1)uboot的终极目标就是启动内核，启动内核在uboot中表现为一个指令，uboot命令行中调用这个指令就会启动内核（不管成功与否，所以这个指令是一条死路）。

(2)差别：bootm启动内核同时给内核传参，而Go命令启动内核不传参。bootm其实才是正宗的启动内核的命令，一般情况下都用这个；go命令本来不是专为启动内核设计的，go命令内部其实就是一个函数指针指向一个内存地址然后直接调用那个函数，go命令的实质就是PC直接跳转到一个内存地址去运行而已。go命令可以用来在uboot中执行任何的裸机程序（有一种调试裸机程序的方法就是事先启动uboot，然后在uboot中去下载裸机程序，用go命令去执行裸机程序）

10.uboot的常用环境变量1

10.1、环境变量如何参与程序运行

(1)环境变量有2份，一份在Flash中，另一份在DDR中。uboot开机时一次性从Flash中读取全部环境变量到DDR中作为环境变量的初始化值，然后使用过程中都是用DDR中这一份，用户可以用saveenv指令将DDR中的环境变量重新写入Flash中去更新Flash中环境变量。下次开机时又会从Flash中再读一次。

(2)环境变量在uboot中是用字符串表示的，也就是说uboot是按照字符匹配的方式来区分各个环境变量的。因此用的时候一定要注意不要打错字了。

1、自动运行倒数时间：bootdelay

2、网络设置：ipaddr serverip

(1)ipaddr是开发板的本地IP地址

(2)serverip是开发板通过tftp指令去tftp服务器下载东西时，tftp服务器的IP地址。

(3)gatewayip是开发板的本地网关地址

(4)netmask是子网掩码

(5)ethaddr是开发板的本地网卡的MAC地址。

11.uboot的常用环境变量2

11.1、自动运行命令设置：bootcmd

(1)uboot启动后会开机自动倒数bootdelay秒，如果没有人按下回车打断启动，则uboot会自动执行启动命令来启动内核。

(2)uboot开机自动启动时实际就是在内部执行了bootcmd这个环境变量的值所对应的命令集：bootcmd=movi read kernel 30008000; bootm 30008000

意思是：将iNand的kernel分区读取到DDR内存的0x30008000地址处，然后使用bootm启动命令从内存0x30008000处去启动内核。

(3)set bootcmd printenv，然后saveenv；然后重启则会看到启动倒数后自动执行printenv命令打印出环境变量。这个小实验说明开机自动执行了bootcmd。

(4)设置bootcmd环境变量：set bootcmd 'movi read kernel 30008000; bootm 30008000'

11.2、uboot给kernel传参：bootargs

(1)linux内核启动时可以接收uboot给他传递的启动参数，这些启动参数是uboot和内核约定好的形式、内容，linux内核在这些启动参数的指导下完成启动过程。这样的设计是为了灵活，为了内核在不重新编译的情况下可以用不同的方式启动。

(2)我们要做的事情就是：在uboot的环境变量中设置bootargs，然后bootm命令启动内核时会自动将bootargs传给内核。

(3)环境变量bootargs=console=ttySAC2,115200 root=/dev/mmcblk0p2 rw init=/linuxrc rootfstype=ext3

意义解释：

console=ttySAC2,115200 控制台使用串口2，波特率115200.

root=/dev/mmcblk0p2 rw 根文件系统在SD卡端口0设备（iNand）第2分区，根文件系统是可读可写的

init=/linuxrc linux的进程1（init进程）的路径

rootfstype=ext3 根文件系统的类型是ext3

(4)内核传参非常重要。在内核移植的时候，新手经常因为忘记给内核传参，或者给内核传递的参数不对，造成内核启动不起来。

11.3、新建、更改、删除一个环境变量的方法

(1)新建一个环境变量，使用set var value

(2)更改一个环境变量，使用set var value

(3)删除一个环境变量，使用set var

注意：修改完成环境变量后一定要保存，否则下次开机更改就又没了。

12.uboot中对Flash和DDR的管理

12.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中使用同一个分区表。将来在系统部署时和系统代码中的分区方法也必须一样。

12.2、uboot阶段DDR的分区

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

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

(3)注意内存分区关键就在于内存中哪一块用来干什么必须分配好，以避免各个不同功能使用了同一块内存造成的互相踩踏。譬如说我们tftp 0x23E00000 zImage去下载zImage到内存的0x23E00000处就会出错，因为这个内存处实际是uboot的镜像所在。这样下载会导致下载的zImage把内存中的uboot给冲掉。

广告商务合作，请联系0755-33248146

智能座舱之存储篇第三篇---NAND Flash 一眼就看明白了

为什么要有uboot带你全面分析嵌入式中uboot的作用

关于我们

产品中心

服务与支持