From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] How do ARM platform initialize DDR?
Date: Thu, 19 Sep 2013 14:08:34 -0700 [thread overview]
Message-ID: <523B67D2.2050107@freescale.com> (raw)
In-Reply-To: <20130919205713.GB5273@bill-the-cat>
On 09/19/2013 01:57 PM, Tom Rini wrote:
> On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote:
>
>> Albert,
>>
>> Pardon me if this is a dumb question. I have been working on powerpc
>> platforms in the past. Now we (the developers I work with) are exploring
>> ARM cores. I am searching how memory is initialized and found different
>> solutions. Some platforms have memory ready before u-boot even starts,
>> some simply write to a set of registers. I understand many platforms
>> don't share the IP of DDR controller. I am wondering if there is generic
>> DDR driver used by many ARM platforms, like the one we have for
>> powerpc/mpc85xx SoCs.
>
> Thinking back, as a rule of thumb, PowerPC has SPD I2C data
> available, usually. That's not the rule for ARM. One of a few choices
> happen:
> 1) ROM sets up DDR.
> 2) U-Boot/SPL sets up the DDR controller.
>
So for ARM platforms, the majority don't have the flexibility of using
different DIMMs and/or clocks?
> The problem is that the DDR controller is usually vendor-specific.
> Perhaps the flip-side here is that there's not so much a generic DDR
> driver for mpc85xx but simply one vendor for mpc85xx. Taking
> arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what you're talking about,
> arch/arm/cpu/armv7/omap-common/emif-common.c would be an ARM-world
> example (the 'EMIF' is found on a large variety of TI parts, not just
> "omap" ones).
Does it make sense to share the Freescale DDR driver across ARM and
Powerpc? Or does it make more sense to selectively copy the mpc8xxx DDR
driver to Freescale ARM subfolder to start with. If the similarity
sustains then we merge them into common driver. If not, we maintain two
separated drivers.
For those who is not familiar with, Freescale is extending products to
ARM cores. I am expecting peripherals stay relatively close, so many
driver can be reused.
York
next prev parent reply other threads:[~2013-09-19 21:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-17 15:59 [U-Boot] How do ARM platform initialize DDR? York Sun
2013-09-17 16:34 ` MJ embd
2013-09-17 16:41 ` York Sun
2013-09-17 17:07 ` MJ embd
2013-09-18 4:23 ` Sharma Bhupesh-B45370
2013-09-19 20:57 ` Tom Rini
2013-09-19 21:08 ` York Sun [this message]
2013-09-19 21:33 ` Tom Rini
2013-09-19 21:49 ` York Sun
2013-09-20 7:13 ` Mj Embd
2013-09-19 21:39 ` Wolfgang Denk
2013-09-19 21:48 ` York Sun
2013-09-25 23:30 ` [U-Boot] When to create a SoC directory for ARM York Sun
2013-09-25 23:52 ` Scott Wood
2013-09-26 1:04 ` sun york-R58495
2013-09-26 1:10 ` Scott Wood
2013-09-26 9:58 ` Wolfgang Denk
2013-09-22 13:02 ` [U-Boot] How do ARM platform initialize DDR? Timur Tabi
2013-09-22 13:00 ` Timur Tabi
2013-09-22 13:50 ` Wolfgang Denk
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=523B67D2.2050107@freescale.com \
--to=yorksun@freescale.com \
--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