[U-Boot] [PATCH 1/4] arm: mx5: Fix memory slowness on MX53QSB

[Fabio Estevam]

On Fri, Mar 28, 2014 at 1:32 AM, Marek Vasut <marex at denx.de> 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 at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Stefano Babic <sbabic at denx.de>
> Cc: Wolfgang Denk <wd at denx.de>

Excellent job, Marek!

Ethernet transfers are 4 times faster now and overall boot time is
greatly reduced :-)

Tested-by: Fabio Estevam <fabio.estevam at freescale.com>