public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long
Date: Fri, 18 Oct 2013 16:04:18 -0500	[thread overview]
Message-ID: <1382130258.7979.896.camel@snotra.buserror.net> (raw)
In-Reply-To: <20131018202659.28E95380627@gemini.denx.de>

On Fri, 2013-10-18 at 22:26 +0200, Wolfgang Denk wrote:
> Dear Scott Wood,
> 
> In message <1382114601.7979.843.camel@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

  reply	other threads:[~2013-10-18 21:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03 21:15 [U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long Oliver Schinagl
2013-10-07  2:41 ` Oliver Schinagl
2013-10-15  7:12   ` Albert ARIBAUD
2013-10-15 17:57     ` Scott Wood
2013-10-17  6:27       ` Albert ARIBAUD
2013-10-18  0:04         ` Oliver Schinagl
2013-10-18 16:43           ` Scott Wood
2013-10-18 20:26             ` Wolfgang Denk
2013-10-18 21:04               ` Scott Wood [this message]
2013-10-18 21:53                 ` Wolfgang Denk
2013-10-18 23:11               ` Oliver Schinagl
2013-10-18 23:07             ` Oliver Schinagl
2013-10-18 23:25               ` Scott Wood
2013-10-18 23:25                 ` Scott Wood
2013-10-19  9:21                   ` Oliver Schinagl
2013-10-19  9:07                 ` Oliver Schinagl
2013-10-19 18:25                   ` Tom Rini
2013-10-21 19:44                 ` Wolfgang Denk
2014-03-24 10:14                   ` Olliver Schinagl
2013-10-15 18:01 ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1382130258.7979.896.camel@snotra.buserror.net \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox