[U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long
Scott Wood
scottwood at freescale.com
Fri Oct 18 23:04:18 CEST 2013
On Fri, 2013-10-18 at 22:26 +0200, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <1382114601.7979.843.camel at snotra.buserror.net> you wrote:
> >
> > Did you see my other mail in this thread? This patch is sort of OK for
> > raising the get_ram_size() limit from 1 GiB to 2 GiB (with an increased
> > risk of false positives from I/O), but it can't go beyond that on
> > 32-bit. A better approach would be to get the RAM size from the memory
> > controller, which is what we do on many Freescale PPC boards.
>
> This is NOT a better approach. Reading the memory controller just
> tells you what is supposed to be there, i. e. what you programmed into
> the controller. get_ram_size() shows you what is _actually_ there,
That may be useful with simpler memory controllers where there isn't
much to get wrong other than size, but on modern DDR controllers you're
pretty screwed anyway if you don't know what's actually there. If you
don't get the size right, what are the odds you got the timing right?
We hard code a lot of other things in U-Boot such as the address of
various I/O...
And if RAM is socketed (or the board designer was nice enough to include
it with non-socketed RAM), the information should be coming from SPD
EEPROMs, not hardcoded in the U-Boot image.
> which may be a totally different thing, for example when different RAM
> chips can be fit on the board, or when the working area of the RAM is
> not the same as the actual chip size, for example due to hardware
> errors (shorts or interruptions on the address lines, etc.).
>
> get_ram_size() is a very efficient memory test that detects 95% or
> more of all RAM related hardware issues.
So call it something like test_ram_simple() and bound it by the maximum
amount of RAM that you expect to be there, so you don't accidentally
touch I/O. For RAM beyond 2G, either leave it untested or use the MMU
to test it, but don't tell the rest of the system that RAM beyond that
doesn't exist. For RAM that ends on a non-power-of-2 (below 2G), do one
final test at the end of the supplied size.
And if the test finds missing/bad RAM below the supplied limit, the
caller should generally make noise that there's a problem rather than
just use less RAM.
-Scott
More information about the U-Boot
mailing list