From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Mon, 15 Jun 2015 09:56:16 -0700 Subject: [U-Boot] [PATCH] keystone2: use detected ddr3a size In-Reply-To: <557F0089.8030306@ti.com> References: <1434372481-1166-1-git-send-email-vitalya@ti.com> <20150615141752.GP1728@bill-the-cat> <557F0089.8030306@ti.com> Message-ID: <557F03B0.7070705@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >> >> 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