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