Hi Tom, On 20 November 2014 at 10:42, Simon Glass <s...@chromium.org> wrote: > Hi Tom, > > On 20 November 2014 14:37, Tom Rini <tr...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
