Uboot和系统移植
资料整理于自己的笔记（有许多的图片和代码块没有添加，后面会慢慢补齐），也有些是博客之类 ，如有侵权，请及时联系我，我会及时删除。因为都是手码的，可能会有些错别字，理解有误的地方请联系我，以便及时修改
计算机系统的组成：
CPU(控制器/运算器) + 内存（DDR /SDRAM ） +外存（硬盘、flash）
嵌入式系统的启动过程：Uboot存放在norflash中，开机从norflah启动Uboot、uboot去初始化DDR,OS存放flash中，DDR初始化结束以后，将OS加载到DDR中去运行，这是就启动了操作系统。
简而言之，分为两个部分
（1）Uboot加载启动操作系统
（2）操作系统启动以后，加载rootfs（跟文件系统）
<自己动手安装交叉编译工具链2>
1.4.4.自己动手安装交叉编译工具链2
1.4.3.1、环境变量的意义
环境变量就是操作系统的全局变量。每一个环境变量对操作系统来说都是唯一的，名字和所代表的意义都是唯一的。linux系统可以有很多个环境变量。其中有一部分是linux系统自带的，还有一些是我们自己来扩充的。我们这里涉及到的一个环境变量是
PATH。PATH这个环境变量是系统自带的，它的含义就是系统在查找可执行程序时会搜索的路径范围。
1.4.3.2、将工具链导出到环境变量
exportPATH=/usr/local/arm/arm-2009q3/bin:$PATH
在一个终端中执行以上命令后，该终端中就可以直接使用arm-linux-gcc了，但是只要关掉这个终端再另外打开一个立马就不行了。原因是我们本次终端中执行时的操作只是针对本终端，以后再打开的终端并未被执行过这个命令所以没导出。
解决方案是在~/.bashrc中，添加export PATH=/usr/local/arm/arm-2009q3/bin:$PATH 即可。
注意：我们导出这个环境变量是在当前用户，如果你登录时在其他用户下是没用的。
1.4.3.3、为工具链创建arm-linux-xxx符号链接
lnarm-none-linux-gnueabi-addr2line -s arm-linux-addr2line
< Uboot是干嘛的 >
（1）原始目的：启动操作系统
启动操作系统中，有一项也很重要，就是给内核传参，依靠传参来配置内核启动的细节。
（2）部署整个操作系统（部署就是把响应的东西放到该在的地方，比如OS在flash中，Uboot把它加载到DDR中去运行）根文件系统的布置，Uboot可以布置操作系统（烧录系统镜像。）
（3）操作flash等板子上的驱动
Uboot支持SOC级，和版级的硬件驱动，比如在Uboot刷系统中，LCD屏幕上显示了一个进度条，在开机自启动的时间，自动提供了一个Shell界面（SOC）,如果在启动时需要配置网络之类的，那么就要包含驱动网卡芯片的功能。
（4）提供一个命令行界面供人操作
< Uboot必须解决的问题 >
（1）必须能自动启动，给内核传参
（2）部署整个操作系统
（3）驱动版级和SOC的硬件
< Uboot的生命周期 >
Uboot本质上是一个裸机程序，裸机程序和操作系统不同，裸机程序只能单个运行，操作系统可以多进度运行，重复运行，而uboot不可以，这也是为什么Uboot可以ping通主机而主机不能Ping通uboot的原理，因为Uboot内不具备接收数据包的功能。
Uboot的入口就是自动启动，它的终极目标就是启动操作系统，如果它没有成功启动操作系统，就会一直打转，知道启动为止，而一旦操作系统启动代码开启，这就是它的出口，它就死了。
Uboot的两个关键点：
（1）命令
（2）环境变量
< Uboot常用命令 >
（1）print = printenv 打印环境变量
（2）set = setenv name value 设置环境变量
（3）save 保存更改（这里有一个机制，uboot中的环境变量都是存放在Flash中的，所以可以实现掉电保存，而在uboot中修改的环境变量是在内存中，所以当我们需要重启依旧保持环境变量的修改，那么就需要save）
（4）ping:
（1）umask：需要设置为同一个子网掩码255.255.255.0
（2）保证Uboot和虚拟机/PC机在同一个网段
（3）虚拟机的网络需要设立为桥接模式
（4）虚拟机的菜单中有个“虚拟网络编辑器”，这里面要设置为桥接到有线网卡。（默认是自动的，自动的一般会影响ping通。因为电脑现在一般都有2个网卡：一个有线的一个无线的。如果选了自动，那么虚拟机会自动桥接到无线网卡上，但是我们却是通过有线网卡来连接开发板的，自然ping不通）
如图所示
（5）tftp
Uboot有两种部署镜像的方法
（1）fastboot 装裸机驱动部分有教程
（2）tftp 利用在Ubuntu中的tftp工具，发送
安装和配置教程在（嵌入式开发环境搭建中有详述）
注意：
（1）安装好以后会在Ubuntu中有一个文件夹（我的是tftpboot），我们把需要传输的镜像放在这个文件夹下，然后去uboot去pingUbuntu，如果通了，就可以使用命令
tftp0x30000000 name 来传输了
（2）传输时是依靠字符来匹配文件，所以命令中的字符一定要匹配
（3）传输的地址要有效，比如S5PV210中是0x30000000~0x50000000
（6）movi指令族
（7）读写DDR指令
md[.b, .w, .l] address [# of objects]
读取一个地址的内容
可以指定读取的字节数.b .w .l 分别对应不同的字节数
mw[.b, .w, .l] address value [count]
向一个地址写内容
mm[.b, .w, .l] address
向一个地址写内容，但是是地址会自动向下增加，输入Y结束
（7）bootcmd
开机自动启动的环境变量，是一个命令集合，所以在设置bootcmd时需要加' '双单引号。
（8）bootarg
前面说过了在bootm启动系统时需要给内核传参，这里的Bootarg就是给内核的传参
注意：如果在启动时启动不起来，那么就需要查询环境变量，以及bootarg，仔细观察是否有写错，修改完环境变量以后要记得保存。
对flash和DDR的分区>
（1）Uboot对flash的分区
flash是掉电仍然在的，所以用来存储Uboot.kernel.。。。。
Uboot规定必须在flash的开头，因为作为启动代码
环境变量贴着Uboot分区
剩下的分区如图所示
除了Uboot必须在开头以外，其它的分区相对位置是可以改变的。
（2）Uboot对DDR的分区
DDR相对于Flash是掉电消失的，所以对DDR的分区管理是在内核启动之前的，当操作系统内核启动起来之后，会接手对内存的管理，我们只需要在对DDR分区是注意不要内存踩踏即可。
<配置 >
在编译U-boot之前要对Uboot进行配置
(1).make 执行：make x210_sd_config
(2).查看交叉编译工具链是否正确（路径/版本）
在Uboot的makefile 147行
CROSS_COMPILE= ？？？？？查看行代码，如果不正确就需要按照路径装交叉编译工具链
<编译 >
make make -j4（多线程编译）
各文件介绍>
(1).gitignore。git工具的文件，git是一个版本管理工具（类似的还有个svn），这个文件和git有关，和uboot本身无关的，不用去管。
(2)arm_config.mk。后缀是.mk，是一个Makefile文件，将来在某个Makefile中会去调用它。
(3)三个Changelog文件，修改记录文件，该文件记录了这个uboot项目的版本变迁以及每个版本较上个版本修改的记录。正式的项目都有这些记录的。可以直接忽略，主要是给维护uboot的人用的。
(4)config.mk。和arm_config.mk差不多性质。
(5)COPYING。版权声明，uboot本身是GPL许可证的。
(6)CREDITS。鸣谢，里面记录了对uboot有贡献的人，感谢目录。
(7)image_split。一个脚本，看说明是用来分割uboot.bin到BL1的，暂时用不到，先不管。
(8)MAINTAINERS。维护者，就是当前在参与维护uboot源码的社区工作者。
(9)MAKEALL。一个脚本，应该是帮助编译uboot的。
(10)Makefile。这个很重要，是uboot源代码的主Makefile，将来整个uboot被编译时就是用这个Makefile管理编译的，所以我们在下个课程中研究uboot配置编译过程时就要分析这个Makefile。
(11)mk。快速编译的脚本，其实就是先清理然后配置然后编译而已。
(12)mkconfig。这个很重要，是uboot配置阶段的主要配置脚本。uboot的可移植性很大程度就是靠这个配置脚本在维护的。我们在下个课程中研究uboot配置编译过程时就要分析这个配置脚本。
(13)mkmovi。暂时不去管他，一个脚本，和iNand/SD卡启动有关
(14)README。所有的软件都有README，一般拿到一个东西要先读README，这个东西其实就是个简单的使用说明书。
(15)rules.mk。这个文件是我们uboot的Makefile使用的规则，本身非常重要，但是我们不去分析他，不去看他。
总结：以上这些文件中，对我们比较重要，需要认真看的有2个：mkconfig和Makefile。一个负责uboot的配置，一个负责编译。
各文夹介绍>
(1)api.硬件无关的功能函数的API。uboot移植时基本不用管，这些函数是uboot本身使用的。
(2)api_examples. API相关的测试事例代码。
(3)board。board是板的意思，板就是开发板。board文件夹下每一个文件都代表一个开发板，这个文件夹下面放的文件就是用来描述这一个开发板的信息的。board目录下有多少个文件夹，就表示当前这个uboot已经被移植到多少个开发板上了（当前的uboot支持多少个开发板）。
问题一：思考uboot如何支持多套开发板，如何具有可移植性
问题二：board下有这么多文件夹，究竟如何确定具体使用的是哪一个？uboot在配置阶段会有一些手段帮助我们来确定具体使用的是board目录下的哪一个文件夹。（想想为什么不能直接编译而要先配置）
问题三：开发板越来越多，board目录下文件夹越来越多不方便管控
Q1:Uboot之所以支持多套开发板，是因为在每移植好一块开发板以后会在board目录下放上这个开发版的信息，表示支持了这个开发板
Q2：之所以不能直接编译Uboot的原因就在于此，我们不知道Uboot需要的是哪一部分代码，配置就是对broad下支持的开发板文件夹进行一个索引
Q3:开发板越来越多，所以后来在board中添加了一个文件夹，用来标识开发板的IC厂商，然后在把开发板的信息放到相应的厂商文件夹下，那么为了向前兼容，之前的开发板信息不会改变，因为一旦改变之前的代码就不能用了（路径）
注意：
在Uboot配置阶段，其实就是在mkconfig脚本和makefile中配置关键的路径，找到相应的文件（已解决兼容性问题）
(4)common。common是普遍的普通的，这个文件夹下放的是一些与具体硬件无关的普遍适用的一些代码。譬如控制台实现、crc校验的。但是更多的主要是两类：一类是cmd开头的，是用来实现uboot的命令系统的；另一类是env开头的，是用来实现环境变量的。
(5)cpu。这个目录是SoC相关的，里面存放的代码都是SoC相关初始化和控制代码（譬如CPU的、中断的、串口等SoC内部外设的，包括起始代码start.S也在这里）。里面很多子文件夹，每一个子文件夹就是一个SoC系列。
注意：这个问价是严格和硬件相关的，因此移植时也是要注意的。但是因为这个文件夹内都是SoC有关的，我们自己的开发板和三星的开发板虽然板子设计不同但是SoC都是同一个，因此实际移植时这个目录几乎不用动。
(6)disk。磁盘有关的，没研究过，没用过。
(7)doc。文档目录，里面存放了很多uboot相关文档，这些文档可以帮助我们理解uboot代码。但是因为是纯英文的，而且很杂乱，所以几乎没用。
(8)drivers。顾名思义，驱动。这里面放的就是从linux源代码中扣出来的原封不动的linux设备驱动，主要是开发板上必须用到的一些驱动，如网卡驱动、Inand/SD卡、NandFlash等的驱动。要知道：uboot中的驱动其实就是linux中的驱动，uboot在一定程度上移植了linux的驱动给自己用。但是linux是操作系统而uboot只是个裸机程序，因此这种移植会有不同，让我说：uboot中的驱动其实是linux中的驱动的一部分。
(9)examples。示例代码，没用过。
(10)fs。filesystem，文件系统。这个也是从linux源代码中移植过来的，用来管理Flash等资源。
(11)include。头文件目录。uboot和linux kernel在管理头文件时都采用了同一个思路，就是把所有的头文件全部集中存放在include目录下，而不是头文件跟着自己对应的c文件。所以在uboot中头文件包含时路径结构要在这里去找。
(12)lib_开头的一坨。（典型的lib_arm和lib_generic）架构相关的库文件。譬如lib_arm里面就是arm架构使用的一些库文件。lib_generic里是所有架构通用的库文件。这类文件夹中的内容移植时基本不用管。
(13)libfdt。设备树有关的。linux内核在3.4左右的版本的时候更改了启动传参的机制，改用设备树来进行启动传参，进行硬件信息的描述了。
(14)nand_spl。nand相关的，不讲。
(15)net。网络相关的代码，譬如uboot中的tftp nfs ping命令 都是在这里实现的。
(16)onenand开头的，是onenand相关的代码，是三星加的，标准uboot中应该是没有的。
(17)post。没关注过，不知道干嘛的。
(18)sd_fusing。这里面代码实现了烧录uboot镜像到SD卡的代码。后面要仔细研究的。
(19)tools。里面是一些工具类的代码。譬如mkimage。
总结：文件夹里面比较重要的，后面会分析涉及到的有：board、common、cpu、drivers、include、lib_arm、lib_generic、sd_fusing
编译和配置详解>
TIPS：
在shell中 ` cmd `可以执行该命令
shell uname 也可以执行命令
makefile分析（环境变量）
1.Uboot version（uboot的版本号）
2.HOSTARCH（主机的架构号）
shelluname -m ：显示主机的架构号 ix86
sed-e s/i.86/i386/ 以/为分隔符替换字符串 （.）是通配符
3.HOSTOS（主机操作系统）
shelluname -s : 显示主机的操作系统
tr'[:upper:]' '[:lower:]' 将大写字符串转换为小写的字符串
cygwin是早期的虚拟Linux
export就是导出环境变量
4.静默编译
makefile后加的参数去找字符串，又没有s,然后和空去做对比
如果是空则成立，就是非静默的，如果makeflag中有s，则XECHO标志为空，即为静默编译
5.原地编译和单独输出编译
两种方法：
1) AddO= to the make command line
#'make O=/tmp/build all'
2) Setenvironement variable BUILD_DIR to point to the desired location
#'export BUILD_DIR=/tmp/build'
#'make'
这句指令就表面，在make时加 o=参数会覆盖掉环境变量导出的路径
注意：
（1）在配置时就需要 make O=/..... [ 配置指令]
（2）编译时make O=/....
如果报错信息中是某个文件夹为空无法创建，则需要我们手动创建。
OBJTREE生产的目标文件树。SRCTREE源代码树，决定我们单独输出编译的输出路径的
6.OBJTREE / SRCTREE MKCONFIG
OBJTREE:就是编译生产的.o根目录
SRCTREE:就是源代码根目录
如果OBJTREE不等于SRCTREE，那么就证明是单独输出编译的
如果OBJTREE等于SRCTREE，那么就是原地编译的
obj= OBJTREE src = SRCTREE
MKCONFIG是SRCTREE下的一个配置脚本
7./ CROSS_COMPLI / ARCH
/ include $(obj)include/config.mk
include$(obj)include/config.mk
：obj编译输出的文件夹，文件夹下的include/config.mk 是一个配置文件
从这个脚本导出了一些环境变量
ARCH：芯片架构
如果是arm架构，那么交叉编译工具链就是相对应的前缀为arm-none-linux-guneabi-(默认没有导入到Linux系统环境变量，以及符号链接)如果有导入linux系统环境变量和符号链接则是arm-linux-.
7.TOPDIR := $(SRCTREE)
TOPDIR：顶层目录（源代码目录）
主makefile加载了顶层目录下的一个mk文件
config.mk (vip)
这个文件是辅助配置文件（这里包含了一个非常重要的配置头文件）
编译工具定义（config.mk94-107行）
包含开发板配置项目（config.mk,112行）
（这里包含了一个非常重要的配置头文件）
注意：这里的autoconf.mk是自动生成的，所以是在配置生成的。所以在非编译时是没有的（遇到auto之类的就需要在linux编译好的文件夹下寻找）
根据autoconfig.mk中的参数，判断uboot使用哪个链接脚本
TEXT_BASE：
指定了一个链接地址（在配置阶段）
路径：$(obj)board/samsung/x210/config.mk
内容就是TEXT_BASE= c3e00000
config.mk中的自动推断：
8.剩下的一些makefile
292~351：利用u-boot为以来生成一些u-boot.bin之类文件
配置过程>
x210_sd_config的依赖为unconfig（未配置的）所以重复配置
MKCONFIG是主目录下一个脚本文件，这里开始对它传参
根据上面给MKCONFIG传参$# = 6
（$(@:_config=）为目标 x210_sd_config中的_config替换为 空
所以$1就是x210_sd
[ $1 =x210_sd ] [ $2 = arm ] [ $3= s5pc11x ]
[ $4 =x210 ] [ $5 = sansung ] [ $6 = s5pc110 ]
$# = 6，所以这段代码直接break
注意：shell中上语句中的break，不是case的break，shell中的case是不需要break的，所以这里跳出的是while循环
这样的语句相当于一个简易版的if，因为之前的BOARD_NAME上来就被置空了。所以前句为fause,后面的执行
下面的指令就是传参的个数限定在4~6之内，否则就exit
剩下的33~118就是在创建符号连接
第一个：在include目录下创建asm文件，指向asm-arm。（46-48行）
第二个：在inlcude/asm-arm下创建一个arch文件，指向include/asm-arm/arch-s5pc110
第三个：在include目录下创建regs.h文件，指向include/s5pc110.h
删除第二个。
第四个：在inlcude/asm-arm下创建一个arch文件，指向include/asm-arm/arch-s5pc11x
第五个：在include/asm-arm下创建一个proc文件，指向include/asm-arm/proc-armv
总结：一共创建了4个符号链接。这4个符号链接将来在写代码过程中，头文件包含时非常有用。譬如一个头文件包含可能是：#include
(1)创建include/config.mk文件（mkconfig文件123-129行）
(2)创建include/config.mk文件是为了让主Makefile在第133行去包含的。
(3)思考：uboot的配置和编译过程的配合。编译的时候需要ARCH=arm、CPU=xx等这些变量来指导编译，配置的时候就是为编译阶段提供这些变量。那为什么不在Makefile中直接定义这些变量去使用，而要在mkconfig脚本中创建config.mk文件然后又在Makefile中include这些文件呢？
(4)理解这些脚本时，时刻要注意自己当前所处的路径。
(5)创建（默认情况）/追加（make -a时追加）include/config.h文件（mkconfig文件的134-141行）。
(6)这个文件里面的内容就一行#include
(7)x210_sd.h文件会被用来生成一个autoconf.mk文件，这个文件会被主Makefile引入，指导整个编译过程。这里面的这些宏定义会影响我们对uboot中大部分.c文件中一些条件编译的选择。从而实现最终的可移植性。
的链接脚本 >
ENTRY：
ALIGEN（4）:四字节对齐
(1)uboot的链接脚本和我们之前裸机中的链接脚本并没有本质区别，只是复杂度高一些，文件多一些，使用到的技巧多一些。
(2)ENTRY(_start)用来指定整个程序的入口地址。所谓入口地址就是整个程序的开头地址，可以认为就是整个程序的第一句指令。有点像C语言中的main。
(3)之前在裸机中告诉大家，指定程序的链接地址有2种方法：一种是在Makefile中ld的flags用-Ttext 0x20000000来指定；第二种是在链接脚本的SECTIONS开头用.=0x20000000来指定。两种都可以实现相同效果。其实，这两种技巧是可以共同配合使用的，也就是说既在链接脚本中指定也在ld flags中用-Ttext来指定。两个都指定以后以-Ttext指定的为准。
(4)uboot的最终链接起始地址就是在Makefile中用-Ttext 来指定的，具体参见2.4.5.2节，注意TEXT_BASE变量。最终来源是Makefile中配置对应的命令中，在make xxx_config时得到的。
(5)在代码段中注意文件排列的顺序。指定必须放在前面部分的那些文件就是那些必须安排在前16KB内的文件，这些文件中的函数在前16KB会被调用。在后面第二部分（16KB之后）中调用的程序，前后顺序就无所谓了。
(6)链接脚本中除了.text .data .rodata .bss段等编译工具自带的段之外，编译工具还允许我们自定义段。譬如uboot总的.u_boot_cmd段就是自定义段。自定义段很重要。
启动的第一阶段 >
任何工程的起点
在C语言中是以main.c开始的，而在汇编中，是以链接脚本中的ENTRY ...开始的所以需要从链接脚本入手
找到以后，用SI搜索这个标号（crtl + /）
ONENAND之类不是我们需要的，所以由此找到了这个标号
start.S分析1.开局头文件包含
< config.h >-->include下是在mkconfig自动生成的
其实包含了是这个头文件，这个头文件中包含了许多的配置信息
asm -> asm-arm（ARCH）
proc-> proc-armv
所以其实是
include下 asm-arm/proc-armv
这样设计的原因是为了兼容性
start.S的向下继续分析（1）
就是16字节的校验头（有些CPU没有）
.word= 就是定义一个4字节的数据（变量）
以16字节对齐0xdeadbeef是句玩笑
这是一种汇编的技巧，定义一个标号，再定义一个变量，变量中存放一个地址，然后在使用的时间去ldr加载这个标号，就相当于加载这个地址
start.S的向下继续分析（2）
UBoot运行的物理地址
清楚bss段
设置CPSR的状态（工作模式，中断禁止）
reset后CPU自动进入SVC模式（CPSR_C就是设置CPSR的0~7位）禁止I F 设置SVC模式（使程序不以来于硬件设定），进入ARM状态
注意：Uboot整个工作程序中都工作在SVC模式，特权模式
l2cache的初始化（流程：关闭->设置->使能）
从OMPIN读取启动方式。
设置栈并调用lowlevel_init函数
TIPS：
SP:在调用函数前初始化栈，主要原因是在被调用的函数内还有再次调用函数，而BL只会将返回地址存储到LR中，但是我们只有一个LR，所以在第二层调用函数前要先将LR入栈，否则函数返回时第一层的返回地址就丢了。
lowlevel_init:低层初始化，CPU，底层一些非常重要的初始化
在跳转lowlevel_init函数时，注意要查看路径是否正确，因为Uboot的可移植性，内置了很多的一样名字的代码，而对应的开发板不同。
比如在210中路径对于的就是这个。
Pushlr :就是给lr压栈保存
Lr 压栈保存 ->
检查复位状态（冷启动/热启动(休眠)）->
冷启动：CPU上电，此时DDR，是需要初始化的
休眠：此时只有CPU在工作，其余的外设都关闭了，但是是初始化过的，所以不需要初始化。
关看门狗->在CPU上电后，在启动阶段需要关闭看门狗，因为如果不关闭看门狗，当看门狗计数器的数值计数完毕后，会产生复位（中断），打断启动。
内存的一些初始化->
PS_HOLD（供电琐存）->
检查代码运行在DRAM（DDR ） 中还是运行在IRAM中，（冷热启动），决定是否进行始终和内存的初始化。
原理和裸机部分一致，通过对比链接地址和运行地址是否相同。
区别：这里判断的是PC，所以将地址的部分高低位都清了0，只对有用部分进行对比。
beq:1f 1是标号，f是向下查找， b是向后查找
跳转到DRAM初始化程序（和裸机部分基本一致）
Uart的初始化程序
返回
第二次栈设置到DDR中
当代码在Ram中就需要重定位了，至此，第一阶段基本结束；
(1)D0037488这个内存地址在SRAM中，这个地址中的值是被硬件自动设置的。硬件根据我们实际电路中SD卡在哪个通道中，会将这个地址中的值设置为相应的数字。譬如我们从SD0通道启动时，这个值为EB000000；从SD2通道启动时，这个值为EB200000
(2)我们在start.S的260行确定了从MMCSD启动，然后又在278行将#BOOT_MMCSD写入了INF_REG3寄存器中存储着。然后又在322行读出来，再和#BOOT_MMCSD去比较，确定是从MMCSD启动。最终跳转到mmcsd_boot函数中去执行重定位动作。
(3)真正的重定位是通过调用movi_bl2_copy函数完成的，在uboot/cpu/s5pc11x/movi.c中。是一个C语言的函数
(4)copy_bl2(2,MOVI_BL2_POS, MOVI_BL2_BLKCNT,
CFG_PHY_UBOOT_BASE,0);
分析参数：2表示通道2；MOVI_BL2_POS是uboot的第二部分在SD卡中的开始扇区，这个扇区数字必须和烧录uboot时烧录的位置相同；MOVI_BL2_BLKCNT是uboot的长度占用的扇区数；CFG_PHY_UBOOT_BASE是重定位时将uboot的第二部分复制到DDR中的起始地址（33E00000）.
虚拟地址映射：
MMU单片在CP15协处理器中进行控制，也就是说要操控MMU进行虚拟地址映射，方法就是对cp15协处理器的寄存器进行编程。
MMU提供了一个虚拟地址映射层，用来实现虚拟地址映射。
（1）提供了内存管理
（2）cache的实现（cache的工作和虚拟地址映射有关系）
总结：
Uboot的第一阶段：
（1）构件异常向量表
（2）设置CPSR的状态（SVC，I/F终端禁止）
（3）PS_HOLD供电锁存
（4）OMPing启动个引脚读取
（5）第一次设置栈，进入low_lever_init（CPU相关初始化）
1）：检验启动状态（冷热启动）
2）：IO状态
3）：关看门狗
4）：判断当前代码位置（在SRAM中还是DDR中）
1）：选择是否初始化时钟
2）：选择是否初始化内存
5）：初始化串口
Uboot的第二阶段：
（1）初始化外设
（2）进入main_loop - -> 启动内核
最近准备笔试面试，休息了慢慢补全