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 11:21:24 +0200 [thread overview]
Message-ID: <52624F14.5040907@schinagl.nl> (raw)
In-Reply-To: <1382138758.7979.929.camel@snotra.buserror.net>
On 10/19/13 01:25, Scott Wood wrote:
> On Fri, 2013-10-18 at 18:25 -0500, Scott Wood wrote:
>> On Sat, 2013-10-19 at 01:07 +0200, Oliver Schinagl wrote:
>>> On 10/18/13 18:43, Scott Wood wrote:
>>>> On Fri, 2013-10-18 at 02:04 +0200, Oliver Schinagl wrote:
>>>>> So now that that's settled, anything fundamentally wrong with my patch? :)
>>>>
>>>> Did you see my other mail in this thread? This patch is sort of OK for
>>> Sorry I did and I got distracted from it.
>>>
>>>> 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
>>> I'd ask 'how so' but I'm not sure I'd understand anyway ;)
>>
>> Do you mean why it can't go beyond 2 GiB? The next address to probe
>> after 0x8000_0000 would be 0x1_0000_0000 which is beyond what can be
>> addressed in a 32-bit environment. I suppose you could return 4 GiB if
>> 0x8000_0000 tests OK, but nothing beyond that. You'd need a larger
>> datatype than "unsigned long" if you want to return 4 GiB, though.
>
> Oh, and if you actually had 4 GiB of RAM mapped in a 32-bit environment,
> where would I/O go?
Well you need 4 GiB of address-space don't you? If you have 2 GiB of
ram, the other 2 GiB is used as register-space isn't it. So to support 2
GiB of ram you need 4 GiB of address sapce. Granted having more then 2
GiB of ram is highly unlikly as you probably can't get ramsizes that
would fit. But the bug exists with 2 GiB, get_ram_size in its current
form, which triggered me into fixing it. get_ram_size reports negative
ram on our 2 GiB board. Obviously incidentally it doesn't hugely matter
because ramsize = get_ram_size(); you put a long inside an unsigned long
and it gets automagically fixed.
My point was simply get_ram_size is bugged, it cramps signed long into
an unsigned long, and I tried to fix that. A side effect is that upto 4
GiB of address space is fixed. :)
Oliver
>
> -Scott
>
>
>
next prev parent reply other threads:[~2013-10-19 9:21 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
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 [this message]
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=52624F14.5040907@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.