当前位置:文档之家› U-BOOT中MAKEFILE详解

U-BOOT中MAKEFILE详解

U-BOOT中MAKEFILE详解
U-BOOT中MAKEFILE详解

U-BOOT详解

U-BOOT是一个LINUX下的工程,在编译之前必须已经安装对应体系结构的交叉编译环境,这里只针对ARM,编译器系列软件为arm-linux-*。

U-BOOT的下载地址: https://www.doczj.com/doc/931227402.html,/projects/u-boot

我下载的是1.1.6版本,一开始在FTP上下载了一个次新版,结果编译失败。1.1.6是没问题的。

u-boot源码结构

解压就可以得到全部u-boot源程序。在顶层目录下有18个子目录,分别存放和管理不同的源程序。这些目录中所要存放的文件有其规则,可以分为3类。

第1类目录与处理器体系结构或者开发板硬件直接相关;

第2类目录是一些通用的函数或者驱动程序;

第3类目录是u-boot的应用程序、工具或者文档。

u-boot的源码顶层目录说明

目录特性解释说明

board 平台依赖存放电路板相关的目录文件,

例如:RPXlite(mpc8xx)、

smdk2410(arm920t)、

sc520_cdp(x86) 等目录

cpu 平台依赖存放CPU相关的目录文件

例如:mpc8xx、ppc4xx、

arm720t、arm920t、 xscale、i386等目录

lib_ppc 平台依赖存放对PowerPC体系结构通用的文件,

主要用于实现PowerPC平台通用的函数

lib_arm 平台依赖存放对ARM体系结构通用的文件,

主要用于实现ARM平台通用的函数

lib_i386 平台依赖存放对X86体系结构通用的文件,

主要用于实现X86平台通用的函数

include 通用头文件和开发板配置文件,

所有开发板的配置文件都在configs目录下

common 通用通用的多功能函数实现

lib_generic 通用通用库函数的实现

net 通用存放网络的程序

fs 通用存放文件系统的程序

post 通用存放上电自检程序

drivers 通用通用的设备驱动程序,主要有以太网接口的驱动

disk 通用硬盘接口程序

rtc 通用 RTC的驱动程序

dtt 通用数字温度测量器或者传感器的驱动examples 应用例程一些独立运行的应用程序的例子,例如helloworld

tools 工具存放制作S-Record或者u-boot格式的映像等工具,

例如mkimage

doc 文档开发使用文档

u-boot的源代码包含对几十种处理器、数百种开发板的支持。可是对于特定的开发板,

配置编译过程只需要其中部分程序。这里具体以S3C2410 & arm920t处理器为例,具体分析S3C2410处理器和开发板所依赖的程序,以及u-boot的通用函数和工具。

编译

以smdk_2410板为例,编译的过程分两部:

# make smdk2410_config

# make

顶层Makefile分析

要了解一个LINUX工程的结构必须看懂Makefile,尤其是顶层的,没办法,UNIX世界就是这么无奈,什么东西都用文档去管理、配置。首先在这方面我是个新手,时间所限只粗浅地看了一些Makefile规则。

以smdk_2410为例,顺序分析Makefile大致的流程及结构如下:

1) Makefile中定义了源码及生成的目标文件存放的目录,目标文件存放目录BUILD_DIR 可以通过make O=dir 指定。如果没有指定,则设定为源码顶层目录。一般编译的时候不指定输出目录,则BUILD_DIR为空。其它目录变量定义如下:

#OBJTREE和LNDIR为存放生成文件的目录,TOPDIR与SRCTREE为源码所在目录OBJTREE := $(if $(BUILD_DIR),$(BUILD_DIR),$(CURDIR))

SRCTREE := $(CURDIR)

TOPDIR := $(SRCTREE)

LNDIR := $(OBJTREE)

export TOPDIR SRCTREE OBJTREE

2)定义变量MKCONFIG:这个变量指向一个脚本,即顶层目录的mkconfig。

Mkconfig源码详解见https://www.doczj.com/doc/931227402.html,/space.php?uid=91306&do=blog&id=6389 MKCONFIG := $(SRCTREE)/mkconfig

export MKCONFIG

在编译U-BOOT之前,先要执行

# make smdk2410_config

smdk2410_config是Makefile的一个目标,定义如下:

smdk2410_config : unconfig

@$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 NULL s3c24x0

unconfig::

@rm -f $(obj)include/config.h $(obj)include/config.mk \

$(obj)board/*/config.tmp $(obj)board/*/*/config.tmp

显然,执行# make smdk2410_config时,先执行unconfig目标,注意不指定输出目标时,obj,src变量均为空,unconfig下面的命令清理上一次执行make *_config时生成的头文件和makefile的包含文件。主要是include/config.h 和include/config.mk文件。

然后才执行命令

@$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 NULL s3c24x0

MKCONFIG 是顶层目录下的mkcofig脚本文件,后面五个是传入的参数。

对于smdk2410_config而言,mkconfig主要做三件事:

在include文件夹下建立相应的文件(夹)软连接,

#如果是ARM体系将执行以下操作:

#ln -s asm-arm asm

#ln -s arch-s3c24x0 asm-arm/arch

#ln -s proc-armv asm-arm/proc

生成Makefile包含文件include/config.mk,内容很简单,定义了四个变量:

ARCH = arm

CPU = arm920t

BOARD = smdk2410

SOC = s3c24x0

生成include/config.h头文件,只有一行:

/* Automatically generated - do not edit */

#include "config/smdk2410.h"

mkconfig脚本文件的执行至此结束,继续分析Makefile剩下部分。

3)包含include/config.mk,其实也就相当于在Makefile里定义了上面四个变量而已。

4) 指定交叉编译器前缀:

ifeq ($(ARCH),arm)#这里根据ARCH变量,指定编译器前缀。

CROSS_COMPILE = arm-linux-

endif

5)包含config.mk:

#包含顶层目录下的config.mk,这个文件里面主要定义了交叉编译器及选项和编译规则

# load other configuration

include $(TOPDIR)/config.mk

下面分析config.mk的内容:

@包含体系,开发板,CPU特定的规则文件:

ifdef ARCH #指定预编译体系结构选项

sinclude $(TOPDIR)/$(ARCH)_config.mk # include architecture dependend rules

endif

ifdef CPU #定义编译时对齐,浮点等选项

sinclude $(TOPDIR)/cpu/$(CPU)/config.mk # include CPU specific rules endif

ifdef SOC #没有这个文件

sinclude $(TOPDIR)/cpu/$(CPU)/$(SOC)/config.mk #

include SoC specific rules

endif

ifdef BOARD #指定特定板子的镜像连接时的内存基地址,重要!

sinclude $(TOPDIR)/board/$(BOARDDIR)/config.mk # include board specific rules

endif

@定义交叉编译链工具

# Include the make variables (CC, etc...)

#

AS = $(CROSS_COMPILE)as

LD = $(CROSS_COMPILE)ld

CC = $(CROSS_COMPILE)gcc

CPP = $(CC) -E

AR = $(CROSS_COMPILE)ar

NM = $(CROSS_COMPILE)nm

STRIP = $(CROSS_COMPILE)strip

OBJCOPY = $(CROSS_COMPILE)objcopy

OBJDUMP = $(CROSS_COMPILE)objdump

RANLIB = $(CROSS_COMPILE)RANLIB

@定义AR选项ARFLAGS,调试选项DBGFLAGS,优化选项OPTFLAGS 预处理选项CPPFLAGS,C编译器选项CFLAGS,连接选项LDFLAGS

LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE) $(PLATFORM_LDFLAGS) #指定了起始地址TEXT_BASE

@指定编译规则:

$(obj)%.s: %.S

$(CPP) $(AFLAGS) -o $@ $<

$(obj)%.o: %.S

$(CC) $(AFLAGS) -c -o $@ $<

$(obj)%.o: %.c

$(CC) $(CFLAGS) -c -o $@ $<

回到顶层makefile文件:

6)U-boot需要的目标文件。

OBJS = cpu/$(CPU)/start.o # 顺序很重要,start.o必须放第一位

7)需要的库文件:

LIBS = lib_generic/libgeneric.a

LIBS += board/$(BOARDDIR)/lib$(BOARD).a

LIBS += cpu/$(CPU)/lib$(CPU).a

ifdef SOC

LIBS += cpu/$(CPU)/$(SOC)/lib$(SOC).a

endif

LIBS += lib_$(ARCH)/lib$(ARCH).a

LIBS += fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a

fs/jffs2/libjffs2.a \

fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a

LIBS += net/libnet.a

LIBS += disk/libdisk.a

LIBS += rtc/librtc.a

LIBS += dtt/libdtt.a

LIBS += drivers/libdrivers.a

LIBS += drivers/nand/libnand.a

LIBS += drivers/nand_legacy/libnand_legacy.a

LIBS += drivers/sk98lin/libsk98lin.a

LIBS += post/libpost.a post/cpu/libcpu.a

LIBS += common/libcommon.a

LIBS += $(BOARDLIBS)

LIBS := $(addprefix $(obj),$(LIBS))

.PHONY : $(LIBS)

根据上面的include/config.mk文件定义的ARCH、CPU、BOARD、SOC这些变量。硬件平台依赖的目录文件可以根据这些定义来确定。SMDK2410平台相关目录及对应生成的库文件如下。

board/smdk2410/ :库文件board/smdk2410/libsmdk2410.a

cpu/arm920t/ :库文件cpu/arm920t/libarm920t.a

cpu/arm920t/s3c24x0/ : 库文件cpu/arm920t/s3c24x0/libs3c24x0.a

lib_arm/ : 库文件lib_arm/libarm.a

include/asm-arm/ :下面两个是头文件。

include/configs/smdk2410.h

8)最终生成的各种镜像文件:

ALL = $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map

$(U_BOOT_NAND)

all: $(ALL)

$(obj)u-boot.hex: $(obj)u-boot

$(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@

$(obj)u-boot.srec: $(obj)u-boot

$(OBJCOPY) ${OBJCFLAGS} -O srec $< $@

$(obj)u-boot.bin: $(obj)u-boot

$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@

#这里生成的是U-boot 的ELF文件镜像

$(obj)u-boot: depend version $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT) UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) |sed -n -e

''''''''''''''''''''''''''''''''s/.*\(__u_boot_cmd_.*\)/-u\1/p'''''' ''''''''''''''''''''''''''|sort|uniq`;\

cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \

--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \

-Map u-boot.map -o u-boot

分析一下最关键的u-boot ELF文件镜像的生成:

@依赖目标depend :生成各个子目录的.depend文件,.depend列出每个目标文件的依赖文件。生成方法,调用每个子目录的make _depend。depend dep:

for dir in $(SUBDIRS) ; do $(MAKE) -C $$dir _depend ; done

@依赖目标version:生成版本信息到版本文件VERSION_FILE中。

version:

@echo -n "#define U_BOOT_VERSION \"U-Boot " > $(VERSION_FILE); \ echo -n "$(U_BOOT_VERSION)" >> $(VERSION_FILE); \

echo -n $(shell $(CONFIG_SHELL) $(TOPDIR)/tools/setlocalversion \ $(TOPDIR)) >> $(VERSION_FILE); \

echo "\"" >> $(VERSION_FILE)

@伪目标SUBDIRS: 执行tools ,examples ,post,post\cpu 子目录下面的make 文件。

SUBDIRS = tools \

examples \

post \

post/cpu

.PHONY : $(SUBDIRS)

$(SUBDIRS):

$(MAKE) -C $@ all

@依赖目标$(OBJS),即cpu/start.o

$(OBJS):

$(MAKE) -C cpu/$(CPU) $(if $(REMOTE_BUILD),$@,$(notdir $@))

@依赖目标$(LIBS),这个目标太多,都是每个子目录的库文件*.a ,通过执行相应子目录下的make来完成:

$(LIBS):

$(MAKE) -C $(dir $(subst $(obj),,$@))

@依赖目标$(LDSCRIPT):

LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds

LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE) $(PLATFORM_LDFLAGS)

对于smdk2410,LDSCRIPT即连接脚本文件是board/smdk2410/u-boot.lds,定义了连接时各个目标文件是如何组织的。内容如下:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") /*OUTPUT_FORMAT("elf32-arm", "elf32-arm", "elf32-arm")*/

OUTPUT_ARCH(arm)

ENTRY(_start)

SECTIONS

{

. = 0x00000000;

. = ALIGN(4);

.text :/*.text的基地址由LDFLAGS中-Ttext $(TEXT_BASE)指定*/

{ /*smdk2410指定的基地址为0x33f80000*/

cpu/arm920t/start.o (.text) /*start.o为首*/

*(.text)

}

. = ALIGN(4);

.rodata : { *(.rodata) }

. = ALIGN(4);

.data : { *(.data) }

. = ALIGN(4);

.got : { *(.got) }

. = .;

__u_boot_cmd_start = .;

.u_boot_cmd : { *(.u_boot_cmd) }

__u_boot_cmd_end = .;

. = ALIGN(4);

__bss_start = .;

.bss : { *(.bss) }

_end = .;

}

@执行连接命令:

cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \

--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \

-Map u-boot.map -o u-boot

其实就是把start.o和各个子目录makefile生成的库文件按照LDFLAGS连接在一起,生成ELF文件u-boot 和连接时内存分配图文件u-boot.map。

9)对于各子目录的makefile文件,主要是生成*.o文件然后执行AR生成对应的库文件。如lib_generic文件夹Makefile:

LIB = $(obj)libgeneric.a

COBJS = bzlib.o bzlib_crctable.o bzlib_decompress.o \

bzlib_randtable.o bzlib_huffman.o \

crc32.o ctype.o display_options.o ldiv.o \

string.o vsprintf.o zlib.o

SRCS := $(COBJS:.o=.c)

OBJS := $(addprefix $(obj),$(COBJS))

$(LIB): $(obj).depend $(OBJS) #项层Makefile执行make libgeneric.a

$(AR) $(ARFLAGS) $@ $(OBJS)

整个makefile剩下的内容全部是各种不同的开发板的*_config:目标的定义了。概括起来,工程的编译流程也就是通过执行执行一个make *_config传入ARCH,CPU,BOARD,SOC参数,mkconfig根据参数将include头文件夹相应的头文件夹连接好,生成config.h。然后执行make分别调用各子目录的makefile 生成所有的obj文件和obj库文件*.a. 最后连接所有目标文件,生成镜像。不同格式的镜像都是调用相应工具由elf镜像直接或者间接生成的。

剩下的工作就是分析U-Boot源代码了。

手动建立makefile简单实例解析

手动建立makefile简单实例解析 假设我们有一个程序由5个文件组成,源代码如下:/*main.c*/ #include "mytool1.h" #include "mytool2.h" int main() { mytool1_print("hello mytool1!"); mytool2_print("hello mytool2!"); return 0; } /*mytool1.c*/ #include "mytool1.h" #include void mytool1_print(char *print_str) { printf("This is mytool1 print : %s ",print_str); } /*mytool1.h*/ #ifndef _MYTOOL_1_H #define _MYTOOL_1_H void mytool1_print(char *print_str); #endif /*mytool2.c*/ #include "mytool2.h" #include void mytool2_print(char *print_str) { printf("This is mytool2 print : %s ",print_str); }

/*mytool2.h*/ #ifndef _MYTOOL_2_H #define _MYTOOL_2_H void mytool2_print(char *print_str); #endif 首先了解一下make和Makefile。GNU make是一个工程管理器,它可以管理较多的文件。我所使用的RedHat 9.0的make版本为GNU Make version 3.79.1。使用make的最大好处就是实现了“自动化编译”。如果有一个上百个文件的代码构成的项目,其中一个或者几个文件进行了修改,make就能够自动识别更新了的文件代码,不需要输入冗长的命令行就可以完成最后的编译工作。make执行时,自动寻找Makefile(makefile)文件,然后执行编译工作。所以我们需要编写Makefile文件,这样可以提高实际项目的工作效率。 在一个Makefile中通常包含下面内容: 1、需要由make工具创建的目标体(target),通常是目标文件或可执行文件。 2、要创建的目标体所依赖的文件(dependency_file)。 3、创建每个目标体时需要运行的命令(command)。 格式如下: target:dependency_files command target:规则的目标。通常是程序中间或者最后需要生成的文件名,可以是.o文件、也可以是最后的可执行程序的文件名。另外,目标也可以是一个make执行的动作的名称,如目标“clean”,这样的目标称为“伪目标”。 dependency_files:规则的依赖。生成规则目标所需要的文件名列表。通常一个目标依赖于一个或者多个文件。 command:规则的命令行。是make程序所有执行的动作(任意的shell命令或者可在shell下执行的程序)。一个规则可以有多个命令行,每一条命令占一行。注意:每一个命令行必须以[Tab]字符开始,[Tab]字符告诉make此行是一个命令行。make按照命令完成相应的动作。这也是书写Makefile中容易产生,而且比较隐蔽的错误。命令就是在任何一个目标的依赖文件发生变化后重建目标的动作描述。一个目标可以没有依赖而只有动作(指定的命令)。比如Makefile中的目标“clean”,此目标没有依赖,只有命令。它所指定的命令用来删除make过程产生的中间文件(清理工作)。 在Makefile中“规则”就是描述在什么情况下、如何重建规则的目标文件,通常规则

linux驱动的Makefile分析

第6行,判断KERNELRELEASE是否为空,该变量是描述内核版本的字符串。只有执行make命令的当前目录为内核源代码目录时,该变量才不为空字符。 第7、8行定义了KERNELDIR和PWD变量。KERNELDIR是内核路径变量,PWD是由执行pwd命令得到的当前模块路径。 第11行make的语法是”Make –C 内核路径M=模块路径modules”,该语法会执行内核模块的编译 第13行是将模块安装到对应的路径中,当在命令执行make modules_install时,执行该命令,其他时候不执行 第24行,意思是将hello.o编译成hello.ko模块。如果要编译其他模块时,只要将hello.o中的hello改成模块的文件名就可以了 Makefile的执行过程: 执行make命令后,将进入Makefile文件。此时KERNELRELEASE变量为空,此时是第一次进入Makefile文件。当执行完变量赋值代码后,会根据make参数执行不同的逻辑。 如下: make modules_install 命令,将执行13、15行将模块安装到操作系统中。 make clean命令,会删除目录中的所有临时文件。 make命令,会执行10、11行编译模块。首先$(MAKE) -C $(KERNELDIR) M=$(PWD) modules 中的-C $(KERNELDIR)选项,会使编译器进入内核源码目录/home/zzc/linux-2.6.31,读取Makefile文件,从中得到一些信息,例如变量KERNELRELEASE将在这里赋值。当内核源码目录中的Makefile文件读取完成后,编译器会根据选项M=$(PWD)第二次进入模块所在的目录,并再一次执行Makefie文件。当第二次执行Makefile文件时,变量KERNELRELEASE

u-boot启动分析

背景: Board →ar7240(ap93) Cpu →mips 1、首先弄清楚什么是u-boot Uboot是德国DENX小组的开发,它用于多种嵌入式CPU的bootloader程序, uboot不仅支持嵌入式linux系统的引导,当前,它还支持其他的很多嵌入式操作系统。 除了PowerPC系列,还支持MIPS,x86,ARM,NIOS,XScale。 2、下载完uboot后解压,在根目录下,有如下重要的信息(目录或者文件): 以下为为每个目录的说明: Board:和一些已有开发板有关的文件。每一个开发板都以一个子目录出现在当前目录中,子目录存放和开发板相关的配置文件。它的每个子文件夹里都有如下文件(以ar7240/ap93为例): Makefile Config.mk Ap93.c 和板子相关的代码 Flash.c Flash操作代码 u-boot.lds 对应的链接文件 common:实现uboot命令行下支持的命令,每一条命令都对应一个文件。例如bootm命令对应就是cmd_bootm.c cpu:与特定CPU架构相关目录,每一款Uboot下支持的CPU在该目录下对应一个子目录,比如有子目录mips等。它的每个子文件夹里都有入下文件: Makefile Config.mk Cpu.c 和处理器相关的代码s Interrupts.c 中断处理代码 Serial.c 串口初始化代码 Start.s 全局开始启动代码 Disk:对磁盘的支持

Doc:文档目录。Uboot有非常完善的文档。 Drivers:Uboot支持的设备驱动程序都放在该目录,比如网卡,支持CFI的Flash,串口和USB等。 Fs:支持的文件系统,Uboot现在支持cramfs、fat、fdos、jffs2和registerfs。 Include:Uboot使用的头文件,还有对各种硬件平台支持的汇编文件,系统的配置文件和对文件系统支持的文件。该目下configs目录有与开发板相关的配置文件,如 ar7240_soc.h。该目录下的asm目录有与CPU体系结构相关的头文件,比如说mips 对应的有asm-mips。 Lib_xxx:与体系结构相关的库文件。如与ARM相关的库放在lib_arm中。 Net:与网络协议栈相关的代码,BOOTP协议、TFTP协议、RARP协议和NFS文件系统的实现。 Tools:生成Uboot的工具,如:mkimage等等。 3、mips架构u-boot启动流程 u-boot的启动过程大致做如下工作: 1、cpu初始化 2、时钟、串口、内存(ddr ram)初始化 3、内存划分、分配栈、数据、配置参数、以及u-boot代码在内存中的位置。 4、对u-boot代码作relocate 5、初始化malloc、flash、pci以及外设(比如,网口) 6、进入命令行或者直接启动Linux kernel 刚一开始由于参考网上代码,我一个劲的对基于smdk2410的板子,arm926ejs的cpu看了N 久,启动过程和这个大致相同。 整个启动中要涉及到四个文件: Start.S →cpu/mips/start.S Cache.S →cpu/mips/cache.S Lowlevel_init.S →board/ar7240/common/lowlevel_init.S Board.c →lib_mips/board.c 整个启动过程分为两个阶段来看: Stage1:系统上电后通过汇编执行代码 Stage2:通过一些列设置搭建了C环境,通过汇编指令跳转到C语言执行. Stage1: 程序从Start.S的_start开始执行.(至于为什么,参考u-boot.lds分析.doc) 先查看start.S文件吧!~ 从_start标记开始会看到一长串莫名奇妙的代码:

LAMMPS手册-中文版讲解之欧阳家百创编

LAMMPS手册-中文解析 一、 欧阳家百(2021.03.07) 二、简介 本部分大至介绍了LAMMPS的一些功能和缺陷。 1.什么是LAMMPS? LAMMPS是一个经典的分子动力学代码,他可以模拟液体中的粒子,固体和汽体的系综。他可以采用不同的力场和边界条件来模拟全原子,聚合物,生物,金属,粒状和粗料化体系。LAMMPS可以计算的体系小至几个粒子,大到上百万甚至是上亿个粒子。 LAMMPS可以在单个处理器的台式机和笔记本本上运行且有较高的计算效率,但是它是专门为并行计算机设计的。他可以在任何一个按装了C++编译器和MPI的平台上运算,这其中当然包括分布式和共享式并行机和Beowulf型的集群机。 LAMMPS是一可以修改和扩展的计算程序,比如,可以加上一些新的力场,原子模型,边界条件和诊断功能等。 通常意义上来讲,LAMMPS是根据不同的边界条件和初始条件对通过短程和长程力相互作用的分子,原子和宏观粒子集合对它们的牛顿运动方程进行积分。高效率计算的LAMMPS通过采用相邻清单来跟踪他们邻近的粒子。这些清单是根据粒子间的短程互拆力的大小进行优化过的,目的是防止局部粒子密度过高。在

并行机上,LAMMPS采用的是空间分解技术来分配模拟的区域,把整个模拟空间分成较小的三维小空间,其中每一个小空间可以分配在一个处理器上。各个处理器之间相互通信并且存储每一个小空间边界上的”ghost”原子的信息。LAMMPS(并行情况)在模拟3维矩行盒子并且具有近均一密度的体系时效率最高。 2.LAMMPS的功能 总体功能: 可以串行和并行计算 分布式MPI策略 模拟空间的分解并行机制 开源 高移植性C++语言编写 MPI和单处理器串行FFT的可选性(自定义) 可以方便的为之扩展上新特征和功能 只需一个输入脚本就可运行 有定义和使用变量和方程完备语法规则 在运行过程中循环的控制都有严格的规则 只要一个输入脚本试就可以同时实现一个或多个模拟任务 粒子和模拟的类型: (atom style命令) 原子 粗粒化粒子 全原子聚合物,有机分子,蛋白质,DNA

LINUX编程 Makefile中的变量详解应用

第六章:Makefile中的变量 -------------------------------------------------------------------------------- 在Makefile中,变量就是一个名字(像是C语言中的宏),代表一个文本字符串(变量的值)。在Makefile的目标、依赖、命令中引用一个变量的地方,变量会被它的值所取代(与C语言中宏引用的方式相同,因此其他版本的make也把变量称之为“宏”)。在Makefile中变量的特征有以下几点: 1. Makefile中变量和函数的展开(除规则的命令行以外),是在make读取makefile文件时进行的,这里的变量包括了使用“=”定义和使用指示符“define”定义的。 2. 变量可以用来代表一个文件名列表、编译选项列表、程序运行的选项参数列表、搜索源文件的目录列表、编译输出的目录列表和所有我们能够想到的事物。 3. 变量名是不包括“:”、“#”、“=”、前置空白和尾空白的任何字符串。需要注意的是,尽管在GNU make中没有对变量的命名有其它的限制,但定义一个包含除字母、数字和下划线以外的变量的做法也是不可取的,因为除字母、数字和下划线以外的其它字符可能会在以后的make版本中被赋予特殊含义,并且这样命名的变量对于一些shell来说不能作为环境变量使用。 4. 变量名是大小写敏感的。变量“foo”、“Foo”和“FOO”指的是三个不同的变量。Makefile 传统做法是变量名是全采用大写的方式。推荐的做法是在对于内部定义定义的一般变量(例如:目标文件列表objects)使用小写方式,而对于一些参数列表(例如:编译选项CFLAGS)采用大写方式,这并不是要求的。但需要强调一点:对于一个工程,所有Makefile中的变量命名应保持一种风格,否则会显得你是一个蹩脚的程序员(就像代码的变量命名风格一样)。 5. 另外有一些变量名只包含了一个或者很少的几个特殊的字符(符号)。称它们为自动化变量。像“$<”、“$@”、“$?”、“$*”等。 6.1 变量的引用 当我们定义了一个变量之后,就可以在Makefile的很多地方使用这个变量。变量的引用方式是:使用“$(VARIABLE_NAME)”或者“${ VARIABLE_NAME }”来引用一个变量的定义。例如:“$(foo) ”或者“${foo}”就是取变量“foo”的值。美元符号“$”在Makefile中有特殊的含义,所有在命令或者文件名中使用“$”时需要用两个美元符号“$$”来表示。对一个变量的引用可以在Makefile的任何上下文中,目标、依赖、命令、绝大多数指示符和新变量的赋值中。这里有一个例子,其中变量保存了所有.o文件的列表: objects = program.o foo.o utils.o program : $(objects) cc -o program $(objects)

嵌入式Linux之我行 史上最牛最详细的uboot移植,不看别后悔

嵌入式Linux之我行——u-boot-2009.08在2440上的移植详解(一) 嵌入式Linux之我行,主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验,二希望能给想入门嵌入式Linux 的朋友提供方便。如有错误之处,谢请指正。 ?共享资源,欢迎转载:https://www.doczj.com/doc/931227402.html, 一、移植环境 ?主机:VMWare--Fedora 9 ?开发板:Mini2440--64MB Nand,Kernel:2.6.30.4 ?编译器:arm-linux-gcc-4.3.2.tgz ?u-boot:u-boot-2009.08.tar.bz2 二、移植步骤 本次移植的功能特点包括: ?支持Nand Flash读写 ?支持从Nor/Nand Flash启动 ?支持CS8900或者DM9000网卡 ?支持Yaffs文件系统 ?支持USB下载(还未实现) 1.了解u-boot主要的目录结构和启动流程,如下图。

u-boot的stage1代码通常放在cpu/xxxx/start.S文件中,他用汇编语言写成;u-boot的stage2代码通常放在lib_xxxx/board.c文件中,他用C语言写成。各个部分的流程图如下:

2. 建立自己的开发板项目并测试编译。 目前u-boot对很多CPU直接支持,可以查看board目录的一些子目录,如:board/samsung/目录下就是对三星一些ARM 处理器的支持,有smdk2400、smdk2410和smdk6400,但没有2440,所以我们就在这里建立自己的开发板项目。 1)因2440和2410的资源差不多,主频和外设有点差别,所以我们就在board/samsung/下建立自己开发板的项目,取名叫my2440 2)因2440和2410的资源差不多,所以就以2410项目的代码作为模板,以后再修改

模块驱动笔记

驱动模块装载全纪录 模块驱动源代码demo.c如下: /* ************************************************************************* * *my first linux driver * ************************************************************************* */ //#ifndef_KERNEL_ //#define_KERNEL_/*缂..杩..??/ //#endif #ifdef MODULE/*浠ユā?..寮.?璇./ #include #ifdef CONFIG_DEVFS_FS #include/*璁惧??.欢绯荤?澶存.浠?/ #endif #include/*初始化相关头文件*/ #include/*与printk()等函数有关的头文件*/ #include/*与kmalloc()等函数有关的头文件*/ #include/*与文件系统有关的头文件*/ #include/*错误代码处理头文件error codes*/ #include/*数据类型头文件size_t*/ #include/*与进程调度相关的头文件*/ #include/*O_ACCMODE*/ #include/*COPY_TO_USER*/ #include/*cli(),*_flag*/ #define DEVICE_NAME"ZJD demo"/*该驱动的设备名*/ #define DEMORAW_MINOR1 #define DEMO_Devfs_path"demo/0"/*驱动目录*/ //#define demo_MAJOR254/*主设备号*/ //#define demo_MINOR0/*次设备号*/ static int demoMajor=0;

make_Makefile 结构分析

Makefile结构分析 -----uClinux (2.6.x内核)系统映像过程 刘江欧阳昭暐吕熙隆 1、源代码文件及目录构成 解压缩uClinux-dist-20070130.tar.gz压缩文件,在uClinux-dist原始子目录下主要有:config、Bin、linux-2.4.x、linux-2.6.x 、lib、tools、Include、user和vendors,以及文件Makefile。另外,在编译后生成子目录images和romfs,以及文件autoconfig.h、config.in和两个隐含文件:.config和.depend。 config子目录包含文件及下一级子目录,如 config.in、configure.help、Fixconfig、Makefile、 Mkconfig、Setconfig所有这些文件及子目录 Scripts均与系统配置有关; linux-2.6.x子目录是嵌入式操作系统 uClinux-2.6.x的核心目录,包括下一级子目录 arch、include、init、drivers、fs、ipc、kernel、 lib、Mm、scripts和关键文件Makefile、 rules.make,编译后还要生成新文件romfs.o、linux 和system.map;lib子目录为嵌入式操作系统提供 压缩和改进了的函数库支持;tools子目录包含 romfs-inst.sh文件,通过调用此文件,可以把目录 或文件加入到romfs子目录中;user子目录包含各 种驱动程序文件目录,根据用户的配置情况,不同的 驱动程序会被编译进最后形成的操作系统中; vendors子目录包括与特定硬件平台相关的分类目录 组。目录结构如图1所示。 Makefile的详细介绍情况在 uClinux-dist\linux-2.6.x\Documentation\kbuil d中,如图2所示。图1、目录结构即Linux 内核中的 Makefile 以及与 Makefile 直接相关的文件有:

Linux系统的Makefile和Kconfig及模块简介

Linux系统的Makefile、Kconfig和模块 1Makefile 1.1Makefile组织层次 Linux的Make体系由如下几部分组成: ?顶层Makefile 顶层Makefile通过读取配置文件,递归编译内核代码树的相关目录,从而产生两个重要的目标文件:vmlinux和模块。 ?内核相关Makefile 位于arch/$(ARCH) 目录下,为顶层Makefile提供与具体硬件体系结构相关的信息。?公共编译规则定义文件。 包括Makefile.build 、Makefile.clean、Makefile.lib、Makefile.host等文件组成。这些文件位于scripts目录中,定义了编译需要的公共的规则和定义。 ?内核配置文件 .config 通过调用make menuconfig或者make xconfig命令,用户可以选择需要的配置来生成期望的目标文件。 ?其他Makefile 主要为整个Makefile体系提供各自模块的目标文件定义,上层Makefile根据它所定义的目标来完成各自模块的编译。 1.2Makefile的使用 在编译内核之前,用户必须首先完成必要的配置。Linux内核提供了数不胜数的功能,支持众多的硬件体系结构,这就需要用户对将要生成的内核进行裁减。内核提供了多种不同的工具来简化内核的配置。 make config,字符界面下命令行工具,这个工具会依次遍历内核所有的配置项,要求用户进行逐项的选择配置。这个工具会耗费用户太多时间,除非万不得以(你的编译主机不支持其他配置工具)一般不建议使用。 make menuconfig,基于ncurse库编制的图形界面工具,一般台式机使用该工具。 make xconfig,基于X11的图形配置工具,一般用于工作站环境。

Makefile 语法分析

Makefile 语法分析第一部分 VERSION = 2 # 给变量VERSION赋值 PATCHLEVEL = 6 # 给变量PATCHLEVEL赋值 SUBLEVEL = 22 # 给变量SUBLEVEL赋值 EXTRAVERSION = .6 # 给变量EXTRAVERSION赋值 NAME = Holy Dancing Manatees, Batman! # 给变量NAME赋值 # *DOCUMENTATION* # To see a list of typical targets execute "make help" # More info can be located in ./README # Comments in this file are targeted only to the developer, do not # expect to learn how to build the kernel reading this file. # Do not: # o use make's built-in rules and variables # (this increases performance and avoid hard-to-debug behavour); # o print "Entering directory ..."; MAKEFLAGS += -rR --no-print-directory # 操作符“+=”的作用是给变量(“+=”前面的MAKEFLAGS)追加值。 # 如果变量(“+=”前面的MAKEFLAGS)之前没有定义过,那么,“+=”会自动变成“=”; # 如果前面有变量(“+=”前面的MAKEFLAGS)定义,那么“+=”会继承于前次操作的赋值符;# 如果前一次的是“:=”,那么“+=”会以“:=”作为其赋值符 # 在执行make时的命令行选项参数被通过变量“MAKEFLAGS”传递给子目录下的make程序。# 对于这个变量除非使用指示符“unexport”对它们进行声明,它们在整个make的执行过程中始终被自动的传递给所有的子make。 # 还有个特殊变量SHELL与MAKEFLAGS一样,默认情况(没有用“unexport”声明)下在整个make的执行过程中被自动的传递给所有的子make。 # # -rR --no-print-directory # -r disable the built-in impilict rules. # -R disable the built-in variable setttings. # --no-print-directory。 # We are using a recursive build, so we need to do a little thinking # to get the ordering right. # # Most importantly: sub-Makefiles should only ever modify files in # their own directory. If in some directory we have a dependency on # a file in another dir (which doesn't happen often, but it's often # unavoidable when linking the built-in.o targets which finally # turn into vmlinux), we will call a sub make in that other dir, and

AM335x uboot spl分析

AM335x uboot spl分析 芯片到uboot启动流程 ROM → SPL→ uboot.img 简介 在335x 中ROM code是第一级的bootlader。mpu上电后将会自动执行这里的代码,完成部分初始化和引导第二级的bootlader,第二级的bootlader引导第三级bootader,在 ti官方上对于第二级和第三级的bootlader由uboot提供。 SPL To unify all existing implementations for a secondary program loader (SPL) and to allow simply adding of new implementations this generic SPL framework has been created. With this framework almost all source files for a board can be reused. No code duplication or symlinking is necessary anymore. 1> Basic ARM initialization 2> UART console initialization 3> Clocks and DPLL locking (minimal) 4> SDRAM initialization 5> Mux (minimal) 6> BootDevice initialization(based on where we are booting from.MMC1/MMC2/Nand/Onenand) 7> Bootloading real u-boot from the BootDevice and passing control to it. uboot spl源代码分析 一、makefile分析 打开spl文件夹只有一个makefile 可见spl都是复用uboot原先的代码。 主要涉及的代码文件为u-boot-2011.09-psp04.06.00.03/arch/arm/cpu/armv7 u-boot-2011.09-psp04.06.00.03/arch/arm/lib u-boot-2011.09-psp04.06.00.03/drivers LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-spl.lds 这个为链接脚本 __image_copy_end _end 三、代码解析 __start 为程序开始(arch/arm/cpu/armv7/start.S) .globl _start 这是在定义u-boot的启动定义入口点,汇编程序的缺省入口是 start 标号,用户也可以在连接脚本文件中用ENTRY标志指明其它入口点。

linux设备驱动程序的hello模块编译过程

linux设备驱动程序的hello模块编译过程 今天把linux设备驱动程序(第三版)的第一个模块hello模块编译通过了,这个东西卡了我好长时间了,期间我又花了很多时间去看linux程序设计(第二版),终于今天机械性地完成了这个试验。 编译环境:虚拟机linux2.6.18内核,(如果内核不是2.6的,可以参考我的内核升级过程,另外一篇文章有详细记录) 源程序hello.c: ///////////////////////////////////////////////////////////////////// /////// #include #include #include MODULE_LICENSE("Dual BSD/GPL"); static int hello_init(void) //有的上面定义的是init_modules(void)是通不过编译的 { printk(KERN_ALERT "Hello, world\n"); return 0; } static void hello_exit(void) { printk(KERN_ALERT "Goodbye, world\n"); } module_init(hello_init); module_exit(hello_exit); ///////////////////////////////////////////////////////////////////// /// Makefile的内容: ifneq ($(KERNELRELEASE),) obj-m := hello.o else KDIR:=/lib/modules/$(shell uname -r)/build PWD:=$(shell pwd)

uboot版本文件结构

uboot版本文件结构的更新改变 分类:ARM2011-09-22 12:57 339人阅读评论(0) 收藏举报本来是开始分析uboot代码的,但是无论是教材还是网上资料都对于我最新下的uboot原码结构不同,对于还是小白的我不容易找到相应的文件,下面是uboot版本中文件组织结构的改变,,,,, u-boot版本情况 网站:http://ftp.denx.de/pub/u-boot/ 1、版本号变化: 2008年8月及以前 按版本号命名:u-boot-1.3.4.tar.bz2(2008年8月更新) 2008年8月以后均按日期命名。 目前最新版本:u-boot-2011.06.tar.bz2(2011年6月更新) 2、目录结构变化: u-boot目录结构主要经历过2次变化,u-boot版本第一次从u-boot-1.3.2开始发生变化,主要增加了api的内容;变化最大的是第二次,从2010.6版本开始。 u-boot-2010.03及以前版本 ├── api存放uboot提供的接口函数 ├── board根据不同开发板定制的代码,代码也不少 ├── common通用的代码,涵盖各个方面,已命令行处理为主 ├── cpu与体系结构相关的代码,uboot的重头戏 ├── disk磁盘分区相关代码 ├── doc文档,一堆README开头的文件 ├── drivers驱动,很丰富,每种类型的设备驱动占用一个子目录 ├── examples示例程序 ├── fs文件系统,支持嵌入式开发板常见的文件系统 ├── include头文件,已通用的头文件为主 ├── lib_【arch】与体系结构相关的通用库文件 ├── nand_spl NAND存储器相关代码 ├── net网络相关代码,小型的协议栈 ├── onenand_ipl

makefile 中文手册 第六章 _ Makefile中的变量

第六章:Makefile中的变量 在Makefile中,变量是一个名字(像是C语言中的宏),代表一个文本字符串(变量的值)。在Makefile的目标、依赖、命令中引用变量的地方,变量会被它的值所取代(与C语言中宏引用的方式相同,因此其他版本的make也把变量称之为“宏”)。在Makefile中变量有以下几个特征: 1.Makefile中变量和函数的展开(除规则命令行中的变量和函数以外),是在make读取makefile文件时 进行的,这里的变量包括了使用“=”定义和使用指示符“define”定义的。 2.变量可以用来代表一个文件名列表、编译选项列表、程序运行的选项参数列表、搜索源文件的目录列 表、编译输出的目录列表和所有我们能够想到的事物。 3.变量名是不包括“:”、“#”、“=”、前置空白和尾空白的任何字符串。需要注意的是,尽管在GNU make中没有对变量的命名有其它的限制,但定义一个包含除字母、数字和下划线以外的变量的做法也是不可取的,因为除字母、数字和下划线以外的其它字符可能会在make的后续版本中被赋予特殊含义,并且这样命名的变量对于一些shell来说是不能被作为环境变量来使用的。 4.变量名是大小写敏感的。变量“foo”、“Foo”和“FOO”指的是三个不同的变量。Makefile传统做 法是变量名是全采用大写的方式。推荐的做法是在对于内部定义定义的一般变量(例如:目标文件列表objects)使用小写方式,而对于一些参数列表(例如:编译选项CFLAGS)采用大写方式,但这并不是要求的。但需要强调一点:对于一个工程,所有Makefile中的变量命名应保持一种风格,否则会显得你是一个蹩脚的程序员(就像代码的变量命名风格一样)。 5.另外有一些变量名只包含了一个或者很少的几个特殊的字符(符号)。称它们为自动化变量。 像“$<”、“$@”、“$?”、“$*”等。 6.1变量的引用 当我们定义了一个变量之后,就可以在Makefile的很多地方使用这个变量。变量的引用方式 是:“$(VARIABLE_NAME)”或者“${ VARIABLE_NAME }”来引用一个变量的定义。例如:“$(foo)”或者“${foo}”就是取变量“foo”的值。美元符号“$”在Makefile中有特殊的含义,所有在命令或者文件名中使用“$”时需要用两个美元符号“$$”来表示。对一个变量的引用可以在Makefile的任何上下文中,目标、依赖、命令、绝大多数指示符和新变量的赋值中。这里有一个例子,其中变量保存了所有.o文件的列表: objects = program.o foo.o utils.o program : $(objects) cc -o program $(objects) $(objects) : defs.h 变量引用的展开过程是严格的文本替换过程,就是说变量值的字符串被精确的展开在变量被引用的地方。因此规则: foo = c prog.o : prog.$(foo) $(foo) $(foo) -$(foo) prog.$(foo) 被展开后就是:

LN电机驱动模块详解

L298N电机驱动器使用说明书 注意:本说明书中添加超链接的按CTRL并点击连接,即可看到内容。

1.信号电源引入端 2.控制信号输入端 3.直流电机调速PWM脉宽信号输入 端。(控制步进电机或者控制直流电机 无需调速时,保持此状态) 4.控制信号指示灯 5. 光电隔离(抗干扰) 6.核心芯片(L298N) 7.二极管桥式续流保护8.电源滤波9.端子接线 实例一:步进电机的控制实例

步进电机是数字控制电机,它将脉冲信号转变成角位移,即给一个脉冲信号,步进电机就转动一个角度,因此非常适合于单片机控制。步进电机可分为反应式步进电机(简称VR)、永磁式步进电机(简称PM)和混合式步进电机(简称HB)。 一、步进电机最大特点是: 1、它是通过输入脉冲信号来进行控制的。 2、电机的总转动角度由输入脉冲数决定。 3、电机的转速由脉冲信号频率决定。 二、步进电机的驱动电路 根据控制信号工作,控制信号由单片机产生。(或者其他信号源) 三、基本原理作用如下: 两相四拍工作模式时序图:

(1)控制换相顺序 1、通电换相这一过程称为脉冲分配。 例如: 1、两相四线步进电机的四拍工作方式,其各相通电顺序为(A-B-A’ -B’)通电控制脉冲必须严格按照这一顺序分别控制A,B相的通断。) 2、两相四线步进电机的四拍工作方式,其各相通电顺序为: (A-AB-B-BA’-A’-A’B’-B’-B’ 依次循环。(出于对力矩、平稳、噪音及减少角度等方面考虑。往往采用八拍工作方式) (2)控制步进电机的转向 如果给定工作方式正序换相通电,步进电机正转,如果按反序通电换相,则电机就反转。如:正转通电顺序是:(A-B-A’-B’依次循环。)则反转的通电顺序是:(B‘-A’-B-A依次循环。) 参考下例:

uboot_freescale_imx51_start.s_详解

/* * *Purpose: the document is used to learn detailed information aboutimx51 cpu start.S, *referring to some documents on websites. *file address: U-boot-2009.08/Cpu/Arm_cortexa8/start.S * * writer: xfhai 2011.7.22 * *Instruction: *1.@xxxx : indicates annotation *2./***** *** *****/ : stand for code in my files *3.instructions refers to code not included in my file * */ Section 1: uboot overview 大多数bootloader都分为stage1和stage2两部分,u-boot也不例外。依赖于CPU体系结构的代码(如设备初始化代码等)通常都放在stage1且可以用汇编语言来实现,而stage2则通常用C语言来实现,这样可以实现复杂的功能,而且有更好的可读性和移植性。 1、Stage1 start.S代码结构 u-boot的stage1代码通常放在start.S文件中,他用汇编语言写成,其主要代码部分如下:==> (1)定义入口。由于一个可执行的Image必须有一个入口点,并且只能有一个全局入口,通常这个入口放在ROM(Flash)的0x0地址,因此,必须通知编译器以使其知道这个入口,该工作可通过修改连接器脚本来完成。 ==>(2)设置异常向量(Exception Vector)。 ==>(3)设置CPU的速度、时钟频率及终端控制寄存器。 ==>(4)初始化内存控制器。 ==>(5)将ROM中的程序复制到RAM中。 ==>(6)初始化堆栈。 ==>(7)转到RAM中执行,该工作可使用指令ldr pc来完成。 2、Stage2 C语言代码部分 lib_arm/board.c中的start arm boot是C语言开始的函数也是整个启动代码中C语言的主函数,同时还是整个u-boot(armboot)的主函数,该函数只要完成如下操作: ==>(1)调用一系列的初始化函数。 ==>(2)初始化Flash设备。 ==>(3)初始化系统内存分配函数。 ==>(4)如果目标系统拥有NAND设备,则初始化NAND设备。 ==>(5)如果目标系统有显示设备,则初始化该类设备。 ==>(6)初始化相关网络设备,填写IP、MAC地址等。 ==>(7)进去命令循环(即整个boot的工作循环),接受用户从串口输入的命令,然后进行相应的工作。

openwrt顶层Makefile分析

openwrt 这里主要介绍openwrt的主Makefile,并未对各个目录下的Makefile和相关文件进行介绍。 在Makefile里是两个主要的分支,由if语句根据OPENWRT_BUILD的值进行不同的处理。第一个部分主要是执行编译前的准备,第二个部分是执行编译。 打开Makefile文件,可以看到默认的make目标world,这个目标没有依赖文件和执行命令。 执行make的时候,首先进入第一个部分,此时OPENWRT_BUILD的值为0,然后将OPENWRT_BUILD的值赋为1,在这里用到了override指示符,override指示符的作用的忽略make命令行的参数的赋值,可以对该变量进行赋值。 载入include下的相关文件,在toplevel.mk可以看到 %:: @+$(PREP_MK) $(NO_TRACE_MAKE) -r -s prereq @+$(SUBMAKE) -r $@ 默认的目标就会执行这里。 在toplevel.mk的顶部定义了PREP_MK= OPENWRT_BUILD= QUIET=0,将OPENWRT_BUILD的值赋为0。 在执行@+$(PREP_MK) $(NO_TRACE_MAKE) -r -s prereq命令的时候,在make命令行里有$(PREP_MK)变量,而由于OPENWRT_BUILD的值为0,在verbose.mk文件里NO_TRACE_MAKE := $(MAKE) V=99,所以会执行顶层 目录的Makefile第一个分支部分的目标prereq,即toplevel.mk文件中的目标prereq: prereq:: prepare-tmpinfo .config @+$(MAKE) -r -s tmp/.prereq-build $(PREP_MK) @+$(NO_TRACE_MAKE) -r -s $@ 这里会进行一些编译前的准备工作,然后执行@+$(NO_TRACE_MAKE) -r -s $@,再次去执行顶层Makefile,此时,并没有$(PREP_MK)变量,所以会执行顶层Makefile的第一个部分,载入include下的相关文件,和一些必要的Makefile文件,在顶层Makefile去寻找prereq目标, prereq: $(target/stamp-prereq) tmp/.prereq_packages 处理它的依赖文件。 然后再接着执行toplevel.mk %:: @+$(PREP_MK) $(NO_TRACE_MAKE) -r -s prereq @+$(SUBMAKE) -r $@ 在@+$(SUBMAKE) -r $@命令中也没有$(PREP_MK)变量,所以在顶层Makefile的第二个部分,寻找Makefile的默认目标,即world。 world: prepare $(target/stamp-compile) $(package/stamp-cleanup) $(package/stamp-compile) $(package/stamp-install) $(package/stamp-rootfs-prepare) $(target/stamp-install) FORCE $(_SINGLE)$(SUBMAKE) -r package/index 根据各个依赖文件进行相应的编译,最终完成编译。 在顶层Makefile里比较麻烦的是,将Makefile分为了两个主要分支,在每个分支里通过include载入相应的文件,在这些文件里包含相应的目标执行命令,在命令中多次用make + 目标+ 参数的方式,则会再次执行Makefile文件,就形成了Makefile的嵌套执行。

相关主题
文本预览
相关文档 最新文档