All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Donald White" <dbwhite@asu.edu>
To: "Navin Boppuri" <navin.boppuri@newisys.com>
Cc: "Linuxppc-Embedded (E-mail)" <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: SDRAM is finally working
Date: Wed, 20 Feb 2002 17:41:27 -0700	[thread overview]
Message-ID: <3C744237.BCCDC004@asu.edu> (raw)
In-Reply-To: D3A72C5007329A4F991C0DD87202259F096A65@sekhmet.ad.newisys.com


Navin,

While I have no right to ask, could you provide a tutorial on how one
goes from the SDRAM chip specifications to the UPM words?

I did a port of HHL 2.0 to an 860 board and never felt I really
understood the SDRAM initialization.  The board manufacturer provided a
set of UPM words.  These had been used by a previous vxWorks port.  But
burst mode never worked right for either and I was never confident that
the UPM words were right.

Thanks,

Don

Navin Boppuri wrote:
>
> I now have Linux kernel booting up and mounting a file system without
>any problems. I had all the timing right but my SDRAM initialization
>was messed up. My init sequence was missing a single NOP command at
>the very start. And so, things worked fine with PPCBOOT but with more
>memory intensive stuff that the kernel does, I had software emulation
>errors during the kernel boot.
>
> I appreciate all the help from Wolfgang in doing this. I got my very
>first SDRAM interface working on the 855 processor.
>
> I would like to point out to everyone in this mailing list that there
>is an App. Note from Motorola (ANxxx/D) that talks about a high speed
>SDRAM interface to the MPC823. The document is a good start for anyone
>trying to interface the 8xx processor to and SDRAM while running the
>bus at speeds greater than 50Mhz. But please NOTE that the timings
>shown in the example SDRAM interface in this App. Note for the Micron
>MT48LC* chip are very wrong. Please do not design your timing around
>this example.
>
> I looked at the sample timings from various board supports in PPCBOOT
>(eg. hermes). I manually inserted these timings into an *.mgp file for
>the MCUinit utility and looked at them in the GUI interface. But the
>final timings are totally dependent on your particular SDRAM chip ( The
>fact which Wolfgang tells us about all the time ;) ).

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-02-21  0:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-11 19:42 SDRAM is finally working Navin Boppuri
2002-02-21  0:41 ` Donald White [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-02-21 20:17 Kerl, John
2002-04-15 19:00 ` Jin Cheng
2002-04-15 19:07 Navin Boppuri

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=3C744237.BCCDC004@asu.edu \
    --to=dbwhite@asu.edu \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=navin.boppuri@newisys.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.