<ubbot&Makefile>uboot下的文件目录结构和主Makefile的分析

关于uboot下的文件目录结构和主Makefile的分析
uboot文件目录的分析(基于九鼎官方移植到Makefile的版本)
文件夹:
api:硬件无关的功能函数的API。uboot移植时基本不用管,这些函数是uboot本身使用的。
api_examples:API相关的测试事例代码。
board:board是板的意思,板就是开发板。board文件夹下每一个文件都代表一个开发板,这个文件夹下面放的文件就是用来描述这一个开发板的信息的。board目录下有多少个文件夹,就表示当前这个uboot已经被移植到多少个开发板上了(当前的uboot支持多少个开发板)。uboot的配置阶段(其实就是根目录下面的mkconfig脚本和Makefile中配置有关的部分)主要解决的问题就是在可移植性领域能够帮助我们确定具体的文件夹的路径,然后编译时可以找到应该找到的文件,才能编译成功。因此board目录下的不同会造成配置时的不同。如果移植时没注意这里肯定要失败。
common:common是普遍的普通的,这个文件夹下放的是一些与具体硬件无关的普遍适用的一些代码。譬如控制台实现、crc校验的。但是更多的主要是两类:一类是cmd开头的,是用来实现uboot的命令系统的;另一类是env开头的,是用来实现环境变量的。
cpu:这个目录是SoC相关的,里面存放的代码都是SoC相关初始化和控制代码(譬如CPU的、中断的、串口等SoC内部外设的,包括起始代码start.S也在这里)。里面很多子文件夹,每一个子文件夹就是一个SoC系列。
注意:这个文件是严格和硬件相关的,因此移植时也是要注意的。但是因为这个文件夹内都是SoC有关的,我们自己的开发板和三星的开发板虽然板子设计不同但是SoC都是同一个,因此实际移植时这个目录几乎不用动。
disk:磁盘有关的。
doc:文档目录,里面存放了很多uboot相关文档,这些文档可以帮助我们理解uboot代码。
drivers:顾名思义,驱动。这里面放的就是从linux源代码中扣出来的原封不动的linux设备驱动,主要是开发板上必须用到的一些驱动,如网卡驱动、Inand/SD卡、NandFlash等的驱动。要知道:uboot中的驱动其实就是linux中的驱动,uboot在一定程度上移植了linux的驱动给自己用。但是linux是操作系统而uboot只是个裸机程序,因此这种移植会有不同,让我说:uboot中的驱动其实是linux中的驱动的一部分。
examples:示例代码。
fs:filesystem,文件系统。这个也是从linux源代码中移植过来的,用来管理Flash等资源。
include:头文件目录。uboot和linux kernel在管理头文件时都采用了同一个思路,就是把所有的头文件全部集中存放在include目录下,而不是头文件跟着自己对应的c文件。所以在uboot中头文件包含时路径结构要在这里去找。
lib_arm:(典型的lib_arm和lib_generic)架构相关的库文件。譬如lib_arm里面就是arm架构使用的一些库文件。lib_generic里是所有架构通用的库文件。这类文件夹中的内容移植时基本不用管。
lib_generic:
libfdt:设备树有关的。linux内核在3.4左右的版本的时候更改了启动传参的机制,改用设备树来进行启动传参,进行硬件信息的描述了。
nand_spl:nand相关的,
net:网络相关的代码,譬如uboot中的tftp nfs ping命令 都是在这里实现的。
onenand_bl1:是onenand相关的代码,是三星加的,标准uboot中应该是没有的。
onenand_ipl:
post:没关注过,不知道干嘛的。
sd_fusing:这里面代码实现了烧录uboot镜像到SD卡的代码。
tools:里面是一些工具类的代码。譬如mkimage。
文件:
(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的配置编译
配置
(1)uboot和linux kernel等复杂项目,都不能直接编译,都要先配置才能编译。
(2)uboot也要先配置,配置方法是:首先cd进入uboot源码的根目录,然后在根目录下执行:make x210_sd_config。执行配置命令后,如果出现:Configuring for x210_sd board…
说明配置好了,如果不是这个是别的说明配置出错了。
注意:uboot的配置阶段(其实就是根目录下面的mkconfig脚本和Makefile中配置有关的部分)主要解决的问题就是在可移植性领域能够帮助我们确定具体的文件夹的路径,然后编译时可以找到应该找到的文件,才能编译成功。因此board目录下的不同会造成配置时的不同。如果移植时没注意这里肯定要失败。
编译
编译最终得到uboot.bin
(1)编译之前一定要注意检查arm-linux-gcc对不对,检查份2步:
第一步:检查当前编译环境中有没有安装合适的arm-linux-gcc。我们装的是arm-2009q3,因为这个是三星官方、九鼎官方开发uboot时使用的。
第二步:检查当前目录下(uboot根目录)的Makefile中编译器的设置是否正确。在工程的总Makefile中会设置交叉编译工具链的路径和名字,必须确保这个路径和名字和我们自己装的一致,否则编译会出错。
(2)确保了以上2点,即可进行编译。编译很简单,直接make即可。或者可以make -j4 (多线程编译,主机如果是多核心电脑,可以尝试多线程编译,会快一些)
注:文章是拷贝朱老师课件做的总结

上一篇:06项目自动化构建工具-make/Makefile


下一篇:准备工作