由于最近工作需要用到uboot相关知识，便将自己之前的学习笔记整理一下，顺便回顾回顾。人生若只如初见，何事秋风悲画扇。就让我们一起在本篇文章来初识uboot
(1)计算机系统就是有CPU来做核心进行运行的系统。典型的计算机系统有：PC机（台式机+笔记本）、嵌入式设备（手机、平板电脑、游戏机）、单片机（家用电器像电饭锅、空调）
(2)计算机系统的组成部件非常多，不同的计算机系统组成部件也不同。但是所有的计算机系统运行时需要的主要核心部件都是3个东西：CPU + 外部存储器（Flash/硬盘） + 内部存储器（DDR SDRAM/SDRAM/SRAM）
在嵌入式操作系统中，BootLoader是在操作系统内核运行之前运行。可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。
在嵌入式系统中，通常并没有像BIOS那样的固件程序（注，有的嵌入式CPU也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由BootLoader来完成。在一个基于ARM7TDMI core的嵌入式系统中，系统在上电或复位时通常都从地址0x00000000处开始执行，而在这个地址处安排的通常就是系统的BootLoader程序。
Bootloader是嵌入式系统在加电后执行的第一段代码，在它完成CPU和相关硬件的初始化之后，再将操作系统映像或固化的嵌入式应用程序装载到内存中然后跳转到操作系统所在的空间，启动操作系统运行
对于嵌入式系统，Bootloader是基于特定硬件平台来实现的。因此，几乎不可能为所有的嵌入式系统建立一个通用的Bootloader，不同的处理器架构都有不同的Bootloader。Bootloader不但依赖于CPU的体系结构，而且依赖于嵌入式系统板级设备的配置。对于2块不同的嵌入式板而言，即使它们使用同一种处理器，要想让运行在一块板子上的Bootloader程序也能运行在另一块板子上，一般也都需要修改Bootloader的源程序。
反过来，大部分Bootloader仍然具有很多共性，某些Bootloader也能够支持多种体系结构的嵌入式系统。例如，U-Boot就同时支持PowerPC、ARM、MIPS和X86等体系结构，支持的板子有上百种。通常，它们都能够自动从存储介质上启动，都能够引导操作系统启动，并且大部分都可以支持串口和以太网接口。
(1)典型的PC机的部署：BIOS程序部署在PC机主板上（随主板出厂时已经预制了），操作系统部署在硬盘上，内存在掉电时无作用（掉电时不会保存内容），CPU在掉电时不工作。
(2)启动过程：PC上电后先执行BIOS程序（实际上PC的BIOS就是部署在NorFlash），BIOS程序负责初始化DDR内存，负责初始化硬盘，然后从硬盘上将OS镜像读取到DDR中，然后跳转到DDR中去执行OS直到启动（OS启动后BIOS就无用了）
(1)嵌入式系统的部署和启动都是参考PC机的。只是设备上有一些差别
(2)典型嵌入式系统的部署：uboot程序部署在Flash（能作为启动设备的Flash）上、OS部署在FLash（嵌入式系统中用Flash代替了硬盘，现在大多数开发板可能使用emmc）上、内存在掉电时无作用，CPU在掉电时不工作。
(3)启动过程：嵌入式系统上电后先执行uboot、然后uboot负责初始化DDR，初始化Flash，然后将OS从Flash中读取到DDR中，然后启动OS（OS启动后uboot就无用了），虽然存储设备不一定是flash，但是上述的过程都是一样的。
总结：嵌入式系统和PC机的启动过程几乎没有两样，只是BIOS成了uboot，硬盘成了Flash。
(1)android系统的启动和linux系统（前面讲的典型的嵌入式系统启动）几乎一样。几乎一样意思就是前面完全一样，只是在内核启动后加载根文件系统后不同了。
(2)可以认为启动分为2个阶段：第一个阶段是uboot到OS启动；第二个阶段是OS启动后到rootfs加载到命令行执行；现在我们主要研究第一个阶段，android的启动和linux的差别在第二阶段。
(1)uboot主要作用是用来启动操作系统内核。
(2)uboot还要负责部署整个计算机系统。
(3)uboot中还有操作Flash等板子上存储设备的驱动。
(4)uboot还提供一个命令行界面供人来操作。
(1)uboot是SourceForge上的开源项目
(2)uboot项目的作者：一个德国人最早发起的项目
(3)uboot就是由一个人发起，然后由整个网络上所有感兴趣的人共同维护发展而来的一个bootloader。
(1)自己使用的小开源项目。
(2)被更多人认可使用
(3)被SoC厂商默认支持。
uboot经过多年发展，已经成为事实上的业内bootloader标准。现在大部分的嵌入式设备都会默认使用uboot来做为bootloader。
(1)早期的uboot的版本号类似于这样：uboot1.3.4。后来版本号便成了类似于uboot-2010.06。
(2)uboot的核心部分几乎没怎么变化，越新的版本支持的开发板越多而已，对于一个老版本的芯片来说，新旧版本的uboot并没有太大差异，只不过可能多了一些新的机制，如设备树机制。
(1)uboot就是universal bootloader（通用的启动代码），通用的意思就是在各种地方都可以用。所以说uboot具有可移植性。
(2)uboot具有可移植性并不是说uboot在哪个开发板都可以随便用，而是说uboot具有在源代码级别的移植能力，可以针对多个开发板进行移植，移植后就可以在这个开发板上使用了。
uboot的出现是一种必然，如果没有uboot也会有另一个bootloader来代替。
(1)一般的SoC都支持多种启动方式，譬如SD卡启动、NorFlash启动、NandFlash启动等·····uboot要能够开机启动，必须根据具体的SoC的启动设计来设计uboot。
(2)uboot必须进行和硬件相对应的代码级别的更改和移植，才能够保证可以从相应的启动介质启动。uboot中第一阶段的start.S文件中具体处理了这一块。
(1)uboot的终极目标就是启动内核。
(2)linux内核在设计的时候，设计为可以被传参。也就是说我们可以在uboot中事先给linux内核准备一些启动参数放在内存中特定位置然后传给内核，内核启动后会到这个特定位置去取uboot传给他的参数，然后在内核中解析这些参数，这些参数将被用来指导linux内核的启动过程。
uboot必须能够被人借助而完成整个系统（包括uboot、kernel、rootfs等的镜像）在Flash上的烧录下载工作。
(1)uboot中实现了一部分硬件的控制能力（uboot中初始化了一部分硬件），因为uboot为了完成一些任务必须让这些硬件工作。譬如uboot要实现刷机必须能驱动板载的存储设备，譬如uboot要在刷机时LCD上显示进度条就必须能驱动LCD，譬如uboot能够通过串口提供操作界面就必须驱动串口。譬如uboot要实现网络功能就必须驱动网卡芯片。
(2)SoC级（譬如串口）就是SoC内部外设，板级就是SoC外面开发板上面的硬件（譬如网卡、iNand）
(1)uboot的生命周期就是指：uboot什么时候开始运行，什么时候结束运行。
(2)uboot本质上是一个裸机程序（不是操作系统），一旦uboot开始SoC就会单纯运行uboot（意思就是uboot运行的时候别的程序是不可能同时运行的），一旦uboot结束运行则无法再回到uboot（所以uboot启动了内核后uboot自己本身就死了，要想再次看到uboot界面只能重启系统。重启并不是复活了刚才的uboot，重启只是uboot的另一生）。
(3)uboot的入口和出口。uboot的入口就是开机自动启动，uboot的唯一出口就是启动内核。uboot还可以执行很多别的任务（譬如烧录系统），但是其他任务执行完后都可以回到uboot的命令行继续执行uboot命令，而启动内核命令一旦执行就回不来了。
总结：一切都是为了启动内核
(1)uboot的本质就是一个裸机程序，和那些裸机程序xx.bin并没有本质区别。如果非说要有区别，那就是：我们写的大部分裸机程序小于16KB，而uboot大于16KB（一般uboot在180k-400k之间）
(2)uboot本身是一个开源项目，由若干个.c文件和.h文件组成，配置编译之后会生成一个uboot.bin，这就是uboot这个裸机程序的镜像文件。然后这个镜像文件被合理的烧录到启动介质中拿给SoC去启动。也就是说uboot在没有运行时表现为uboot.bin，一般躺在启动介质中。
(3)uboot运行时会被加载到内存中然后一条指令一条指令的拿给CPU去运行。
(1)普通的裸机程序运行起来就直接执行了，执行时效果和代码有关。
(2)有些程序需要和人进行交互，于是乎程序中就实现了一个shell（shell就是提供人机交互的一个界面），uboot就实现了一个shell。
注意：shell并不是操作系统，和操作系统一点关系都没有。linux中打开一个终端后就得到了一个shell，可以输入命令回车执行。uboot中的shell工作方式和linux中的终端shell非常像（其实几乎是一样的，只是命令集不一样。譬如linux中可以ls，uboot中ls就不识别）
(1)uboot启动后大部分时间和工作都是在shell下完成的（譬如uboot要部署系统要在shell下输命令、要设置环境变量也得在命令行地下，要启动内核也要在命令行底下输入命令）
(2)命令就是uboot的shell中可以识别的各种命令。uboot中有几十个命令，其中有一些常用另一些不常用（我们还可以自己给uboot添加命令）。
(3)uboot的环境变量 和 操作系统的环境变量工作原理和方式几乎完全相同。uboot在设计时借助了操作系统的设计理念（命令行工作方式借鉴了linux终端命令行，环境变量借鉴了操作系统的环境变量，uboot的驱动管理几乎完全照抄了linux的驱动框架）。
(4)环境变量可以被认为是系统的全局变量，环境变量名都是系统内置的（系统认识就认识，不认识就不认识，这部分是系统自带的默认的环境变量，譬如PATH；但是也有一部分环境变量是自己添加的，自己添加的系统就不认识但是我们自己认识）。系统或者我们自己的程序在运行时可以通过读取环境变量来指导程序的运行。这样设计的好处就是灵活，譬如我们要让一个程序更改运行方法，不用去重新修改程序代码再重新编译运行，而只要修改相应的环境变量就可以了。
(5)环境变量就是运行时的配置属性。
(1)行缓冲的意思就是：当我们向终端命令行输入命令的时候，这些命令没有立即被系统识别，而是被缓冲到一个缓存区（也就是系统认为我们还没有输入完），当我们按下回车键（换行）后系统就认为我们输入完了，然后将缓冲区中所有刚才输入的作为命令拿去分析处理。
(2)linux终端设计有3种缓冲机制：无缓冲、行缓冲、全缓冲
(1)有些命令有简化的别名，譬如printenv命令可以简化为print，譬如setenv可以简化为set。
(2)有些命令会带参数（注意格式是固定的），uboot的每个命令都有事先规定好的各种格式。
有些命令就是不带参数的，譬如printenv/print命令；
有些命令带可选的参数（可以带也可以不带，当然带不带参数的执行结果是不同的）；
有些命令必须带参数（譬如setenv/set命令）。可通过help查看各个命令的使用方法和功能介绍。
(1)uboot的有些命令带的参数非常长，为了告诉uboot这个非常长而且中间有好多个空格的东西是给他的一整个参数，所以用单引号将这个很长且中间有空格隔开的参数引起来。
(2)别的符号也许也有，而且有特定的意义。当碰到uboot的命令行有特殊符号时要注意不是弄错了，而是可能有特别的含义。
(1)命令族意思就是好多个命令开头都是用同一个命令关键字的，但是后面的参数不一样，这些命令的功能和作用也不同。这就叫一个命令族。
(2)同一个命令族中所有的命令都有极大的关联，譬如movi开头的命令族都和moviNand（EMMC、iNand）操作有关。
(1)print命令不用带参数，作用是打印出系统中所有的环境变量。
(2)环境变量就好像程序的全局变量一样。程序中任何地方都可以根据需要去调用或者更改环境变量（一般都是调用），环境变量和全局变量不同之处在于：全局变量的生命周期是在程序的一次运行当中，开始运行时诞生程序结束时死亡，下次运行程序时从头开始；但是环境变量被存储在Flash的另一块专门区域（Flash上有一个环境变量分区），一旦我们在程序中保存了该环境变量，那么下次开机时该环境变量的值将维持上一次更改保存后的值。
(1)设置（添加/更改）环境变量：setenv/set
用法：set name value
(2)保存环境变量的更改：saveenv/save
saveenv/save命令不带参数，直接执行，作用是将内存中的环境变量的值同步保存到Flash中环境变量的分区。注意：环境变量的保存是整体的覆盖保存，也就是说内存中所有的环境变量都会整体的将Flash中环境变量分区中原来的内容整体覆盖。
总结：彻底更改一个环境变量的值，需要2步：第一步set命令来更改内存中的环境变量，第二步用save命令将其同步到Flash中环境变量的分区。
有时候我们只是想测试下这个环境变量，不希望影响到下一次开机，那就只set不save，这样set后当前本次运行的uboot已经起效果了，只不过没save下一次开机还是会恢复到原来的状况。
(1)命令用法： ping ip地址
注意：ping是测试开发板和主机之间的网络链接，注意以下步骤：
1)网线将开发板和电脑直连(此时将电脑会将开发板当作一个路由器)，然后设置PC端的IP地址，具体设置操作可搜索相关百度教程。
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）属于主机地址。
(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服务器，如在ubuntu中搭建tftp服务器，可以自己上网搜索教程尝试。
(4)我的ubuntu虚拟机搭建的时候设置的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指令进行镜像的烧写了。
注意：
1）如果你是用的windows下的tftp服务器，那uboot的serverip就要设置为和windwos下
tftp服务器的ip地址一样。
2）整个过程中间环节比较多，实际做的时候可能最后会下载不下来。这时候可能的问题非
常多，逐步来排查。
（譬如：第一步应该先保证uboot和ubuntu可以ping通；第二步再保证ubuntu中tftp服务器
搭建正确；第三步再实现tftp下载。）
(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都一样）。
(1)DDR中是没有分区的（只听说过对硬盘、Flash进行分区，没听说过对内存进行分区····），但是内存使用时要注意，千万不能越界踩到别人了。
因为uboot是一个裸机程序，不像操作系统会由系统整体管理所有内存，系统负责分配和管理，系统会保证内存不会随便越界。然后裸机程序中uboot并不管理所有内存，内存是散的随便用的，所以如果程序员（使用uboot的人）自己不注意就可能出现自己把自己的数据给覆盖了。
(2)md就是memory display，用来显示内存中的内容。
(3)mw就是memory write，将内容写到内存中
(4)mm就是memory modify，修改内存中的某一块，说白了还是写内存（如果需要批量的逐个单元的修改内存，用mm最合适）
(5)NandFlash操作指令nand，理解方法和操作方法完全类似于movi指令
(1)uboot的终极目标就是启动内核，启动内核在uboot中表现为一个指令，uboot命令行中调用这个指令就会启动内核（不管成功与否，一旦执行这个命令就回不来了，所以这个指令是一条死路）。
(2)差别：bootm启动内核同时给内核传参，而go命令启动内核不传参。bootm其实才是正宗的启动内核的命令，一般情况下都用这个；go命令本来不是专为启动内核设计的，go命令内部其实就是一个函数指针指向一个内存地址然后直接调用那个函数，go命令的实质就是PC直接跳转到一个内存地址去运行而已。
go命令可以用来在uboot中执行任何的裸机程序（有一种调试裸机程序的方法就是事先启动uboot，然后在uboot中去下载裸机程序，用go命令去执行裸机程序，但我没有用过）
(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中的网络软件设置是好的。
(1)虚拟机的网卡设置可以选择好几种方式，常用的就是NAT和桥接（bridged）。
(2)虚拟机要和开发板进行网络通信，只能通过桥接方式连接。
(3)虚拟机要想被开发板ping通，设置步骤如下：
第一步：虚拟机设置成桥接方式。
第二步：虚拟机的菜单中有个“虚拟网络编辑器”，这里面要设置为桥接到有线网卡。（默认是
自动的，自动的一般会影响ping通。因为电脑现在一般都有2个网卡：一个有线的一个无线的。
如果选了自动，那么虚拟机会自动桥接到无线网卡上，但是我们却是通过有线网卡来连接开发
板的，开发板和PC使用网线直连，自然ping不通）
第三步：在虚拟机ubuntu中设置IP地址为192.168.1.141（可以通过
/etc/network/interfaces文件来设置静态的然后重启，也可以直接命令行ifconfig去设置）
(4)此时开发板ping虚拟机ubuntu应该就通了。
(5)此时虚拟机ubuntu中ping开发板也是通的。
(1)刚才开发板运行linux时和主机windows、虚拟机ubuntu都ping通了，说明硬件和连接和主机设置没错。
(2)此时开发板重启进入uboot，设置好ipaddr、gatewayip，然后去ping windows,应该可以ping通，若不通，则需要去排查解决。
uboot和虚拟机ubuntu互相ping通（前提是虚拟机ubuntu设置为桥接，且桥接到有线网卡，且ip地址设置正确的情况下）
我个人实验结论：开发板中运行的uboot有点小bug，ping windows就不通，ping虚拟机ubuntu就通，当然我用的uboot版本比较老，你们现在用的应该不会有这个问题。
(1)环境变量有2份，一份在Flash中，另一份在DDR中。uboot开机时一次性从Flash中读取全部环境变量到DDR中作为环境变量的初始化值，然后使用过程中都是用DDR中这一份，用户可以用saveenv指令将DDR中的环境变量重新写入Flash中去更新Flash中环境变量。下次开机时又会从Flash中再读一次。
(2)环境变量在uboot中是用字符串表示的，也就是说uboot是按照字符匹配的方式来区分各个环境变量的。因此用的时候一定要注意不要打错字了。如自动运行程序倒数时间环境变量：bootdelay
(1)ipaddr是开发板的本地IP地址
(2)serverip是开发板通过tftp指令去tftp服务器下载东西时，tftp服务器的IP地址。
(3)gatewayip是开发板的本地网关地址
(4)netmask是子网掩码
(5)ethaddr是开发板的本地网卡的MAC地址。
(1)uboot启动后会开机自动倒数bootdelay秒，如果没有人按下回车打断启动(我用的uboot的打断方式是enter键，有的可能是其他按键)，则uboot会自动执行启动命令来启动内核。
(2)uboot开机自动启动时实际就是在内部执行了bootcmd这个环境变量的值所对应的命令集。
(3)bootcmd=movi read kernel 30008000; bootm 30008000 意思是：将iNand的kernel分区内容读取到DDR内存的0x30008000地址处，然后使用bootm启动命令从内存0x30008000处去启动内核。
(4)命令行执行set bootcmd printenv，然后saveenv；然后重启则会看到启动倒数后自动执行printenv命令打印出环境变量。这个小实验说明开机自动执行了bootcmd。
(1)linux内核启动时可以接收uboot给他传递的启动参数，这些启动参数是uboot和内核约定好的形式、内容，linux内核在这些启动参数的指导下完成启动过程。这样的设计是为了灵活，为了内核在不重新编译的情况下可以用不同的方式启动。
(2)我们要做的事情就是：在uboot的环境变量中设置bootargs，然后bootm命令启动内核时会自动将bootargs传给内核。
bootargs=console=ttySAC2,115200 root=/dev/mmcblk0p2 rw init=/linuxrc rootfstype=ext3
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)内核传参非常重要。在内核移植的时候，新手经常因为忘记给内核传参，或者给内核传递的参数不对，造成内核启动不起来。
(1)新建一个环境变量，使用set var value
(2)更改一个环境变量，使用set var value
(3)删除一个环境变量，使用set var
注意：修改完成环境变量后一定要保存，否则下次开机更改就又没了。
(1)所谓分区，就是说对Flash进行分块管理。
(2)PC机等产品中，因为大家都是在操作系统下使用硬盘的，整个硬盘由操作系统统一管理，操作系统会使用文件系统帮我们管理硬盘空间。（管理保证了文件之间不会互相堆叠），于是乎使用者不用自己太过在意分区问题。
(3)在uboot中是没有操作系统的，因此我们对Flash（相当于硬盘）的管理必须事先使用分区界定（实际上在uboot中和kernel中都有个分区表，分区表就是我们在做系统移植时对Flash的整体管理分配方法）。有了这个界定后，我们在部署系统时按照分区界定方法来部署，uboot和kernel的软件中也是按照这个分区界定来工作，就不会错。
(4)分区方法不是一定的，不是固定的，是可以变动的。但是在一个移植中必须事先设计好定死，一般在设计系统移植时就会定好，定的标准是：
uboot必须从Flash起始地址开始存放（也许是扇区0，也许是扇区1，也许是其他，取决于SoC的启动设计），uboot分区的大小必须保证uboot肯定能放下，一般设计为512KB或者1MB（因为一般uboot肯定不足512KB，给再大其实也可以工作，但是浪费）；
环境变量分区一般紧贴着uboot来存放，大小为32KB或者更多一点。
kernel可以紧贴环境变量存放，大小一般为3MB或5MB或其他。
rootfs跟在kernel后存放，大小取决于自己的rootfs大小
剩下的就是自由分区，一般kernel启动后将自由分区挂载到rootfs下使用。以上各个部分所占的大小是根据我的s5pv210开发板设置的，实际操纵以你的开发板为主。
总结：一般规律如下：
(1)各分区彼此相连，前面一个分区的结尾就是后一个分区的开头。
(2)整个flash充分利用，从开头到结尾。
(3)uboot必须在Flash开头，其他分区相对位置是可变的。
(4)各分区的大小由系统移植工程师自己来定，一般定为合适大小（不能太小，太小了容易
溢出；不能太大，太大了浪费空间，但要留有一定的预留量，便于后续升级）
(5)分区在系统移植前确定好，在uboot中和kernel中使用同一个分区表。将来在系统部署
时和系统代码中的分区方法也必须一样。
(1)DDR的分区和Flash的分区不同，主要是因为Flash是掉电存在的，而DDR是掉电消失，因此可以说DDR是每次系统运行时才开始部署使用的。
(2)内存的分区主要是在linux内核启动起来之前，linux内核启动后 内核的内存管理模块 会接管整个内存空间，那时候就不用我们来管了。
(3)注意内存分区** 关键 就在于内存中哪一块用来干什么必须分配好，以避免各个不同功能使用了同一块内存造成的互相踩踏**。
譬如说我们tftp 0x23E00000 zImage去下载zImage到内存的0x23E00000处就会出错，因为这个内存处实际是uboot的镜像所在。这样下载会导致下载的zImage把内存中的uboot给覆盖掉。
注：本资料大部分由朱老师物联网大讲堂课程笔记整理而来、引用了百度百科、部分他人博客的内容并结合自己实际开发经历，如有侵权，联系删除！水平有限，如有错误，欢迎各位在评论区交流。