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/ ------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
