From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olliver Schinagl Date: Mon, 24 Mar 2014 11:14:45 +0100 Subject: [U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long In-Reply-To: <20131021194436.EECF73811D8@gemini.denx.de> References: <524DDE54.7090709@schinagl.nl> <52521F5B.4090002@schinagl.nl> <20131015091241.48901e5c@lilith> <1381859853.7979.696.camel@snotra.buserror.net> <20131017082748.06618979@lilith> <52607AF9.7050302@schinagl.nl> <1382114601.7979.843.camel@snotra <5261BF4E.9070301@schinagl.nl> <1382138723.7979.928.camel@snotra.buserror.net> <20131021194436.EECF73811D8@gemini.denx.de> Message-ID: <53300595.4040501@schinagl.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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 >