[U-Boot] [PATCH] fdt_support: Use CONFIG_NR_DRAM_BANKS if defined

[Tom Rini]

On Fri, May 17, 2013 at 09:26:19AM -0700, Doug Anderson wrote:

> Tom,
> 
> On Wed, May 15, 2013 at 9:51 AM, Doug Anderson <dianders at chromium.org> wrote:
> > Vadim,
> >
> > On Wed, May 15, 2013 at 8:58 AM, Vadim Bendebury <vbendeb at chromium.org> wrote:
> >> This is not a big deal for u-boot (maybe very marginally inefficient
> >> when determining the actual memory size). Is this a big deal for
> >> kernel? I mean it is easy to squash these seven memory banks into one
> >> when filling out the memory node of the device tree, the question is
> >> is it even necessary?
> >
> > I think the kernel can go either way.  It can handle 1 big bank or 7
> > banks.  The parts that were broken in the past were:
> > * U-boot would refuse to tell the kernel about more than 4 banks
> > (that's what my patch fixed).
> > * The kernel choked if it was told about a bogus 8th bank that started
> > at 0 and was 0 bytes big.
> >
> > What about if we just take my patch to support more than 4 banks
> > (Vadim now has good justification for needing it)?  ...and then we'll
> > fix our U-Boot not to tell the kernel about a bogus 8th bank (that was
> > just a bug in our config file).
> 
> Do you think it would be OK to apply my patch now given Vadim's
> justification of why we need 7 banks in U-Boot.  AKA: we need 7 banks
> so banks are a power of 2 and all the same size (which U-Boot
> assumes).
> 
> ...or would you prefer not to have it and come up with some other solution?

I think my email must have been lost in the shuffle, see
http://patchwork.ozlabs.org/patch/240687/

So yes, I've got another fix in mind that should solve this and some
other problems.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130517/481a8f15/attachment.pgp>