public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 1/4] arm: mx5: Fix memory slowness on MX53QSB
Date: Mon, 31 Mar 2014 09:48:46 +0200	[thread overview]
Message-ID: <201403310948.47004.marex@denx.de> (raw)
In-Reply-To: <53391782.8060100@denx.de>

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

  reply	other threads:[~2014-03-31  7:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28  7:30 [U-Boot] [PATCH V2 1/4] arm: mx5: Fix memory slowness on MX53QSB Marek Vasut
2014-03-28  7:30 ` [U-Boot] [PATCH V3 2/4] arm: mx5: Avoid hardcoding memory sizes " Marek Vasut
2014-04-01  8:19   ` Stefano Babic
2014-03-28  7:31 ` [U-Boot] [PATCH V2 3/4] arm: mx5: Fix memory slowness on M53EVK Marek Vasut
2014-04-01  8:20   ` Stefano Babic
2014-03-28  7:31 ` [U-Boot] [PATCH V3 4/4] arm: mx5: Avoid hardcoding memory sizes " Marek Vasut
2014-04-01  8:20   ` Stefano Babic
2014-03-31  7:21 ` [U-Boot] [PATCH V2 1/4] arm: mx5: Fix memory slowness on MX53QSB Stefano Babic
2014-03-31  7:48   ` Marek Vasut [this message]
2014-03-31  9:47     ` Stefano Babic
2014-03-31  9:52       ` Marek Vasut
2014-04-01  8:19 ` Stefano Babic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201403310948.47004.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox