From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Tue, 01 Apr 2014 10:20:19 +0200 Subject: [U-Boot] [PATCH V2 3/4] arm: mx5: Fix memory slowness on M53EVK In-Reply-To: <1395991861-6528-3-git-send-email-marex@denx.de> References: <1395991861-6528-1-git-send-email-marex@denx.de> <1395991861-6528-3-git-send-email-marex@denx.de> Message-ID: <533A76C3.3020300@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 On 28/03/2014 08:31, Marek Vasut wrote: > Fix memory access slowness on i.MX53 M53EVK 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 M53EVK, > 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 M53EVK, 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 > --- Applied to u-boot-imx, thanks ! 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 =====================================================================