From: Oliver Schinagl <oliver+list@schinagl.nl>
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: Sat, 19 Oct 2013 01:11:00 +0200 [thread overview]
Message-ID: <5261C004.9010900@schinagl.nl> (raw)
In-Reply-To: <20131018202659.28E95380627@gemini.denx.de>
On 10/18/13 22:26, 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,
> 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.
But is my patch acceptable and does it fix the phys_size_t = long vs
phys_size_t = unsigned long 'issue'. Does this patch fix that or make it
worse? And if so, how would that needed to be fixed.
Oliver
>
> Best regards,
>
> Wolfgang Denk
>
next prev parent reply other threads:[~2013-10-18 23:11 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
2013-10-18 21:53 ` Wolfgang Denk
2013-10-18 23:11 ` Oliver Schinagl [this message]
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=5261C004.9010900@schinagl.nl \
--to=oliver+list@schinagl.nl \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.