From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <17145.12993.672427.466466@cargo.ozlabs.ibm.com> Date: Wed, 10 Aug 2005 08:48:33 +1000 From: Paul Mackerras To: Segher Boessenkool In-Reply-To: References: <17136.13558.773102.465379@cargo.ozlabs.ibm.com> <42F79D89.3040709@austin.ibm.com> Cc: Joel Schopp , linuxppc-dev@ozlabs.org, linuxppc64-dev@ozlabs.org Subject: Re: Merging ppc32 and ppc64 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Segher Boessenkool writes: > _Please_ don't throw the real device tree away; I'm happy with > the flattened device tree if and only if it is a _minimum_ > requirement, and having a _real_ device tree (or even real > Open Firmware support) is still an option. Aarrgh! There seems to be a lot of misunderstanding about the flattened device tree concept. The flattened device tree is simply a representation of a device tree (i.e., the full, or "real" (whatever that means) device tree) that does not contain any pointers and is in a single contiguous block of memory. On systems with open firmware, the boot is separated into two phases. In the first phase, OF is still active. The kernel is not based at physical address 0, and can do OF client calls. In the second phase, the kernel is based at physical address 0 and OF's memory has been reclaimed by the kernel. The flattened device tree is the main data structure that is passed from the first phase to the second. One of the first things that the second phase does is to expand the flattened device tree into the normal in-kernel device tree representation (a tree of struct device_node). Having the flattened device tree doesn't mean that we will be using the device tree less, it means we will be using it _more_. Paul.