Uboot和系统移植

Bertha 。 2022-06-06 06:56 387阅读 0赞

Author: sx                                                          E-mail:598726409@qq.com

资料整理于自己的笔记（有许多的图片和代码块没有添加，后面会慢慢补齐），也有些是博客之类 ，如有侵权，请及时联系我，我会及时删除。因为都是手码的，可能会有些错别字，理解有误的地方请联系我，以便及时修改

--------------------

**<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的入口就是自动启动，它的终极目标就是启动操作系统，如果它没有成功启动操作系统，就会一直打转，知道启动为止，而一旦操作系统启动代码开启，这就是它的出口，它就死了。

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，仔细观察是否有写错，修改完环境变量以后要记得保存。

# <Uboot对flash和DDR的分区> #

（1）Uboot对flash的分区

flash是掉电仍然在的，所以用来存储Uboot.kernel.。。。。

Uboot规定必须在flash的开头，因为作为启动代码

环境变量贴着Uboot分区

剩下的分区如图所示

除了Uboot必须在开头以外，其它的分区相对位置是可以改变的。

（2）Uboot对DDR的分区

DDR相对于Flash是掉电消失的，所以对DDR的分区管理是在内核启动之前的，当操作系统内核启动起来之后，会接手对内存的管理，我们只需要在对DDR分区是注意不要内存踩踏即可。

**<Uboot的初体验 >**

# <配置 > #

在编译U-boot之前要对Uboot进行配置

(1).make  执行：make x210\_sd\_config

(2).查看交叉编译工具链是否正确（路径/版本）

在Uboot的makefile 147行

CROSS\_COMPILE= ？？？？？查看行代码，如果不正确就需要按照路径装交叉编译工具链

# <编译 > #

# make  make -j4（多线程编译） #

# <Uboot各文件介绍> #

(1).gitignore。git工具的文件，git是一个版本管理工具（类似的还有个svn），这个文件和git有关，和uboot本身无关的，不用去管。

(2)arm\_config.mk。后缀是.mk，是一个Makefile文件，将来在某个Makefile中会去调用它。

(3)三个Changelog文件，修改记录文件，该文件记录了这个uboot项目的版本变迁以及每个版本较上个版本修改的记录。正式的项目都有这些记录的。可以直接忽略，主要是给维护uboot的人用的。

(4)config.mk。和arm\_config.mk差不多性质。

(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的配置，一个负责编译。

# <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

# <Uboot编译和配置详解> #

**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)

主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之类文件

# <Uboot配置过程> #

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<asm/xx.h>  -->  asm-arm/...

(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 <configs/x210\_sd.h>，这个头文件是我们移植x210开发板时，对开发板的宏定义配置文件。这个文件是我们移植x210时最主要的文件。

(7)x210\_sd.h文件会被用来生成一个autoconf.mk文件，这个文件会被主Makefile引入，指导整个编译过程。这里面的这些宏定义会影响我们对uboot中大部分.c文件中一些条件编译的选择。从而实现最终的可移植性。

# <Uboot的链接脚本 > #

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段就是自定义段。自定义段很重要。

# <Uboot启动的第一阶段 > #

任何工程的起点

在C语言中是以main.c开始的，而在汇编中，是以链接脚本中的ENTRY ...开始的所以需要从链接脚本入手

找到以后，用SI搜索这个标号（crtl + /）

ONENAND之类不是我们需要的，所以由此找到了这个标号

start.S分析1.开局头文件包含

< config.h >\-->include下是在mkconfig自动生成的

其实包含了是这个头文件，这个头文件中包含了许多的配置信息

<version.h>\-->在incude下 会自动生产一个"version\_autogenerated.h"文件，这个文件是(主makefile）自动生成的。里面是u-boot的版本信息

<asm/proc/domain.h>  -->符号链接

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相关初始化）