[U-Boot] [PATCH] arm/omap3: limit chip select iteration based on board config

[Grant Erickson <marathon96@gmail.com>]

On Jan 4, 2012, at 8:14 AM, Tom Rini wrote:
> On 01/04/2012 09:10 AM, Grant Erickson wrote:
>> On Jan 3, 2012, at 6:31 AM, Tom Rini wrote:
>>> On 12/22/2011 12:28 PM, Grant Erickson wrote:
>>>> Only attempt to configure and add DRAM at chip select 1 if the board has configured more than one bank of DRAM.
>>>> 
>>>> This prevents boards that have CONFIG_NR_DRAM_BANKS set to 1 from getting an incorrect DRAM size.
>>>> 
>>>> Signed-off-by: Grant Erickson <marathon96@gmail.com>
>>>> Cc: Tom Rini <trini@ti.com>
>>> 
>>> OK, what problem (and on what board) are you seeing?  Many boards only
>>> have CS0 populated with DRAM but when we try and configure CS1 the
>>> mem_ok() call fails and we don't try and use it, so we don't get a wrong
>>> amount of memory.  Thanks!
>> 
>> Tom:
>> 
>> This is on an OMAP3EVM-derived board with 64 MiB of fixed Micron MDDR DRAM.
>> 
>> The board is bootstrapped in second stage boot using X-Loader 1.46 (it'll move to U-Boot SPL really soon now). The original X-Loader 1.46 + U-Boot 2010.09 went successfully as follows:
> 
> X-Loader is misbehaving (and misconfiguring) here.  Actual OMAP3EVM also had this problem until the SPL switch.

Tom:

That makes sense; however, I have deployed boards in the field for which an in-place X-Loader update isn't trivial and for which interoperability is key. In light of that, are you willing to accept the patch?

	* For CONFIG_NR_DRAM_BANKS set to 1, we get interop with old second stage boot such as X-Loader.

	* For CONFIG_NR_DRAM_BANKS set to 2 (most boards) the behavior is exactly as it is without the patch.

What do you think?

Thanks,

Grant