Hi Tom,
On 20 November 2014 at 10:42, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On 20 November 2014 14:37, Tom Rini trini@ti.com wrote:
On Wed, Nov 12, 2014 at 03:14:35PM -0700, Simon Glass wrote:
[snip, and sorry for the late reply]
What I am talking about here is the memory for U-Boot - i.e. how does U-Boot know how much memory is available. The scheme here is that you can have a board ID which controls this, with the U-Boot device tree allowing the options to be specified (i.e. the mapping from board ID to SDRAM banks)
OK. So what I'm getting at is how is this different from other boards where we say "Oh, this is $FOO, it has $X LPDRR2 RAM" and "Oh, this is $BAR, it has $Y DDR3 RAM" ? The only thing I'm able to think of is that we cannot call get_ram_size() to see the _size_ of the RAM after doing $whatever to see what board we're on and doing the right configuration for the DDR controller or whatever.
Yes the memory type can go in the FDT too (and does for snow and pit).
That's right, we can call get_ram_size() but only within the known boundaries. If we try to probe a 2GB machine as if it has 4GB of RAM it will hang. So we have to *know*.
I have left this one out so far, but would like to apply it. With this I can support Pit and Pi (and with a bit more work Snow and Spring) with the same U-Boot board, dealing with the memory differences between the boards.
Regards, Simon