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