David,
David Hawkins wrote:
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 :)
Yes - now I now.
But it's bad feeling at first glance if compilation fails due to a
define which isn't neccessary for your config ...
I've "grep"ed the code and found nothing beside the mpc83xx assembly
file - so I defined the HRCW to "0".
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.
Of course - I feared someone is using the define ...
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.
Running the CPU as a host gives more freedom. It's also a pitty that
there are no hard-coded HRCW for host operation :-(
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 :)
Remeber to use a Prom with "extended adressing", i.e. no 24xx Microchip etc.
I'm using ROHM.
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.
There's another thread from Tor who submitted a patch for the Vitesse
VSC8601. That's the RGMII PHY I'm using.
So that'll be no problem. Communication with both PHYs is actually working.
Best of luck with the board bring-up,
thanks :-)
Cheers,
Dave
regards,
André
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
