On Wed, May 19, 2010 at 07:03:17PM -0500, Timur Tabi wrote:
> On Wed, May 19, 2010 at 5:44 PM, Benjamin Herrenschmidt
> <b...@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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
