[U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces >32 bit

[Timur Tabi]

On Thu, May 27, 2010 at 1:11 PM, Wolfgang Denk <wd at denx.de> wrote:
> get_ram_size() used to use "long" data types for addresses and data,
> which in 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 <wd at denx.de>
> Cc: Timur Tabi <timur at freescale.com>
> ---

The problem is that on all of our PowerPC boards, the TLBs only map
the lower 2GB of memory, regardless as to how much is present.  So we
still can't use get_ram_size() to determine how much memory is in the
system, because any attempt to access memory higher than 2GB will
fail.

And even if we did have TLBs for all of memory, an attempt to access
RAM that doesn't exist will cause a machine check, which will hang
U-Boot.  So we still couldn't use get_ram_size() to determine how much
RAM actually exists.

> -long get_ram_size(volatile long *base, long maxsize)
> +phys_size_t get_ram_size(volatile phys_addr_t *base, phys_size_t maxsize)

I don't think you want 'base' to be a pointer to phys_addr_t, because
the pointer type determines how much is read/written in a single
operation.  I don't think you want to be doing 64-bit reads and
writes.

Plus, you still have this:

	for (cnt = (maxsize / sizeof (long)) >> 1; cnt > 0; cnt >>= 1) {
		addr = base + cnt;	/* pointer arith! */
		sync ();
		save[i++] = *addr;
		sync ();
		*addr = ~cnt;
	}

I'm not quite sure what this loop is doing, but I have a suspicion the
"sizeof(long)" does not match with "phys_addr_t *base".

-- 
Timur Tabi
Linux kernel developer at Freescale