From: David Hawkins <dwh@ovro.caltech.edu>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] MPC83xx HRCW
Date: Fri, 28 Mar 2008 14:53:23 -0700 [thread overview]
Message-ID: <47ED68D3.2030403@ovro.caltech.edu> (raw)
In-Reply-To: <47ED5EC9.2000301@matrix-vision.de>
Hi Andr?,
> I was just wondering why there's a need to define the HRCW inside a
> header. This _only_ makes sense for the "HRCW from flash on local
> bus"-section. Any hard coded reset word or the use of an I2C Prom
> does make this obsolete.
Right. But there is also no harm in having it :)
> My fear was that the defined HRCW is actually used somewhere - which
> would be a bug.
That is true.
Code needing the values of the RCWs should be reading them
from the IMMR registers 900h (RCWLR) and 904h (RCWHR).
If you are concerned, you could have a look through the
code to check that is true.
> I'm actually bringing up my latest design. It's a MPC8343B based board
> stereo-camera board with external Altera FPGA on PCI and a MiniPCI Slot
> for different expansion. Configuring the 512MByte Micron memory was a
> little bit time consuming ... but now everything works fine.
Great!
Since my board is a cPCI peripheral, I could cheat a little,
and program all the DDR register over PCI from an x86 host.
This allowed me to sweep the clocks (MCK and DQS), mess with
ECC, etc, until I got things right.
> My HRCW resides in a write-protected EEPROM on I2C. It's very easy with
> pre-programmed EEPROMS during production ... no faults possible with
> erased/invalid flash memory.
Hmm, good point ... perhaps I'll have to use that idea ... thanks :)
> Currently I'm bringing up the two Ethernet PHYs (Vitesse VSC8601)
> in RGMII mode. Communication is already established and both PHY
> report valid links ... but no data yet.
>
> Do you have experience with RGMII on MPC834x ? Any uncommon defines ?
I've used a single PHY, but its the same as the Marvell PHYs on
the MPC8349EA-MDS-PB. I've wired it up for GMII, but I'm pretty
sure I can probably run it in DDRed RGMII mode too. I'm currently
working on UPM programming (via PCI) and writing VHDL for the
local bus UPM interface, so haven't checked out my PHY yet.
If you need a second opinion on RGMII, I can try something out
when I get to that point.
Best of luck with the board bring-up,
Cheers,
Dave
next prev parent reply other threads:[~2008-03-28 21:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-28 11:12 [U-Boot-Users] MPC83xx HRCW Andre Schwarz
2008-03-28 11:55 ` Jerry Van Baren
[not found] ` <47ECE17A.9060906@matrix-vision.de>
2008-03-28 12:24 ` Jerry Van Baren
2008-03-28 12:34 ` Andre Schwarz
2008-03-28 16:11 ` David Hawkins
2008-03-28 21:10 ` André Schwarz
2008-03-28 21:53 ` David Hawkins [this message]
2008-03-28 22:13 ` André Schwarz
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=47ED68D3.2030403@ovro.caltech.edu \
--to=dwh@ovro.caltech.edu \
--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