在一篇名為《 Device trees everywhere 》的文章裡，談及了二零零五年五月時，  IBM 的 Benjamin Herrenschmidt 建置了一套新的『設備樹』之 linux kernel 啟動機制，即使一個沒有『 OF 』 Open Firmware 的系統，也可以使用『設備樹』得到好處。此事記載於 Linux 《 booting-without-of.txt 》 文件之中，那時 ── May 18, 2005: Rev 0.1 – Initial draft, no chapter III yet. ── ，到了

November 21, 2005: Rev 0.5

– Additions/generalizations for 32-bit
– Changed to reflect the new arch/powerpc structure
– Added chapter VI

和此刻的差異實在說並不大。『術語』與『架構』延襲至今，正是深入理解『 /proc/device-tree 』、『 The DT block format 』、『 Required content of the device tree 』以及一些『建議』的基礎『文本』。俗話講︰『十年磨一劍』，正此之謂耶？？

雖說『設備樹』是種系統連接『硬體裝置』的簡易『描述語言』 ，但要三言兩語講清楚它與『第一啟動』 BIOS 韌體或是『 Boot Loader 』與『 kernel os 』之裝置『驅動程式』間的關係，其實很不容易。因此這裡也只能借花獻佛，請讀者自讀《 Device Tree for DUMMIES 》的了。

既然『設備樹』 與『檔案樹』都是『樹狀結構』，系統開機後用『 /proc/device-tree 』來表現啟始 dtb 之結果，正是一一對應︰

設備根節點 Device Root /proc/device-tree 目錄

設備節點 Device Node 子目錄

設備屬性 Device Property 檔案

# 設備樹鏈結至 /sys/firmware/devicetree/base
ls -la /proc/device-tree
lrwxrwxrwx 1 root root 29  3月  2 15:56 /proc/device-tree -> /sys/firmware/devicetree/base

# 與 fdt 同構
cd /proc/device-tree
ls -l

總計 0
-r--r--r--  1 root root  4  3月  2 15:55 #address-cells
drwxr-xr-x  2 root root  0  3月  2 15:55 aliases
drwxr-xr-x  7 root root  0  3月  2 15:55 axi
drwxr-xr-x  2 root root  0  3月  2 15:55 chosen
drwxr-xr-x  4 root root  0  3月  2 15:55 clocks
-r--r--r--  1 root root 13  3月  2 15:55 compatible
drwxr-xr-x  6 root root  0  3月  2 15:55 cpus
drwxr-xr-x  2 root root  0  3月  2 15:55 display
-r--r--r--  1 root root  4  3月  2 15:55 interrupt-parent
drwxr-xr-x  2 root root  0  3月  2 15:55 memory
-r--r--r--  1 root root  8  3月  2 15:55 memreserve
-r--r--r--  1 root root 23  3月  2 15:55 model
-r--r--r--  1 root root  1  3月  2 15:55 name
drwxr-xr-x  2 root root  0  3月  2 15:55 __overrides__
-r--r--r--  1 root root  4  3月  2 15:55 #size-cells
drwxr-xr-x 10 root root  0  3月  2 15:55 soc
drwxr-xr-x  2 root root  0  3月  2 15:55 sound
drwxr-xr-x  2 root root  0  3月  2 15:55 __symbols__
drwxr-xr-x  2 root root  0  3月  2 15:55 system
drwxr-xr-x  2 root root  0  3月  2 15:55 timer

這雖然說是了解 Linux FDT 建制很好的辦法， 然而

# 不是 ASCII 碼
cat \#address-cells 


□

# 不符數據內容
hexdump \#address-cells 
0000000 0000 0100                              
0000004

# 字串 OK
cat compatible 
brcm,bcm2709

，所以也不是容易的事。要是

# 產生當下 /proc/device-tree
dtc -I fs -O dtb -o runtime.dtb /proc/device-tree
Warning (avoid_default_addr_size): Relying on default #address-cells value for /axi/vc_mem
Warning (avoid_default_addr_size): Relying on default #size-cells value for /axi/vc_mem

# 總覽
fdtdump runtime.dtb
/dts-v1/;
// magic:		0xd00dfeed
// totalsize:		0x1ce3 (7395)
// off_dt_struct:	0x38
// off_dt_strings:	0x1948
// off_mem_rsvmap:	0x28
// version:		17
// last_comp_version:	16
// boot_cpuid_phys:	0xf00
// size_dt_strings:	0x39b
// size_dt_struct:	0x1910

/ {
    model = "Raspberry Pi 2 Model B";
    compatible = "brcm,bcm2709";
    memreserve = <0x3b000000 0x0000001c>;
    #address-cells = <0x00000001>;
    #size-cells = <0x00000001>;
    interrupt-parent = <0x00000001>;
    axi {
...

# 閱讀
fdtget runtime.dtb -l /
axi
soc
cpus
display
sound
timer
chosen
clocks
memory
system
__symbols__
aliases
__overrides__

fdtget runtime.dtb -p /
model
compatible
memreserve
#address-cells
#size-cells
interrupt-parent

fdtget runtime.dtb / \#address-cells
1

─── 也許在這逐鹿中原之時，快就是好！！ ───

□︰今已有兩極四方，恐入八卦矣！

○︰所為何事？

□︰圍城而不攻？是何故耶？？

○︰是所謂碩果不食。能上不能下？窮之災！囧之禍乎？？

○︰《易》有剝極來復之道！！

與時並進者遭遇『困難』，面對『未知』是再自然不過的事。如之何『求解』正砥礪著學者的『百折不撓』之精神。『九天九地』的探尋，難到不會有『一陽來復』之時？深體自由軟體者之心？？

假使仔細閱讀《 Device Tree on ARCH_BCM2708 》，留心一下『那個人』── notro ── 與『那個時間』── on Jul 30, 2014 ──，也許我們不只對樹莓派『裝置樹』有更多的了解，更能明白許多的貢獻其來有自，正所謂『德不孤，必有鄰』乎！！

此處將僅簡單說說幾個工具程式，以及簡介它們的用法。

常用縮寫︰

【 DT 】︰  Device Tree
【 FDT 】︰ Flattended Device Tree: a DT representation used in the dtb blob.
【 .dtb 】︰ Device Tree Binary
【 .dts 】︰ Device Tree Source
【 .dtsi 】︰ Device Tree Source Include
【 dtc 】︰ Device Tree Compiler

# dtc 的用法說明

pi@raspberrypi ~  fdtdump -h
Usage: fdtdump [options] 

Options: -[dshV]
  -d, --debug   Dump debug information while decoding the file
  -s, --scan    Scan for an embedded fdt in file
  -h, --help    Print this help and exit
  -V, --version Print version and exit

# 範例︰顯示 dtb 內容
fdtdump /boot/overlays/lirc-rpi-overlay.dtb



# fdtget 的用法說明
pi@raspberrypi ~  fdtput -h
Usage: write a property value to a device tree
	fdtput 
   [...]
	fdtput -c 
 [...]

The command line arguments are joined together into a single value.
	s=string, i=int, u=unsigned, x=hex
	Optional modifier prefix:
		hh or b=byte, h=2 byte, l=4 byte (default)

Options: -[cpt:vhV]
  -c, --create     Create nodes if they don't already exist
  -p, --auto-path  Automatically create nodes as needed for the node path
  -t, --type  Type of data
  -v, --verbose    Display each value decoded from command line
  -h, --help       Print this help and exit
  -V, --version    Print version and exit

# 範例︰
cp /boot/bcm2709-rpi-2-b.dtb .
fdtput --type s bcm2709-rpi-2-b.dtb /soc/spi@7e204000 status "okay"
fdtget bcm2709-rpi-2-b.dtb /soc/spi@7e204000 status

在大變動時候，通常『問題』和『答案』至少一樣重要，甚至於更重要。許多『零碎資訊』拼湊出『藍圖』，或許正是『逆流朔源』的大好時機！因此也許該閱讀論壇的這個『文本』︰

《 I2C, SPI, I2S, LIRC, PPS, stopped working? Read this. 》

by PhilE » Wed Jan 21, 2015 4:45 pm
The most recent Raspbian release, with Pi 2 support, switches to a new kernel (3.18), and includes a configuration change to enable Device Tree support by default. This has caused some previously working things to mysteriously stop working, but with a few configuration changes normal service should be resumed. I’ll tell you how to do that in a moment, but first a short history lesson. Skip forward to “TL;DR: Yeah, yeah, but how do I fix it?” if you don’t care.
……
So DT is officially a “Thing”, but why should Raspberry Pi use it? The change is primarily a practical one. Until now, supporting some peripheral cards has required the addition of “struct platform_device” objects to the board support code. These are usually conditionally compiled based on the kernel configuration options, but in order to prevent regular users from having to compile their own kernel these options are turned on in the standard builds. As a result, at boot time many (typically unwanted) modules are loaded unless they added to the blacklist (which prevents the automatic loading but still allows subsequent manual loading). Insufficient blacklisting could lead to nasty contention for GPIO pins, usually experienced after a kernel update since the blacklist file (/etc/modprobe.d/raspi-blacklist.conf) isn’t a part of the kernel and hence doesn’t automatically get updated.

Device Tree turns this system on its head, by replacing those “struct platform_device”s with nodes in the DT, allowing users to control which devices are enabled and hence which modules get loaded. Adding a new device driver module to the kernel doesn’t automatically result in a module being loaded – the appropriate nodes must also be added to the DT.

TL;DR: Yeah, yeah, but how do I fix it?……

要是帶著『思源之心』慎思 Q&A ……

《 I2C, SPI, I2S, LIRC, PPS, stopped working? Read this. 》

by PhilE » Mon Feb 09, 2015 1:27 pm

We need a bit more information:
1) Which version are you running now? What does `uname -a` say?

2) Does /proc/device-tree exist?

3) Have you read the above and enabled the SPI interface? I would guess so, if it gets that far before failing, but I’d like confirmation.

4) Does disabling device tree (add “device_tree=” to your config.txt and reboot) make a difference?

5) What is connected to your SPI interface?

是否能窺探『先機』於萬一？？