[文章]Uboot简单介绍
0
2
1、认识uboot
U-Boot，全称 Universal Boot Loader，是遵循GPL条款是一个开源项目，用于启动操作系统内核，操作系统并不是一开机就会自动启动，是要有引导程序的。uboot就是一个这样的开源的引导程序。uboot的官方网站：http://www.denx.de/wiki/U-Boot/SourceCode
uboot早期的版本号是这样的 uboot1.4.3,后来是是这样的uboot-2018.11.
2、使用uboot
我们可以在uboot启动过程中进入uboot的控制台底下，使用uboot。所谓的使用uboot也就是使用uboot的环境变量和命令。ping
3、配置编译下载uboot
这里说一下如何配置编译下载uboot，后面的部分为详细讲解uboot源代码的部分。现在最新版本的uboot的配置方法和Linux内核的配置方法是一样的，后面我会有Linux内核配置的文章。
配置
uboot和linux kernel等复杂项目，都不能直接编译，都要先配置才能编译。uboot也要先配置，配置方法是：首先cd进入uboot源码的根目录，然后在根目录下执行：make x210_sd_config(就看Makefile中的那个目标来确定，其实也就是include/configs/目录下的配置文件后面加上_config，比如我这里include/configs/x210_sd.h，所以这里就是make x210_sd_config)。执行配置命令后，如果出现：Configuring for x210_sd board…说明配置好了，如果不是这个是别的说明配置出错了。
编译
编译之前一定要注意检查arm-linux-gcc对不对，检查份2步：
第一步：检查当前编译环境中有没有安装合适的arm-linux-gcc。我们装的是arm-2009q3，因为这个是三星官方、九鼎官方开发uboot时使用的。
第二步：检查当前目录下（uboot根目录）的Makefile中编译器的设置是否正确。在工程的总Makefile中会设置交叉编译工具链的路径和名字，必须确保这个路径和名字和我们自己装的一致，否则编译会出错。
确保了以上2点，即可进行编译。编译很简单，直接make即可。或者可以make -j4 (多线程编译，主机如果是多核心电脑，可以尝试多线程编译，会快一些)
下载
uboot根目录下有一个sd_fusing文件夹，进去之后先检查sd_fusing.sh的执行权限有没有，文件中的bin文件与根目录中生成的bin文件是否一致，文件中的reader_type1="/dev/sdc" 中是否是对应的自己的SD卡，make clean,然后make,然后插入SD卡。执行./sd_fusing.sh /dev/sdc，即可
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差不多性质。
(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使用的规则，本身非常重要，但是我们不去分析他，不去看他。
文件夹介绍：
(1)api. 硬件无关的功能函数的API。uboot移植时基本不用管，这些函数是uboot本身使用的。
(2)api_examples. API相关的测试事例代码。
(3)board。board是板的意思，板就是开发板。board文件夹下每一个文件都代表一个开发板，这个文件夹下面放的文件就是用来描述这一个开发板的信息的。board目录下有多少个文件夹，就表示当前这个uboot已经被移植到多少个开发板上了（当前的uboot支持多少个开发板）。
(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。
uboot主Makefile分析
1、uboot version确定（Makefile的24-29行）
(1)uboot的版本号分3个级别：
VERSION：主板本号
PATCHLEVEL：次版本号
SUBLEVEL：再次版本号
EXTRAVERSION:另外附加的版本信息
这4个用.分隔开共同构成了最终的版本号。
(2)Makefile中版本号最终生成了一个变量U_BOOT_VERSION，这个变量记录了Makefile中配置的版本号。
(3)include/version_autogenerated.h文件是编译过程中自动生成的一个文件，所以源目录中没有，但是编译过后的uboot中就有了。它里面的内容是一个宏定义，宏定义的值内容就是我们在Makefile中配置的uboot的版本号。 (4)验证方法：自己修改主Makefile中几个Version有关的变量，然后重新编译uboot，然后烧录到SD卡中，从SD卡启动，然后去看启动时uboot打印出来的版本信息，看看变化是不是和自己的分析一致。
2、HOSTARCH和HOSTOS
(1)直接在shell中执行uname -m得到i686，得到的值其实你当前执行这个命令的电脑的CPU的版本号。
(2)shell中的 叫做管道，管道的作用就是把管道前面一个运算式的输出作为后面一个的输入再去做处理，最终的输出才是我们整个式子的输出。
(3)HOSTARCH这个名字：HOST是主机，就是当前在做开发用的这台电脑就叫主机；ARCH是architecture(架构)的缩写，表示CPU的架构。所以HOSTARCH就表示主机的CPU的架构。
(4)这两个环境变量是主机的操作系统和主机的CPU架构，得出后保存备用，后面自然会用到。
3、静默编译（50-54行）
(1)平时默认编译时命令行会打印出来很多编译信息。但是有时候我们不希望看到这些编译信息，就后台编译即可。这就叫静默编译。
(2)使用方法就是编译时make -s，-s会作为MAKEFLAGS传给Makefile，在50-54行这段代码作用下XECHO变量就会被变成空（默认等于echo），于是实现了静默编译。
4、2种编译方法（原地编译和单独输出文件夹编译）
(1)编译复杂项目，Makefile提供2种编译管理方法。默认情况下是当前文件夹中的.c文件，编译出来的.o文件会放在同一文件夹下。这种方式叫原地编译。原地编译的好处就是处理起来简单。
(2)原地编译有一些坏处：第一，污染了源文件目录。第二的缺陷就是一套源代码只能按照一种配置和编译方法进行处理，无法同时维护2个或2个以上的配置编译方式。
(3)为了解决以上2种缺陷，uboot支持单独输出文件夹方式的编译（linux kernel也支持，而且uboot的这种技术就是从linux kernel学习来的）。基本思路就是在编译时另外指定一个输出目录，将来所有的编译生成的.o文件或生成的其他文件全部丢到那个输出目录下去。源代码目录不做任何污染，这样输出目录就承载了本次配置编译的所有结果。
(4)具体用法：默认的就是原地编译。如果需要指定具体的输出目录编译则有2种方式来指定输出目录。（具体参考Makefile 56-76行注释内容）
第一种：make O=输出目录
第二种：export BUILD_DIR=输出目录 然后再make ，如果两个都指定了（既有BUILD_DIR环境变量存在，又有O=xx），则O=xx具有更高优先级，听他的。
(5)两种编译的实现代码在Makefile的78-123行。
5、OBJTREE、SRCTREE、TOPDIR
(1)OBJTREE：编译出的.o文件存放的目录的根目录。在默认编译下，OBJTREE等于当前目录；在O=xx编译下，OBJTREE就等于我们设置的那个输出目录。
(2)SRCTREE: 源码目录，其实就是源代码的根目录，也就是当前目录。
总结：在默认编译下，OBJTREE和SRCTREE相等；在O=xx这种编译下OBJTREE和SRCTREE不相等。Makefile中定义这两个变量，其实就是为了记录编译后的.o文件往哪里放，就是为了实现O=xx的这种编译方式的。
6、MKCONFIG（Makefile的101行）
(1)Makefile中定义的一个变量（在这里定义，在后面使用），它的值就是我们源码根目录下面的mkconfig。 这个mkconfig是一个脚本，这个脚本就是uboot配置阶段的配置脚本。后面仔细说
7、include $(obj)include/config.mk（133行）
(1)include/config.mk不是源码自带的（你在没有编译过的源码目录下是找不到这个文件的），要在配置过程（make x210_sd_config）中才会生成这个文件。因此这个文件的值和我们配置过程有关，是由配置过程根据我们的配置自动生成的。
(2)我们X210在iNand情况下配置生成的config.mk内容为：
ARCH = arm
CPU = s5pc11x
BOARD = x210
VENDOR = samsung
SOC = s5pc110
(3)我们在下一行（134行）export导出了这5个变量作为环境变量。所以着两行加起来其实就是为当前makefile定义了5个环境变量而已。之所以不直接给出这5个环境变量的值，是因为我们希望这5个值是可以被人很容易的、集中的配置的。
(4)这里的配置值来自于2589行那里的配置项。如果我们要更改这里的某个配置值要到2589行那里调用MKCONFIG脚本传参时的参数。
8、ARCH CROSS_COMPILE
(1)接下来有2个很重要的环境变量。一个是ARCH，上面导出的，值来自于我们的配置过程，它的值会影响后面的CROSS_COMPILE环境变量的值。ARCH的意义是定义当前编译的目标CPU的架构。
(2)CROSS_COMPILE是定义交叉编译工具链的前缀的。定义这些前缀是为了在后面用（用前缀加上后缀来定义编译过程中用到的各种工具链中的工具）。我们把前缀和后缀分开还有一个原因就是：在不同CPU架构上的交叉编译工具链，只是前缀不一样，后缀都是一样的。因此定义时把前缀和后缀分开，只需要在定义前缀时区分各种架构即可实现可移植性。
(3)CROSS_COMPILE在136-182行来确定。CROSS_COMPILE是被ARCH所确定的，只要配置了ARCH=arm，那么我们就只能在ARM的那个分支去设置CROSS_COMPILE的值。这个设置值只要能保证找到那个交叉编译工具链即可，不一定非得是全路径的，相对路径也可以。（如果已经将工具链导出到环境变量，并且设置了符号链接，这样CROSS_COMPILE = arm-linux-就可以）
(4)实际运用时，我们可以在Makefile中去更改设置CROSS_COMPILE的值，也可以在编译时用make CROSS_COMPILE=xxxx来设置，而且编译时传参的方法可以覆盖Makefile里面的设置。
9、$(TOPDIR)/config.mk（主Makefile的185行）
编译工具定义（config.mk 94-107行）
包含开发板配置项目（config.mk, 112行）
(1)autoconfig.mk文件不是源码提供的，是配置过程自动生成的。
(2)这个文件的作用就是用来指导整个uboot的编译过程。这个文件的内容其实就是很多CONFIG_开头的宏（可以理解为变量），这些宏/变量会影响我们uboot编译过程的走向（原理就是条件编译）。在uboot代码中有很多地方使用条件编译进行编写，这个条件编译是用来实现可移植性的。（可以说uboot的源代码在很大程度来说是拼凑起来的，同一个代码包含了各种不同开发板的适用代码，用条件编译进行区别。）
(3)这个文件不是凭空产生的，配置过程也是需要原材料来产生这个文件的。原材料在源码目录的inlcude/configs/xxx.h头文件。（X210开发板中为include/configs/x210_sd.h）。这个h头文件里面全都是宏定义，这些宏定义就是我们对当前开发板的移植。每一个开发板的移植都对应这个目录下的一个头文件，这个头文件里每一个宏定义都很重要，这些配置的宏定义就是我们移植uboot的关键所在。
10、链接脚本（config.mk 142-149行）
(1)如果定义了CONFIG_NAND_U_BOOT宏，则链接脚本叫u-boot-nand.lds，如果未定义这个宏则链接脚本叫u-boot.lds。
(2)从字面意思分析，即可知：CONFIG_NAND_U_BOOT是在Nand版本情况下才使用的，我们使用的X210都是iNand版本的，因此这个宏没有的。
(3)实际在boardsamsungx210目录下有u-boot.lds，这个就是链接脚本。我们在分析uboot的编译链接过程时就要考虑这个链接脚本。
11、TEXT_BASE（config.mk 156-158行）
(1)Makefile中在配置X210开发板时，在board/samsung/x210目录下生成了一个文件config.mk，其中的内容就是：TEXT_BASE = 0xc3e00000相当于定义了一个变量。
(2)TEXT_BASE是将来我们整个uboot链接时指定的链接地址。因为uboot中启用了虚拟地址映射，因此这个C3E00000地址就等于0x23E00000(也可能是33E00000具体地址要取决于uboot中做的虚拟地址映射关系)。
(3)回顾裸机中讲的链接地址的问题，再想想dnw方式先下载x210_u***.bin然后再下载uboot.bin时为什么第二个地址是23E00000.
12、自动推导规则（config.mk 239-256行）
我们在讲Makefile时提到过自动推导规则
13、Makefile的目标
(1)291行出现了整个主Makefile中第一个目标all（也就是默认目标，我们直接在uboot根目录下make其实就等于make all，就等于make这个目标）
(2)目标中有一些比较重要的。譬如：u-boot是最终编译链接生成的elf格式的可执行文件，
(3)unconfig字面意思来理解就是未配置。这个符号用来做为我们各个开发板配置目标的依赖。目标是当我们已经配置过一个开发板后再次去配置时还可以配置。
(4)我们配置开发板时使用：make x210_sd_config，因此分析x210_sd_config肯定是主Makefile中的一个目标。
uboot配置过程详解
(1)mkconfig脚本的6个参数
$(@:_config=) arm s5pc11x x210 samsung s5pc110(Makefile中2590行)
x210_sd_config里的_config部分用空替换，得到：x210_sd，这就是第一个参数，所以：
$1: x210_sd
$2: arm
$3: s5pc11x
$4: x210
$5: samsumg
$6: s5pc110
所以，$# = 6
(2)第23行：其实就是看BOARD_NAME变量是否有值，如果有值就维持不变；如果无值就给他赋值为$1，实际分析结果：BOARD_NAME=x210_sd
(3)第25行：如果$#小于4，则exit 1（mkconfig脚本返回1）
(4)第26行：如果$#大于6，则也返回1.
所以：mkconfig脚本传参只能是4、5、6，如果大于6或者小于4都不行。
(5)从第33行到第118行，都是在创建符号链接。为什么要创建符号链接？这些符号链接文件的存在就是整个配置过程的核心，这些符号链接文件（文件夹）的主要作用是给头文件包含等过程提供指向性连接。根本目的是让uboot具有可移植性。uboot可移植性的实现原理：在uboot中有很多彼此平行的代码，各自属于各自不同的架构/CPU/开发板，我们在具体到一个开发板的编译时用符号连接的方式提供一个具体的名字的文件夹供编译时使用。这样就可以在配置的过程中通过不同的配置使用不同的文件，就可以正确的包含正确的文件。
(6)创建的符号链接：
第一个：在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>
(7)创建include/config.mk文件（mkconfig文件123-129行）
(8)创建include/config.mk文件是为了让主Makefile在第133行去包含的。
(9)思考：uboot的配置和编译过程的配合。编译的时候需要ARCH=arm、CPU=xx等这些变量来指导编译，配置的时候就是为编译阶段提供这些变量。那为什么不在Makefile中直接定义这些变量去使用，而要在mkconfig脚本中创建config.mk文件然后又在Makefile中include这些文件呢？
个人理解是为了uboot的可移植性。
(10)理解这些脚本时，时刻要注意自己当前所处的路径。
(11)创建（默认情况）/追加（make -a时追加）include/config.h文件（mkconfig文件的134-141行）。
(12)这个文件里面的内容就一行#include <configs/x210_sd.h>，这个头文件是我们移植x210开发板时，对开发板的宏定义配置文件。这个文件是我们移植x210时最主要的文件。
(13)x210_sd.h文件会被用来生成一个autoconfig.mk文件，这个文件会被主Makefile引入，指导整个编译过程。这里面的这些宏定义会影响我们对uboot中大部分.c文件中一些条件编译的选择。从而实现最终的可移植性。
注意：uboot的整个配置过程，很多文件之间是有关联的（有时候这个文件是在那个文件中创建出来的；有时候这个文件被那个文件包含进去；有时候这个文件是由那个文件的内容生成的决定的）
注意：uboot中配置和编译过程，所有的文件或者全局变量都是字符串形式的（不是指的C语言字符串的概念，指的是都是字符组成的序列）。这意味着我们整个uboot的配置过程都是字符串匹配的，所以一定要细节，注意大小写，要注意不要输错字符，因为一旦错一个最后会出现一些莫名其妙的错误，很难排查，这个是uboot移植过程中新手来说最难的地方。
uboot的链接脚本
(1)uboot的链接脚本和我们之前裸机中的链接脚本并没有本质区别，只是复杂度高一些，文件多一些，使用到的技巧多一些。
(2)ENTRY(_start)用来指定整个程序的入口地址。所谓入口地址就是整个程序的开头地址，可以认为就是整个程序的第一句指令。有点像C语言中的main。
(3)之前在裸机中指定程序的链接地址有2种方法：一种是在Makefile中ld的flags用-Ttext 0x20000000来指定；第二种是在链接脚本的SECTIONS开头用.=0x20000000来指定。两种都可以实现相同效果。其实，这两种技巧是可以共同配合使用的，也就是说既在链接脚本中指定也在ld flags中用-Ttext来指定。两个都指定以后以-Ttext指定的为准。
4、以启动内核为主线分析代码
1、start.S引入
u-boot.lds中找到start.S入口
(1)在C语言中整个项目的入口就是main函数（这是C语言规定的），所以譬如说一个有10000个.c文件的项目，第一个要分析的文件就是包含了main函数的那个文件。
(2)在uboot中因为有汇编阶段参与，因此不能直接找main.c。整个程序的入口取决于链接脚本中ENTRY声明的地方。ENTRY(_start)因此_start符号所在的文件就是整个程序的起始文件，_start所在处的代码就是整个程序的起始代码。
2、不简单的头文件包含
(1)#include <config.h>。
config.h是在include目录下的，这个文件不是源码中本身存在的文件，而是配置过程中自动生成的文件。（详见mkconfig脚本）。
这个文件的内容其实是包含了一个头文件：#include <configs/x210_sd.h>".
(2)经过分析后，发现start.S中包含的第一个头文件就是：include/configs/x210_sd.h，这个文件是整个uboot移植时的配置文件。这里面是好多宏。
因此这个头文件包含将include/configs/x210_sd.h文件和start.S文件关联了起来。因此之后在分析start.S文件时，主要要考虑的就是x210_sd.h文件。
(3)#include <version.h>。include/version.h中包含了include/version_autogenerated.h，这个头文件就是配置过程中自动生成的。里面就一行内容：
#define U_BOOT_VERSION "U-Boot 1.3.4"。这里面定义的宏U_BOOT_VERSION的值是一个字符串，字符串中的版本号信息来自于Makefile中的配置值。这个宏在程序中会被调用，在uboot启动过程中会串口打印出uboot的版本号，那个版本号信息就是从这来的。
(4)#include <asm/proc/domain.h>。asm目录不是uboot中的原生目录，uboot中本来是没有这个目录的。asm目录是配置时创建的一个符号链接，实际指向的是就是asm-arm（详解上一章节分析mkconfig脚本时）.
(5)经过分析后发现，实际文件是：include/asm-arm/proc-armv/domain.h
(6)从这里可以看出之前配置时创建的符号链接的作用，如果没有这些符号链接则编译时根本通不过，因为找不到头文件。（所以uboot不能在windows的共享文件夹下配置编译，因为windows中没有符号链接）
思考：为什么start.S不直接包含asm-arm/proc-armv/domain.h，而要用asm/proc/domain.h。这样的设计主要是为了可移植性。因为如果直接包含，则start.S文件和CPU架构（和硬件）有关了，可移植性就差了。譬如我要把uboot移植到mips架构下，则start.S源代码中所有的头文件包含全部要修改。我们用了符号链接之后，则start.S中源代码不用改，只需要在具体的硬件移植时配置不同，创建的符号链接指向的不同，则可以具有可移植性。
3、uboot汇编部分
1、启动代码的16字节头部
(1)裸机中讲过，在SD卡启动/Nand启动等整个镜像开头需要16字节的校验头。（mkv210image.c中就是为了计算这个校验头）。我们以前做裸机程序时根本没考虑这16字节校验头，因为：1、如果我们是u***启动直接下载的方式启动的则不需要16字节校验头（irom application note）；2、如果是SD卡启动mkv210image.c中会给原镜像前加16字节的校验头。
(2)uboot这里start.S中在开头位置放了16字节的填充占位，这个占位的16字节只是保证正式的image的头部确实有16字节，但是这16字节的内容是不对的，还是需要后面去计算校验和然后重新填充的。
2、异常向量表的构建
(1)异常向量表是硬件决定的，软件只是参照硬件的设计来实现它。
(2)异常向量表中每种异常都应该被处理，否则真遇到了这种异常就跑飞了。但是我们在uboot中并未非常细致的处理各种异常。
(3)复位异常处的代码是：b reset，因此在CPU复位后真正去执行的有效代码是reset处的代码，因此reset符号处才是真正的有意义的代码开始的地方。
3、有点意思的deadbeef
(1).balignl 16,0xdeadbeef. 这一句指令是让当前地址对齐排布，如果当前地址不对齐则自动向后走地址直到对齐，并且向后走的那些内存要用0xdeadbeef来填充。
(2)0xdeadbeef这是一个十六进制的数字，这个数字很有意思，组成这个数字的十六进制数全是abcdef之中的字母，而且这8个字母刚好组成了英文的dead beef这两个单词，字面意思是坏牛肉
(3)为什么要对齐访问？有时候是效率的要求，有时候是硬件的特殊要求。
4、TEXT_BASE等
(1)第100行这个TEXT_BASE就是上个课程中分析Makefile时讲到的那个配置阶段的TEXT_BASE，其实就是我们链接时指定的uboot的链接地址。（值就是c3e00000）
(2)源代码中和配置Makefile中很多变量是可以互相运送的。简单来说有些符号的值可以从Makefile中传递到源代码中。
(1)CFG_PHY_UBOOT_BASE 33e00000 uboot在DDR中的物理地址
5、设置CPU为SVC模式
(1)msr cpsr_c, #0xd3 将CPU设置为禁止FIQ IRQ，ARM状态，SVC模式。
(2)其实ARM CPU在复位时默认就会进入SVC模式，但是这里还是使用软件将其置为SVC模式。整个uboot工作时CPU一直处于SVC模式。
6、设置L2、L1cache和MMU
(1)bl disable_l2cache // 禁止L2 cache
(2)bl set_l2cache_auxctrl_cycle // l2 cache相关初始化
(3)bl enable_l2cache // 使能l2 cache
(4)刷新L1 cache的icache和dcache。
(5)关闭MMU
总结：上面这5步都是和CPU的cache和mmu有关的，不用去细看，大概知道即可。
7、识别并暂存启动介质选择
(1)从哪里启动是由SoC的OM5:OM0这6个引脚的高低电平决定的。
(2)实际上在210内部有一个寄存器（地址是0xE0000004），这个寄存器中的值是硬件根据OM引脚的设置而自动设置值的。这个值反映的就是OM引脚的接法（电平高低），也就是真正的启动介质是谁。
(3)我们代码中可以通过读取这个寄存器的值然后判断其值来确定当前选中的启动介质是Nand还是SD还是其他的。
(4)start.S的225-227行执行完后，在r2寄存器中存储了一个数字，这个数字等于某个特定值时就表示SD启动，等于另一个特定值时表示从Nand启动····
(5)260行中给r3中赋值#BOOT_MMCSD(0x03)，这个在SD启动时实际会被执行，因此执行完这一段代码后r3中存储了0x03，以后备用。
8、设置栈（SRAM中的栈）并调用lowlevel_init
(1)284-286行第一次设置栈。这次设置栈是在SRAM中设置的，因为当前整个代码还在SRAM中运行，此时DDR还未被初始化还不能用。栈地址0xd0036000是自己指定的，指定的原则就是这块空间只给栈用，不会被别人占用。
(2)在调用函数前初始化栈，主要原因是在被调用的函数内还有再次调用函数，而BL只会将返回地址存储到LR中，但是我们只有一个LR，所以在第二层调用函数前要先将LR入栈，否则函数返回时第一层的返回地址就丢了。
(1)使用SourceInsight的Reference功能，找到lowlevel_init函数真正的地方，是在uboot/board/samsumg/x210/lowlevel_init.S中。
9、检查复位状态
(1)复杂CPU允许多种复位情况。譬如直接冷上电、热启动、睡眠(低功耗)状态下的唤醒等，这些情况都属于复位。所以我们在复位代码中要去检测复位状态，来判断到底是哪种情况。
(2)判断哪种复位的意义在于：冷上电时DDR是需要初始化才能用的；而热启动或者低功耗状态下的复位则不需要再次初始化DDR。
10、IO状态恢复
(1)这个和上一个和主线启动代码都无关，因此不用去管他。
11、关看门狗
12、一些SRAM SROM相关GPIO设置
(1)与主线启动代码无关，不用管
12、供电锁存
(1)lowlevel_init.S的第100-104行，开发板供电锁存。
总结：在前100行，lowlevel_init.S中并没有做太多有意义的事情（除了关看门狗、供电锁存外），然后下面从110行才开始进行有意义的操作。
16、判断当前代码执行位置
(1)lowlevel_init.S的110-115行。
(2)这几行代码的作用就是判定当前代码执行的位置在SRAM中还是在DDR中。为什么要做这个判定？原因1：BL1（uboot的前一部分）在SRAM中有一份，在DDR中也有一份，因此如果是冷启动那么当前代码应该是在SRAM中运行的BL1，如果是低功耗状态的复位这时候应该就是在DDR中运行的。
原因2：我们判定当前运行代码的地址是有用的，可以指导后面代码的运行。譬如在lowlevel_init.S中判定当前代码的运行地址，就是为了确定要不要执行时钟初始化和初始化DDR的代码。如果当前代码是在SRAM中，说明冷启动，那么时钟和DDR都需要初始化；如果当前代码是在DDR中，那么说明是热启动则时钟和DDR都不用再次初始化。
(2)bic r1, pc, r0 这句代码的意义是：将pc的值中的某些bit位清0，剩下一些特殊的bit位赋值给r1（r0中为1的那些位清零）相等于：r1 = pc & ~(ff000fff)，ldr r2, _TEXT_BASE 加载链接地址到r2，然后将r2的相应位清0剩下特定位。
(3)最后比较r1和r2.
总结：这一段代码是通过读取当前运行地址和链接地址，然后处理两个地址后对比是否相等，来判定当前运行是在SRAM中（不相等）还是DDR中（相等）。从而决定是否跳过下面的时钟和DDR初始化。
17、system_clock_init
(1)使用SI搜索功能，确定这个函数就在当前文件的205行，一直到第385行。这个初始化时钟的过程和裸机中初始化的过程一样的，只是更加完整而且是用汇编代码写的。
(2)在x210_sd.h中300行到428行，都是和时钟相关的配置值。这些宏定义就决定了210的时钟配置是多少。也就是说代码在lowlevel_init.S中都写好了，但是代码的设置值都被宏定义在x210_sd.h中了。因此，如果移植时需要更改CPU的时钟设置，根本不需要动代码，只需要在x210_sd.h中更改配置值即可。
18、mem_ctrl_asm_init
(1)该函数用来初始化DDR
(2)函数位置在uboot/cpu/s5pc11x/s5pc110/cpu_init.S文件中。
(3)该函数和裸机中初始化DDR代码是一样的。
(4)配置值中其他配置值参考裸机中的解释即可明白，有一个和裸机中讲的不一样。DMC0_MEMCONFIG_0，在裸机中配置值为0x20E01323；在uboot中配置为0x30F01313.这个配置不同就导致结果不同。在 裸机中DMC0的256MB内存地址范围是0x20000000-0x2FFFFFFF; 在uboot中DMC0的256MB内存地址范围为0x30000000-0x3FFFFFFF。
(5)之前在裸机中时配置为2开头的地址，当时并没有说可以配置为3开头。从分析九鼎移植的uboot可以看出：DMC0上允许的地址范围是20000000-3FFFFFFF（一共是512MB），而我们实际只接了256MB物理内存，SoC允许我们给这256MB挑选地址范围。
(6)总结一下：在uboot中，可用的物理地址范围为：0x30000000-0x4FFFFFFF。一共512MB，其中30000000-3FFFFFFF为DMC0，40000000-4FFFFFFF为DMC1。
(7)我们需要的内存配置值在x210_sd.h的438行到468行之间。分析的时候要注意条件编译的条件，配置头文件中考虑了不同时钟配置下的内存配置值，这个的主要目的是让不同时钟需求的客户都能找到合适自己的内存配置值。
(8)在uboot中DMC0和DMC1都工作了，所以在裸机中只要把uboot中的配置值和配置代码全部移植过去，应该是能够让DMC0和DMC1都工作的。
19、uart_asm_init
(1)这个函数用来初始化串口
(2)初始化完了后通过串口发送了一个'O'
20、tzpc_init
(1)trust zone初始化，没搞过，不管
21、pop {pc}以返回
(1)返回前通过串口打印'K'
分析；lowlevel_init.S执行完如果没错那么就会串口打印出"OK"字样。这应该是我们uboot中看到的最早的输出信息。
22、再次设置栈（DDR中的栈）
(1)再次开发板供电锁存。第一，做2次是不会错的；第二，做2次则第2次无意义；做代码移植时有一个古怪谨慎保守策略就是尽量添加代码而不要删除代码。
(2)之前在调用lowlevel_init程序前设置过1次栈（start.S 284-287行），那时候因为DDR尚未初始化，因此程序执行都是在SRAM中，所以在SRAM中分配了一部分内存作为栈。本次因为DDR已经被初始化了，因此要把栈挪移到DDR中，所以要重新设置栈，这是第二次（start.S 297-299行）；这里实际设置的栈的地址是33E00000，刚好在uboot的代码段的下面紧挨着。
(3)为什么要再次设置栈？DDR已经初始化了，已经有大片内存可以用了，没必要再把栈放在SRAM中可怜兮兮的了；原来SRAM中内存大小空间有限，栈放在那里要注意不能使用过多的栈否则栈会溢出，我们及时将栈迁移到DDR中也是为了尽可能避免栈使用时候的小心翼翼。
感慨：uboot的启动阶段主要技巧就在于小范围内有限条件下的辗转腾挪。
23、再次判断当前地址以决定是否重定位
(1)再次用相同的代码判断运行地址是在SRAM中还是DDR中，不过本次判断的目的不同（上次判断是为了决定是否要执行初始化时钟和DDR的代码）这次判断是为了决定是否进行uboot的relocate。
(2)冷启动时当前情况是uboot的前一部分（16kb或者8kb）开机自动从SD卡加载到SRAM中正在运行，uboot的第二部分（其实第二部分是整个uboot）还躺在SD卡的某个扇区开头的N个扇区中。此时uboot的第一阶段已经即将结束了（第一阶段该做的事基本做完了），结束之前要把第二部分加载到DDR中链接地址处（33e00000），这个加载过程就叫重定位。
4.uboot重定位详解
重定位
(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）.**
5、MMU等概念
1、什么是虚拟地址、物理地址
(1)物理地址就是物理设备设计生产时赋予的地址。像裸机中使用的寄存器的地址就是CPU设计时指定的，这个就是物理地址。物理地址是硬件编码的，是设计生产时确定好的，一旦确定了就不能改了。
(2)一个事实就是：寄存器的物理地址是无法通过编程修改的，是多少就是多少，只能通过查询数据手册获得并操作。坏处就是不够灵活。一个解决方案就是使用虚拟地址。
(3)虚拟地址意思就是在我们软件操作和硬件***作之间增加一个层次，叫做虚拟地址映射层。有了虚拟地址映射后，软件操作只需要给虚拟地址，硬件操作还是用原来的物理地址，映射层建立一个虚拟地址到物理地址的映射表。当我们软件运行的时候，软件中使用的虚拟地址在映射表中查询得到对应的物理地址再发给硬件去执行（虚拟地址到物理地址的映射是不可能通过软件来实现的）。
2、MMU单元的作用
(1)MMU就是memory management unit，内存管理单元。MMU实际上是SOC中一个硬件单元，它的主要功能就是实现虚拟地址到物理地址的映射。
(2)MMU单片在CP15协处理器中进行控制，也就是说要操控MMU进行虚拟地址映射，方法就是对cp15协处理器的寄存器进行编程。
3、地址映射的额外收益1：访问控制
(1)访问控制就是：在管理上对内存进行分块，然后每块进行独立的虚拟地址映射，然后在每一块的映射关系中同时还实现了访问控制（对该块可读、可写、只读、只写、不可访问等控制）
(2)回想在C语言中编程中经常会出现一个错误：Segmentation fault。实际上这个段错误就和MMU实现的访问控制有关。当前程序只能操作自己有权操作的地址范围（若干个内存块），如果当前程序指针出错访问了不该访问的内存块则就会触发段错误。
4、地址映射的额外收益2：cache
(1)cache的工作和虚拟地址映射有关系。
(2)cache是快速缓存，意思就是比CPU慢但是比DDR块。CPU嫌DDR太慢了，于是乎把一些DDR中常用的内容事先读取缓存在cache中，然后CPU每次需要找东西时先在cache中找。如果cache中有就直接用cache中的；如果cache中没有才会去DDR中寻找。
5、使能域访问（cp15的c3寄存器）
(1)cp15协处理器内部有c0到c15共16个寄存器，这些寄存器每一个都有自己的作用。我们通过mrc和mcr指令来访问这些寄存器。所谓的操作cp协处理器其实就是操作cp15的这些寄存器。
(2)c3寄存器在mmu中的作用是控制域访问。域访问是和MMU的访问控制有关的。
6、设置TTB（cp15的c2寄存器）
(1)TTB就是translation table base，转换表基地址。首先要明白什么是TT（translation table转换表），TTB其实就是转换表的基地址。
(2)转换表是建立一套虚拟地址映射的关键。转换表分2部分，表索引和表项。表索引对应虚拟地址，表项对应物理地址。一对表索引和表项构成一个转换表单元，能够对一个内存块进行虚拟地址转换。（映射中基本规定中规定了内存映射和管理是以块为单位的，至于块有多大，要看你的MMU的支持和你自己的选择。在ARM中支持3种块大小，细表1KB、粗表4KB、段1MB）。真正的转换表就是由若干个转换表单元构成的，每个单元负责1个内存块，总体的转换表负责整个内存空间（0-4G）的映射。
(3)整个建立虚拟地址映射的主要工作就是建立这张转换表
(4)转换表放置在内存中的，放置时要求起始地址在内存中要xx位对齐。转换表不需要软件去干涉使用，而是将基地址TTB设置到cp15的c2寄存器中，然后MMU工作时会自动去查转换表。
7、使能MMU单元（cp15的c1寄存器）
(1)cp15的c1寄存器的bit0控制MMU的开关。只要将这一个bit置1即可开启MMU。开启MMU之后上层软件层的地址就必须经过TT的转换才能发给下层物理层去执行。
8、找到映射表待分析
(1)通过符号查找，确定转换表在lowlevel_init.S文件的593行。
宏FL_SECTION_ENTRY
页表项各bit位含义
段式页表详解
宏观上理解转换表：整个转换表可以看作是一个int类型的数组，数组中的一个元素就是一个表索引和表项的单元。数组中的元素值就是表项，这个元素的数组下标就是表索引。
ARM的段式映射中长度为1MB，因此一个映射单元只能管1MB内存，那我们整个4G范围内需要4G/1MB=4096个映射单元，也就是说这个数组的元素个数是4096.实际上我们做的时候并没有依次单个处理这4096个单元，而是把4096个分成几部分，然后每部分用for循环做相同的处理。
6、为远跳转到DDR做准备
1、再次设置栈
(1)第三次设置栈。这次设置栈还是在DDR中，之前虽然已经在DDR中设置过一次栈了，但是本次设置栈的目的是将栈放在比较合适（安全，紧凑而不浪费内存）的地方。
(2)我们实际将栈设置在uboot起始地址上方2MB处，这样安全的栈空间是：2MB-uboot大小-0x1000=1.8MB左右。这个空间既没有太浪费内存，又足够安全。
2、清理bss
(1)清理bss段代码和裸机中讲的一样。注意表示bss段的开头和结尾地址的符号是从链接脚本u-boot.lds得来的。
3、ldr pc, _start_armboot
(1)start_armboot是uboot/lib_arm/board.c中，这是一个C语言实现的函数。这个函数就是uboot的第二阶段。这句代码的作用就是将uboot第二阶段执行的函数的地址传给pc，实际上就是使用一个远跳转直接跳转到DDR中的第二阶段开始地址处。
(2)远跳转的含义就是这句话加载的地址和当前运行地址无关，而和链接地址有关。因此这个远跳转可以实现从SRAM中的第一阶段跳转到DDR中的第二阶段。
(3)这里这个远跳转就是uboot第一阶段和第二阶段的分界线。
5、start_armboot函数简介
start_armboot是一个很长的函数
(1)这个函数在uboot/lib_arm/board.c的第444行开始到908行结束。
(2)450行还不是全部，因为里面还调用了别的函数。
(3)为什么这么长的函数，怎么不分成两三个函数？主要因为这个函数整个构成了uboot启动的第二阶段。
start_armboot函数的分析详解
1、init_fnc_t
(1)typedef int (init_fnc_t) (void); 这是一个函数类型
(2)init_fnc_ptr是一个二重函数指针，回顾高级C语言中讲过：二重指针的作用有2个（其中一个是用来指向一重指针），一个是用来指向指针数组。因此这里的init_fuc_ptr可以用来指向一个函数指针数组。
2、DECLARE_GLOBAL_DATA_PTR
(1)#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")定义了一个全局变量名字叫gd,这个全局变量是一个指针类型，占4字节。用volatile修饰表示可变的，用register修饰表示这个变量要尽量放到寄存器中，后面的asm("r8")是gcc支持的一种语法，意思就是要把gd放到寄存器r8中。
(2)综合分析，DECLARE_GLOBAL_DATA_PTR就是定义了一个要放在寄存器r8中的全局变量，名字叫gd，类型是一个指向gd_t类型变量的指针。
(3)为什么要定义为register？因为这个全局变量gd（global data的简称）是uboot中很重要的一个全局变量（准确的说这个全局变量是一个结构体，里面有很多内容，这些内容加起来构成的结构体就是uboot中常用的所有的全局变量），这个gd在程序中经常被访问，因此放在register中提升效率。因此纯粹是运行效率方面考虑，和功能要求无关。并不是必须的。
(4)gd_t定义在include/asm-arm/global_data.h中。
gd_t中定义了很多全局变量，都是整个uboot使用的；其中有一个bd_t类型的指针，指向一个bd_t类型的变量，这个bd是开发板的板级信息的结构体，里面有不少硬件相关的参数，譬如波特率、IP地址、机器码、DDR内存分布。
3、内存使用排布
为什么要分配内存
(1)DECLARE_GLOBAL_DATA_PTR只能定义了一个指针，也就是说gd里的这些全局变量并没有被分配内存，我们在使用gd之前要给他分配内存，否则gd也只是一个野指针而已。
(2)gd和bd需要内存，内存当前没有被人管理（因为没有操作系统统一管理内存），大片的DDR内存散放着可以随意使用（只要使用内存地址直接去访问内存即可）。但是因为uboot中后续很多操作还需要大片的连着内存块，因此这里使用内存要本着够用就好，紧凑排布的原则。所以我们在uboot中需要有一个整体规划。
4、内存排布
(1)uboot区 CFG_UBOOT_BASE-xx（长度为uboot的实际长度）
(2)堆区 长度为CFG_MALLOC_LEN，实际为912KB
(3)栈区 长度为CFG_STACK_SIZE，实际为512KB
(4)gd 长度为sizeof(gd_t)，实际36字节
(5)bd 长度为sizeof(bd_t)，实际为44字节左右
(6)内存间隔 为了防止高版本的gcc的优化造成错误。
5、for循环执行init_sequence
(1)init_sequence是一个函数指针数组，数组中存储了很多个函数指针，这些指向指向的函数都是init_fnc_t类型（特征是接收参数是void类型，返回值是int）。
(2)init_sequence在定义时就同时给了初始化，初始化的函数指针都是一些函数名。（C语言高级专题中讲过：函数名的实质）
(3)init_fnc_ptr是一个二重函数指针，可以指向init_sequence这个函数指针数组。
(4)用for循环肯定是想要去遍历这个函数指针数组（遍历的目的也是去依次执行这个函数指针数组中的所有函数）。思考：如何遍历一个函数指针数组？有2种方法：第一种也是最常用的一种，用下标去遍历，用数组元素个数来截至。第二种不常用，但是也可以。就是在数组的有效元素末尾放一个标志，依次遍历到标准处即可截至（有点类似字符串的思路）。
我们这里使用了第二种思路。因为数组中存的全是函数指针，因此我们选用了NULL来作为标志。我们遍历时从开头依次进行，直到看到NULL标志截至。这种方法的优势是不用事先统计数组有多少个元素。
(5)init_fnc_t的这些函数的返回值定义方式一样的，都是：函数执行正确时返回0，不正确时返回-1.所以我们在遍历时去检查函数返回值，如果遍历中有一个函数返回值不等于0则hang()挂起。从分析hang函数可知：uboot启动过程中初始化板级硬件时不能出任何错误，只要有一个错误整个启动就终止，除了重启开发板没有任何办法。
(6)init_sequence中的这些函数，都是board级别的各种硬件初始化。
6、cpu_init
(1)看名字这个函数应该是cpu内部的初始化，所以这里是空的。
7、board_init
(1)board_init在uboot/board/samsung/x210/x210.c中，这个看名字就知道是x210开发板相关的初始化。
(2)DECLARE_GLOBAL_DATA_PTR在这里声明是为了后面使用gd方便。可以看出把gd的声明定义成一个宏的原因就是我们要到处去使用gd，因此就要到处声明，定义成宏比较方便。
(3)网卡初始化。CONFIG_DRIVER_DM9000这个宏是x210_sd.h中定义的，这个宏用来配置开发板的网卡的。dm9000_pre_init函数就是对应的DM9000网卡的初始化函数。开发板移植uboot时，如果要移植网卡，主要的工作就在这里。
(4)这个函数中主要是网卡的GPIO和端口的配置，而不是驱动。因为网卡的驱动都是现成的正确的，移植的时候驱动是不需要改动的，关键是这里的基本初始化。因为这些基本初始化是硬件相关的。
8、gd->bd->bi_arch_number
(1)bi_arch_number是board_info中的一个元素，含义是：开发板的机器码。所谓机器码就是uboot给这个开发板定义的一个唯一编号。
(2)机器码的主要作用就是在uboot和linux内核之间进行比对和适配。
(3)嵌入式设备中每一个设备的硬件都是定制化的，不能通用。嵌入式设备的高度定制化导致硬件和软件不能随便适配使用。这就告诉我们：这个开发板移植的内核镜像绝对不能下载到另一个开发板去，否则也不能启动，就算启动也不能正常工作，有很多隐患。因此linux做了个设置：给每个开发板做个唯一编号（机器码），然后在uboot、linux内核中都有一个软件维护的机器码编号。然后开发板、uboot、linux三者去比对机器码，如果机器码对上了就启动，否则就不启动（因为软件认为我和这个硬件不适配）。
(4)MACH_TYPE在x210_sd.h中定义，值是2456，并没有特殊含义，只是当前开发板对应的编号。这个编号就代表了x210这个开发板的机器码，将来这个开发板上面移植的linux内核中的机器码也必须是2456，否则就启动不起来。
(5)uboot中配置的这个机器码，会作为uboot给linux内核的传参的一部分传给linux内核，内核启动过程中会比对这个接收到的机器码，和自己本身的机器码相对比，如果相等就启动，如果不想等就不启动。
(6)理论上来说，一个开发板的机器码不能自己随便定。理论来说有权利去发放这个机器码的只有uboot官方，所以我们做好一个开发板并且移植了uboot之后，理论上应该提交给uboot官方审核并发放机器码（好像是免费的）。但是国内的开发板基本都没有申请（主要是因为国内开发者英文都不行，和国外开源社区接触比较少），都是自己随便编号的。随便编号的问题就是有可能和别人的编号冲突，但是只要保证uboot和kernel中的编号是一致的，就不影响自己的开发板启动。
9、gd->bd->bi_boot_params
(1)bd_info中另一个主要元素，bi_boot_params表示uboot给linux kernel启动时的传参的内存地址。也就是说uboot给linux内核传参的时候是这么传的：uboot事先将准备好的传参（字符串，就是bootargs）放在内存的一个地址处（就是bi_boot_params），然后uboot就启动了内核（uboot在启动内核时真正是通过寄存器r0 r1 r2来直接传递参数的，其中有一个寄存器中就是bi_boot_params）。内核启动后从寄存器中读取bi_boot_params就知道了uboot给我传递的参数到底在内存的哪里。然后自己去内存的那个地方去找bootargs。
(2)经过计算得知：X210中bi_boot_params的值为0x30000100，这个内存地址就被分配用来做内核传参了。所以在uboot的其他地方使用内存时要注意，千万不敢把这里给淹没了。
9、背景：关于DDR的配置：
(1)board_init中除了网卡的初始化之外，剩下的2行用来初始化DDR。
(2)注意：这里的初始化DDR和汇编阶段lowlevel_init中初始化DDR是不同的。当时是硬件的初始化，目的是让DDR可以开始工作。现在是软件结构中一些DDR相关的属性配置、地址设置的初始化，是纯软件层面的。
(3)软件层次初始化DDR的原因：对于uboot来说，他怎么知道开发板上到底有几片DDR内存，每一片的起始地址、长度这些信息呢？在uboot的设计中采用了一种简单直接有效的方式：程序员在移植uboot到一个开发板时，程序员自己在x210_sd.h中使用宏定义去配置出来板子上DDR内存的信息，然后uboot只要读取这些信息即可。（实际上还有另外一条思路：就是uboot通过代码读取硬件信息来知道DDR配置，但是uboot没有这样。实际上PC的BIOS采用的是这种）
(4)x210_sd.h的496行到501行中使用了标准的宏定义来配置DDR相关的参数。主要配置了这么几个信息：有几片DDR内存、每一片DDR的起始地址、长度。这里的配置信息我们在uboot代码中使用到内存时就可以从这里提取使用（想象uboot中使用到内存的地方都不是直接用地址数字的，都是用宏定义的）
10、interrupt_init
(1)看名字函数是和中断初始化有关的，但是实际上不是，实际上这个函数是用来初始化定时器的（实际使用的是Timer4）。
(2)裸机中讲过：210共有5个PWM定时器。其中Timer0-timer3都有一个对应的PWM信号输出的引脚。而Timer4没有引脚，无法输出PWM波形。Timer4在设计的时候就不是用来输出PWM波形的（没有引脚，没有TCMPB寄存器），这个定时器被设计用来做计时。
(3)Timer4用来做计时时要使用到2个寄存器：TCNTB4、TCNTO4。TCNTB中存了一个数，这个数就是定时次数（每一次时间是由时钟决定的，其实就是由2级时钟分频器决定的）。我们定时时只需要把定时时间/基准时间=数，将这个数放入TCNTB中即可；我们通过TCNTO寄存器即可读取时间有没有减到0，读取到0后就知道定的时间已经到了。
(4)使用Timer4来定时，因为没有中断支持，所以CPU不能做其他事情同时定时，CPU只能使用轮询方式来不断查看TCNTO寄存器才能知道定时时间到了没。因为Timer4的定时是不能实现微观上的并行。uboot中定时就是通过Timer4来实现定时的。所以uboot中定时时不能做其他事（考虑下，典型的就是bootdelay，bootdelay中实现定时并且检查用户输入是用轮询方式实现的，原理参考裸机中按键章节中的轮询方式处理按键）
(5)interrupt_init函数将timer4设置为定时10ms。关键部位就是get_PCLK函数获取系统设置的PCLK_PSYS时钟频率，然后设置TCFG0和TCFG1进行分频，然后计算出设置为10ms时需要向TCNTB中写入的值，将其写入TCNTB，然后设置为auto reload模式，然后开定时器开始计时就没了。
总结：在学习这个函数时，注意标准代码和之前裸机代码中的区别，重点学会：通过定义结构体的方式来访问寄存器，通过函数来自动计算设置值以设置定时器。
11、env_init
(1)env_init，看名字就知道是和环境变量有关的初始化。
(2)为什么有很多env_init函数，主要原因是uboot支持各种不同的启动介质（譬如norflash、nandflash、inand、sd卡·····），我们一般从哪里启动就会把环境变量env放到哪里。而各种介质存取操作env的方法都是不一样的。因此uboot支持了各种不同介质中env的操作方法。所以有好多个env_xx开头的c文件。实际使用的是哪一个要根据自己开发板使用的存储介质来定（这些env_xx.c同时只有1个会起作用，其他是不能进去的，通过x210_sd.h中配置的宏来决定谁被包含的），对于x210来说，我们应该看env_movi.c中的函数。
(3)经过基本分析，这个函数只是对内存里维护的那一份uboot的env做了基本的初始化或者说是判定（判定里面有没有能用的环境变量）。当前因为我们还没进行环境变量从SD卡到DDR中的relocate，因此当前环境变量是不能用的。
(4)在start_armboot函数中（776行）调用env_relocate才进行环境变量从SD卡中到DDR中的重定位。重定位之后需要环境变量时才可以从DDR中去取，重定位之前如果要使用环境变量只能从SD卡中去读取。
12、init_baudrate
(1)init_baudrate看名字就是初始化串口通信的波特率的。
(2)getenv_r函数用来读取环境变量的值。用getenv函数读取环境变量中“baudrate”的值（注意读取到的不是int型而是字符串类型），然后用simple_strtoul函数将字符串转成数字格式的波特率。
(3)baudrate初始化时的规则是：先去环境变量中读取"baudrate"这个环境变量的值。如果读取成功则使用这个值作为环境变量，记录在gd->baudrate和gd->bd->bi_baudrate中；如果读取不成功则使用x210_sd.h中的的CONFIG_BAUDRATE的值作为波特率。从这可以看出：环境变量的优先级是很高的。
13、serial_init
(1)serial_init看名字是初始化串口的。（疑问：start.S中调用的lowlevel_init.S中已经使用汇编初始化过串口了，这里怎么又初始化？这两个初始化是重复的还是各自有不同？）
(2)SI中可以看出uboot中有很多个serial_init函数，我们使用的是uboot/cpu/s5pc11x/serial.c中的serial_init函数。
(3)进来后发现serial_init函数其实什么都没做。因为在汇编阶段串口已经被初始化过了，因此这里就不再进行硬件寄存器的初始化了。
14、console_init_f
(1)console_init_f是console（控制台）的第一阶段初始化。_f表示是第一阶段初始化，_r表示第二阶段初始化。有时候初始化函数不能一次一起完成，中间必须要夹杂一些代码，因此将完整的一个模块的初始化分成了2个阶段。（我们的uboot中start_armboot的826行进行了console_init_r的初始化）
(2)console_init_f在uboot/common/console.c中，仅仅是对gd->have_console设置为1而已，其他事情都没做。
15、display_banner
(1)display_banner用来串口输出显示uboot的logo
(2)display_banner中使用printf函数向串口输出了version_string这个字符串。那么上面的分析表示console_init_f并没有初始化好console怎么就可以printf了呢？
(3)通过追踪printf的实现，发现printf->puts，而puts函数中会判断当前uboot中console有没有被初始化好。如果console初始化好了则调用fputs完成串口发送（这条线才是控制台）；如果console尚未初始化好则会调用serial_puts(再调用serial_putc直接操作串口寄存器进行内容发送)。
(4)控制台也是通过串口输出，非控制台也是通过串口输出。究竟什么是控制台？和不用控制台的区别？实际上分析代码会发现，控制台就是一个用软件虚拟出来的设备，这个设备有一套专用的通信函数（发送、接收···），控制台的通信函数最终会映射到硬件的通信函数中来实现。uboot中实际上控制台的通信函数是直接映射到硬件串口的通信函数中的，也就是说uboot中用没用控制器其实并没有本质差别。
(5)但是在别的体系中，控制台的通信函数映射到硬件通信函数时可以用软件来做一些中间优化，譬如说缓冲机制。（操作系统中的控制台都使用了缓冲机制，所以有时候我们printf了内容但是屏幕上并没有看到输出信息，就是因为被缓冲了。我们输出的信息只是到了console的buffer中，buffer还没有被刷新到硬件输出设备上，尤其是在输出设备是LCD屏幕时）
(6)U_BOOT_VERSION在uboot源代码中找不到定义，这个变量实际上是在makefile中定义的，然后在编译时生成的include/version_autogenerated.h中用一个宏定义来实现的。
16、print_cpuinfo
(1)uboot启动过程中：
CPU: S5PV210@1000MHz(OK)
APLL = 1000MHz, HclkMsys = 200MHz, PclkMsys = 100MHz
MPLL = 667MHz, EPLL = 96MHz
HclkDsys = 166MHz, PclkDsys = 83MHz
HclkPsys = 133MHz, PclkPsys = 66MHz
SCLKA2M = 200MHz
Serial = CLKUART
这些信息都是print_cpuinfo打印出来的。
(2)回顾ARM裸机中时钟配置一章的内容，比对这里调用的函数中计算各种时钟的方法，自己去慢慢分析体会这些代码的原理和实现方法。这就是学习。
17、checkboard
(1)checkboard看名字是检查、确认开发板的意思。这个函数的作用就是检查当前开发板是哪个开发板并且打印出开发板的名字。
18、init_func_i2c
(1)这个函数实际没有被执行，X210的uboot中并没有使用I2C。如果将来我们的开发板要扩展I2C来接外接硬件，则在x210_sd.h中配置相应的宏即可开启。
19、dram_init
(1)dram_init看名字是关于DDR的初始化。疑问：在汇编阶段已经初始化过DDR了否则也无法relocate到第二部分运行，怎么在这里又初始化DDR？
(2)dram_init都是在给gd->bd里面关于DDR配置部分的全局变量赋值，让gd->bd数据记录下当前开发板的DDR的配置信息，以便uboot中使用内存。
(3)从代码来看，其实就是初始化gd->bd->bi_dram这个结构体数组。
20、display_dram_config
(1)看名字意思就是打印显示dram的配置信息。
(2)启动信息中的：（DRAM: 512 MB）就是在这个函数中打印出来的。
(3)思考：如何在uboot运行中得知uboot的DDR配置信息？uboot中有一个命令叫bdinfo，这个命令可以打印出gd->bd中记录的所有硬件相关的全局变量的值，因此可以得知DDR的配置信息。
DRAM bank = 0x00000000
-> start = 0x30000000
-> size = 0x10000000
DRAM bank = 0x00000001
-> start = 0x40000000
-> size = 0x10000000
21、init_sequence总结
(1)都是板级硬件的初始化以及gd、gd->bd中的数据结构的初始化。譬如：
网卡初始化、机器码（gd->bd->bi_arch_number）、内核传参DDR地址（gd->bd->bi_boot_params）、Timer4初始化为10ms一次、波特率设置（gd->bd->bi_baudrate和gd->baudrate）、console第一阶段初始化（gd->have_console设置为1）、打印uboot的启动信息、打印cpu相关设置信息、检查并打印当前开发板名字、DDR配置信息初始化（gd->bd->bi_dram）、打印DDR总容量。
22、CFG_NO_FLASH
(1)虽然NandFlash和NorFlash都是Flash，但是一般NandFlash会简称为Nand而不是Flash，一般讲Flash都是指的Norflash。这里2行代码是Norflash相关的。
(2)flash_init执行的是开发板中对应的NorFlash的初始化、display_flash_config打印的也是NorFlash的配置信息（Flash: 8 MB就是这里打印出来的）。但是实际上X210中是没有Norflash的。所以着两行代码是可以去掉的（我也不知道为什么没去掉？猜测原因有可能是去掉着两行代码会导致别的地方工作不正常，需要花时间去移植调试，然后移植的人就懒得弄。实际上不去掉除了显示有8MB Flash实际没用之外也没有别的影响）
CONFIG_VFD和CONFIG_LCD是显示相关的，这个是uboot中自带的LCD显示的软件架构。但是实际上我们用LCD而没有使用uboot中设置的这套软件架构，我们自己在后面自己添加了一个LCD显示的部分。
23、mem_malloc_init
(1)mem_malloc_init函数用来初始化uboot的堆管理器。
(2)uboot中自己维护了一段堆内存，肯定自己就有一套代码来管理这个堆内存。有了这些东西uboot中你也可以malloc、free这套机制来申请内存和释放内存。我们在DDR内存中给堆预留了896KB的内存。
24、代码实践，去掉Flash看会不会出错。
结论：加上CONFIG_NOFLASH宏之后编译出错，说明代码移植的不好，那个文件的包含没有被这个宏控制。于是乎移植的人就直接放这没管。
25、开发板独有初始化：mmc初始化
(1)从536到768行为开发板独有的初始化。意思是三星用一套uboot同时满足了好多个系列型号的开发板，然后在这里把不同开发板自己独有的一些初始化写到了这里。用#if条件编译配合CONFIG_xxx宏来选定特定的开发板。
(2)X210相关的配置在599行到632行。
(3)mmc_initialize看名字就应该是MMC相关的一些基础的初始化，其实就是用来初始化SoC内部的SD/MMC控制器的。函数在uboot/drivers/mmc/mmc.c里。
(4)uboot中对硬件的操作（譬如网卡、SD卡···）都是借用的linux内核中的驱动来实现的，uboot根目录底下有个drivers文件夹，这里面放的全都是从linux内核中移植过来的各种驱动源文件。
(5)mmc_initialize是具体硬件架构无关的一个MMC初始化函数，所有的使用了这套架构的代码都掉用这个函数来完成MMC的初始化。mmc_initialize中再调用board_mmc_init和cpu_mmc_init来完成具体的硬件的MMC控制器初始化工作。
(6)cpu_mmc_init在uboot/cpu/s5pc11x/cpu.c中，这里面又间接的调用了drivers/mmc/s3c_mmcxxx.c中的驱动代码来初始化硬件MMC控制器。这里面分层很多，分层的思想一定要有，否则完全就糊涂了。
26、env_relocate
(1)env_relocate是环境变量的重定位，完成从SD卡中将环境变量读取到DDR中的任务。
(2)环境变量到底从哪里来？SD卡中有一些（8个）独立的扇区作为环境变量存储区域的。但是我们烧录/部署系统时，我们只是烧录了uboot分区、kernel分区和rootfs分区，根本不曾烧录env分区。所以当我们烧录完系统第一次启动时ENV分区是空的，本次启动uboot尝试去SD卡的ENV分区读取环境变量时失败（读取回来后进行CRC校验时失败），我们uboot选择从uboot内部代码中设置的一套默认的环境变量出发来使用（这就是默认环境变量）；这套默认的环境变量在本次运行时会被读取到DDR中的环境变量中，然后被写入（也可能是你saveenv时写入，也可能是uboot设计了第一次读取默认环境变量后就写入）SD卡的ENV分区。然后下次再次开机时uboot就会从SD卡的ENV分区读取环境变量到DDR中，这次读取就不会失败了。
(3)真正的从SD卡到DDR中重定位ENV的代码是在env_relocate_spec内部的movi_read_env完成的。
27、IP地址、MAC地址的确定
(1)开发板的IP地址是在gd->bd中维护的，来源于环境变量ipaddr。getenv函数用来获取字符串格式的IP地址，然后用string_to_ip将字符串格式的IP地址转成字符串格式的点分十进制格式。
(2)IP地址由4个0-255之间的数字组成，因此一个IP地址在程序中最简单的存储方法就是一个unsigend int。但是人类容易看懂的并不是这种类型，而是点分十进制类型（192.168.1.2）。这两种类型可以互相转换。
28、devices_init
(1)devices_init看名字就是设备的初始化。这里的设备指的就是开发板上的硬件设备。放在这里初始化的设备都是驱动设备，这个函数本来就是从驱动框架中衍生出来的。uboot中很多设备的驱动是直接移植linux内核的（譬如网卡、SD卡），linux内核中的驱动都有相应的设备初始化函数。linux内核在启动过程中就有一个devices_init(名字不一定完全对，但是差不多)，作用就是集中执行各种硬件驱动的init函数。
(2)uboot的这个函数其实就是从linux内核中移植过来的，它的作用也是去执行所有的从linux内核中继承来的那些硬件驱动的初始化函数。
29、jumptable_init
(1)jumptable跳转表，本身是一个函数指针数组，里面记录了很多函数的函数名。看这阵势是要实现一个函数指针到具体函数的映射关系，将来通过跳转表中的函数指针就可以执行具体的函数。这个其实就是在用C语言实现面向对象编程。在linux内核中有很多这种技巧。
(2)通过分析发现跳转表只是被赋值从未被引用，因此跳转表在uboot中根本就没使用。
30、console_init_r
(1)console_init_f是控制台的第一阶段初始化，console_init_r是第二阶段初始化。实际上第一阶段初始化并没有实质性工作，第二阶段初始化才进行了实质性工作。
(2)uboot中有很多同名函数，使用SI工具去索引时经常索引到不对的函数处（回忆下当时start.S中找lowlevel_init.S时，自动索引找到的是错误的，真正的反而根本没找到。）
(3)console_init_r就是console的纯软件架构方面的初始化（说白了就是去给console相关的数据结构中填充相应的值），所以属于纯软件配置类型的初始化。
(4)uboot的console实际上并没有干有意义的转化，它就是直接调用的串口通信的函数。所以用不用console实际并没有什么分别。（在linux内console就可以提供缓冲机制等不用console不能实现的东西）。
31、enable_interrupts
(1)看名字应该是中断初始化代码。这里指的是CPSR中总中断标志位的使能。
(2)因为我们uboot中没有使用中断，因此没有定义CONFIG_USE_IRQ宏，因此我们这里这个函数是个空壳子。
(3)uboot中经常出现一种情况就是根据一个宏是否定义了来条件编译决定是否调用一个函数内部的代码。uboot中有2种解决方案来处理这种情况：方案一：在调用函数处使用条件编译，然后函数体实际完全提供代码。方案二：在调用函数处直接调用，然后在函数体处提供2个函数体，一个是有实体的一个是空壳子，用宏定义条件编译来决定实际编译时编译哪个函数进去。
32、loadaddr、bootfile两个环境变量
(1)这两个环境变量都是内核启动有关的，在启动linux内核时会参考这两个环境变量的值。
33、board_late_init
(1)看名字这个函数就是开发板级别的一些初始化里比较晚的了，就是晚期初始化。所以晚期就是前面该初始化的都初始化过了，剩下的一些必须放在后面初始化的就在这里了。侧面说明了开发板级别的硬件软件初始化告一段落了。
(2)对于X210来说，这个函数是空的。
34、eth_initialize
(1)看名字应该是网卡相关的初始化。这里不是SoC与网卡芯片连接时SoC这边的初始化，而是网卡芯片本的一些初始化。
(2)对于X210（DM9000）来说，这个函数是空的。X210的网卡初始化在board_init函数中，网卡芯片的初始化在驱动中。
35、x210_preboot_init（LCD和logo显示）
(1)x210开发板在启动起来之前的一些初始化，以及LCD屏幕上的logo显示。
36、check menukey to update from sd
(1)uboot启动的最后阶段设计了一个自动更新的功能。就是：我们可以将要升级的镜像放到SD卡的固定目录中，然后开机时在uboot启动的最后阶段检查升级标志（是一个按键。按键中标志为"LEFT"的那个按键，这个按键如果按下则表示update mode，如果启动时未按下则表示boot mode）。如果进入update mode则uboot会自动从SD卡中读取镜像文件然后烧录到iNand中；如果进入boot mode则uboot不执行update，直接启动正常运行。
(2)这种机制能够帮助我们快速烧录系统，常用于量产时用SD卡进行系统烧录部署。
37、死循环
(1)解析器
(2)开机倒数自动执行
(3)命令补全
文章来自网络
回帖高级模式
声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容图片侵权或者其他问题，请联系本站作侵删。 侵权投诉