[U-Boot-Users] MPC83xx HRCW

["André Schwarz" <Andre.Schwarz@matrix-vision.de>]

Hi David,

thanks for your reply.

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.

My fear was that the defined HRCW is actually used somewhere - which 
would be a bug.

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.
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.

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 ?

regards,
Andre

David Hawkins wrote:
> Hi Andre,
>
>> In "cpu/mpc83xx/start.S" there is a comment :
>>
>> /*
>>  * The Hard Reset Configuration Word (HRCW) table is in the first 64
>>  * (0x40) bytes of flash.  It has 8 bytes, but each byte is repeated 8
>>  * times so the processor can fetch it out of flash whether the flash
>>  * is 8, 16, 32, or 64 bits wide (hardware trickery).
>>  */
>>
>> This does _not_ hold true for all configurations. Flash is simply
>> one of many options ... Maybe it's true for the Freescale boards.
>>
>> Other sources of the HRCW can be hard-coded strapping pins or an
>> I2C EEPROM.
>>
>> Why is there a need to define the HRCW ?
>
> I think the main reasoning here is that the original board
> ports, eg. the Freescale development boards, used this method.
>
> For example, on the MPC8349E-MDS-PB and MPC8349EA-MDS-PB, the
> HRCW is defined in the port header file MPC8349EMDS.h, and
> the assembly code generated in the section in start.S is
> written to the Flash at the beginning of Flash - regardless
> of whether the processor will boot from high-memory (BMS = 1,
> old U-Boot code), or low-memory (BMS = 1, latest U-boot code).
> (The start code is in a different assembler section).
>
> But that being said, the MDS board doesn't have to use the Flash
> HRCW. If you change one of the toggle switches on the MDS board,
> the BCSR CPLD will drive the local bus read for the HRCW from
> a set of toggle switches, and basically over-ride the HRCW
> from Flash.
>
> Note that for the current U-Boot code, BMS = 0, so the reset
> vector occurs at 100h, and the HRCW is always read from 0h.
> Since both of these locations are withing the first sector of
> a typical Flash device, it would be 'difficult' to erase the
> Flash and write just the U-Boot start-up code without also
> writing the HRCW. Hence the reason for the code you see.
>
> In my design, I have an FPGA between the boot flash and the
> MPC8349EA processor. This allows my PORESET# code in the FPGA
> to read the flash, and if it is blank (reads 0xFFFF), it can
> place a hard-coded reset source, CFG_RS[0:2], onto the bus,
> otherwise if the Flash is not blank, CFG_RS[0:2] is driven with
> the HRCW from Flash. If I wanted to, I could have the HRCW in
> the FPGA too (I just love FPGAs :) ). Since the FPGA also reads
> the state of the cPCI M66EN signal (33MHz or 66MHz clock
> reference), it can drive CFG_CLKIN_DIV such that the processor
> always generates the same clock frequencies.
>
> I have also put an I2C EEPROM on the board, but haven't played
> with it yet.
>
> Let me know if you have any design questions, and I can share
> what I have worked on.
>
> Regards,
> Dave
>
> Here's the hardware design I'm working on:
>
> http://www.ovro.caltech.edu/~dwh/carma_board/
>


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner