RFC: ARM Boot standard for passing device tree blob

[David Gibson]

On Thu, Mar 25, 2010 at 09:04:09PM +0000, Russell King - ARM Linux wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> > Hi all,
> > 
> > Since work is being done to add ARM Flattened Device Tree support to
> > both Linux and FreeBSD, I think it would be worth while to agree on a
> > common boot interface for passing a device tree blob from firmware to
> > the kernel (or in the case of kexec, from the old to new kernels).
> > I've drafted up something quickly on fdt.secretlab.ca.  The page can
> > be found here:
> > 
> > http://fdt.secretlab.ca/Boot_Environment#ARM
> > 
> > Feel free to modify the draft on the wiki if you notice any missing
> > details.  I've also posted the current text below so it is easy to
> > review and comment on.
> > 
> > (btw, the wiki at fdt.secretlab.ca should be moving to devicetree.org
> > in the near future, but I'll keep the old domain name around.
> > devicetree.org will be used to document new device tree bindings in an
> > OS-agnostic location.)
> > 
> > 
> > == ARM ==
> > See Documentation/arm/Booting and arch/arm/include/asm/setup.h in the
> > Linux kernel source tree for background information.  Some of the
> > content of this section is extracted from those files.
> > 
> > '''Draft'''
> > 
> > ===Required System State===
> > *Quiesce all DMA
> > *CPU register contents
> > **r0 = 0
> > **r1 = Linux machine number (as defined in the ARM Linux machine database) or 0
> 
> 0 is a valid machine number.  What is your purpose of passing 0?

Presumably a machine number will need to be allocated to mean "use the
device tree instead of fixed machine number info".

> > **r2 = physical address of tagged parameter list in system RAM
> > *IRQs disabled
> > *MMU off
> > *Instruction cache either on or off
> > *Data cache turned off
> 
> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> included.
> 
> > ===Minimal state for Flattened Device Tree Boot===
> > For FDT booting, the tagged list only needs to contain a single device
> > tree tag, and the device tree blob could be appended to the end of the
> > tagged list so that everything resides in the same region of memory.
> 
> That's a bad idea.  Sometimes the tagged list can be extended by wrappers
> around the kernel, and data placed at the end of the list would be
> overwritten.
> 
> As the tagged list can encode arbitarily sized data chunks, there's no
> reason to use a pointer in the tagged list.  However, there is a problem:
> what do you do with a large chunk of data in the tagged list?  You can't
> allocate memory to copy it in the kernel because no memory allocators
> are up and running...

It's not clear that you'll need to copy it particularly soon.  The
libfdt functions we use in the zImage wrapper on powerpc will deal
fine with a device tree accessed in place, or moved about.  They are
built specifically not to assume the existence of an allocater.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson