[U-Boot-Users] MPC83xx HRCW

David Hawkins dwh at ovro.caltech.edu
Fri Mar 28 17:11:06 CET 2008


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/





More information about the U-Boot mailing list