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

[Scott Wood]

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
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.

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.

> > 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?

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

-Scott