[U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long

[Oliver Schinagl]

On 10/19/13 01:25, Scott Wood wrote:
> On Sat, 2013-10-19 at 01:07 +0200, Oliver Schinagl wrote:
>> On 10/18/13 18:43, Scott Wood wrote:
>>> On Fri, 2013-10-18 at 02:04 +0200, Oliver Schinagl wrote:
>>>> So now that that's settled, anything fundamentally wrong with my patch? :)
>>>
>>> Did you see my other mail in this thread?  This patch is sort of OK for
>> Sorry I did and I got distracted from it.
>>
>>> raising the get_ram_size() limit from 1 GiB to 2 GiB (with an increased
>>> risk of false positives from I/O), but it can't go beyond that on
>> I'd ask 'how so' but I'm not sure I'd understand anyway ;)
>
> Do you mean why it can't go beyond 2 GiB?  The next address to probe
> after 0x8000_0000 would be 0x1_0000_0000 which is beyond what can be
Yeah why can't it go beyond 2 GiB. It should be an unsigned long, so it 
should be able to go beyond 2 GiB, as you state, upto 4 GiB on a 32-bit 
environment.

What my patch fixes is, that u-boot passes ram parameters (ramsize) via 
the global data -> ramsize. Ramsize is a phys_size_t which is defined as 
unsigned long (yay for typedef :p). Nearly all platforms pass the memory 
size to the linux kernel as gd->ramsize = get_ram_size();

And here is the bug, (unsigned long)ramsize = (signed long)get_ram_size();

 > addressed in a 32-bit environment.  I suppose you could return 4 GiB > if
 > 0x8000_0000 tests OK, but nothing beyond that.  You'd need a larger
 > datatype than "unsigned long" if you want to return 4 GiB, though.
As for returning exactly 4 GiB, assuming that register space is 0 bytes 
(impossible but lets just say for arguments sake) we now have 
0x8000_0000 addresses available, so exactly 4 GiB. If for whatever 
reason it ends up being only 4 GiB -1 byte, I don't think anybody will 
care/notice (but it would have to be taken into account I suppose?

>
> 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.
So get_ram_size() needs a brother, get_discont_ram_size? :)
>
>>> 32-bit.  A better approach would be to get the RAM size from the memory
>>> controller, which is what we do on many Freescale PPC boards.
>> Not possible for us at this moment. The memory controller is programed
>> with hard-coded values on a per board basis. I think we could
>> technically obtain values via/from the memory controller, but have no
>> knowledge at this moment. Allwinner has a tool, livesuit, which is used
>> to flash full disk images to a device. We currently guesstimate that
>> livesuit can somehow detect the memory parameters and injects it into
>> the stock bootloader. But we really have no clue if that really happens
>> or how it's done. So we rely on extracting the information from a
>> running stock android/linux and hardcode it into u-boot.
>
> So the issue is that you don't have documentation on what the values you
> program into the memory controller mean?  Can you extract the memory
> size as well from a running stock image?
Sort of, we bus-width, io-size and chip density, from those values we 
determine the chip-size/ram-size we can't exctract the actual number.

That said, io-size I think (or was it bus-width?) while programmed into 
the ram controller, isn't even highly important, it is expected that it 
is used for drive strength, 2 chips vs 4 chips, but physical examination 
of the tablet/board helps here.

Oliver
>
> BTW, shouldn't get_ram_size restore the original data in the final
> "return (maxsize)" case?  I know, patches welcome. :-)
>
> -Scott
>
>
>