全面解析PowerPC架构下的扁平设备树FDT
Sailor_forever sailing_9806#163.com
(本原创文章发表于Sailor_forever 的个人blog，未经本人许可，不得用于商业用途。任何个人、媒体、其他网站不得私自抄袭；网络媒体转载请注明出处，增加原文链接，否则属于侵权行为。如有任何问题，请留言或者发邮件给sailing_9806@163.com)
http://blog.youkuaiyun.com/sailor_8318/archive/2009/12/26/5078959.aspx
【摘要】本文以MPC8378处理器、Linux2.6.25内核及U-boot1.3.4为例，讲述了如何在PowerPC架构下使用FDT。首先介绍了引入FDT的背景，接着详细介绍了FDT的组成及制作。最后介绍了U-boot及内核如何支持FDT。
【关键字】PowerPC，MPC8378，DTS，DTB，FDT，device node，property，compatible
1 背景 2
2 设备树的描述方式 2
2.1 root Node 3
2.2 chosen 3
2.3 cpus Node 3
2.4 System Memory 5
2.5 Devices 5
2.5.1 Compatible属性 6
2.5.2 Addressing 6
2.6 Interrupts and Interrupt Controllers 7
3 如何制作设备树映像 8
3.1 输入 8
3.2 输出 9
3.3 命令格式 9
4 设备树的传递途径 9
4.1 U-boot对FDT的支持 10
4.2 如何配置FDT 10
4.3 如何传递设备树 10
5 内核如何解析设备树 12
6 设备树对驱动设计产生的影响 15
1 背景
通常情况下，桌面机和服务器可以兼容大部分软件。最好的结果就是当添加新硬件时，无需重新编译Linux内核。标准的固件接口可以保证bootloader将正确的参数传递给内核。PC可以采用bios，PowerPC and Sparc采用Open-Firmware接口。但是对于嵌入式系统，软件差别太大，内核本身也是定制的，bootloader只需要传递很少的参数，因为大部分信息都是硬编码在系统的配置中的。这样同一个内核映像很难同时使用在多个不同的平台上。
早期的PowerPC平台采用特定的数据结构bd_info来传递参数，其定义在include/asm-ppc/ppcboot.h，#define来定义特定平台的数据域，但并没有什么信息来说明当前采用的是那个bd_info结构，所以必须保证在内核和bootloader中同时更新，以便保持一致。
合并32-bit (arch/ppc) 和 64-bit (arch/ppc64) PowerPC的同时，决定重新整理固件接口，建立新的目录arch/powerpc，这里所有的平台必须向内核提供Open Firmware风格的设备树，以便内核启动时可以获得当前平台的硬件配置。
2 设备树的描述方式
简单的说设备书是一种描述硬件配置信息的数据结构，包括CPU，内存，总线及相关外设。内核启动时可以解析这些信息，以此决定如何配置内核及加载那些驱动。该数据结构有一个单一的根节点“/”。每个节点有个名字并可以包含多个子节点。数据的格式遵循IEEE standard 1275。
Device tree source (.dts)采用一种易编辑的文本方式来表达设备树，device tree compiler tool (dtc)将.dts转换成binary device tree blob(.dtb)。设备树并不是控制系统设备的唯一方法，比如内核对USB和PCI已经有非常方便的检测机制。
/ { // the root node
an-empty-property;
a-child-node {
array-prop = <0x100 32>;
string-prop = "hello, world";
};
another-child-node {
binary-prop = [0102CAFE];
string-list = "yes","no","maybe";
};
};
Figure 1: Simple example of the .dts file format
2.1 root Node
设备树的起点是根节点，Model和compatible属性指明了当前平台的名字，格式为<mfg>,<board>：
Mfg是vendor，board是板子模型
Compatible属性不一定非得要，但是当两个系统在硬件配置上基本一致时，这个参数可以用于辨别当前系统。
/ {
model = "fsl,mpc8377rdb";
compatible = "fsl,mpc8377rdb";
#address-cells = <1>;
#size-cells = <1>;
aliases {
ethernet0 = &enet0;
ethernet1 = &enet1;
serial0 = &serial0;
serial1 = &serial1;
//pci0 = &pci0;
};
// Child nodes go here
};
Figure 3: Example system root node
2.2 chosen
此节点并不真正代表设备节点，而是一些虚拟的由bootloader传递给内核的一些参数，包括bootargs(cmdline)和initrd等。一般由bootloader在启动内核时添加此节点。
2.3 cpus Node
cpus节点是root节点的子节点，对于多核CPU系统，每个CPU有一个子节点。Cpus节点并不需要特别的特性，但是通常习惯指定#address-cells = <1>和#size-cells = <0>，这指定了各个CPU节点的reg属性的格式，其用于编码物理CPU号。
CPU节点的格式为cpu@x，model属性描述CPU类型，其他的是时钟频率及cache 相关属性。
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8377@0 {
device_type = "cpu";
model = "PowerPC, 8377";
reg = <0x0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <32768>;
i-cache-size = <32768>;
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
};
};
Figure 4: cpus node
cpus {
#cpus = <2>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8641@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // From uboot
clock-frequency = <0>; // From uboot
32-bit;
linux,boot-cpu;
};
PowerPC,8641@1 {
device_type = "cpu";
reg = <1>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // From uboot
clock-frequency = <0>; // From uboot
32-bit;
};
};
2.4 System Memory
描述系统内存的节点成为memory node，其为root节点的子节点，通常只用一个memory节点描述系统所有的内存范围，reg属性用来定义当前可用的各个memory范围。
memory {
device_type = "memory";
reg = <0x00000000 0x40000000>; // 256MB at 0
};
Figure 5: Memory node
2.5 Devices
一系列节点用于描述系统总线及设备，每个总线及设备在设备树种都有自己的节点。处理器的local bus通常直接作为根节点的子节点，附着在local bus上的Devices and bridges将作为其子节点。
下图显示的PLB bus上的设备包括interrupt controller, an Ethernet device,
及 OPB bridge，OPB总线上有serial devices and a Flash device
plb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
UIC0: interrupt-controller {
compatible = "ibm,uic-440gp",
"ibm,uic";
interrupt-controller;
#interrupt-cells = <2>;
};
ethernet@20000 {
compatible = "ibm,emac-440gp";
reg = <0x20000 0x70>;
interrupt-parent = <&UIC0>;
interrupts = <0 4>;
};
opb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xe0000000
0x20000000>;
serial@0 {
compatible = "ns16550";
reg = <0x0 0x10>;
interrupt-parent = <&UIC0>;
interrupts = <1 4>;
};
serial@10000 {
compatible = "ns16550";
reg = <0x10000 0x10>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
};
flash@1ff00000 {
compatible = "amd,s29gl256n",
"cfi-flash";
reg = <0x1ff00000 0x100000>;
};
};
};
Figure 6: Simple System Device Hierarchy
2.5.1 Compatible属性
几乎每个设备都有compatible属性，OS利用此关键字来确定node所描述的设备，通常compatible字符串的格式如下：
<manufacturer>,<part-num>
对于每个特定的compatible值，需要为该设备定义一个device tree binding。
有时候compatible是一系列字符串，如果某个设备在寄存器级别和某个旧设备兼容，则可以同时指定多个字串，这样OS就知道这两个驱动是兼容的。通常该设备的compatible字串在前，然后是兼容的旧设备的字串。
2.5.2 Addressing
设备地址由reg属性指定，其为一系列cell单元。格式如下：
reg = <base1 size1 [base2 size2 [...]]>;
每个reg的实际大小有父节点的#address-cells and #size-cells属性决定，#address-cells是用来指定base address基地址的cells个数，#size-cells是用来指定region size的cells个数。Reg所使用的cells个数必须是（#address-cells + #size-cells）的倍数。
Reg定义的是bus address，而非system address，bus address是设备依赖的总线上的相对地址，或者更专业的说bus address是相对于父节点的。
Ranges属性可以将bus address映射到父节点一级，格式如下：
ranges = <addr1 parent1 size1 [...]>;
addr为总线地址，宽度为#address-cells，parent是父节点总线上的地址，宽度为父节点的#address-cells，size宽度为父节点的#size-cells。但是当总线地址和父节点地址映射关系为1：1时，可以简化映射关系：
ranges;
在本示例中，Flash在OPB总线上的地址为0x1ff00000，但OPB总线中，PLB bus address 0xe0000000 映射到了0x0000000 on the OPB bus，因此Flash设备的地址为0xfff00000。
2.6 Interrupts and Interrupt Controllers
设备树的自然布局很方便描述设备间的简单关系，但是中断系统是个比较复杂的例子。可以将serial device描述为OPB总线的子节点，但也可以说其是interrupt controller设备的子节点，那么如何描述呢？目前的规范是，自然树的结构适用于描述那些寻址和控制设备的主要接口，次要连接可以通过phandle属性来描述相互之间的关系，其为节点中的一个指针，指向另一个节点。
对于中断连接，设备节点利用interrupt-parent and interrupts属性来描述到interrupt controller的连接。interrupt-parent是指向描述interrupt controller节点的指针，interrupts是interrupt controller可以触发的一系列中断信号。
Interrupt controller节点必须定义空属性interrupt-controller，同时定义#interrupt-cells，确定几个cells描述一个中断信号。由于Interrupt controller节点在设备树种被其他节点链接，因此必须定义属性linux,phandle = <xx>。
对于大部分SOC系统，通常只有一个interrupt controller,，但是多个interrupt controller之间可以级联。interrupt controller和设备之间的关系就形成了interrupt tree。
对于serial device node，interrupt-parent属性定义了其在中断树中与其父节点的关系。Interrupts属性定义了特定的中断标识，其格式取决于中断树中父节点的#interrupt-cells，通常#interrupt-cells为2，这样第一个值表示interrupt controller中的硬件中断编号，第二个值表示中断触发方式：电平触发或者边沿触发。
/* IPIC
* interrupts cell = <intr #, sense>
* sense values match linux IORESOURCE_IRQ_* defines:
* sense == 8: Level, low assertion
* sense == 2: Edge, high-to-low change
*/
pic@700 {
linux,phandle = <700>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
built-in;
device_type = "ipic";
};
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>;
clock-frequency = <0>;
interrupts = <9 8>;
interrupt-parent = <700>;
};
3 如何制作设备树映像
Device tree compiler(dtc)负责将文本格式的设备树转换成OS可以识别的格式。
3.1 输入
Dtc接受三种输入格式：
源文件，即device tree source；
Blob (dtb)，flattened tree format，主要用于检查现有的DTB映像；
FS文件系统，/proc/device-tree下面的文件树目录，主要用于从当前运行的内核中获得设备树映像。
-sh-3.1# ls -al /proc/device-tree
ls -l /proc/device-tree/
-r--r--r-- 1 root root 4 Jan 1 00:05 #address-cells
-r--r--r-- 1 root root 4 Jan 1 00:05 #size-cells
dr-xr-xr-x 2 root root 0 Jan 1 00:05 aliases
dr-xr-xr-x 2 root root 0 Jan 1 00:05 chosen
-r--r--r-- 1 root root 15 Jan 1 00:05 compatible
dr-xr-xr-x 3 root root 0 Jan 1 00:05 cpus
dr-xr-xr-x 15 root root 0 Jan 1 00:05 immr@e0000000
dr-xr-xr-x 4 root root 0 Jan 1 00:05 localbus@e0005000
dr-xr-xr-x 2 root root 0 Jan 1 00:05 memory
-r--r--r-- 1 root root 1 Jan 1 00:05 name
dr-xr-xr-x 2 root root 0 Jan 1 00:05 pci@e000a000
dr-xr-xr-x 2 root root 0 Jan 1 00:05 redbox-fpga-card0@F0000000
dr-xr-xr-x 2 root root 0 Jan 1 00:05 redbox-fpga-card1@F0000000
dr-xr-xr-x 2 root root 0 Jan 1 00:05 redbox-fpga-dbstate@F0000000
dr-xr-xr-x 2 root root 0 Jan 1 00:05 redbox-fpga-misc@F0000000
ls -l /proc/device-tree/immr/@e0000000/
-r--r--r-- 1 root root 4 Jan 1 00:06 #address-cells
-r--r--r-- 1 root root 4 Jan 1 00:06 #size-cells
-r--r--r-- 1 root root 4 Jan 1 00:06 bus-frequency
-r--r--r-- 1 root root 11 Jan 1 00:06 compatible
-r--r--r-- 1 root root 4 Jan 1 00:06 device_type
dr-xr-xr-x 2 root root 0 Jan 1 00:06 ethernet@24000
dr-xr-xr-x 2 root root 0 Jan 1 00:06 ethernet@25000
dr-xr-xr-x 2 root root 0 Jan 1 00:06 i2c@3000
dr-xr-xr-x 3 root root 0 Jan 1 00:06 i2c@3100
dr-xr-xr-x 2 root root 0 Jan 1 00:06 interrupt-controller@700
dr-xr-xr-x 3 root root 0 Jan 1 00:06 mdio@24520
-r--r--r-- 1 root root 5 Jan 1 00:06 name
dr-xr-xr-x 2 root root 0 Jan 1 00:06 power@b00
-r--r--r-- 1 root root 12 Jan 1 00:06 ranges
-r--r--r-- 1 root root 8 Jan 1 00:06 reg
dr-xr-xr-x 2 root root 0 Jan 1 00:06 serial@4500
dr-xr-xr-x 2 root root 0 Jan 1 00:06 serial@4600
dr-xr-xr-x 2 root root 0 Jan 1 00:06 spi@7000
dr-xr-xr-x 2 root root 0 Jan 1 00:06 timer@500
dr-xr-xr-x 2 root root 0 Jan 1 00:06 usb@23000
dr-xr-xr-x 2 root root 0 Jan 1 00:06 wdt@200
3.2 输出
Blob (dtb)，主要用于从DTS获得设备树映像；
source (dts), 当输入参数为Blob (dtb)，可以“反汇编”出设备树源文件；
assembler source (asm)，其最终可以编译成.O文件，可以链接到bootloader中或者frrmware image。
3.3 命令格式
dtc [-I <input -format > ] [-O <output -format > ] [-o output-filename] [-V output_version] input_filename
dtc -I dts -O dtb -S 0x3000 -o obj_name.dtb source_name.dts
-S 指定的是生成的dtb文件的大小，需要适当地扩大以供u-boot 创建/choose节点时使用
4 设备树的传递途径
对于Open Firmware (OF)系统，prom_init.c中的代码负责解析设备树，并将其转化为blob印象。
对于无Open Firmware (OF)的系统，内核可以直接从入口启动，并接受外部传递的flattened device tree参数。对于嵌入式系统，此参数由bootloader提供，或者封装过的zImage映像提供。
4.1 U-boot对FDT的支持
U-boot为了支持FDT，专门添加了新的代码，如下：
/Libfdt目录
fdt.h
libfdt.h
fdt_support.h
fdt_support.c
4.2 如何配置FDT
通常在板子配置头文件定义相关宏，以支持FDT
/* Pass open firmware flat tree */
#define CONFIG_OF_LIBFDT 1
#define CONFIG_OF_BOARD_SETUP 1
#define CONFIG_OF_STDOUT_VIA_ALIAS 1
CONFIG_OF_BOARD_SETUP宏表示会对设备树中的部分参数进行调整，主要是timebase-frequency，bus-frequency，clock-frequency等参数，在设备树配置文件中，这些参数可能为0，即采用U-boot中的参数。
4.3 如何传递设备树
Lib_ppc/board.c中do_bootm_linux负责启动Linux内核。
#if defined(CONFIG_OF_LIBFDT)
#include <fdt.h>
#include <libfdt.h>
#include <fdt_support.h>
static void fdt_error (const char *msg);
static int boot_get_fdt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
bootm_headers_t *images, char **of_flat_tree, ulong *of_size);
static int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
char **of_flat_tree, ulong *of_size);
#endif
相关流程如下：
在该流程中，主要从启动参数中找出设备树，然后在设备树中添加chosen 节点， 并将initrd 的地址地址，结束地址，bootargs,cmd_line 等参数保存到chosen 节点中，最后根据是否支持扁平设备树选择不同的内核启动方式。
#if defined(CONFIG_OF_LIBFDT)
if (of_flat_tree) { /* device tree; boot new style */
/*
* Linux Kernel Parameters (passing device tree):
* r3: pointer to the fdt, followed by the board info data
* r4: physical pointer to the kernel itself
* r5: NULL
* r6: NULL
* r7: NULL
*/
debug (" Booting using OF flat tree.../n");
(*kernel) ((bd_t *)of_flat_tree, (ulong)kernel, 0, 0, 0);
/* does not return */
} else
#endif
{
/*
* Linux Kernel Parameters (passing board info data):
* r3: ptr to board info data
* r4: initrd_start or 0 if no initrd
* r5: initrd_end - unused if r4 is 0
* r6: Start of command line string
* r7: End of command line string
*/
debug (" Booting using board info.../n");
(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);
/* does not return */
}
如果未定义CONFIG_OF_LIBFDT或者当前bootm命令没有FDT参数时则采用传统的方式启动内核。
启动命令格式如下：
Bootm kernel_addr ramdisk_addr/- fdt_addr
当不采用ramdisk时，第二个参数为“-”
5 内核如何解析设备树
1）首先将从u-boot 传递过来的映像基地址和dtb 文件映像基地址保存通用寄存器r30,r31；
2）通过调用machine_init()、early_init_devtree()函数来获取内核前期初始化所需的bootargs,cmd_line等系统引导参数；
3）调用start_kernel()、setup_arch()、unflatten_device_tree（）函数来解析dtb 文件，构建一个由device_node 结构连接而成的单项链表，并使用全局变量allnodes 指针来保存这个链表的头指针；
4）内核调用OF 提供的API 函数获取allnodes链表信息来初始化内核其他子系统、设备等。
Head_32.S
/*
* This is where the main kernel code starts.
*/
start_here:
。。。。
/*
* Do early platform-specific initialization,
* and set up the MMU.
*/
mr r3,r31
mr r4,r30
bl machine_init
/*
* Find out what kind of machine we're on and save any data we need
* from the early boot process (devtree is copied on pmac by prom_init()).
* This is called very early on the boot process, after a minimal
* MMU environment has been set up but before MMU_init is called.
*/
void __init machine_init(unsigned long dt_ptr, unsigned long phys)
{
/* If btext is enabled, we might have a BAT setup for early display,
* thus we do enable some very basic udbg output
*/
#ifdef CONFIG_BOOTX_TEXT
udbg_putc = btext_drawchar;
#endif
/* Do some early initialization based on the flat device tree */
early_init_devtree(__va(dt_ptr));
}
/* Warning, IO base is not yet inited */
void __init setup_arch(char **cmdline_p)
{
*cmdline_p = cmd_line;
/* so udelay does something sensible, assume <= 1000 bogomips */
loops_per_jiffy = 500000000 / HZ;
unflatten_device_tree();
…..
}
/**
* unflattens the device-tree passed by the firmware, creating the
* tree of struct device_node. It also fills the "name" and "type"
* pointers of the nodes so the normal device-tree walking functions
* can be used (this used to be done by finish_device_tree)
*/
void __init unflatten_device_tree(void)
{
unsigned long start, mem, size;
struct device_node **allnextp = &allnodes;
DBG(" -> unflatten_device_tree()/n");
/* First pass, scan for size */
start = ((unsigned long)initial_boot_params) +
initial_boot_params->off_dt_struct;
size = unflatten_dt_node(0, &start, NULL, NULL, 0);
size = (size | 3) + 1;
DBG(" size is %lx, allocating.../n", size);
/* Allocate memory for the expanded device tree */
mem = lmb_alloc(size + 4, __alignof__(struct device_node));
mem = (unsigned long) __va(mem);
((u32 *)mem)[size / 4] = 0xdeadbeef;
DBG(" unflattening %lx.../n", mem);
/* Second pass, do actual unflattening */
start = ((unsigned long)initial_boot_params) +
initial_boot_params->off_dt_struct;
unflatten_dt_node(mem, &start, NULL, &allnextp, 0);
if (*((u32 *)start) != OF_DT_END)
printk(KERN_WARNING "Weird tag at end of tree: %08x/n", *((u32 *)start));
if (((u32 *)mem)[size / 4] != 0xdeadbeef)
printk(KERN_WARNING "End of tree marker overwritten: %08x/n",
((u32 *)mem)[size / 4] );
*allnextp = NULL;
/* Get pointer to OF "/chosen" node for use everywhere */
of_chosen = of_find_node_by_path("/chosen");
if (of_chosen == NULL)
of_chosen = of_find_node_by_path("/chosen@0");
DBG(" <- unflatten_device_tree()/n");
}
6 设备树对驱动设计产生的影响
TBD
3172
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
