❶ 為什麼使用設備樹替代設備文件，有什麼好處
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) 是一個數據結構，也是一種描述硬體的語言。准確地說，它是一種能被操作系統解析的描述硬體的語言，這樣操作系統就不需要把硬體平台的細節在代碼中寫死...