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

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

[Marek Vasut]

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>
---
 include/configs/mx53loco.h | 2 ++
 1 file changed, 2 insertions(+)

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)
-- 
1.9.0

[U-Boot] [PATCH 2/4] arm: mx5: Avoid hardcoding memory sizes on MX53QSB

[Marek Vasut]

The DRAM size can be easily detected at runtime on i.MX53. Implement
such detection on MX53QSB and adjust the rest of the macros accordingly
to use the detected values.

An important thing to note here is that we had to override the function
for trimming the effective DRAM address, get_effective_memsize(). That
is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of
the available DRAM and we don't have gd->bd->bi_dram[0].size set up at
the time the function is called, thus we cannot put this into the macro
CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the
size of the first DRAM block which we just detected.

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>
---
 board/freescale/mx53loco/mx53loco.c | 21 ++++++++++++++-------
 include/configs/mx53loco.h          | 10 +++++-----
 2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c
index 08dd66f..118ff05 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -15,6 +15,7 @@
 #include <asm/arch/clock.h>
 #include <asm/errno.h>
 #include <asm/imx-common/mx5_video.h>
+#include <asm/sizes.h>
 #include <netdev.h>
 #include <i2c.h>
 #include <mmc.h>
@@ -30,24 +31,30 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int dram_init(void)
+static uint32_t mx53_dram_size[2];
+
+phys_size_t get_effective_memsize(void)
 {
-	u32 size1, size2;
+	return mx53_dram_size[0];
+}
 
-	size1 = get_ram_size((void *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
-	size2 = get_ram_size((void *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
+int dram_init(void)
+{
+	mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, SZ_1G);
+	mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, SZ_1G);
 
-	gd->ram_size = size1 + size2;
+	gd->ram_size = mx53_dram_size[0] + mx53_dram_size[1];
 
 	return 0;
 }
+
 void dram_init_banksize(void)
 {
 	gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
-	gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+	gd->bd->bi_dram[0].size = mx53_dram_size[0];
 
 	gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
-	gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
+	gd->bd->bi_dram[1].size = mx53_dram_size[1];
 }
 
 u32 get_board_rev(void)
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index 82e0249..7f0b799 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -194,11 +194,11 @@
 
 /* Physical Memory Map */
 #define CONFIG_NR_DRAM_BANKS	2
-#define PHYS_SDRAM_1		CSD0_BASE_ADDR
-#define PHYS_SDRAM_1_SIZE	(512 * 1024 * 1024)
-#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 PHYS_SDRAM_1			CSD0_BASE_ADDR
+#define PHYS_SDRAM_1_SIZE		(gd->bd->bi_dram[0].size)
+#define PHYS_SDRAM_2			CSD1_BASE_ADDR
+#define PHYS_SDRAM_2_SIZE		(gd->bd->bi_dram[1].size)
+#define PHYS_SDRAM_SIZE			(gd->ram_size)
 #define CONFIG_VERY_BIG_RAM
 #define CONFIG_MAX_MEM_MAPPED	PHYS_SDRAM_1_SIZE
 
-- 
1.9.0

[U-Boot] [PATCH V2 2/4] arm: mx5: Avoid hardcoding memory sizes on MX53QSB

[Marek Vasut]

The DRAM size can be easily detected at runtime on i.MX53. Implement
such detection on MX53QSB and adjust the rest of the macros accordingly
to use the detected values.

An important thing to note here is that we had to override the function
for trimming the effective DRAM address, get_effective_memsize(). That
is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of
the available DRAM and we don't have gd->bd->bi_dram[0].size set up at
the time the function is called, thus we cannot put this into the macro
CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the
size of the first DRAM block which we just detected.

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>
---
 board/freescale/mx53loco/mx53loco.c | 21 ++++++++++++++-------
 include/configs/mx53loco.h          | 10 +++++-----
 2 files changed, 19 insertions(+), 12 deletions(-)

V2: Use linux/sizes.h instead of asm/sizes.h

diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c
index 08dd66f..9aa73ef 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -25,29 +25,36 @@
 #include <fsl_pmic.h>
 #include <linux/fb.h>
 #include <ipu_pixfmt.h>
+#include <linux/sizes.h>
 
 #define MX53LOCO_LCD_POWER		IMX_GPIO_NR(3, 24)
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int dram_init(void)
+static uint32_t mx53_dram_size[2];
+
+phys_size_t get_effective_memsize(void)
 {
-	u32 size1, size2;
+	return mx53_dram_size[0];
+}
 
-	size1 = get_ram_size((void *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
-	size2 = get_ram_size((void *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
+int dram_init(void)
+{
+	mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, SZ_1G);
+	mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, SZ_1G);
 
-	gd->ram_size = size1 + size2;
+	gd->ram_size = mx53_dram_size[0] + mx53_dram_size[1];
 
 	return 0;
 }
+
 void dram_init_banksize(void)
 {
 	gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
-	gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+	gd->bd->bi_dram[0].size = mx53_dram_size[0];
 
 	gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
-	gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
+	gd->bd->bi_dram[1].size = mx53_dram_size[1];
 }
 
 u32 get_board_rev(void)
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index 82e0249..7f0b799 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -194,11 +194,11 @@
 
 /* Physical Memory Map */
 #define CONFIG_NR_DRAM_BANKS	2
-#define PHYS_SDRAM_1		CSD0_BASE_ADDR
-#define PHYS_SDRAM_1_SIZE	(512 * 1024 * 1024)
-#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 PHYS_SDRAM_1			CSD0_BASE_ADDR
+#define PHYS_SDRAM_1_SIZE		(gd->bd->bi_dram[0].size)
+#define PHYS_SDRAM_2			CSD1_BASE_ADDR
+#define PHYS_SDRAM_2_SIZE		(gd->bd->bi_dram[1].size)
+#define PHYS_SDRAM_SIZE			(gd->ram_size)
 #define CONFIG_VERY_BIG_RAM
 #define CONFIG_MAX_MEM_MAPPED	PHYS_SDRAM_1_SIZE
 
-- 
1.9.0

[U-Boot] [PATCH 3/4] arm: mx5: Fix memory slowness on M53EVK

[Marek Vasut]

Fix memory access slowness on i.MX53 M53EVK 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 M53EVK, 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 M53EVK, 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>
---
 include/configs/m53evk.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index 16546c2..6f8872e 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -52,7 +52,9 @@
 #define PHYS_SDRAM_SIZE			(PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE)
 #define CONFIG_SYS_MALLOC_LEN		(10 * 1024 * 1024)
 #define CONFIG_SYS_MEMTEST_START	0x70000000
-#define CONFIG_SYS_MEMTEST_END		0xaff00000
+#define CONFIG_SYS_MEMTEST_END		0x8ff00000
+#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)
-- 
1.9.0

[U-Boot] [PATCH 4/4] arm: mx5: Avoid hardcoding memory sizes on M53EVK

[Marek Vasut]

The DRAM size can be easily detected at runtime on i.MX53. Implement
such detection on M53EVK and adjust the rest of the macros accordingly
to use the detected values.

An important thing to note here is that we had to override the function
for trimming the effective DRAM address, get_effective_memsize(). That
is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of
the available DRAM and we don't have gd->bd->bi_dram[0].size set up at
the time the function is called, thus we cannot put this into the macro
CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the
size of the first DRAM block which we just detected.

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>
---
 board/denx/m53evk/m53evk.c | 21 ++++++++++++++-------
 include/configs/m53evk.h   |  6 +++---
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/board/denx/m53evk/m53evk.c b/board/denx/m53evk/m53evk.c
index 0f71a16..de0bdb6 100644
--- a/board/denx/m53evk/m53evk.c
+++ b/board/denx/m53evk/m53evk.c
@@ -16,6 +16,7 @@
 #include <asm/imx-common/mx5_video.h>
 #include <asm/arch/spl.h>
 #include <asm/errno.h>
+#include <asm/sizes.h>
 #include <netdev.h>
 #include <i2c.h>
 #include <mmc.h>
@@ -31,24 +32,30 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int dram_init(void)
+static uint32_t mx53_dram_size[2];
+
+phys_size_t get_effective_memsize(void)
 {
-	u32 size1, size2;
+	return mx53_dram_size[0];
+}
 
-	size1 = get_ram_size((void *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
-	size2 = get_ram_size((void *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
+int dram_init(void)
+{
+	mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, SZ_1G);
+	mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, SZ_1G);
 
-	gd->ram_size = size1 + size2;
+	gd->ram_size = mx53_dram_size[0] + mx53_dram_size[1];
 
 	return 0;
 }
+
 void dram_init_banksize(void)
 {
 	gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
-	gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+	gd->bd->bi_dram[0].size = mx53_dram_size[0];
 
 	gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
-	gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
+	gd->bd->bi_dram[1].size = mx53_dram_size[1];
 }
 
 static void setup_iomux_uart(void)
diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index 6f8872e..d4d0567 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -46,10 +46,10 @@
  */
 #define CONFIG_NR_DRAM_BANKS		2
 #define PHYS_SDRAM_1			CSD0_BASE_ADDR
-#define PHYS_SDRAM_1_SIZE		(512 * 1024 * 1024)
+#define PHYS_SDRAM_1_SIZE		(gd->bd->bi_dram[0].size)
 #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 PHYS_SDRAM_2_SIZE		(gd->bd->bi_dram[1].size)
+#define PHYS_SDRAM_SIZE			(gd->ram_size)
 #define CONFIG_SYS_MALLOC_LEN		(10 * 1024 * 1024)
 #define CONFIG_SYS_MEMTEST_START	0x70000000
 #define CONFIG_SYS_MEMTEST_END		0x8ff00000
-- 
1.9.0

[U-Boot] [PATCH V2 4/4] arm: mx5: Avoid hardcoding memory sizes on M53EVK

[Marek Vasut]

The DRAM size can be easily detected at runtime on i.MX53. Implement
such detection on M53EVK and adjust the rest of the macros accordingly
to use the detected values.

An important thing to note here is that we had to override the function
for trimming the effective DRAM address, get_effective_memsize(). That
is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of
the available DRAM and we don't have gd->bd->bi_dram[0].size set up at
the time the function is called, thus we cannot put this into the macro
CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the
size of the first DRAM block which we just detected.

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>
---
 board/denx/m53evk/m53evk.c | 21 ++++++++++++++-------
 include/configs/m53evk.h   |  6 +++---
 2 files changed, 17 insertions(+), 10 deletions(-)

V2: Use linux/sizes.h instead of asm/sizes.h

diff --git a/board/denx/m53evk/m53evk.c b/board/denx/m53evk/m53evk.c
index 0f71a16..e3c29cc 100644
--- a/board/denx/m53evk/m53evk.c
+++ b/board/denx/m53evk/m53evk.c
@@ -25,30 +25,37 @@
 #include <usb/ehci-fsl.h>
 #include <linux/fb.h>
 #include <ipu_pixfmt.h>
+#include <linux/sizes.h>
 
 /* Special MXCFB sync flags are here. */
 #include "../drivers/video/mxcfb.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int dram_init(void)
+static uint32_t mx53_dram_size[2];
+
+phys_size_t get_effective_memsize(void)
 {
-	u32 size1, size2;
+	return mx53_dram_size[0];
+}
 
-	size1 = get_ram_size((void *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
-	size2 = get_ram_size((void *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
+int dram_init(void)
+{
+	mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, SZ_1G);
+	mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, SZ_1G);
 
-	gd->ram_size = size1 + size2;
+	gd->ram_size = mx53_dram_size[0] + mx53_dram_size[1];
 
 	return 0;
 }
+
 void dram_init_banksize(void)
 {
 	gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
-	gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+	gd->bd->bi_dram[0].size = mx53_dram_size[0];
 
 	gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
-	gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
+	gd->bd->bi_dram[1].size = mx53_dram_size[1];
 }
 
 static void setup_iomux_uart(void)
diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index 6f8872e..d4d0567 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -46,10 +46,10 @@
  */
 #define CONFIG_NR_DRAM_BANKS		2
 #define PHYS_SDRAM_1			CSD0_BASE_ADDR
-#define PHYS_SDRAM_1_SIZE		(512 * 1024 * 1024)
+#define PHYS_SDRAM_1_SIZE		(gd->bd->bi_dram[0].size)
 #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 PHYS_SDRAM_2_SIZE		(gd->bd->bi_dram[1].size)
+#define PHYS_SDRAM_SIZE			(gd->ram_size)
 #define CONFIG_SYS_MALLOC_LEN		(10 * 1024 * 1024)
 #define CONFIG_SYS_MEMTEST_START	0x70000000
 #define CONFIG_SYS_MEMTEST_END		0x8ff00000
-- 
1.9.0

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

[Marek Vasut]

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

[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@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>