[U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
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.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Timur Tabi ti...@freescale.com
---
Note: this is only minimally tested - I just compiled a dozen of ppc
boards with it without appearent problems. Please review and test
carefully.
v2: - fix commit message
- change function prototype, too.
common/memsize.c | 14 +++---
include/common.h |2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/common/memsize.c b/common/memsize.c
index 6c275c9..b99e51b 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -37,14 +37,14 @@
* the actually available RAM size between addresses `base' and
* `base + maxsize'.
*/
-long get_ram_size(volatile long *base, long maxsize)
+phys_size_t get_ram_size(volatile phys_addr_t *base, phys_size_t maxsize)
{
- volatile long *addr;
- long save[32];
- long cnt;
- long val;
- long size;
- inti = 0;
+ volatile phys_addr_t *addr;
+ phys_size_t save[32];
+ phys_size_t cnt;
+ phys_size_t val;
+ phys_size_t size;
+ int i = 0;
for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
diff --git a/include/common.h b/include/common.h
index 8bca04f..648e00f 100644
--- a/include/common.h
+++ b/include/common.h
@@ -316,7 +316,7 @@ const char *symbol_lookup(unsigned long addr, unsigned long
*caddr);
void api_init (void);
/* common/memsize.c */
-long get_ram_size (volatile long *, long);
+phys_size_t get_ram_size(volatile phys_addr_t *, phys_size_t);
/* $(BOARD)/$(BOARD).c */
void reset_phy (void);
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
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. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Scott Wood, In message 20100527194618.gc5...@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? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. - David Jones @ Megatest Corporation ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
On 05/27/2010 02:57 PM, Wolfgang Denk wrote: Dear Scott Wood, In message20100527194618.gc5...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Scott Wood, In message 4bfecf43.40...@freescale.com you wrote: 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. Ah, right. OK, so this needs more work... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
