[U-Boot] [PATCH] arm/omap3: limit chip select iteration based on board config
Grant Erickson
marathon96 at gmail.com
Wed Jan 4 17:28:22 CET 2012
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 at gmail.com>
>>>> Cc: Tom Rini <trini at 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
More information about the U-Boot
mailing list