On 06/15/2015 12:56 PM, York Sun wrote:
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 <vita...@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
Hi York,
Thank you for the reply. Actually Keystone2 platforms detect ddr3 size
and that is done in ddr3_init(). The function is called before
relocation. The size detection itself can be done in many different
ways. It can be done by reading SPD data (if it is presend), or just
simply read from board configuration file (if DDR3 chips are just
soldered to the board). This patch is not about this.
This patch is how to make the ddr3 size available to other patch of the
code after relocation. The code which uses the size is common for all
KS2 SOCs and EVMs, while the ddr3_init() implementation may be different.
Regards,
-Vitaly
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
