From: Stefano Babic <sbabic@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:21:38 +0200 [thread overview]
Message-ID: <53391782.8060100@denx.de> (raw)
In-Reply-To: <1395991861-6528-1-git-send-email-marex@denx.de>
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
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
next prev parent reply other threads:[~2014-03-31 7:21 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 ` Stefano Babic [this message]
2014-03-31 7:48 ` [U-Boot] [PATCH V2 1/4] arm: mx5: Fix memory slowness on MX53QSB Marek Vasut
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=53391782.8060100@denx.de \
--to=sbabic@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