All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Andrianov <vitalya@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] keystone2: use detected ddr3a size
Date: Mon, 15 Jun 2015 12:42:49 -0400	[thread overview]
Message-ID: <557F0089.8030306@ti.com> (raw)
In-Reply-To: <20150615141752.GP1728@bill-the-cat>



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

Thanks,
Vitaly

  reply	other threads:[~2015-06-15 16:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15 12:48 [U-Boot] [PATCH] keystone2: use detected ddr3a size Vitaly Andrianov
2015-06-15 14:17 ` Tom Rini
2015-06-15 16:42   ` Vitaly Andrianov [this message]
2015-06-15 16:56     ` York Sun
2015-06-17 17:11       ` Vitaly Andrianov
2015-06-18 15:57     ` Tom Rini
2015-06-23 12:24       ` Vitaly Andrianov
2015-06-23 14:08         ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=557F0089.8030306@ti.com \
    --to=vitalya@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.