2.3.1、X210官方uboot配置编译实践
2.3.1.1、找到官方移植好的uboot(BSP概念)
- （1）源头的源代码是uboot官网下载的。这个下载的源代码可能没有你当前使用的开发板的移植，甚至找不到当前开发板使用SoC对应的移植版本。
- （2）SoC厂商在推出一款SoC后厂商的工程师会去uboot官网下载一个uboot，根据自己的SoC进行第一步移植，移植的目标是厂商推出的开发板（譬如三星的S5PV210芯片厂商出的开发板就叫SMDKV210）。所以三星的工程师移植的uboot是根据他们自己的SMDKV210开发板移植的。
- （3）具体的开发板供应商（譬如x210的生产商深圳市九鼎科技）首先购买三星的SMDKV210开发板，然后进行裁剪（把无用的接口功能裁剪掉，配置降低一下，某些配置会被替换）。硬件替换和裁剪之后生成的新的开发板（譬如x210）和三星官方的SMDKV210有所不同，因此uboot也不同。但是SoC是相同的，所以相似度至少有60%。所以具体开发板供应商会以SMDKV210中一直的uboot为蓝本来一直得到自己开发板的一个uboot一直。我们买的x210开发板时，厂商光盘中带的BSP中的uboot源码就是他一直过的。
总结：uboot可以有三种获取途径：uboot官方、soc官方、具体开发板的官方。
2.3.1.2、在linux原生目录下配置编译
- （1）x210一直过的uboot在开发板光盘的BSP中
- （2）BSP就是board support package（板级支持包，一般有开发板供应商提供，里面的内容就是这个开发板的所有相关的源代码、文档、教程等）
- （3）将整个BSP打包文件弄到linux的原生目录中去解压分析，不要在windows中的共享文件夹中解压开。（除非你的代码只在windows下分析，而不去编译，如果想要编译工程就一定不要在windows共享文件夹下，否则会出错）
- （4）tar -jxvf qt_x210v3 130807.tar.bz2
- （5）我们在linux下维持一份uboot，在windows下也维持一份uboot，在我们没有开始任何工作之前，这两份uboot内容一样的，都是九鼎官方的uboot内容。我们这样做的目的是：在linux下进行编译，在windows下进行代码分析和观看。（windows下有很好的 工具辅助我们看代码，编辑嗲吗，在linux下编译和看代码都很麻烦.........）
2.3.1.3、配置
- （1）uboot和linux kernel等复杂项目，都不能直接编译，都要先配置才能编译
- （2）uboot也要先配置，配置的方法是：首先cd进入uboot源码的根目录，然后在根目录下执行：make x210_sd_config。执行配置命令后如果出现：configuring for x210_sd board....
说明配置好了，如果不是这个是别的说明配置出错了。
2.3.1.4、编译得到uboot.bin
- （1）编译之前一定要注意检查arm-linux-gcc对不对，检查分为2步
第一步：检查当前编译环境中有没有安装合适的arm-linux-gcc。我们装的是arm-2009q3，因为这个是三星官方、九鼎官方开发uboot时候使用的。
第二步：检查当前目录下（uboot根目录）的Makefile中编译器的设置是否正确。在工程的总Makefile中会设置交叉编译工具链的路径和名字，必须确保和我们自己装的
- （2）在确保了以上两点之后，即可进行编译。编译很简单，直接make即可。或者可以make -j4 （多线程编译，主机如果是多核电脑，可以尝试多线程编译，会快一些）
2.3.2.X210官方uboot配置编译实践2
2.3.2.1、在linux源生目录下配置编译
- (1)X210移植过的uboot在开发板光盘的BSP中。
- (2)BSP就是board support package(板级支持包，一般由开发板供应商提供)，里面的内容就是这个开发板的所有相关的源代码、文档、教程等。
- (3)将整个BSP打包文件弄到linux的源生目录中去解压分析，不要在windows中的共享文件夹中解压开。（除非你的代码只在windows下去分析而不去编译，如果你想编译工程就一定不要在windows共享文件夹下，否则会出错）
- (4)tar -jxvf qt_x210v3_130807.tar.bz2
- (5)我们在linux下维持一份uboot，在windows下也维持一份uboot，在我们没有开始任何工作之前，这两份uboot内容一样的，都是九鼎官方的uboot 内容。我们这样做目的是：在linux中进行编译、在windwos下进行代码分析和观看。（windwos下有SourceInsight等很好的工具辅助我们看代码、编辑代码，在linux下编译和看代码都很麻烦·····）
2.3.2.2、配置
- (1)uboot和linux kernel等复杂项目，都不能直接编译，都要先配置才能编译。
- (2)uboot也要先配置，配置方法是：首先cd进入uboot源码的根目录，然后在根目录下执行：make x210_sd_config。执行配置命令后，如果出现：Configuring for x210_sd board...说明配置好了，如果不是这个是别的说明配置出错了。
2.3.2.3、编译得到uboot.bin
- (1)编译之前一定要注意检查arm-linux-gcc对不对，检查份2步：
第一步：检查当前编译环境中有没有安装合适的arm-linux-gcc。我们装的是arm-2009q3，因为这个是三星官方、九鼎官方开发uboot时使用的。
第二步：检查当前目录下（uboot根目录）的Makefile中编译器的设置是否正确。在工程的总Makefile中会设置交叉编译工具链的路径和名字
（vi Makefile可查看），必须确保这个路径和名字和我们自己装的一致，否则编译会出错。
- (2)确保了以上2点，即可进行编译。编译很简单，直接make即可。或者可以make -j4 (多线程编译，主机如果是多核心电脑，可以尝试多线程编译，会快一些)
2.3.3.uboot的源码目录分析1
2.3.3.1、九鼎官方uboot和三星原版uboot对比
- (1)以九鼎官方的uboot为蓝本来学习的，以三星官方的这份为对照。
- (2)不同版本的uboot或者同一版本不同人移植的uboot，可能目录结构和文件内容都有所不同。将来大家懂了后也可以自己根据需要去添加/删除/更改目录结构。
- (3)九鼎在以三星的uboot为原材料进行移植时，把三星版本的uboot中很多不必要的文件夹、文件给删除掉了。这个删除把很多完全用不到的文件清除出去，减少了整体的文件数量，便于工作。
2.3.3.2、各文件介绍
- (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的配置，一个负责编译。我们在第四部分的课程中会详细讲解分析这两个东西。
2.3.4、uboot的源码目录分析2
2.3.4.1、硬件无关的功能函数的API
- （1）api：硬件无关的功能函数API。uboot移植时基本不用管，这些函数是uboot本身使用的
- （2）api_example，API相关的测试事例代码
- （3）board。board是板的意思，板就是开发板，board文件夹下每一个文件都代表一个开发板，这个文件夹下面放的文件就是用来描述这个开发板的信息的、board下面有多少文件夹就说明当前这个uboot已经被移植到多少个开发板上了（当前的uboot支持多少个开发板）。
- 问题一：思考uboot如何支持多套开发板，如何具有移植性
- 问题二：board下有这么多文件夹，究竟如何确定具体使用哪一个？uboot在配置阶段会有一些手段帮助我们确定具体是使用board目录下的哪个文件夹（想想为什么不能直接编译而要先配置）
- 问题三：开发板越来越多，board目录下的文件夹越来越多，不方便管控。于是乎uboot就新增了一种机制可以在board目录下不直接放开发板目录，而是在board目录下放开发板目录，而是在board目录下放厂家目录（vendor目录，以具体芯片厂商名字命名）然后这个IC厂商所有芯片开发板都丢到这个vendor目录下面去，所以大家会发现我们x210对应的开发板目录在board/samsung/x210。多了这层目录会影响配置阶段是路径深度和实际存放要对应，不然配置后编译时找不到文件编译就会失败。注意一个细节就是历史原因造成的兼容性麻烦。最开始时board目录下就是开发板名字，后来才改成厂商名字的，但是要向前兼容，同一个厂商原来还是外面的开发板并没有挪移到厂商目录下面去。这样就造成后来的人不知道原委的感到很奇怪，感觉很混乱。
- 要注意：uboot的配置阶段（其实就是根目录下面的mkconfig脚本和Makefile中配置有关的部分）主要解决的问题就是在可移植性领域能够帮助我们确定具体的文件夹的路径，然后编译时不报错，编译时可以找到应该找到的文件，才能编译成功。因此board目录下的不同会造成我们配置时的不同。如果一直是没注意到这里，肯定要失败。
2.3.5、uboot的源码分析3
- （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。file systerm ，文件系统。这个也是从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。这里main代码实现了烧录镜像带SD卡的代码。后面要仔细研究的
- （19）tools。里面是一些工具类的代码。譬如mkimage。
总结：文件夹里面比较重要的，后面分析会涉及到的有:board、common、cpu、drivers、include、lib_arm、lib_generic、sd_fusing
2.3.6、SourceInsight的基本使用
2.3.6.1为什么要使用SourceInsight
- （1）对于一个真正的项目，往往有几十几百甚至上万个.c文件、.h文件，代码量非常大，代码之间关联非常复杂，就带来一个问题，代码的分析。阅读越来越难。譬如这里引用了饿一个函数，但是这个函数可能在另外一个目录下的一个文件夹中存放，这样的情况下代码查找和阅读很困难，我们希望有一个很好的工具能够帮助。于是乎有了SourceInsight
2.3.6.2、建立工程及添加文件
- （1）要使用SI看代码，首先要创建一个工程。菜单栏：project->new project。在弹出的对话框中上面输入工程名字（自己起名字，随便写，但是一般要和工程相对应，免得时间长了就忘记了），下面要输入工程文件存放的位置。
- （2）工程项目文件和工程中管理的源代码文件的目录可以是不同的，但是我一般习惯放在一起E:winshares5pv210ubootuboot_jiudingSI_Proj点确定，进入new project setting，直接点OK进入下一步。
- （3）到了项目中添加文件的步骤：在左侧选择uboot-jiuding这个目录，然后点右侧边栏的add tree即可添加，发现添加了1054个文件进去
- （4）对于老师提供的版本来说，本来应该已经结束了，但是有遗留问题，因为SI软件有个特点，他只能发现自己识别的文件类型，对于它未识别的文件类型它就看不到。譬如start.S文件就包未包含在内，因为SI默认不认识.S文件。
- 解决方案：第一种是自己配置：第二种是加载我提供的AstonSICFG.
- （5）解决了（4）中问题再次添加文件。菜单栏 project->Add and Remove Project Files
2.3.6.3、解析工程文件
- （1）SI工作原理就是语言吧所有源代码中的所有符号全部解析全部解析到存储数据库中，然后等我们进行符号查找是，SI不是查文件而是帮我们索引符号，因袭SI查找非常快。
- （2）因此我们使用SI查阅源码前应该预先进行源码解析。在菜单栏Project->Syneronize Files，选中上面两个，然后确定。