❶ 为什么使用设备树替代设备文件，有什么好处
linux源码的arch/powerpc/boot/dts/目录下存放了很多dts文件，可以作为参考文件。另外dtc编译器在内核源码2.6.25版本之后已经被包含进去。
❷ linux内核源码详解
Linux的内核源代码可以从很多途径得到。一般来讲，在安装的linux系统下，/usr/src/linux目录下的东西就是内核源代码。
对于源代码的阅读，要想比较顺利，事先最好对源代码的知识背景有一定的了解。对于linux内核源代码来讲，我认为，基本要求是:1、操作系统的基本知识; 2、对C语言比较熟悉，最好要有汇编语言的知识和GNU C对标准C的扩展的知识的了解。
另外在阅读之前，还应该知道Linux内核源代码的整体分布情况。我们知道现代的操作系统一般由进程管理、内存管理、文件系统、驱动程序、网络等组成。看一下Linux内核源代码就可看出，各个目录大致对应了这些方面。Linux内核源代码的组成如下(假设相对于linux目录):
arch 这个子目录包含了此核心源代码所支持的硬件体系结构相关的核心代码。如对于X86平台就是i386。
include 这个目录包括了核心的大多数include文件。另外对于每种支持的体系结构分别有一个子目录。
init 此目录包含核心启动代码。
mm 此目录包含了所有的内存管理代码。与具体硬件体系结构相关的内存管理代码位于arch/-/mm目录下，如对应于X86的就是arch/i386/mm/fault.c 。
drivers 系统中所有的设备驱动都位于此目录中。它又进一步划分成几类设备驱动，每一种也有对应的子目录，如声卡的驱动对应于drivers/sound。
ipc 此目录包含了核心的进程间通讯代码。
moles 此目录包含已建好可动态加载的模块。
fs Linux支持的文件系统代码。不同的文件系统有不同的子目录对应，如ext2文件系统对应的就是ext2子目录。
kernel 主要核心代码。同时与处理器结构相关代码都放在arch/-/kernel目录下。
net 核心的网络部分代码。里面的每个子目录对应于网络的一个方面。
lib 此目录包含了核心的库代码。与处理器结构相关库代码被放在arch/-/lib/目录下。
scripts 此目录包含用于配置核心的脚本文件。
Documentation 此目录是一些文档，起参考作用。
❸ linux设备树到底是什么该如何彻底理解
Linux这几年发展迅猛，势如破竹。 虽然内核 3.0版本，并没有什么重大的修改，不过，这已经预示着Linux将迎来一个新的时代。 《linux设备驱动程序》是基于2.6.10来写的。《深入理解linux内核》是基于2.6.11来写的。虽然2.6.x的内核，在主要内容上变化不大，不过已经有些显得跟不上内核更迭的速度了。 目前内核方面写的不错的书籍中，最新的算是《深入Linux内核架构》了，一个德国人写的。这本书是基于2.6.24写的。这本书在国外是作为教材用的，个人觉得，从自学的角度上讲，要比ULK更好，而且里面与最新的内核更贴近，看起来更舒服一些。 《linux device drivers》英文第三版序言里有这样一段话:“I'm excited by what I witness in the embedded arena, and I hope this text helps by doing more; but ideas are moving fast these days, and it's already time to plan for the fouth edition, and look for a fourth author to help.” 不难看懂，我就不翻译了。从这里可以看出，作者们已经做好找第四位合作者写第四版的准备了:) 万事都是需要与时俱进的。所以，这两本书都是会不断更新的。否则，就只能说明一点，出版商发现有更好的书籍替代他们了:) 不管怎么样，希望这些大部头的下一版的作者中，能看到中国开发者的名字~~
❹ linux 模块编程为什么要编译内核源码树
当然需要。。。
第一点，就是源码树中有相应的头文件和函数的实现，没有源码树，你哪调用去呢？（PC上编译的时候内核有导出符号，系统中有头文件，这样就可以引用内核给你的接口了，但是只能编译你PC上版本的内核可加载的模块）。
第二个，内核模块中会记录版本号的部分，需要记录版本号的原因是不同的内核版本之间，那些接口和调用可能会有比较大的差异，因此必须要保证你的代码和某个特定的内核对应，这样编译出来的模块就可以（也是只能）在运行这个内核版本的Linux系统中加载，否则一个很简单的异常就会导致内核崩溃，或者你的代码根本无法编译通过(接口名变了)。
我上面说的是编译模块的情况，当然如果是把模块直接编译到内核当中去的话，那就不用说了，没有内核源码，你无法编译内核。
❺ 编译linux内核设备树文件使用什么命令
Linux源码的arch/powerpc/boot/dts/目录下存放了很多dts文件，可以作为参考文件。另外dtc编译器在内核源码2.6.25版本之后已经被包含进去。在2.6.26版本之后，生成blob的简单规则已经加入makefile，如下命令：
$ make ARCH=powerpc canyonlands.dtb
也可以根据自己的硬件修改好dts文件后，用下面类似命令生成dtb文件。
$ dtc -f -I dts -O dtb -R 8 -S 0x3000 test.dts > mpc836x_mds.dtb
$ mkimage -A ppc -O Linux -T flat_dt -C none -a 0x300000 -e 0 -d mpc836x_mds.dtb mpc836x_mds.dtu
❻ 为什么要构造内核源码树编写驱动程序时必须建立内核树
首先回答：
已经下载了最新的源码，编译之后不会对本机已经安装的linux系统有影响吗？
不会有影响，只是占用了一点存储空间。
这里的内核源码树指的是什么？
就是源码树中有相应的头文件和函数的实现，没有源码树，自己写的应用程序就没办法执行起来。
我的电脑明明装的就是linux，为什么还要下载源码（不都已经安装完成了吗）
我们做linux开发一般在PC机上编译好了，下到板子上去运行，板子上的linux内核和PC机上的linux版本很多时候都是不一样的，比如pc机上的是linux2.6,板子上的是linux3.1，这个时候就要下linux3.1的内核，用它编译的驱动模块在板子上才能加载上，不然会出错。在编译内核模块时可以指定是用PC自带的linux内核,还是自己下载的linux内核；这个在Makefile文件中设置的，比如KERN_DIR=/usr/src/linux-headers-3.2.0-29-generic-pae
如果不设置就是用系统自带的；
如果就在PC机上运行，不下到板子上就不用下载linux内核源码树了。
不知解释清楚了没，亲
❼ 如何构造内核源代码树
Linux内核的配置系统由三个部分组成，分别是：
Makefile：分布在 Linux 内核源代码中的 Makefile，定义 Linux 内核的编译规则；
配置文件（config.in）：给用户提供配置选择的功能；
配置工具：包括配置命令解释器（对配置脚本中使用的配置命令进行解释）和配置用户界面（提供基于字符界面、基于 Ncurses 图形界面以及基于 Xwindows 图形界面的用户配置界面，各自对应于 Make config、Make menuconfig 和 make xconfig）。
这些配置工具都是使用脚本语言，如 Tcl/TK、Perl 编写的（也包含一些用 C 编写的代码）。本文并不是对配置系统本身进行分析，而是介绍如何使用配置系统。所以，除非是配置系统的维护者，一般的内核开发者无须了解它们的原理，只需要知道如何编写 Makefile 和配置文件就可以。所以，在本文中，我们只对 Makefile 和配置文件进行讨论。另外，凡是涉及到与具体 CPU 体系结构相关的内容，我们都以 ARM 为例，这样不仅可以将讨论的问题明确化，而且对内容本身不产生影响。
2． Makefile
2.1 Makefile 概述
Makefile 的作用是根据配置的情况，构造出需要编译的源文件列表，然后分别编译，并把目标代码链接到一起，最终形成 Linux 内核二进制文件。
由于 Linux 内核源代码是按照树形结构组织的，所以 Makefile 也被分布在目录树中。Linux 内核中的 Makefile 以及与 Makefile 直接相关的文件有：
Makefile：顶层 Makefile，是整个内核配置、编译的总体控制文件。
.config：内核配置文件，包含由用户选择的配置选项，用来存放内核配置后的结果（如 make config）。
arch/*/Makefile：位于各种 CPU 体系目录下的 Makefile，如 arch/arm/Makefile，是针对特定平台的 Makefile。
各个子目录下的 Makefile：比如 drivers/Makefile，负责所在子目录下源代码的管理。
Rules.make：规则文件，被所有的 Makefile 使用。
用户通过 make config 配置后，产生了 .config。顶层 Makefile 读入 .config 中的配置选择。顶层 Makefile 有两个主要的任务：产生 vmlinux 文件和内核模块（mole）。为了达到此目的，顶层 Makefile 递归的进入到内核的各个子目录中，分别调用位于这些子目录中的 Makefile。至于到底进入哪些子目录，取决于内核的配置。在顶层 Makefile 中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 体系结构下的 Makefile，这个 Makefile 中包含了平台相关的信息。
位于各个子目录下的 Makefile 同样也根据 .config 给出的配置信息，构造出当前配置下需要的源文件列表，并在文件的最后有 include $(TOPDIR)/Rules.make。
Rules.make 文件起着非常重要的作用，它定义了所有 Makefile 共用的编译规则。比如，如果需要将本目录下所有的 c 程序编译成汇编代码，需要在 Makefile 中有以下的编译规则：
%.s: %.c
$(CC) $(CFLAGS) -S $< -o $@
有很多子目录下都有同样的要求，就需要在各自的 Makefile 中包含此编译规则，这会比较麻烦。而 Linux 内核中则把此类的编译规则统一放置到 Rules.make 中，并在各自的 Makefile 中包含进了 Rules.make（include Rules.make），这样就避免了在多个 Makefile 中重复同样的规则。对于上面的例子，在 Rules.make 中对应的规则为：
%.s: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o $@
2.2 Makefile 中的变量
顶层 Makefile 定义并向环境中输出了许多变量，为各个子目录下的 Makefile 传递一些信息。有些变量，比如 SUBDIRS，不仅在顶层 Makefile 中定义并且赋初值，而且在 arch/*/Makefile 还作了扩充。
常用的变量有以下几类：
1） 版本信息
版本信息有：VERSION，PATCHLEVEL, SUBLEVEL, EXTRAVERSION，KERNELRELEASE。版本信息定义了当前内核的版本，比如 VERSION=2，PATCHLEVEL=4，SUBLEVEL=18，EXATAVERSION=-rmk7，它们共同构成内核的发行版本KERNELRELEASE：2.4.18-rmk7
2） CPU 体系结构：ARCH
在顶层 Makefile 的开头，用 ARCH 定义目标 CPU 的体系结构，比如 ARCH:=arm 等。许多子目录的 Makefile 中，要根据 ARCH 的定义选择编译源文件的列表。
3） 路径信息：TOPDIR, SUBDIRS
TOPDIR 定义了 Linux 内核源代码所在的根目录。例如，各个子目录下的 Makefile 通过 $(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。
SUBDIRS 定义了一个目录列表，在编译内核或模块时，顶层 Makefile 就是根据 SUBDIRS 来决定进入哪些子目录。SUBDIRS 的值取决于内核的配置，在顶层 Makefile 中 SUBDIRS 赋值为 kernel drivers mm fs net ipc lib；根据内核的配置情况，在 arch/*/Makefile 中扩充了 SUBDIRS 的值，参见4）中的例子。
4） 内核组成信息：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
Linux 内核文件 vmlinux 是由以下规则产生的：
vmlinux: $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o
--start-group
$(CORE_FILES)
$(DRIVERS)
$(NETWORKS)
$(LIBS)
--end-group
-o vmlinux
可以看出，vmlinux 是由 HEAD、main.o、version.o、CORE_FILES、DRIVERS、NETWORKS 和 LIBS 组成的。这些变量（如 HEAD）都是用来定义连接生成 vmlinux 的目标文件和库文件列表。其中，HEAD在arch/*/Makefile 中定义，用来确定被最先链接进 vmlinux 的文件列表。比如，对于 ARM 系列的 CPU，HEAD 定义为：
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
表明 head-$(PROCESSOR).o 和 init_task.o 需要最先被链接到 vmlinux 中。PROCESSOR 为 armv 或 armo，取决于目标 CPU。 CORE_FILES，NETWORK，DRIVERS 和 LIBS 在顶层 Makefile 中定义，并且由 arch/*/Makefile 根据需要进行扩充。 CORE_FILES 对应着内核的核心文件，有 kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，这些是组成内核最为重要的文件。同时，arch/arm/Makefile 对 CORE_FILES 进行了扩充：
# arch/arm/Makefile
# If we have a machine-specific directory, then include it in the build.
MACHDIR := arch/arm/mach-$(MACHINE)
ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))
SUBDIRS += $(MACHDIR)
CORE_FILES := $(MACHDIR)/$(MACHINE).o $(CORE_FILES)
endif
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
SUBDIRS += arch/arm/kernel arch/arm/mm arch/arm/lib arch/arm/nwfpe
CORE_FILES := arch/arm/kernel/kernel.o arch/arm/mm/mm.o $(CORE_FILES)
LIBS := arch/arm/lib/lib.a $(LIBS)
5） 编译信息：CPP, CC, AS, LD, AR，CFLAGS，LINKFLAGS
在 Rules.make 中定义的是编译的通用规则，具体到特定的场合，需要明确给出编译环境，编译环境就是在以上的变量中定义的。针对交叉编译的要求，定义了 CROSS_COMPILE。比如：
CROSS_COMPILE = arm-linux-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
......
CROSS_COMPILE 定义了交叉编译器前缀 arm-linux-，表明所有的交叉编译工具都是以 arm-linux- 开头的，所以在各个交叉编译器工具之前，都加入了 $(CROSS_COMPILE)，以组成一个完整的交叉编译工具文件名，比如 arm-linux-gcc。
CFLAGS 定义了传递给 C 编译器的参数。
LINKFLAGS 是链接生成 vmlinux 时，由链接器使用的参数。LINKFLAGS 在 arm/*/Makefile 中定义，比如：
# arch/arm/Makefile
LINKFLAGS :=-p -X -T arch/arm/vmlinux.lds
6） 配置变量CONFIG_*
.config 文件中有许多的配置变量等式，用来说明用户配置的结果。例如 CONFIG_MODULES=y 表明用户选择了 Linux 内核的模块功能。
.config 被顶层 Makefile 包含后，就形成许多的配置变量，每个配置变量具有确定的值：y 表示本编译选项对应的内核代码被静态编译进 Linux 内核；m 表示本编译选项对应的内核代码被编译成模块；n 表示不选择此编译选项；如果根本就没有选择，那么配置变量的值为空。
2.3 Rules.make 变量
前面讲过，Rules.make 是编译规则文件，所有的 Makefile 中都会包括 Rules.make。Rules.make 文件定义了许多变量，最为重要是那些编译、链接列表变量。
O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目录下需要编译进 Linux 内核 vmlinux 的目标文件列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目标文件使用了 EXPORT_SYMBOL 输出符号。
M_OBJS，MX_OBJS：本目录下需要被编译成可装载模块的目标文件列表。同样，MX_OBJS 中的 "X" 表明目标文件使用了 EXPORT_SYMBOL 输出符号。
O_TARGET，L_TARGET：每个子目录下都有一个 O_TARGET 或 L_TARGET，Rules.make 首先从源代码编译生成 O_OBJS 和 OX_OBJS 中所有的目标文件，然后使用 $(LD) -r 把它们链接成一个 O_TARGET 或 L_TARGET。O_TARGET 以 .o 结尾，而 L_TARGET 以 .a 结尾。
❽ linux 设备树 从哪个版本开始
1、kernel最早加入设备树的历史得追溯到v2.6.23，从这个版本开始，在driver目录下多了一个of目录。当然，此时只是引入一些新想法而已。这距离linus大怒说出(2011年3月17日)：this whole ARM thing is a f*cking pain in the ass，还早着。
2、于是从2011年3月开始，内核在PowerPC、ARM等体系里正式打算使用设备树。以ARM体系为例，加入设备树的版本就是v3.1，可以在arch/arm/boot/目录下看到dts目录的出现。
❾ 设备树何时加入linux内核的
Linux and the Device Tree
Linux内核设备树数据使用模型。
Open Firmware Device Tree (DT) 是一个数据结构，也是一种描述硬件的语言。准确地说，它是一种能被操作系统解析的描述硬件的语言，这样操作系统就不需要把硬件平台的细节在代码中写死。
从结构上来说，DT是一个树形结构，或者有名结点组成的非循环图，结点可能包含任意数量的有名属性，有名属性又可以包含任意数量的数据。同样存在一种机制，可以创建从一个结点到正常树形结构之外的链接。
从概念上讲，一套通用的使用方法，即bindings。Bindings定义了数据如何呈现在设备树中，怎样描述典型的硬件特性，包括数据总线，中断线，GPIO连接以及外设等。
尽可能多的硬件被描述从而使得已经存在的bindings最大化地使用源代码，但是由于属性名和结点名是简单字符串， 可以通过定义新结点和属性的方式很方便地扩展已经存在的bindings或者创建一个新的binding。在没有认真了解过已经存在的bindings的情况下，创建一个新的binding要慎之又慎。对于I2C总线，通常有两种不同的，互不相容的bindings出现，就是因为新的binding创建时没有研究I2C设备是如何在当前系统中被枚举的。
1. 历史
略
2. 数据模型
请参考Device Tree Usage章节
2.1 High Level View
必须要认识到的是，DT是一个描述硬件的数据结构。它并没有什么神奇的地方，也不能把所有硬件配置的问题都解决掉。它只是提供了一种语言，将硬件配置从Linux Kernel支持的board and device driver中提取出来。DT使得board和device变成数据驱动的，它们必须基于传递给内核的数据进行初始化，而不是像以前一样采用hard coded的方式。
观念上说，数据驱动平台初始化可以带来较少的代码重复率，使得单个内核映像能够支持很多硬件平台。
Linux使用DT的三个主要原因：
1） 平台识别 (Platform Identification)
2） 实时配置 (Runtime Configuration)
3） 设备植入 (Device Population)
2.2 平台识别
第一且最重要的是，内核使用DT中的数据去识别特定机器。最完美的情况是，内核应该与特定硬件平台无关，因为所有硬件平台的细节都由设备树来描述。然而，硬件平台并不是完美的，所以内核必须在早期初始化阶段识别机器，这样内核才有机会运行特定机器相关的初始化序列。
大多数情况下，机器识别是与设备树无关的，内核通过机器的核心CPU或者SOC来选择初始化代码。以ARM平台为例，setup_arch()会调用setup_machine_fdt()，后者遍历machine_desc链表，选择最匹配设备树数据的machine_desc结构体。它是通过查找设备树根结点的compatible属性并与machine_desc->dt_compat进行比较来决定哪一个machine_desc结构体是最适合的。
Compatible属性包含一个有序的字符串行表，它以确切的机器名开始，紧跟着一个可选的board列表，从最匹配到其他匹配类型。以TI BeagleBoard的compatible属性为例，BeagleBoard xM Board可能描述如下：
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
在这里，”ti, omap3-beagleboard-xm”是最匹配的模型，"ti,omap3450"次之，"ti,omap3"再次之。
机敏的读者可能指出，Beagle xM也可以声明匹配"ti,omap3-beagleboard"，但是要注意的是，板级层次上，两个机器之间的变化比较大，很难确定是否兼容。从顶层上来看，宁可小心也不要去声明一个board兼容另外一个。值得注意的情况是，当一个board承载另外一个，例如一个CPU附加在一个board上。（两种CPU支持同一个board的情况）
❿ linux 内核什么版本开始有设备树
Linux and the Device Tree Linux内核设备树数据使用模型。 Open Firmware Device Tree (DT) 是一个数据结构，也是一种描述硬件的语言。准确地说，它是一种能被操作系统解析的描述硬件的语言，这样操作系统就不需要把硬件平台的细节在代码中写死...