Device Trees - Revision history

Tim-brown: Changed 'datum' to its plural 'data'

2012-05-03T14:23:29Z

Changed 'datum' to its plural 'data'

2011-05-09T14:44:10Z

Add Category Bootloader, Kernel

2009-08-03T19:01:58Z

‎Mailing list discussion

2009-08-03T18:55:39Z

‎for board designers

2009-08-03T18:54:12Z

‎for System on Chip (SoC) vendors

2009-08-03T18:52:23Z

Make is... and is not... sections subsections of the introduction

2009-08-03T18:40:46Z

Clarify what the FDT is not

2009-08-03T18:26:19Z

Consolidate tool and documentation information to the resources section

2009-08-03T18:05:36Z

Add Microblaze as supported arch

2009-08-03T07:44:44Z

‎board specific data structures

@@ Line 89: / Line 89: @@
 structure is passed to it.  PowerPCs board info structure ended up being
 a mess of #ifdefs and ugly hacks, and it still only passed a handful of
-datum like memory size and Ethernet MAC addresses.
+data like memory size and Ethernet MAC addresses.
 ATAGs have the elegance of providing an well defined namespace for

← Older revision		Revision as of 14:44, 9 May 2011
Line 166:		Line 166:
	David Gibson defends FDT:		David Gibson defends FDT:
	http://lkml.indiana.edu/hypermail/linux/kernel/0905.3/02304.html		http://lkml.indiana.edu/hypermail/linux/kernel/0905.3/02304.html
		+	[[Category:Bootloader]]
		+	[[Category:Kernel]]

@@ Line 161: / Line 161: @@
 http://lkml.indiana.edu/hypermail/linux/kernel/0905.3/01942.html
 (see whole thread for interesting discussion)
 David Gibson defends FDT:
 http://lkml.indiana.edu/hypermail/linux/kernel/0905.3/02304.html

@@ Line 51: / Line 51: @@
 === for board designers ===
-* Reduce effort required to port.  SoC vendor supplied board port for reference design may also be bootable on custom machine.
+* Reduce effort required to port.
-* No need to allocate a new global ARM machine id for each new board design.
+** SoC vendor supplied reference design binaries may also be bootable on custom machine.
 ** Use the FDT <vendor>,<boardname> namespace instead
 * Most board specific code changes constrained to FDT file and device drivers.

@@ Line 48: / Line 48: @@
 === for System on Chip (SoC) vendors ===
-* Reduce or eliminate need to write machine support code (arch/arm/mach-*).  Focus on device driver development instead.
+* Reduce or eliminate effort needed to write machine support code (ie arch/arm/mach-*).  Focus on device driver development instead.
 === for board designers ===

@@ Line 11: / Line 11: @@
 across kernel architectures.
-== The Flattened Device Tree is... ==
+=== The Flattened Device Tree is... ===
 The Flattened Device Tree (FDT) is a data structure.  Nothing more.
@@ Line 25: / Line 25: @@
 Just like initrd images, an FDT image can either be statically linked into the kernel or passed to the kernel
 at boot time.
 == Advantages ==
@@ Line 59: / Line 73: @@
 ** Xilinx FPGA tools do FDT generation
 ** U-Boot firmware can inspect and modify an FDT image before booting
 == Competing Solutions ==

@@ Line 60: / Line 60: @@
 ** U-Boot firmware can inspect and modify an FDT image before booting
-== The device tree is not.... ==
+== The Flattened Device Tree is not.... ==
 * is not a solution to all board port problems
-** Nothing will eliminate board specific drivers for custom and complex boards.
+** Nothing will eliminate all board specific drivers for custom and complex boards.
 * is not a firmware interface
 ** It might be part of a generic firmware interface, but on its own the device tree is just a data structure.
 ** does not replace ATAGS... but an FDT image can be passed via an ATAG.
 ** See "Competing Solutions" below
-* is not a method to build a generic ARM kernel.
+* is not intended to be a universal interface.
-** this does not try to build a single kernel which can boot on all ARM boards
+** It is a useful data structure which solves several problems, but whether or not to use it is still up to the board port author.
 * is not an invasive change
 ** No requirement to use FDT approach in a board port
 ** No requirement to convert existing board ports
-** No requirement to modify firmware
+** No requirement to modify existing firmware
 == Competing Solutions ==

@@ Line 10: / Line 10: @@
 device trees to other platforms, to unify the handling of platform description
 across kernel architectures.
 == The Flattened Device Tree is... ==
@@ Line 131: / Line 123: @@
 == Resources ==
 === Presentations and Papers ===
 "Using the Device Tree to Describe
 Embedded Hardware" - Grant Likely, Embedded Linux Conference, 2008
@@ Line 141: / Line 137: @@
 Note from Device Tree Birds of a Feature session at OLS 2008:
 http://lists.ozlabs.org/pipermail/devicetree-discuss/2008-July/000004.html
 ==== Coming Up Soon ====
 Grant's talk at Plumber's conference 2009 - http://linuxplumbersconf.org/ocw/proposals/47
 === Device-tree Mailing List ===
@@ Line 158: / Line 163: @@
 David Gibson defends FDT:
 http://lkml.indiana.edu/hypermail/linux/kernel/0905.3/02304.html

@@ Line 7: / Line 7: @@
 Currently the Linux kernel can read device tree information in the x86,
-PowerPC and Sparc architectures.  There is interest in extending support for
+Microblaze, PowerPC, and Sparc architectures.  There is interest in extending support for
 device trees to other platforms, to unify the handling of platform description
 across kernel architectures.

@@ Line 86: / Line 86: @@
 Some platforms use board-specific C data structures for passing data
 from the bootloader to the kernel.  Notable here is embedded PowerPC
-support before standardizing on the FDT data format and custom board
+support before standardizing on the FDT data format.
-specific ATAGs used by some ARM platforms.
 Experience with PowerPC demonstrated that using a custom C data