[U-Boot-Users] MPC83xx HRCW

[U-Boot-Users] MPC83xx HRCW

[Andre Schwarz]

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 ?




regards,
Andre Schwarz
Matrix Vision

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

[U-Boot-Users] MPC83xx HRCW

[Jerry Van Baren]

Andre Schwarz wrote:
> 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 ?
> 
> regards,
> Andre Schwarz

Hi Andre,

The HRCW in flash (could be other memory or a FPGA register) is a 
processor feature which a board may or may not use.  I am not familiar 
with the whole 83xx family, but I presume the feature is part of the 
whole family.

As you point out, there are other ways of configuring the processor on 
power up, and it is board-specific which way is used on the particular 
board.

For the boards that support the HRCW, obviously the definition in the 
first 64 bytes of flash is necessary.  For other boards, it is 
unnecessary.  FWIIW, the Freescale eval boards that I have experience 
with allow the HRCW to come from flash, i2c, or an FPGA (BCSR).

To date, having a potentially unused HRCW definition in memory has not 
been an issue - people either use it or ignore it.  If it is an issue, 
you could use conditionals to disable it.  I'm sure the 83xx custodian 
(Kim Phillips) would consider patches to do that.  ;-)  Note that there 
is a possibility that some of the code assumes the presence of a HRCW, 
so you would have to inspect and/or regression test as part of a 
conditionalization patch.

On the other hand, the HRCW is occupying 64 bytes of memory that is 
marked "reserved" by Freescale/PowerPC, so it doesn't "cost" anything to 
have an unused HRCW programmed there.  (We also put the u-boot version 
string in the reserved space which is a violation of the "reserved" 
marking, but it is convenient to put it in a well known place at the 
start of the memory map and, besides, we've gotten away with it for 
years ;-).

Best regards,
gvb

[U-Boot-Users] MPC83xx HRCW

[Jerry Van Baren]

Andre Schwarz wrote:
> Jerry Van Baren schrieb:
>> Andre Schwarz wrote:
>>> 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 ?
>>>
>>> regards,
>>> Andre Schwarz
>>
>> Hi Andre,
>>
>> The HRCW in flash (could be other memory or a FPGA register) is a 
>> processor feature which a board may or may not use.  I am not familiar 
>> with the whole 83xx family, but I presume the feature is part of the 
>> whole family.
>>
>> As you point out, there are other ways of configuring the processor on 
>> power up, and it is board-specific which way is used on the particular 
>> board.
>>
>> For the boards that support the HRCW, obviously the definition in the 
>> first 64 bytes of flash is necessary.  For other boards, it is 
>> unnecessary.  FWIIW, the Freescale eval boards that I have experience 
>> with allow the HRCW to come from flash, i2c, or an FPGA (BCSR).
>>
>> To date, having a potentially unused HRCW definition in memory has not 
>> been an issue - people either use it or ignore it.  If it is an issue, 
>> you could use conditionals to disable it.  I'm sure the 83xx custodian 
>> (Kim Phillips) would consider patches to do that.  ;-)  Note that 
>> there is a possibility that some of the code assumes the presence of a 
>> HRCW, so you would have to inspect and/or regression test as part of a 
>> conditionalization patch.
>>
> ok - so should be no problem to #define the HRCW to "0x0" since it won't 
> be used at all - just occupies some memory.
> I just wanted to be sure that the #defined HRCW is not used as a 
> reference at all in any code !

Theoretically, there is no problem.  I don't know if there are any 
implicit uses of the HRCW - that would be part of the need to inspect 
and/or regression test.

I suspect that the CPU frequency determination code uses it, since part 
of the CPU PLL multiplier comes from the HRCW (IIRC - I get confused 
between the 82xx and 83xx families sometimes).

[snip]

Best regards,
gvb

[U-Boot-Users] MPC83xx HRCW

[Andre Schwarz]

Jerry Van Baren schrieb:
> Andre Schwarz wrote:
>> Jerry Van Baren schrieb:
>>> Andre Schwarz wrote:
>>>> 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 ?
>>>>
>>>> regards,
>>>> Andre Schwarz
>>>
>>> Hi Andre,
>>>
>>> The HRCW in flash (could be other memory or a FPGA register) is a 
>>> processor feature which a board may or may not use.  I am not 
>>> familiar with the whole 83xx family, but I presume the feature is 
>>> part of the whole family.
>>>
>>> As you point out, there are other ways of configuring the processor 
>>> on power up, and it is board-specific which way is used on the 
>>> particular board.
>>>
>>> For the boards that support the HRCW, obviously the definition in 
>>> the first 64 bytes of flash is necessary.  For other boards, it is 
>>> unnecessary.  FWIIW, the Freescale eval boards that I have 
>>> experience with allow the HRCW to come from flash, i2c, or an FPGA 
>>> (BCSR).
>>>
>>> To date, having a potentially unused HRCW definition in memory has 
>>> not been an issue - people either use it or ignore it.  If it is an 
>>> issue, you could use conditionals to disable it.  I'm sure the 83xx 
>>> custodian (Kim Phillips) would consider patches to do that.  ;-)  
>>> Note that there is a possibility that some of the code assumes the 
>>> presence of a HRCW, so you would have to inspect and/or regression 
>>> test as part of a conditionalization patch.
>>>
>> ok - so should be no problem to #define the HRCW to "0x0" since it 
>> won't be used at all - just occupies some memory.
>> I just wanted to be sure that the #defined HRCW is not used as a 
>> reference at all in any code !
>
> Theoretically, there is no problem.  I don't know if there are any 
> implicit uses of the HRCW - that would be part of the need to inspect 
> and/or regression test.
>
> I suspect that the CPU frequency determination code uses it, since 
> part of the CPU PLL multiplier comes from the HRCW (IIRC - I get 
> confused between the 82xx and 83xx families sometimes).
>
Using the HRCW during SystemInit is no problem - but the _real_ one from 
the CPU register and not a #defined one.
The CPU won't start anyway if the HRCW is invalid.

I've just #defined my HRCW to "0" without any problems.

Sorry for the confusion.

regards,
Andre
> [snip]
>
> Best regards,
> gvb


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

[U-Boot-Users] MPC83xx HRCW

[David Hawkins]

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/

[U-Boot-Users] MPC83xx HRCW

[André Schwarz]

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

[U-Boot-Users] MPC83xx HRCW

[David Hawkins]

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

[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