[PATCH] powerpc: make the padding for the device tree a configurable option

David Gibson david at gibson.dropbear.id.au
Thu May 20 11:18:21 EST 2010


On Wed, May 19, 2010 at 07:03:17PM -0500, Timur Tabi wrote:
> On Wed, May 19, 2010 at 5:44 PM, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
> 
> > It's still not kernel business to have to deal with u-boot memory
> > allocation constraints.
> 
> I agree, but it still makes sense to me to allow the padding to be configurable.
> 
> > The padding in the kernel built is intended to
> > make space for DT changes done by the zImage wrapper.
> 
> Well, okay.  I think it would be nice if we expanded that to handle
> general usage.
> 
> > Maybe we could add to libfdt a way to provide a realloc() callback to it
> > when it hits the max size, and uboot can then move things around (or
> > fail).
> 
> The problem is that the code which allocates a block for the fdt is
> completely distinct from the code that manipulates the fdt.  We'd need
> to put in either some kind of funky callback mechanism, or insist that
> every fdt exist in a block of memory allocated by some specific method
> (e.g. lmb).
> 
> I'm stuck between a rock and a hard place, it seems.  No one is
> willing to compromise on any of my ideas.  It's hard to convince our
> BSP developers that they should be pushing more code upstream when I
> get so much resistance for a such a mundane change.

Couldn't you use the configurable padding, but put the stuff to do it
into u-boot.  i.e. repad the dtb at u-boot build time, rather than
u-boot runtime.

-- 
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


More information about the Linuxppc-dev mailing list