From: Olliver 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: Mon, 24 Mar 2014 11:14:45 +0100 [thread overview]
Message-ID: <53300595.4040501@schinagl.nl> (raw)
In-Reply-To: <20131021194436.EECF73811D8@gemini.denx.de>
Hey all,
*ping*
On 10/21/2013 09:44 PM, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <1382138723.7979.928.camel@snotra.buserror.net> you wrote:
>>
>> And the one 64-bit environment that we're about to have in U-Boot
>> (armv8) has discontiguous memory, which is another case where
>> get_ram_size() won't work.
>
> get_ram_size() is supposed to be run per memory bank. If you have
> discontiguous memory, then you probably have several memory banks that
> can be sized separately?
>
>> BTW, shouldn't get_ram_size restore the original data in the final
>> "return (maxsize)" case? I know, patches welcome. :-)
>
> Yes, get_ram_size() is non-destructive (at least in the no-error
> case; otherwise things like PRAM would not work).
Is there anything else that needs to be cleaned up in the patch I
submitted back then (other then re-basing it I suppose).
With all the sunxi stuff slowly being cleaned up, this patch came to
mind again and I was just wondering if anything needs to be done to get
it merged. There was quite a big discussion about get_ram_size() in
general, but nobody ever said if the signed long -> unsigned long was a
good fix.
Olliver
>
> Best regards,
>
> Wolfgang Denk
>
next prev parent reply other threads:[~2014-03-24 10:14 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
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 [this message]
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=53300595.4040501@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.