From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Fri, 28 Mar 2014 05:34:41 +0100
Subject: [U-Boot] [PATCH 1/4] arm: mx5: Fix memory slowness on MX53QSB
In-Reply-To: <1395981165-4652-1-git-send-email-marex@denx.de>
References: <1395981165-4652-1-git-send-email-marex@denx.de>
Message-ID: <201403280534.41201.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Friday, March 28, 2014 at 05:32:42 AM, 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 non-continuous memory
> partitions mapped at 0x7000_0000 and 0xb000_0000 and each of those can
> hold up to 1GiB of DRAM memory. On MX53QSB, each of the partitions contain
> 512MiB of DRAM, which makes a total of 1GiB of memory available to the
> platform.
> 
> 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 partition starts at 0x7000_0000 and contains 512MiB
> of data. Thus, with this algorithm, U-Boot is placed at offset 0x7000_0000
> + 1GiB, which is past the DRAM available in the first partition on
> MX53QSB, but is still within the address range of the first DRAM
> partition. Because of memory wrap-around, this bug was well hidden.
> 
> There were two ideas how to solve this problem, first was to map both of
> the DRAM 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 partition. 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 partition 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 <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>

Fabio, please check the rest of the MX5x series so we squash this and don't 
produce additional technological debt here.

Thanks !

Best regards,
Marek Vasut