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

[Timur Tabi <timur@freescale.com>]

Wolfgang Denk wrote:

>> 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.
> 
> Now this is your problem, then, and you should kno how to fix it.

Scott pointed out that writing/reading memory to determine how much memory
actually exists is dangerous.  I'm not convinced that I should be using
get_ram_size().  I still believe that I shouldn't.

>> 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.
> 
> Please see how it's done on all other PowerPC systems, and do similar.

I have not been able to find any other PowerPC system in U-boot that
supports more memory than is mapped.  If you know of one, please tell me.
Otherwise, I would say that there are no other comparable PowerPC systems
that I can use as an example.

>>> -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.
> 
> I don't know your mnemory bus. This is an RFC patch.

My point is that sizeof(phys_addr_t) has got nothing to do with the size of
the read/write operation, so I think it's wrong on all platforms.

-- 
Timur Tabi
Linux kernel developer at Freescale