MPC83xx HRCW
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
Quoted 13 lines · 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.
Quoted 6 lines
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
Quoted 47 lines · Andre Schwarz
Quoted 38 lines · Jerry Van Baren
Quoted 13 lines · 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.Quoted 7 lines
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 SchwarzHi 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).
Quoted 8 lines
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.
Quoted 4 lines
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
Quoted 54 lines · Jerry Van Baren
Quoted 48 lines · Andre Schwarz
Quoted 39 lines · Jerry Van Baren
Quoted 13 lines · 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.Quoted 7 lines
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 SchwarzHi 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).
Quoted 8 lines
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.
Quoted 4 lines
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 !
Quoted 8 lines
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
Quoted 4 lines
[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
Hi Andre,
Quoted 9 lines
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).
*/
Quoted 7 lines
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:
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
Quoted 60 lines · David Hawkins
Hi Andre,
Quoted 9 lines
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).
*/Quoted 7 lines
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 instart.Sis 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 driveCFG_CLKIN_DIVsuch 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.
Quoted 7 lines
Regards,
DaveHere's the hardware design I'm working on:
MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Hi Andr?,
Quoted 4 lines
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 :)
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
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 :)
Quoted 5 lines
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
David,
Quoted 12 lines · David Hawkins
Hi Andr?,
Quoted 5 lines
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".
Quoted 4 lines
Quoted 3 lines
My fear was that the defined HRCW is actually used somewhere - which would be a bug.
Quoted 8 lines
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 ...
Quoted 6 lines
Quoted 5 lines
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.
Quoted 8 lines
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 :-(
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 6 lines
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 ?
Quoted 10 lines
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.
Quoted 3 lines
Best of luck with the board bring-up,
thanks :-)
Quoted 4 lines
Cheers,
Dave
regards,
Andr?
Quoted 10 lines
-------------------------------------------------------------------------
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