[U-Boot-Users] MPC83xx HRCW

[André Schwarz]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080328/65092f34/attachment.htm