ARM uboot 的源码目录分析

一、uboot的源码目录分析1

1、九鼎官方 uboot 和三星原版 uboot 对比

(1) 以九鼎官方的 uboot 为蓝本来学习的，以三星官方的这份为对照。

(2) 不同版本的 uboot 或者同一版本不同人移植的 uboot，可能目录结构和文件内容都有所不同。将来大家懂了后也可以自己根据需要去添加/删除/更改目录结构。

(3) 九鼎在以三星的 uboot 为原材料进行移植时，把三星版本的 uboot 中很多不必要的文件夹、文件给删除掉了。这个删除把很多完全用不到的文件清除出去，减少了整体的文件数量，便于工作。

---

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 的配置，一个负责编译。我们在第四部分的课程中会详细讲解分析这两个东西。

---

二、uboot 的源码目录分析2

(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 目录下的不同会造成配置时的不同。如果移植时没注意这里肯定要失败。

---

三、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。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。

---

源自朱友鹏老师.