From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Thu, 27 May 2010 15:00:03 -0500 Subject: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces >32 bit In-Reply-To: <20100527195715.CD042EAC238@gemini.denx.de> References: <1274983869-9173-1-git-send-email-wd@denx.de> <1274984188-10200-1-git-send-email-wd@denx.de> <20100527194618.GC5915@schlenkerla.am.freescale.net> <20100527195715.CD042EAC238@gemini.denx.de> Message-ID: <4BFECF43.40600@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 05/27/2010 02:57 PM, Wolfgang Denk wrote: > Dear Scott Wood, > > In message<20100527194618.GC5915@schlenkerla.am.freescale.net> you wrote: >> On Thu, May 27, 2010 at 08:16:28PM +0200, Wolfgang Denk wrote: >>> get_ram_size() used to use "long" data types for addresses and data, >>> which limited it to systems with less than 4 GiB memory. As more and >>> more systems are coming up with bigger memory resources, we adapt the >>> code to use phys_addr_t / phys_size_t data types instead. >> >> This cannot work as is. The only systems where this makes a difference are >> where physical addresses are larger than virtual pointers -- but you try to >> shove the 64-bit physical offset into a 32-bit pointer. >> >> You need to create temporary mappings, if you really want to do this. > > ? > > Isn't phys_addr_t assumed to be the right data type to hold a > physical address? Yes. But you can't dereference a physical address directly. When you do "addr = base + cnt", you're throwing away the upper 32 bits. "phys_addr_t *" is not a 64-bit pointer, it is a 32-bit pointer to a 64-bit quantity. -Scott