[U-Boot] [PATCH 3/3] ARM: tegra: support large RAM sizes

[Stephen Warren <swarren@wwwdotorg.org>]

On 12/23/2014 01:05 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@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 want 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, we can't use get_ram_size() to verify the actual amount of RAM
>> present on such systems, since some of the RAM can't be accesses, which
>> confuses that function. Avoid calling get_ram_size() when the RAM size
>> is too large for it to work correctly. It's never actually needed anyway,
>> since there's no reason for the BCT to report the wrong RAM size.
>>
>> In systems with >=4GB RAM, we still need to clip the reported RAM size
>> since U-Boot uses a 32-bit variable to represent the RAM size in bytes.

>> diff --git a/arch/arm/cpu/tegra-common/board.c b/arch/arm/cpu/tegra-common/board.c

>> @@ -40,7 +40,27 @@ unsigned int query_sdram_size(void)
>>          size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024);
>>   #else
>>          debug("mc->mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n", emem_cfg);
>> -       size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024 * 1024);
>> +       /*
>> +        * If >=4GB RAM is present, the byte RAM size won't fit into 32-bits
>> +        * and will wrap. Clip the reported size to the maximum that a 32-bit
>> +        * variable can represent (rounded to a page).
>> +        */
>> +       if (emem_cfg >= 4096) {
>> +               size_bytes = U32_MAX & ~(0x1000 - 1);
>
> Will this return 4GB - 4KB? Why not return the full size?

A U32 can only store 4GB-1 at most, so we can never put the full 4GB 
value into size_bytes.

I aligned the value down to page alignment rather than storing 4GB-1 
there to prevent surprises elsewhere. For example, not all adjustments 
to gd->relocaddr in board_f.c page-align the allocations. In particular, 
I have enabled reserve_pram() locally for other reasons, and it just 
blindly subtracts the size from the current value of gd->relocaddr. 
Arguably that's a bug in that code, but I figured it was simplest to 
return a sensibly aligned size irrespective of that.