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

Fix memory access slowness on i.MX53 MX53QSB 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 MX53QSB,
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 MX53QSB, 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 <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(+)

V2: Reword the commit message

Hi Marek,

On 28/03/2014 08:30, 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 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 MX53QSB,
> 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 MX53QSB, 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 <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(+)
> 
> V2: Reword the commit message
> 
> 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)
> 

Nice works, thanks ! I will push it soon.

Best regards,
Stefano Babic

On Monday, March 31, 2014 at 09:21:38 AM, Stefano Babic wrote:
> Hi Marek,
> 
> On 28/03/2014 08:30, 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 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 MX53QSB,
> > 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 MX53QSB, 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 <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(+)
> > 
> > V2: Reword the commit message
> > 
> > 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)
> 
> Nice works, thanks ! I will push it soon.

Thanks :)

There are a few more patches in your PW queue from me, please check them and 
apply as seen fit. Thanks again!

Best regards,
Marek Vasut

Hi Marek,

On 31/03/2014 09:48, Marek Vasut wrote:

> Thanks :)
> 
> There are a few more patches in your PW queue from me, please check them and 
> apply as seen fit. Thanks again!

All patches from you (or from others) that are ok for me and ready to be
merged are marked by me in PW as "under reviewed" - there is not a
"review passed " or "ready-to-be-merged" status. You can check yourself
if some of your patches are missing.

Best regards,
Stefano Babic

On Monday, March 31, 2014 at 11:47:14 AM, Stefano Babic wrote:
> Hi Marek,
> 
> On 31/03/2014 09:48, Marek Vasut wrote:
> > Thanks :)
> > 
> > There are a few more patches in your PW queue from me, please check them
> > and apply as seen fit. Thanks again!
> 
> All patches from you (or from others) that are ok for me and ready to be
> merged are marked by me in PW as "under reviewed" - there is not a
> "review passed " or "ready-to-be-merged" status. You can check yourself
> if some of your patches are missing.

Will do, but I think you got them all. Thanks!

Best regards,
Marek Vasut

On 28/03/2014 08:30, 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 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 MX53QSB,
> 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 MX53QSB, 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 <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic