From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/4] arm: mx5: Fix memory slowness on MX53QSB
Date: Fri, 28 Mar 2014 05:34:41 +0100 [thread overview]
Message-ID: <201403280534.41201.marex@denx.de> (raw)
In-Reply-To: <1395981165-4652-1-git-send-email-marex@denx.de>
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
next prev parent reply other threads:[~2014-03-28 4:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 4:32 [U-Boot] [PATCH 1/4] arm: mx5: Fix memory slowness on MX53QSB Marek Vasut
2014-03-28 4:32 ` [U-Boot] [PATCH 2/4] arm: mx5: Avoid hardcoding memory sizes " Marek Vasut
2014-03-28 5:21 ` [U-Boot] [PATCH V2 " Marek Vasut
2014-03-28 4:32 ` [U-Boot] [PATCH 3/4] arm: mx5: Fix memory slowness on M53EVK Marek Vasut
2014-03-28 4:32 ` [U-Boot] [PATCH 4/4] arm: mx5: Avoid hardcoding memory sizes " Marek Vasut
2014-03-28 5:21 ` [U-Boot] [PATCH V2 " Marek Vasut
2014-03-28 4:34 ` Marek Vasut [this message]
2014-03-28 4:45 ` [U-Boot] [PATCH 1/4] arm: mx5: Fix memory slowness on MX53QSB Fabio Estevam
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=201403280534.41201.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