年底完成了公司设备从arm到ppc的移植，有很多心得需要总结，趁年后不是很忙，整理写下来。
自己也是第一次接触ppc架构的kernel（版本号：3.4.55），很多东西学习不够深入，只写个思路框架，不去深究细节，错误地方还望大家指正。
今天首先来总结下PPC的Device Tree设备树机制，之前在移植arm的uboot以及kernel时，uboot和kernel之前的传参机制在arm架构下是可以选择的，使用tags方式还是fdt方式（flattened device tree）。我选择使用tags，之前有总结过tags的传参方式，可以参考我的另一篇文章，链接如下：
http://blog.csdn.net/skyflying2012/article/details/35787971
但是阅读了PPC架构的kernel启动代码后，发现PPC架构kernel启动传参仅支持fdt方式，趁这个机会学习下fdt机制。
1 为什么要用FDT，FDT优点是什么。
从网上找到的官方解释如下：
IBM、Sun等厂家的服务器最初都采用了Firmware（一种嵌入到硬件设备中的程序，用于提供软件和硬件之间的接口），用于初始化系统配置，提供操作系统软件和硬件之间的接口，启动和运行系统。后来为了标准化和兼容性，IBM、Sun等联合推出了固件接口IEEE 1275标准，让他们的服务器如IBM PowerPCpSeries，Apple PowerPC，Sun SPARC等均采用Open Firmware，在运行时构建系统硬件的设备树信息传递给内核，进行系统的启动运行。这样做的好处有，减少内核对系统硬件的严重依赖，利于加速支持包的开发，降低硬件带来的变化需求和成本，降低对内核设计和编译的要求。
在嵌入式PowerPC中，一般使用U-Boot之类的系统引导代码，而不采用Open Firmware。早期的U-Boot使用include/asm-ppc/u-boot.h中的静态数据结构struct bd_t将板子基本信息传递给内核，其余的由内核处理。这样的接口不够灵活，硬件发生变化就需要重新定制编译烧写引导代码和内核，而且也不再适应于现在的内核。为了适应内核的发展及嵌入式PowerPC平台的千变万化，吸收标准OpenFirmware的优点，UBoot引入了扁平设备树FDT这样的动态接口，使用一个单独的FDT blob（二进制大对象，是一个可以存储二进制文件的容器）存储传递给内核的参数，一些确定信息，例如cache大小、中断路由等直接由设备树提供，而其他的信息，例如eTSEC的MAC地址、频率、PCI总线数目等由U-Boot在运行时修改。
我的理解是为了适应灵活的嵌入式平台，FDT将一些固定人为需要修改的参数信息从uboot和kernel中（如uboot下的bd_t）剥离出来，修改硬件后，不需要重新修改烧录uboot kernel，仅需要修改FDT文件即可完成对新硬件的支持。但是有一些动态修改的信息还是需要uboot以及kernel来操作，如cmdline，usb以及pci的枚举设备信息。
对比而言，arm下使用的tags方式就是需要对uboot中的tags（如mem大小等）进行修改，完成对新硬件的支持。
2 FDT怎么用，格式是什么。
FDT设备树我们可以看做是描述设备硬件配置的线性树形数据结构，开发人员需要根据设备硬件配置来编写设备树，设备树的编写提供一套完全可视化的文本形式dts（device tree source），然后利用dtc（device tree compiler）编译成kernel需要的设备数镜像文件dtb，d t c 编译器会对输入文件进行语法和语义检查，并根据L i n u x 内核的要求检查各节点及属性，将设备树源码文件（. d t s ）编译二进制文件（. d t b ），以保证内核能正常启动，一个简单的例子如下：
/ {
#address-cells = <1>;
#size-cells = <1>;
model = "test";
compatible = "test";
dcr-parent = <&{/cpus/cpu@0}>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
model = "PowerPC,460EX";
reg = <0x00000000>;
i-cache-line-size = <32>;
d-cache-line-size = <32>;
i-cache-size = <32768>;
d-cache-size = <32768>;
dcr-controller;
dcr-access-method = "native";
};
};
memory {
device_type = "memory";
reg = <0x80000000 0x40000000>;
};
chosen {
name = "chosen";
bootargs = "console=ttyS0,115200 mem=512M rdinit=/sbin/init";
};
};这是我移植kernel时根据kernel下提供的dts文件修改的，kernel下已经有很多设备的dts文件，在arch/powerpc/boot/dts下，并且也集成了dtc编译器，我上面的dts文件是arch/powerpc/boot/dts/test.dts,则我可以在kernel下运行如下命令：
make test.dtb就可以生成对应的dtb镜像。
对于开发人员来说，直接面对的是dts文件，下来就来说下dts文件的格式：
（dts格式网上有很多详细解释，并且在kernel下也有详细说明的文档，是Documentation/devicetree/booting-without-of.txt）
1 根节点
设备树的起始点称之为根节点” / ” 。属性m o d e l 指明了目标板平台或模块的名称，属性c o m p a t i b l e 值指明和目标板为同一系列的兼容的开发板名称。对于大多数3 2 位平台，属性# a d d r e s s - c e l l s 和# s i z e - c e l l s 的值一般为1 ，address-cells和size-cells分别定义了子节点地址和长度的宽度。
2 CPU节点
/ c p u s 节点是根节点的子节点，对于系统中的每一个C P U ，都有相应的节点。/ c p u s 节点没有必须指明的属性，但指明# a d d r e s s - c e l l s = < 1 > 和 # s i z e - c e l l s = < 0 > 是个好习惯，这同时指明了每个C P U 节点的r e g 属性格式，方便为物理C P U 编号。C P U 节点的单元名应该是c p u @ 0 的格式，此节点一般要指定d e v i c e _ t y p e （固定为” c p u ” ），一级数据/ 指令缓存的表项大小，一级数据/ 指令缓存的大小，核心、总线时钟频率等。在上面的示例中通过系统引导代码动态填写时钟频率相关项。
3 系统内存节点
此节点用于描述目标板上物理内存范围，一般称作/ m e m o r y 节点，可以有一个或多个。当有多个节点时，需要后跟单元地址予以区分；只有一个单元地址时，可以不写单元地址，默认为0 。
此节点包含板上物理内存的属性，一般要指定d e v i c e _ t y p e （固定为” m e m o r y ” ）和r e g 属性。其中r e g 的属性值以< 起始地址 空间大小> 的形式给出，如上示例中目标板内存起始地址为0x80000000 ，大小为1G字节。
4 /chosen节点
这个节点有一点特殊。通常，这里由O p e n F i r m w a r e 存放可变的环境信息，例如参数，默认输入输出设备。
这个节点中一般指定b o o t a r g s 及l i n u x , s t d o u t - p a t h 属性值。b o o t a r g s 属性设置为传递给内核命令行的参数字符串。l i n u x , s t d o u t - p a t h 常常为标准终端设备的节点路径名，内核会以此作为默认终端。U - B o o t 在1 . 3 . 0 版本后添加了对扁平设备树F D T 的支持，U - B o o t 加载L i n u x 内核、R a m d i s k 文件系统（如果使用的话）和设备树二进制镜像到物理内存之后，在启动执行L i n u x 内核之前，它会修改设备树二进制文件。它会填充必要的信息到设备树中，例如M A C 地址、P C I 总线数目等。U - B o o t 也会填写设备树文件中的“/ c h o s e n ”节点，包含了诸如串口、根设备（R a m d i s k 、硬盘或N F S 启动）等相关信息。U - B o o t 源码c o m m o n / c m d _ b o o t m . c 的如下代码，显示了在执行内核代码前将调用f t _ s e t u p 函数填写设备树。
dts中最多的是SOC上的外设硬件配置，因为我在移植中为了保证原来原先依赖于arm框架的代码不变（没有使用FDT），模块driver中尽量不用设备树，所以dts中没有写外设硬件配置，这个有时间再去仔细研究。
3 dtb镜像的存储格式
现在学习代码，已经不像刚毕业那会对于任何代码都会死抠细节，而是想观其大略，了解其框架，待需要细究时在仔细研究，我想这也是一种进步，能让自己在kernel星辰大海中更加从容一点。
学习代码，我一直追求弄明白原因（为什么这样做）和方法（如何做）。
首先来看dtc编译dts生成的dtb镜像文件是什么格式的。
1 设备树主要由三大部分组成：头（H e a d e r ）、结构块（S t r u c t u r e b l o c k ）、字符串块（S t r i n g s b l o c k ）。在内存中分配图如下：
头主要描述设备树的基本信息，如设备树魔数标志、设备树块大小、结构块的偏移地址等，其具体结构b o o t _ p a r a m _ h e a d e r 如下。这个结构中的值都是以大端模式表示，并且偏移地址是相对于设备树头的起始地址计算的。
/*
* This is what gets passed to the kernel by prom_init or kexec
*
* The dt struct contains the device tree structure, full pathes and
* property contents. The dt strings contain a separate block with just
* the strings for the property names, and is fully page aligned and
* self contained in a page, so that it can be kept around by the kernel,
* each property name appears only once in this page (cheap compression)
*
* the mem_rsvmap contains a map of reserved ranges of physical memory,
* passing it here instead of in the device-tree itself greatly simplifies
* the job of everybody. It's just a list of u64 pairs (base/size) that
* ends when size is 0
*/
struct boot_param_header {
__be32 magic; /* magic word OF_DT_HEADER */
__be32 totalsize; /* total size of DT block */
__be32 off_dt_struct; /* offset to structure */
__be32 off_dt_strings; /* offset to strings */
__be32 off_mem_rsvmap; /* offset to memory reserve map */
__be32 version; /* format version */
__be32 last_comp_version; /* last compatible version */
/* version 2 fields below */
__be32 boot_cpuid_phys; /* Physical CPU id we're booting on */
/* version 3 fields below */
__be32 dt_strings_size; /* size of the DT strings block */
/* version 17 fields below */
__be32 dt_struct_size; /* size of the DT structure block */
};2 结构块（structure block）
扁平设备树结构块是线性化的树形结构，和字符串块一起组成了设备树的主体，以节点形式保存目标板的
设备信息。在结构块中，节点起始标志为3 2 位常值宏O F _ D T _ B E G I N _ N O D E ，节点结束标志为宏O F _ D T _ E N D _ N O D E ；子节点定义在节点结束标志前。一个节点的基本结构如下所示：
1 . 节点起始标志O F _ D T _ B E G I N _ N O D E （即0 x 0 0 0 0 _ 0 0 0 1 ）;
2 . 节点路径或者节点单元名（v e r s i o n < 3 以及节点路径表示，v e r s i o n > 1 6 时以节点单元名表示）；
3 . 填充字节保证四字节对齐；
4 . 节点属性。每个属性以常值宏O F _ D T _ P R O P 开始，后面依次为属性值的字节长度、属性名在在字符串块
中的偏移值、属性值及字节对齐填充段；
5 . 如果存在子节点，则定义子节点。
6 . 节点结束标志O F _ D T _ E N D _ N O D E （即0 x 0 0 0 0 _ 0 0 0 2 ）。
归纳起来，一个节点可以概括为以O F _ D T _ B E G I N _ N O D E 开始，节点路径、属性列表、子节点列表以及
O F _ D T _ E N D _ N O D E 结束的序列，每一个子节点自身也是类似的结构。
3 字符串块（Strings block）
为了节省空间，对于那些属性名，尤其是很多属性名是重复冗余出现的，提取出来单独存放到字符串块。
这个块中包含了很多有结束标志的属性名字符串。在设备树的结构块中存储了这些字符串的偏移地址，因
为可以很容易的查找到属性名字符串。字符串块的引入节省嵌入式系统较为紧张的存储空间。
4 kernel如何解析FDT
我们利用dtc编译了dts文件生成dtb，那么kernel就会“反汇编”dtb，从而获取其中的配置信息，因此上面描述到的dtb文件存储格式都会在kernel的解析中体现出来。
dtb文件是独立于bootloader以及kernel存在的，dtb中的chosen节点需要uboot中进行填写，dtb镜像地址也由uboot传递给kernel，保存在r3寄存器中，但是由于我移植中dtb的chosen手动填写，并且不用uboot启动kernel，所以修改kernel启动代码，直接写死dtb的首地址，代码如下：
/* As with the other PowerPC ports, it is expected that when code
* execution begins here, the following registers contain valid, yet
* optional, information:
*
* r3 - Board info structure pointer (DRAM, frequency, MAC address, etc.)
* r4 - Starting address of the init RAM disk
* r5 - Ending address of the init RAM disk
* r6 - Start of kernel command line string (e.g. "mem=128")
* r7 - End of kernel command line string
*
*/
__HEAD
_ENTRY(_stext);
_ENTRY(_start);
/*
* Reserve a word at a fixed location to store the address
* of abatron_pteptrs
*/
nop
#device tree phy addr
lis r3, 0x81000000@h
ori r3, r3, 0x81000000@l
mr r31,r3 /* save device tree ptr */
li r24,0 /* CPU number */PPC架构kernel对FDT解析可以分为两部分：
第一步是早期解析，获取kernel启动必需的cmdline以及cpu mem等信息。
第二步是后期的完全解析，以供driver加载时获取对应配置信息使用。
由于移植中尽量让driver不使用FDT，所以今天主要分析早期解析过程，进入start kernel之前调用machine init
在arch/powerpc/kernel/setup_32.c中，machine init则调用early init devtree完成早期设备树的解析，在arch/powerpc/kernel/prom.c,代码如下：
void __init early_init_devtree(void *params)
{
phys_addr_t limit;
/* Setup flat device-tree pointer */
initial_boot_params = params;
#ifdef CONFIG_PPC_RTAS
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
#endif
#ifdef CONFIG_PPC_POWERNV
/* Some machines might need OPAL info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_opal, NULL);
#endif
#ifdef CONFIG_FA_DUMP
/* scan tree to see if dump is active during last boot */
of_scan_flat_dt(early_init_dt_scan_fw_dump, NULL);
#endif
/* Pre-initialize the cmd_line with the content of boot_commmand_line,
* which will be empty except when the content of the variable has
* been overriden by a bootloading mechanism. This happens typically
* with HAL takeover
*/
strlcpy(cmd_line, boot_command_line, COMMAND_LINE_SIZE);
/* Retrieve various informations from the /chosen node of the
* device-tree, including the platform type, initrd location and
* size, TCE reserve, and more ...
*/
of_scan_flat_dt(early_init_dt_scan_chosen_ppc, cmd_line);
/* Scan memory nodes and rebuild MEMBLOCKs */
of_scan_flat_dt(early_init_dt_scan_root, NULL);
of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
/* Save command line for /proc/cmdline and then parse parameters */
strlcpy(boot_command_line, cmd_line, COMMAND_LINE_SIZE);
parse_early_param();
/* make sure we've parsed cmdline for mem= before this */
if (memory_limit)
first_memblock_size = min(first_memblock_size, memory_limit);
setup_initial_memory_limit(memstart_addr, first_memblock_size);
/* Reserve MEMBLOCK regions used by kernel, initrd, dt, etc... */
memblock_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START);
/* If relocatable, reserve first 32k for interrupt vectors etc. */
if (PHYSICAL_START > MEMORY_START)
memblock_reserve(MEMORY_START, 0x8000);
reserve_kdump_trampoline();
#ifdef CONFIG_FA_DUMP
/*
* If we fail to reserve memory for firmware-assisted dump then
* fallback to kexec based kdump.
*/
if (fadump_reserve_mem() == 0)
#endif
reserve_crashkernel();
early_reserve_mem();
/*
* Ensure that total memory size is page-aligned, because otherwise
* mark_bootmem() gets upset.
*/
limit = ALIGN(memory_limit ?: memblock_phys_mem_size(), PAGE_SIZE);
memblock_enforce_memory_limit(limit);
memblock_allow_resize();
memblock_dump_all();
DBG("Phys. mem: %llx\n", memblock_phys_mem_size());
/* We may need to relocate the flat tree, do it now.
* FIXME .. and the initrd too? */
move_device_tree();
allocate_pacas();
DBG("Scanning CPUs ...\n");
/* Retrieve CPU related informations from the flat tree
* (altivec support, boot CPU ID, ...)
*/
of_scan_flat_dt(early_init_dt_scan_cpus, NULL);
#if defined(CONFIG_SMP) && defined(CONFIG_PPC64)
/* We'll later wait for secondaries to check in; there are
* NCPUS-1 non-boot CPUs :-)
*/
spinning_secondaries = boot_cpu_count - 1;
#endif
DBG(" <- early_init_devtree()\n");
}调用of_scan_flat_dt来遍历dtb中所有节点，调用解析函数early_init_dt_scan_chosen_ppc early_init_dt_scan_mem_ppc early_init_dt_scan_root early_init_dt_scan_cpus，分别获取chosen mem cpus节点信息，完成早期cmdline mem cpu的操作。我们来看一个mem的解析函数，代码如下：
int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
int depth, void *data)
{
unsigned long l;
char *p;
pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
if (depth != 1 || !data ||
(strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen@0") != 0))
return 0;
early_init_dt_check_for_initrd(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
if (p != NULL && l > 0)
strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE));
/*
* CONFIG_CMDLINE is meant to be a default in case nothing else
* managed to set the command line, unless CONFIG_CMDLINE_FORCE
* is set in which case we override whatever was found earlier.
*/
#ifdef CONFIG_CMDLINE
#ifndef CONFIG_CMDLINE_FORCE
if (!((char *)data)[0])
#endif
strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
#endif /* CONFIG_CMDLINE */
pr_debug("Command line is: %s\n", (char*)data);
/* break now */
return 1;
}对于fdt的处理函数主要在arch/powerpc/kernel/prom.c以及driver/of/fdt.c中。
与之前文章分析tags解析方式对比，可以看出FDT的解析跟tags解析的差别之处在于，
tags是采用注册回调函数方式，解析什么类型tags，则调用该类型对应处理函数。
fdt是采用遍历整个设备树，在处理函数中判断是否是所需要解析的内容，然后进行处理。