u-boot的Makefile分析

u-boot的Makefile分析
u-boot的Makefile分析

U-boot的Makefile分析

u-boot的Makefile分析

U-BOOT是一个LINUX下的工程,在编译之前必须已经安装对应体系结构的交叉编译环境,这里只针对ARM,编译器系列软件为ppc_6xx-。U-BOOT的下载地址: https://www.360docs.net/doc/6c15978912.html,/projects/u-boot

我下载的是1.1.5版本

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

几个重要的文件分析:

u-boot-1.1.5/Makefile

u-boot-1.1.5/mkconfig

u-boot-1.1.5/config.mk

u-boot根目录下的Makefile文件(u-boot-1.1.5/Makefile)它负责配置u-boot的编译方式,具体说来包括:使用何种指令集,需包含哪些接口驱动、库等。Makefile的内容从上到下分别是:分定义编译环境:使用何种编译器、编译方式、目标文件的生成及它们最终镜像中的链接次序等。Mkconfig和config.mk在接下来的分析中会涉及到。

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

# make cpci5200_config

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

cpci5200_config: unconfig

@$(MKCONFIG) -a cpci5200 ppc mpc5xxx cpci5200 esd

其中,unconfig定义如下:

unconfig:

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

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

$(obj)board/*/config.tmp

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

然后才执行命令

@$(MKCONFIG) -a cpci5200 ppc mpc5xxx cpci5200 esd

$(MKCONFIG)就会被替换成$(SRCTREE)/mkconfig文件路径, MKCONFIG 是顶层目录下的mkcofig脚本文件(u-boot-1.1.5/mkconfig),后面五个是传入的参数。Mkconfig文件的详细分析见文档末尾。

注意一下u-boot对板卡的分类方法:

Target:宿主机平台

Architecture:定义芯片架构(如MIPS、POWERPC、ARM等)

CPU:定义芯片指令集版本(如ARM7、ARM9、ARM11等)

Board:芯片厂商,它细分为两类

[VENDOR]:按厂商划分(如AT9200、S3C44B0等)

[SOC]:按SOC类型(如S3C2440、S3C2410等)

1)对于cpci5200_config而言,mkconfig主要做三件事:

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

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

#ln -s asm-ppc asm

#ln -s arch-mpc5xxx asm-ppc/arch

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

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

ARCH = ppc

CPU = mpc5xxx

BOARD = cpci5200

VENDOR = esd

这些变量可以供其它的makefile使用,作为一个基本配置.

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

echo“/* Automatically generated - do not edit */”>>config.h

echo“#include ”>>config.h

这两行代码生成一个include/config.h文件,这个文件很简单,只有一句话:#include <$1.h> 当然这里的$1时要被替换成不同的board名字的.这个取决于我们在主Makefile中xxxx_config目标中的xxxx是什么.

mkconfig脚本文件的执行至此结束

2)分析config.mk的内容:

u-boot根目录下自带一个config.mk文件(u-boot-1.1.5/config.mk),应该说这才是真正的Makefile,以上介绍的两个脚本Makefile和mkconfig完成了环境配置之后,在该文件中才定义具体的编译规则,所以你会发现在各个子模块(board、 cpu、lib_xxx、net、disk...)目录中的Makefile第一句就是:include $(TOPDIR)/config.mk。文件内容分析如下:

这个文件的功能就是给各个在编译过程中的变量赋值,包括编译执行的函数与编译的时候所带的参数等等。还会根据是否定义了ARCH,CPU,SOC,VENDOR,BOARD来决定是否包含相应位置的config.mk文件,这些个文件里,也是定义了相应的平台在编译的时候应该加的参数。所以如果你为你自己的开发板取了别的名字了,那么就要检查一下这个文件,看一下相应的位置上的config.mk文件有没有,内容是否为你要想的。

z包含体系,开发板,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 VENDOR

BOARDDIR = $(VENDOR)/$(BOARD)

else

BOARDDIR = $(BOARD)

Endif

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

ifdef BOARD

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

z定义交叉编译链工具

# 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

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

#制定了在编译的时候告诉编译器生成的代码的基地址是TEXT_BASE

CPPFLAGS := $(DBGFLAGS) $(OPTFLAGS) $(RELFLAGS) \

-D__KERNEL__ -DTEXT_BASE=$(TEXT_BASE) \

AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)

#指定了起始地址TEXT_BASE

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

z指定编译规则

ifndef REMOTE_BUILD

%.s: %.S

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

%.o: %.S

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

%.o: %.c

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

else

$(obj)%.s: %.S

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

$(obj)%.o: %.S

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

$(obj)%.o: %.c

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

endif

3)分析最关键的u-boot ELF文件镜像的生成

Makefile文件中的各个依赖目标分析如下:

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

depend dep:

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

z依赖目标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)

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

SUBDIRS = tools \

examples \

post \

post/cpu

.PHONY : $(SUBDIRS)

$(SUBDIRS):

$(MAKE) -C $@ all

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

$(OBJS):

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

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

$(LIBS):

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

z依赖目标$(LDSCRIPT):

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

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

对于每一种开发板来说,LDSCRIPT即连接脚本文件,例如board/esd/cpci5200/u-boot.lds,定义了连接时各个目标文件是如何组织的。内容如下:

OUTPUT_ARCH(powerpc)

SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib);

SEARCH_DIR(/usr/local/powerpc-any-elf/lib);

/* Do we need any of these for elf?

__DYNAMIC = 0; */

SECTIONS

{

/* Read-only sections, merged into text segment: */ . = + SIZEOF_HEADERS;

.interp : { *(.interp) }

.hash: { *(.hash) }

.dynsym : { *(.dynsym) }

.dynstr : { *(.dynstr) }

.rel.text: { *(.rel.text) }

.rela.text : { *(.rela.text) }

.rel.data: { *(.rel.data) }

.rela.data : { *(.rela.data) }

.rel.rodata : { *(.rel.rodata) }

.rela.rodata : { *(.rela.rodata) }

.rel.got: { *(.rel.got) }

.rela.got: { *(.rela.got) }

.rel.ctors : { *(.rel.ctors) }

.rela.ctors : { *(.rela.ctors) }

.rel.dtors : { *(.rel.dtors) }

.rela.dtors : { *(.rela.dtors) }

.rel.bss: { *(.rel.bss) }

.rela.bss: { *(.rela.bss) }

.rel.plt: { *(.rel.plt) }

.rela.plt: { *(.rela.plt) }

.init: { *(.init) }

.plt : { *(.plt) }

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

.text :

{

#start.o为首

cpu/mpc5xxx/start.o (.text)

*(.text)

*(.fixup)

*(.got1)

. = ALIGN(16);

*(.rodata)

*(.rodata1)

*(.rodata.str1.4)

*(.eh_frame)

}

.fini: { *(.fini) } =0

.ctors : { *(.ctors) }

.dtors : { *(.dtors) }

/* Read-write section, merged into data segment: */ . = (. + 0x0FFF) & 0xFFFFF000;

_erotext = .;

PROVIDE (erotext = .);

.reloc :

{

*(.got)

_GOT2_TABLE_ = .;

*(.got2)

_FIXUP_TABLE_ = .;

*(.fixup)

}

__got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2; __fixup_entries = (. - _FIXUP_TABLE_) >> 2;

.data :

{

*(.data)

*(.data1)

*(.sdata)

*(.sdata2)

*(.dynamic)

CONSTRUCTORS

}

_edata = .;

PROVIDE (edata = .);

. = .;

__u_boot_cmd_start = .;

.u_boot_cmd : { *(.u_boot_cmd) }

__u_boot_cmd_end = .;

. = .;

__start___ex_table = .;

__ex_table : { *(__ex_table) }

__stop___ex_table = .;

. = ALIGN(4096);

__init_begin = .;

.text.init : { *(.text.init) }

.data.init : { *(.data.init) }

. = ALIGN(4096);

__init_end = .;

__bss_start = .;

.bss :

{

*(.sbss) *(.scommon)

*(.dynbss)

*(.bss)

*(COMMON)

}

_end = . ;

PROVIDE (end = .);

}

整个makefile剩下的内容全部是各种不同的开发板的*_config:目标的定义了。

对于各子目录的makefile文件,主要是生成*.o文件然后执行AR生成对应的库文件。

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

Mkconfig源码注解

#下面这一行的内容,表示这个shell脚本的解释器是/bin/sh,给的解释器的参数为-e,这个#参数的意思就是,当shell返回值为非零值的时候,shell马上退出执行。在shell脚本里也 #可以没有这一行,这一行不是必须的,如果没有这一行的话,那么shell脚本就会用当前运 #行环境下的默认的shell来执行。

#!/bin/sh -e

# Script to create header files and links to configure

# U-Boot for a specific board.

#

# Parameters: Target Architecture CPU Board [VENDOR] [SOC]

#

# (C) 2002-2006 DENX Software Engineering, Wolfgang Denk

#

#APPEND变量与BOARD_NAME变量都设置了默认值,如果后面对变量值有修改就以后面的为准,#没有就是默认值了。这里的APPEND的参数的意义,实际上就是用来标识是否产生一个新的配

#置文件,还是直接把生成的配置信息写到旧文件后面。

APPEND=no # Default: Create new config file

BOARD_NAME="" # Name to print in make output

#$#代表的是传入脚本的参数的个数,-gt表示是如果左边参数比右边参数大,则返回true, #否则为false。$1代表的是传入的第一个参数的内容,$2表示传入的第二个参数的内容,以 #此类推。shift表示参数都左移一位,原来的$3变为$2,$2为$1,$1的内容则被丢弃。这个 #地方,实际上是处理了一些附加的参数的问题,如果是--,则仅丢弃不做其它处理;如果是#-a,则把APPEND的值置为yes;如果是-n,则表示后面跟的是板子的名字。${a%%pattern}是#shell中的一个替换语法,表示把变量a中的内容,从右至左,最大程度上把符合pattern样 #式的字符串删掉。这里可以看出,如果-n后面跟的是类似于smdk2410_config的参数的话, #则最后会变成smdk2410;如果是其它的值,则退出循环,不执行了。在Makefile中的动作,#其实并不会触发这里的处理逻辑,估计这里是作者为了调试方便,需要单独运行此脚本的时#候,加的一些对参数的处理。

while [ $# -gt 0 ] ; do

case "$1" in

--) shift ; break ;;

-a) shift ; APPEND=yes ;;

-n) shift ; BOARD_NAME="${1%%_config}" ; shift ;;

*) break ;;

esac

done

#第一行的语法表示如果BOARD_NAME没有被设置过,则把它置为变量1的值。然后进行参数个 #数的判断,-lt表示less than则返回true,也就是如果参数少于4个或是参数大于6个,则退#出,不执行。如果没有退出执行的话,则输出Configuring for ${BOARD_NAME} board...这#句话,其中${BOARD_NAME}会被替换成用户输入的板子的名字。

[ "${BOARD_NAME}" ] || BOARD_NAME="$1"

[ $# -lt 4 ] && exit 1

[ $# -gt 6 ] && exit 1

echo "Configuring for ${BOARD_NAME} board..."

#

# Create link to architecture specific headers

#

#当用户指定的$OBJTREE与$SRCTREE不一致的时候会做如下一些事情:

#在$OBJTREE下建立include文件夹

#在$OBJTREE下建立include2文件夹

#进入到include2文件夹,其实就是$OBJTREE文件夹下的include2

#删除asm,其实往后看就知道了,这是一个文件夹,是以link的方式建立的

#然后建立一个asm的文件夹,这个文件夹是指向${SRCTREE}/include/asm-$2的,$2这个参数#多指CPU架构类型如:PPC,ARM。

#给变量LNPREFIX赋值。这个变量在以后的执行会用到,所以这里给的asm的位置,是相对于 #后来执行的时候,当前工作目录与asm之间的关系来定的。

#进入到$OBJTREE中的include文件夹(之前是在include2里)。

#删除掉asm-$2文件夹,其实就是asm-arm文件夹。

#删除掉asm文件夹

#建立一个新的asm-$2文件夹,其实就是asm-arm文件夹

#建立一个名为asm的link,这个link指向新建立的asm-arm文件夹。

#现在看一下整个目录大概的结构:

${OBJTREE}

Include

asm-arm

asm -> ./asm-arm

include2

asm -> ${SRCTREE}/include/asm-arm

#可以看到,目前在include下的asm-arm与asm其实是同一个文件夹,并且内容为空,include2 #文件夹下的asm是指向了源码树中的${SRCTREE}/include/asm-arm文件夹。

#如果"$SRCTREE"与"$OBJTREE"是同一个文件(大多数情况下,咱们都是这种方式来编译的),#那么就是仅仅在include文件夹下,建立一个名为asm的link,直接指向asm-$2,即asm-arm。#最后删除asm-arm/arch文件夹。

if [ "$SRCTREE" != "$OBJTREE" ] ; then

mkdir -p ${OBJTREE}/include

mkdir -p ${OBJTREE}/include2

${OBJTREE}/include2

cd

rm -f asm

ln -s ${SRCTREE}/include/asm-$2 asm

LNPREFIX="../../include2/asm/"

../include

cd

rm -rf asm-$2

rm -f asm

asm-$2

mkdir

ln -s asm-$2 asm

else

./include

cd

rm -f asm

ln -s asm-$2 asm

fi

rm -f asm-$2/arch

#下面第一句中连接两个判断的-o,相当于or的意思,就是表示的“或”。意思就是如果第6 #个参数为空或是为NULL,则在include下建立一个asm-$2/arch的link,指向

#${LNPREFIX}arch-$3,否则就在include下建立一个asm-$2/arch的link,指向

#${LNPREFIX}arch-$6

if [ -z "$6" -o "$6" = "NULL" ] ; then

ln -s ${LNPREFIX}arch-$3 asm-$2/arch

else

ln -s ${LNPREFIX}arch-$6 asm-$2/arch

fi

#如果第二个参数是arm的话,则删除include/asm-$2/proc文件,实际上就是

#include/asm-arm/proc文件夹,建立一个新的link,在include/asm-$2/proc处,也即

#include/asm-arm/proc,指向${LNPREFIX}proc-armv文件夹

if [ "$2" = "arm" ] ; then

rm -f asm-$2/proc

ln -s ${LNPREFIX}proc-armv asm-$2/proc

fi

#

# Create include file for Make

#

#第一行,输出ARCH = $2,即ARCH = arm到config.mk,也即include/config.mk,注意这里 #用了一个>,它表示重新生成一个config.mk文件,如果有旧的,则覆盖

#第二行,同理,输出CPU = arm920t到config.mk中

#第三行,同理,输出BOARD = smdk2410到config.mk

#第四行,判断,如果$5不为空,且$5的值不为NULL,

#则把VENDOR = $5的值输出到config.mk中

#第五行,同理,把SOC输出到config.mk中

echo "ARCH = $2" > config.mk

echo "CPU = $3" >> config.mk

echo "BOARD = $4" >> config.mk

[ "$5" ] && [ "$5" != "NULL" ] && echo "VENDOR = $5" >> config.mk

[ "$6" ] && [ "$6" != "NULL" ] && echo "SOC = $6" >> config.mk

#

# Create board specific header file

#

#如果APPEND的值为yes,则写入一空行到已经存在的config.h中,也即include/config.h中,#如果不是,则生成一个新的config.h,如果旧的文件存在,则覆盖。

if [ "$APPEND" = "yes" ] # Append to existing config file

then

echo >> config.h

else

> config.h # Create new config file

fi

echo "/* Automatically generated - do not edit */" >>config.h

echo "#include " >>config.h

exit 0

手动建立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标记开始会看到一长串莫名奇妙的代码:

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.360docs.net/doc/6c15978912.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项目的代码作为模板,以后再修改

makefile新手教程

makefile新手教程 2013-11-08 本文翻译自https://www.360docs.net/doc/6c15978912.html,/tutorials/ Makefiles --通过示例说明 编译源代码是沉闷的,尤其是当你想要include一些源代码,却又每次都需要手动敲编译命令的时候。 恩,我有个好消息告诉你...你用手敲命令行去编译的日子(基本上)一去不复返了,因为你将会学习如何编写Makefile。Makefile是配合make命令使用的特殊文件,make命令则会帮助你自动地、神奇般地管理你的工程。 这里你需要先准备以下文件: main.cpp

hello.cpp factorial.cpp functions.cpp 我建议你新建一个空的目录,然后将上述4个文件放入其中。

注意:我使用g++命令编译。你完全可以换成别的编译器 make工具 如果你运行make 它会去寻找当前目录下名字为makefile的文件,并按里面的内容执行。 如果你有很多makefile文件,那么可以用这个命令来执行: 当然还有其他的参数来使用make工具,详情请man make。 构建过程 1.编译器编译源代码文件,输出到目标文件 2.链接器将目标文件链接,并创建可执行文件 手动编译 手动编译并获得可执行文件,是一种琐碎的方式: 基本的Makefile

基本的makefile文件组成如下: 将此语法应用到我们的例子中,就是: all: g++ main.cpp hello.cpp factorial.cpp -o hello 我们将此文件保存为Makefile-1。要运行此makefile,则输入:make -f Makefile-1 在这个例子中可以看到,我们的target叫做all。这是makefile中的默认target。若无指定参数,make工具将按这个target 执行。 我们同时发现,这个例子中的target,也就是all,没有dependencies(依赖文件),因此make会安全地执行后续的system commands(系统命令)。 最后,make根据我们设定的命令完成了编译。 使用依赖文件 有时候使用多个不同的target会很有用,因为当你只修改了工程中的一个文件时,不必重新编译所有代码,只需要编译修改过的部分。比如:

模块驱动笔记

驱动模块装载全纪录 模块驱动源代码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

Linux如何写makefile文件

Linux如何写makefile文件 关于程序的编译和链接 —————————— 在此,我想多说关于程序编译的一些规范和方法,一般来说,无论是C、C++、还是pas,首先要把源文件编译成中间代码文件,在Windows下也就是 .obj 文件,UNIX下是 .o 文件,即 Object File,这个动作叫做编译(compile)。然后再把大量的Object File合成执行文件,这个动作叫作链接(link)。 编译时,编译器需要的是语法的正确,函数与变量的声明的正确。对于后者,通常是你需要告诉编译器头文件的所在位置(头文件中应该只是声明,而定义应该放在 C/C++文件中),只要所有的语法正确,编译器就可以编译出中间目标文件。一般来说,每个源文件都应该对应于一个中间目标文件(O文件或是OBJ文 件)。 链接时,主要是链接函数和全局变量,所以,我们可以使用这些中间目标文件(O文件或是OBJ文件)来链接我们的应用程序。链接器并不管函数所在的源文件, 只管函数的中间目标文件(Object File),在大多数时候,由于源文件太多,编译生成的中间目标文件太多,而在链接时需要明显地指出中间目标文件名,这对于编译很不方便,所以,我们要给 中间目标文件打个包,在Windows 下这种包叫“库文件”(Library File),也就是 .lib 文件,在UNIX下,是Archive File,也就是 .a 文件。 总结一下,源文件首先会生成中间目标文件,再由中间目标文件生成执行文件。在编译时,编译器只检测程序语法,和函数、变量是否被声明。如果函数未被声明, 编译器会给出一个警告,但可以生成Object File。而在链接程序时,链接器会在所有的Object File中找寻函数的实现,如果找不到,那到就会报链接错误码(Linker Error),在VC下,这种错误一般是:Link 2001错误,意思说是说,链接器未能找到函数的实现。你需要指定函数的Object File. 好,言归正传,GNU的make有许多的内容,闲言少叙,还是让我们开始吧。 Makefile 介绍 ——————— make命令执行时,需要一个 Makefile 文件,以告诉make命令需要怎么样的去编译和链接程序。 首先,我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册,在这个示例中,我们的工程有 8

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) 被展开后就是:

Makefile超强经典教程

Makefile经典教程 0 Makefile概述 (2) 0.1关于程序的编译和链接 (2) 1 Makefile介绍 (3) 1.1 Makefile的规则 (4) 1.2一个示例 (4) 1.3 make是如何工作的 (6) 1.4 makefile中使用变量 (7) 1.5让make自动推导 (8) 1.6另类风格的makefile (9) 1.7清空目标文件的规则 (10) 2 Makefile总述 (11) 2.1 Makefile里有什么? (11) 2.2Makefile的文件名 (12) 2.3引用其它的Makefile (12) 2.4环境变量MAKEFILES (13) 2.5 make的工作方式 (13) 3 Makefile书写规则 (14) 3.1规则举例 (14) 3.2规则的语法 (14) 3.3在规则中使用通配符 (15) 3.4文件搜寻 (16) 3.5伪目标 (17) 3.6多目标 (19) 3.7静态模式 (20) 3.8自动生成依赖性 (22) 4 Makefile书写命令 (24) 4.1显示命令 (24) 4.2命令执行 (25) 4.3命令出错 (25) 4.4嵌套执行make (26) 4.5定义命令包 (29) 1

0 Makefile概述 什么是makefile?或许很多Winodws的程序员都不知道这个东西,因为那些Windows的IDE都为你做了这个工作,但我觉得要作一个好的和professional的程序员,makefile还是要懂。这就好像现在有这么多的HTML的编辑器,但如果你想成为一个专业人士,你还是要了解HTML的标识的含义。特别在Unix下的软件编译,你就不能不自己写makefile了,会不会写makefile,从一个侧面说明了一个人是否具备完成大型工程的能力。 因为,makefile关系到了整个工程的编译规则。一个工程中的源文件不计数,其按类型、功能、模块分别放在若干个目录中,makefile定义了一系列的规则来指定,哪些文件需要先编译,哪些文件需要后编译,哪些文件需要重新编译,甚至于进行更复杂的功能操作,因为makefile就像一个Shell脚本一样,其中也可以执行操作系统的命令。 makefile带来的好处就是——“自动化编译”,一旦写好,只需要一个make命令,整个工程完全自动编译,极大的提高了软件开发的效率。make是一个命令工具,是一个解释makefile中指令的命令工具,一般来说,大多数的IDE都有这个命令,比如:Delphi的make,Visual C++的nmake,Linux下GNU的make。可见,makefile都成为了一种在工程方面的编译方法。 现在讲述如何写makefile的文章比较少,这是我想写这篇文章的原因。当然,不同产商的make各不相同,也有不同的语法,但其本质都是在“文件依赖性”上做文章,这里,我仅对GNU的make进行讲述,我的环境是RedHat Linux 8.0,make的版本是3.80。必竟,这个make是应用最为广泛的,也是用得最多的。而且其还是最遵循于IEEE 1003.2-1992 标准的(POSIX.2)。 在这篇文档中,将以C/C++的源码作为我们基础,所以必然涉及一些关于C/C++的编译的知识,相关于这方面的内容,还请各位查看相关的编译器的文档。这里所默认的编译器是UNIX下的GCC和CC。 0.1关于程序的编译和链接 在此,我想多说关于程序编译的一些规范和方法,一般来说,无论是C、C++、还是pas,首先要把源文件编译成中间代码文件,在Windows下也就是.obj 文件,UNIX

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依次循环。) 参考下例:

相关文档
最新文档