[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Stephen Warren]

On 12/23/2014 01:01 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 23 December 2014 at 10:34, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> Some systems have so much RAM that the end of RAM is beyond 4GB. An
>> example would be a Tegra124 system (where RAM starts at 2GB physical)
>> that has more than 2GB of RAM.
>>
>> In this case, we can gd->ram_size to represent the actual RAM size, so
>> that the actual RAM size is passed to the OS. This is useful if the OS
>> implements LPAE, and can actually use the "extra" RAM.
>>
>> However, U-Boot does not implement LPAE and so must deal with 32-bit
>> physical addresses. To this end, we enhance board_get_usable_ram_top() to
>> detect the "over-sized" case, and limit the relocation addres so that it
>> fits into 32-bits of physical address space.
>>
>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>
> Reviewed-by: Simon Glass <sjg at chromium.org>

>> diff --git a/common/board_f.c b/common/board_f.c

>>   /* Get the top of usable RAM */
>>   __weak ulong board_get_usable_ram_top(ulong total_size)
>>   {
>> +#ifdef CONFIG_SYS_SDRAM_BASE
>> +       /*
>> +        * Detect whether we have so much RAM it goes past the end of our
>> +        * 32-bit address space. If so, clip the usable RAM so it doesn't.
>> +        */
>> +       if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)
>> +               /*
>> +                * Will wrap back to top of 32-bit space when reservations
>> +                * are made.
>> +                */
>> +               return 0;
>
> I wonder whether (ulong)(1ULL << 32) would be more portable, but
> perhaps it would just be confusing. We can worry about this when we do
> more 64-bit things.

I don't think it makes any difference while board_get_usable_ram_top() 
returns a 32-bit value.

If board_get_usable_ram_top() was modified to return a 32-bit value on 
32-bit systems and a 64-bit value on 64-bit systems then:

The value "0" means "top of addressable address space" (once wrapped 
from 0 backwards when allocations are made later).

The value 1ULL<<32 means 4GB, no matter what the address space size is. 
That's quite a different thing on 64-bit.

We really do want 0 here, not a masked/clipped/overflowed 4GB value, 
since on 64-bit, if gd->ram_top ended up less than 
CONFIG_SYS_SDRAM_BASE, we'd have the exact same situation as I'm fixing 
here on 32-bit, just with much larger numbers; consider a system where 
RAM starts at (U64_MAX + 1 - 2GB) and RAM is 4GB in size; we get the 
same wrapping effect. (Admittedly that physical layout would be quite 
unlikely to happen on 64-bit since presumably no SoC designer would ever 
set CONFIG_SYS_SDRAM_BASE that high if that much RAM were supported, 
since that'd require a 64-bit system with >64-bit LPAE, which hopefully 
is many many years in the future).