[U-Boot] [PATCH] keystone2: use detected ddr3a size

[York Sun]

On 06/15/2015 09:42 AM, Vitaly Andrianov wrote:
> 
> 
> On 06/15/2015 10:17 AM, Tom Rini wrote:
>> On Mon, Jun 15, 2015 at 08:48:01AM -0400, Vitaly Andrianov wrote:
>>
>>> KS2 u-boot detects the ddr3a size installed to EVM. The detected size can
>>> be used instead of environment variable. Because the ddr3 configuration is
>>> done before relocation we cannot use a global variable to pass the
>>> ddr3_size to ft_board_setup(). Instead we have to use the global data
>>> structure.
>>>
>>> Because KS2 u-boot works in 32 bit address space the existing ram_size
>>> global data filed cannot be used. The maximum, which the get_ram_size()
>>> can detect is 2GB only. This patch creates the ddr3_size filed in the
>>> arch_global_data structure, which is used for that purpose.
>>>
>>> Signed-off-by: Vitaly Andrianov <vitalya at ti.com>
>>
>> So we've got a few possibilities here, yes?  Since we have the ability
>> to change the DDR modules on the board and read the sizes in the SPD
>> information U-Boot is the place where the board can find out if we have
>> say 1GB or 2GB of memory and thus has to be the one to correctly
>> populate the device tree.  So the "fix" that we're talking about for
>> Calxeda can't be applied here.
>>
>> But this also brings up http://patchwork.ozlabs.org/patch/281094/ (and
>> the follow-up of http://patchwork.ozlabs.org/patch/291219/ and
>> http://patchwork.ozlabs.org/patch/291247/) where no, we have a problem
>> that we need to fix.
>>
> Hi Tom,
> 
> If I understand correctly the patches above are about changing long to 
> unsigned long to accommodate possible 2GB of DDR size. Or to use 
> phys_addr_t for 64bit architecture. Did I miss something?
> 
> The problem with KS2 platforms is that it is a 32 bit architecture which 
> uses LPAE. So, the EVMs may have more than 2GB memory (typically 4 or 8 
> GB), but u-boot sees only 2GB maximum. That is what get_ram_size() can 
> detect.
> 
> Also it is not always possible to use SPD data to detect the DDR size 
> because not all EVMs use SODIMM. Some of them use DDR3 chips populated 
> to the main board.
> 
> Even if we uses SPD data, we detect the DDR3 size before relocation. So, 
> I believe, instead of reading the SPD EEPROM and calculate the size 
> again, it is easier just to pass the ddr3 size through the global_data.
> 

My 2 cents.

For powerpc, we have been using SPD for a long time. We use gd->ram_size to hold
the total size. For 32-bit u-boot, only 2GB memory can be used by u-boot. But
gd->ram_size still hold the total size and tells Linux.

For arm, we reuse the driver and update gd->ram_size in dram_init().

For either case, we have found it to be more complex than using the SPD data
directly. We need to take into account the actual bus width. One can put a
standard DIMM but only use half the width.

York