uboot跨平台

来源：互联网发布：linux系统cd命令编辑：程序博客网时间：2024/06/10 23:21

1 简介

u-boot跨平台是为了最大化的共用代码，提高开发效率，节约开发时间。

2 目录结构

|--u-boot (根目录)

|-- arch (平台目录)

| |--arm (arm架构)

| |--(config.mk) (指明基于arm的编译器路径)

| | |--cpu (CPU种类目录，如armv7, arm926)

| | | |--armv7 (CPU下的板级目录，和CPU有关的操作)

| | |--lib (基于函数，如字符串/除法等操作，初始化主函数)

| | |--include (所有头文件操作)

| | | |--asm

|--board (板级目录)

| |--mtk (自定义方案目录)

| | |--a9 (方案下的分支)

|--common (所有命令存放目录，以及shell)

|--disk (分区格式操作目录)

|--doc (文档目录)

|--drivers (驱动)

| |--dma (dma)

| |--i2c (i2c)

| |--net (net)

| |--others… (以及其它驱动模块)

|--fs (文件系统目录)

| |--ext2

| |--fat

| |--other fs…

|--include (头文件目录)

| |--asm

| | |--arch-sum (arch/arn/include/arch-sum的软链接)

| |--others

|--lib (C库，标准算法,如crc32)

|--nanx_sum (nand目录)

|--net (协议层目录,如dns, nfs, tftp)

|--… (其它自定义目录)

|--(boards.cfg) (新IC或者方案的配置添加)

|--(Makefile) (顶层makefile)

|--(config.mk) (顶层配置，用宏定义路径，参数)

|--(other file…) (其它文件)

3 新平台支持

3.1 编译方式

通常情况下，u-boot的完整编译命令是

make distclean //清除掉所有的编译信息，包括.o文件

make xxx_config //选择一个平台进行编译，平台信息下面介绍

make –j8 //开始编译，-jx表示使用x个线程，可以没有-jx，数字选择从1-16，数字越大编译越快

uboot中添加一个新平台的支持，主要做好以下几方面的工作。

3.2 编译支持

打开根目录下，board.cfg文件，按照如下的格式

Target ARCH CPU Board_name Vendor SoC Options

在原有的数据下添加新的支持。中间使用一个或者多个空格或者tab隔开。

下面说明其中每个符号的含义，以及需要完成的工作。

3.2.1 Target

目标名称，用于指定编译时候的名称

比如，如果添加sum，则编译时候就使用make sum_config；如果添加a9，则编译时候使用make a9_config。

此外，它也决定了所使用的编译时的总头文件，这个头文件位于include/configs目录下，文件名即为$(Target).h。比如sum.h，a9.h。

其中存放的是编译宏，决定了哪些代码需要编译，哪些不需要；或者定义了部分变量，比如目前用到的MMU_BASE，即在这个头文件中定义。

3.2.2 ARCH

CPU架构，比如arm，mips，等等。对于我们的IC，就直接使用arm。

举例来说，当使用arm的时候，则编译器会自动到目录arch/arm目录下寻找相关内容。

我们需要记住这个添加的ARCH。

3.2.3 CPU

通常这里表示指令集分类，比如我们用到的armv7，以前用过的arm926ejs，等等。编译的时候，会使用这里的参数来区分使用不同指令集。

同时，它和ARCH一起决定了我们添加的代码，应该存放在arch/arm/cpu/armv7这个目录下。

CPU也需要记住，我们将在$(ARCH)/cpu/$(CPU)/目录下添加自己的代码

3.2.4 SOC

指基于同一指令集的不同IC，即不同的bsp。

以armv7为例，这个目录下存放了相同指令集，但是不同IC的bsp，习惯上一颗IC使用一个目录，则目录的名字就是SOC，目录存放在arch/arm/cpu/armv7目录下。编译的时候会根据SOC来寻找指定的目录。

除了代码外，还需要完成自己的底层makefile。

3.2.5 Vendor

这是一个目录的名词，位于board目录下，说明了顶层板级方案的添加，用来指明同一颗CPU下的不同方案。习惯上，Vendor根目录下没有代码，而是有下一层目录。具体的内容包括在下级目录中。

3.2.6 Board_name

这就是Vendor目录下的名词，包括了具体的方案内容。不同的IC可以使用相同的Vendor/Board_name的内容。

3.2.7 Options

说明部分，没有实际含义。可以直接留空不写。

3.3 跨平台

跨平台的要点主要有：

1. 合适的bsp接口，可以保持在bsp独立的情况下，驱动层保持不变

2. 不同平台独有的文件，可以在makefile中使用编译宏来区分

3. 文件中如果不同的平台需要使用不同的功能，比如调用不同函数，也可以在文件中使用编译宏来区分

具体如何实现，请参见下一节的举例说明。

3.4 举例说明

为了添加对于a9的支持，需要完成以下的工作。

3.4.1 完成编译支持

在board.cfg文件中新起一行，添加以下内容

a9 arm armv7 sunxi allwinner a9

3.4.2 添加bsp

在arch/arm/cpu/armv7目录下添加a9目录，在目录中添加bsp层支持。

3.4.3 添加bsp头文件

在arch/arm/include/asm/目录下添加arch-a9目录，添加bsp的全部头文件。

3.4.4 添加全局头文件

在include/config目录中，添加文件a9.h。文件内容可以参照目前有的完成。

3.4.5 添加板级代码

在board目录下，添加mtk目录，然后在其中添加sum目录，在里面完成自己需要的板级配置函数。

一般，板级配置函数中，包括了获取内存大小。

对于我们的方案而已，由于采用了外部配置脚本的方式，因此这里的函数很少，主要的有板级初始化(有u-boot初始化调用)，其中可以添加自己的内容，比如扫描分区信息，等等。

由于这个目录下全部是逻辑操作，和硬件无关，因此所有方案/IC可以使用同样的代码。

3.4.6 添加方案独有代码

如果代码可以给所有方案所使用，就不需要在文件对应的makefile中加入任何宏定义。否则，对于方案独有的代码，可以按照如下的格式，修改makefile。

比如，有一个C文件，名为a9.c，需要在配置a9的时候进行编译，否则不应该编译，则makefile中应该如下写法

…

COBJS-$(CONFIG_A9) += a9.o

…

它表示，如果在全局头文件(a9.h)中定义了宏CONFIG_A9，则编译这个文件，否则不编译。

如果一个文件，无论如果都应该编译，则应该写作

…

COBJS-y += a9.o

…

通常，我们都应该在方案的全局头文件中定义方案的宏，比如CONFIG_A9，CONFIG_A8

bsp是为驱动服务的，有必要做到只有bsp做出修改的情况下，保持驱动不变。因此，驱动编写前应该考虑好结构，抽出恰当的接口，使所有bsp提供相同的函数。

如果驱动变化很大，就需要用前面所介绍的编译宏来决定不同的代码是否参与编译。

3.4.8 细分功能

如果一个文件中，某个函数，甚至函数中的某个部分，只有某个平台才能涌动，可以代码中用宏加以区分，比如

…

#ifdef A9_CONFIG

printf(“a9\n”);

#else

printf (“not a9\n”);

#endif

…

但是不推荐这么做，因为可能导致后面维护的时候，漏掉了这些用宏加以区分的代码。

建议的做法是，把不同的地方做成函数调用，然后不同的IC维护各种的代码，最终在makefile中形成统一。

4 其它细节

4.1 编译器路径

u-boot编译的时候，编译器只能使用绝对路径，不能使用相对路径。这是因为编译的时候，将进入到每个目录下之后，再调用编译器。这时候，由于目录层次的变化，最初设定的编译器路径相对关系将失效。

解决方案：

u-boot编译脚本中定义了一个全局宏CURDIR，其实就是`pwd，可以取得u-boot的绝对路径。

由于已知编译器和u-boot的相对路径关系，假设二者处于同一个目录下，其中编译器目录为gcc，则可以在文件arch/arm/cpu/config.mk中，修改如下的代码

原为 CROSS_COMPILE ?= gcc-

修改为 CROSS_COMPILE ?= $(CURDIR)/../gcc/bin/gcc-

由于顶层编译的时候，CURDIR已经转换成了绝对路径，所以这里使用的也是绝对路径，因此编译的时候能够找到编译器。

如果修改为

原为 CROSS_COMPILE ?= gcc-

修改为 CROSS_COMPILE ?= ./../gcc/bin/gcc-

那么，在编译顶层目录的时候正确，但编译下一级目录的时候将报错。这就是因为到了下一级目录，编译器相对关系变成了

CROSS_COMPILE ?= ./../../gcc/bin/gcc-

但是makefile认为没有变化，因此会出现找不到编译器的错误。

4.2 链接脚本参数

原始的u-boot中，编译脚本中的.o都是绝对路径，但是这对于跨平台来说是不合适的。

比如，有必要在uboot的头部添加一个数据用于校验uboot的正确性，原来的做法是

OUTPUT_FORMAT("elf32-littlearm","elf32-littlearm","elf32-littlearm")

OUTPUT_ARCH(arm)

ENTRY(_start)

SECTIONS

{

. = 0x00000000;

. = ALIGN(4);

.head :

{

arch/arm/cpu/armv7/a9/spare_head.o (.data)

}

…

它表示，把arch/arm/cpu/armv7/a9/spare_head.o中的数据段放到head段中。

如前文所述，a9表示了一颗IC的bsp，但是不同的IC有不同的bsp目录，比如a9,a8，等等，总不能一颗IC就自带一个链接脚本。

实际上，合适的做法是

OUTPUT_FORMAT("elf32-littlearm","elf32-littlearm","elf32-littlearm")

OUTPUT_ARCH(arm)

ENTRY(_start)

SECTIONS

{

. = 0x00000000;

. = ALIGN(4);

.head :

{

SOCDIR/spare_head.o (.data)

}

…

SOCDIR是一个路径，它的含义是

SOCDIR=arch/$(ARCH)/cpu /$(SOC)

这样，当选择不同的IC时，也能使用相同的代码结构了。

当然，真正使用的链接脚本中是不能够带宏的。实际上，uboot编译的时候，会根据基本的链接脚本，利用shell语法在uboot根目录下重新生成，这个过程中会执行宏展开，这样，原始定义的宏就能够被识别了。

为了让编译器能够识别这样的符号，需要在在调用的时候，把宏的含义传递给shell。

生成链接脚本的makefile语句是

$(obj)u-boot.lds: $(LDSCRIPT)

$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@

传递的参数就在LDPPFLAGS中。

目前传递的参数如下所示。

$(obj)u-boot.lds: $(LDSCRIPT)

LDPPFLAGS += \

-include $(TOPDIR)/include/u-boot/u-boot.lds.h \

-DCPUDIR=$(CPUDIR) \

-DSOCDIR=$(SOCDIR) \

$(shell $(LD) --version | \

sed -ne 's/GNU ld version $[0-9][0-9]*$\.$[0-9][0-9]*$.*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')

其中，-DSOCDIR表示了SOC所代表的路径。这样，重新生成uboot.lds的时候，就会自动展开成arch/arm/cpu/armv7/a9了。

0 0