x210 uboot编译

x210 uboot编译
1.源头的源代码是uboot官网下载的，SoC厂商在推出一款SoC后，厂商的工程师会去uboot官网下载一个uboot，根据自己的SoC进行第一步的移植，移植的目标是厂商推出的开发板。（譬如三星的S5PV210芯片厂商出的开发板就叫SMDKV210）.所以三星的工程师移植的uboot是根据他们自己的SMDKV210开发板移植的
2.具体的开发板供应商（譬如X210的生产商深圳市九鼎科技）首先购买三星的SMDKV210开发板，然后进行裁剪（把一些无用的接口功能裁剪去，配置降低一下，某些配置会被替换）。硬件替换和裁剪之后生成的新的开发板（譬如X210）和三星官方的SMDKV210有所不同，因此uboot也不同。但是因为SoC是相同的，所以相似度至少有60%以上。所以具体开发板供应商会以三星SMDKV210中移植的uboot为蓝本来移植得到自己的开发板的一个uboot移植。我们买X210开发板时厂商光盘中带的BSP中的uboot源码就是他移植过的。
总结：uboot可以有3种获取途径：uboot官方、SoC官方、具体开发板的官方。

---

BSP就是board support package(板级支持包，一般由开发板供应商提供)，里面的内容就是这个开发板的所有相关的源代码、文档、教程等。)
九鼎提供的bsp中有九鼎移植好的uboot
1.编译uboot需要到linux的原生目录中去编译，不能在windows共享文件夹里，也可以在samba服务器里。最方便的就是
在samba服务器里面去操作，既可以阅读代码，也可以去编译。

---

编译uboot的第一步：配置 make x210_sd_config
(1)uboot和linux kernel等复杂项目，都不能直接编译，都要先配置才能编译。
(2)uboot也要先配置，配置方法是：首先cd进入uboot源码的根目录，然后在根目录下执行：make x210_sd_config。执行配置命令后，如果出现：Configuring for x210_sd board…
说明配置好了，如果不是这个是别的说明配置出错了。
编译uboot的第二步：编译 make -j4
(1)编译之前一定要注意检查arm-linux-gcc对不对，检查份2步：
第一步：检查当前编译环境中有没有安装合适的arm-linux-gcc。我们装的是arm-2009q3，因为这个是三星官方、九鼎官方开发uboot时使用的。
第二步：检查当前目录下（uboot根目录）的Makefile中编译器的设置是否正确。在工程的总Makefile中会设置交叉编译工具链的路径和名字，必须确保这个路径和名字和我们自己装的一致，否则编译会出错。

---

uboot根目录下文件分析：
(1).gitignore：git工具的文件
(2)arm_config.mk。后缀是.mk，是一个Makefile文件，将来在某个Makefile中会去调用它。
(3)三个Changelog文件，修改记录文件，该文件记录了这个uboot项目的版本变迁以及每个版本较上个版本修改的记录。正式的项目都有这些记录的。可以直接忽略，主要是给维护uboot的人用的
(4)config.mk。和arm_config.mk差不多性质。一样会被某个Makefile所调用
(5)COPYING。版权声明，uboot本身是GPL许可证的。
(6)CREDITS。鸣谢，里面记录了对uboot有贡献的人，感谢目录。
(7)image_split。一个脚本，可能与镜像分割有关，之后用到再来研究
(8)MAINTAINERS。维护者，就是当前在参与维护uboot源码的社区工作者。
(9)MAKEALL。一个脚本，应该是和uboot编译有关的
(10)Makefile。这个很重要，是uboot源代码的主Makefile，将来整个uboot被编译时就是用这个Makefile管理编译的，
(11)mk。快速编译的脚本，
(12)mkconfig。这个很重要，是uboot配置阶段的主要配置脚本。uboot的可移植性很大程度就是靠这个配置脚本在维护的。
(13)mkmovi。暂时不去管他，一个脚本，和iNand/SD卡启动有关
(14)README。所有的软件都有README，一般拿到一个东西要先读README，这个东西其实就是个简单的使用说明书。
(15)rules.mk。这个文件是我们uboot的Makefile使用的规则，本身非常重要，但是我们不去分析他，不去看他。
总结：对我们重要的文件就是Makefile和mkconfig文件。之后详细分析这两个文件。

---

uboot根目录下文件夹分析：
(1)api：硬件无关的功能函数的API。uboot移植时基本不用管，这些函数是uboot本身使用的。
(2)api_examples. API相关的测试事例代码。
(3)board。board是板的意思，板就是开发板。board文件夹下每一个文件都代表一个开发板，这个文件夹下面放的文件就是用来描述这一个开发板的信息的。board目录下有多少个文件夹，就表示当前这个uboot已经被移植到多少个开发板上了（当前的uboot支持多少个开发板）
问题一：思考uboot如何支持多套开发板，如何具有可移植性？
问题二：board下有这么多文件夹，究竟如何确定具体使用的是哪一个？uboot在配置阶段会有一些手段帮助我们来确定具体使用的是board目录下的哪一个文件夹。（想想为什么不能直接编译而要先配置）
问题三：开发板越来越多，board目录下文件夹越来越多不方便管控。于是乎uboot就新增了一种机制，可以在board目录下不直接放开发板目录，而是在board下放厂家目录（vendor目录，以具体芯片厂商名字命名），然后将这个IC厂商的所有芯片开发板都丢到这个vendor目录下面去。所以大家会发现我们X210对应的开发板目录在board/samsung/x210。多了这层目录会影响配置阶段，在uboot的配置阶段要注意配置时的路径深度和实际存放要对应，不然配置后编译时找不到文件编译就会失败。注意一个细节就是历史原因造成的兼容性麻烦。最开始时board目录下就是开发板名字，后来才改成厂商名字的。但是因为要向前兼容，同一个厂商原来还是外面的开发板并没有挪移到厂商目录下面去。这样就造成后来的人不知道原委的感到很奇怪，感觉很混乱。
注意：强调一下，uboot的配置阶段（其实就是根目录下面的mkconfig脚本和Makefile中配置有关的部分）主要解决的问题就是在可移植性领域能够帮助我们确定具体的文件夹的路径，然后编译时可以找到应该找到的文件，才能编译成功。因此board目录下的不同会造成配置时的不同。如果移植时没注意这里肯定要失败。
(4)common。common是普遍的普通的，这个文件夹下放的是一些与具体硬件无关的普遍适用的一些代码。譬如控制台实现、crc校验的。但是更多的主要是两类：一类是cmd开头的，是用来实现uboot的命令系统的；另一类是env开头的，是用来实现环境变量的。
(5)cpu。这个目录是SoC相关的，里面存放的代码都是SoC相关初始化和控制代码（譬如CPU的、中断的、串口等SoC内部外设的，包括起始代码start.S也在这里）。里面很多子文件夹，每一个子文件夹就是一个SoC系列。
注意：这个文件夹是和硬件相关的，因此移植时也是要注意的。但是因为这个文件夹内都是SoC有关的，我们自己的开发板和三星的开发板虽然板子设计不同但是SoC都是同一个，因此实际移植时这个目录几乎不用动(根据samsung的SMDKV210来做X210的时候)
(6)disk。磁盘有关的，
(7)doc。文档目录，
(8)drivers。顾名思义，驱动。这里面放的就是从linux源代码中扣出来的原封不动的linux设备驱动，主要是开发板上必须用到的一些驱动，如网卡驱动、Inand/SD卡、NandFlash等的驱动。要知道：uboot中的驱动其实就是linux中的驱动，uboot在一定程度上移植了linux的驱动给自己用。但是linux是操作系统而uboot只是个裸机程序，因此这种移植会有不同
(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。还有在linux下读写环境变量相关的代码
总结：文件夹里面比较重要的：board、common、cpu、drivers、include、lib_arm、lib_generic、sd_fusing