All of lore.kernel.org
 help / color / mirror / Atom feed
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
>

  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.