From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Mon, 31 Mar 2014 09:21:38 +0200 Subject: [U-Boot] [PATCH V2 1/4] arm: mx5: Fix memory slowness on MX53QSB In-Reply-To: <1395991861-6528-1-git-send-email-marex@denx.de> References: <1395991861-6528-1-git-send-email-marex@denx.de> Message-ID: <53391782.8060100@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, On 28/03/2014 08:30, Marek Vasut wrote: > Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the > issue: First of all, the i.MX53 CPU has two memory banks mapped at > 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of > DRAM memory. Notice that the memory area is not continuous. On MX53QSB, > each of the banks contain 512MiB of DRAM, which makes a total of 1GiB > of memory available to the system. > > The problem is how the relocation of U-Boot is treated on i.MX53 . The > U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . > This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, > the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. > Thus, with this algorithm, U-Boot is placed at offset: > > 0x7000_0000 + 1GiB - sizeof(u-boot and some small margin) > > This is past the DRAM available in the first bank on MX53QSB, but is still > within the address range of the first DRAM bank. Because of the memory > wrap-around, the data can still be read and written to this area, but the > access is much slower. > > There were two ideas how to solve this problem, first was to map both of > the available DRAM chunks next to one another by using MMU, second was to > define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory > in the first DRAM bank. We choose the later because it turns out the former > is not applicable afterall. The former cannot be used in case Linux kernel > was loaded into the second DRAM bank area, which would be remapped and one > would try booting the kernel, since at some point before the kernel is started, > the MMU would be turned off, which would destroy the mapping and hang the > system. > > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Stefano Babic > Cc: Wolfgang Denk > --- > include/configs/mx53loco.h | 2 ++ > 1 file changed, 2 insertions(+) > > V2: Reword the commit message > > diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h > index 1415584..82e0249 100644 > --- a/include/configs/mx53loco.h > +++ b/include/configs/mx53loco.h > @@ -199,6 +199,8 @@ > #define PHYS_SDRAM_2 CSD1_BASE_ADDR > #define PHYS_SDRAM_2_SIZE (512 * 1024 * 1024) > #define PHYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE) > +#define CONFIG_VERY_BIG_RAM > +#define CONFIG_MAX_MEM_MAPPED PHYS_SDRAM_1_SIZE > > #define CONFIG_SYS_SDRAM_BASE (PHYS_SDRAM_1) > #define CONFIG_SYS_INIT_RAM_ADDR (IRAM_BASE_ADDR) > Nice works, thanks ! I will push it soon. Best regards, Stefano Babic -- ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================