On 05/19/2010 08:18 PM, David Gibson wrote:
On Wed, May 19, 2010 at 07:03:17PM -0500, Timur Tabi wrote:
On Wed, May 19, 2010 at 5:44 PM, Benjamin Herrenschmidt
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
On Thu, May 20, 2010 at 1:17 AM, David Gibson
wrote:
> Um.. what? As far as I can tell that thread is about runtime
> expanding the space given to the dtb. I'm talking about altering the
> padding on the file before giving it to u-boot in the first place.
Sorry, I guess I don't understand. Ho
On Wed, May 19, 2010 at 08:46:19PM -0500, Timur Tabi wrote:
> On Wed, May 19, 2010 at 8:18 PM, David Gibson
> wrote:
>
> > 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.
>
> That's w
On Wed, May 19, 2010 at 8:18 PM, David Gibson
wrote:
> 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.
That's what I was trying to do. Take a look at this thread:
http://lists.denx.de/
On Wed, May 19, 2010 at 07:03:17PM -0500, Timur Tabi wrote:
> On Wed, May 19, 2010 at 5:44 PM, Benjamin Herrenschmidt
> 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 b
In message:
Timur Tabi writes:
: 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
On Wed, 2010-05-19 at 19:03 -0500, Timur Tabi wrote:
> 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 o
On Wed, May 19, 2010 at 5:44 PM, Benjamin Herrenschmidt
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 s
On Wed, 2010-05-19 at 16:33 -0500, Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
>
> >> So to accommodate future boards where more padding is needed, we make the
> >> option for the -p parameter configurable.
> >
> > Can't u-boot just allocate more space ?
>
> Yes and no. U-Boot has functio
Benjamin Herrenschmidt wrote:
>> So to accommodate future boards where more padding is needed, we make the
>> option for the -p parameter configurable.
>
> Can't u-boot just allocate more space ?
Yes and no. U-Boot has functions to increase the size of an fdt, but these
functions can't be sure
On Wed, 2010-05-19 at 14:53 -0500, Timur Tabi wrote:
> Add the DTS_PADDING Kconfig option, which allows users and board defconfig
> files to specify a padding value when compiling device trees.
>
> When a device tree source (DTS) is compiled into a binary (DTB), a hard-coded
> padding of 1024 byte
Add the DTS_PADDING Kconfig option, which allows users and board defconfig
files to specify a padding value when compiling device trees.
When a device tree source (DTS) is compiled into a binary (DTB), a hard-coded
padding of 1024 bytes is used (i.e. dtc command-line parameter "-p 1024").
Although
12 matches
Mail list logo
