137 lines
		
	
	
		
			4.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
			
		
		
	
	
			137 lines
		
	
	
		
			4.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
| 			   AMCC Ebony Board
 | |
| 
 | |
| 		    Last Update: September 12, 2002
 | |
| =======================================================================
 | |
| 
 | |
| This file contains some handy info regarding U-Boot and the AMCC
 | |
| Ebony evalutation board. See the README.ppc440 for additional
 | |
| information.
 | |
| 
 | |
| 
 | |
| SWITCH SETTINGS & JUMPERS
 | |
| ==========================
 | |
| 
 | |
| Here's what I've been using successfully. If you feel inclined to
 | |
| change things ... please read the docs!
 | |
| 
 | |
| DIPSW   U46         U80
 | |
| ------------------------
 | |
| SW 1    off         on
 | |
| SW 2    on          on
 | |
| SW 3    on          on
 | |
| SW 4    off         on
 | |
| SW 5    on          off
 | |
| SW 6    on          on
 | |
| SW 7    on          off
 | |
| SW 8    on          off
 | |
| 
 | |
| J41: strapped
 | |
| J42: open
 | |
| 
 | |
| All others are factory default.
 | |
| 
 | |
| 
 | |
| I2C probe
 | |
| =====================
 | |
| 
 | |
| The i2c utilities have been tested on both Rev B. and Rev C. and
 | |
| look good. The CONFIG_SYS_I2C_NOPROBES macro is defined to prevent
 | |
| probing the CDCV850 clock controller at address 0x69 (since reading
 | |
| it causes the i2c implementation to misbehave. The output of
 | |
| 'i2c probe' should look like this (assuming you are only using a single
 | |
| SO-DIMM:
 | |
| 
 | |
| => i2c probe
 | |
| Valid chip addresses: 50 53 54
 | |
| Excluded chip addresses: 69
 | |
| 
 | |
| 
 | |
| GETTING OUT OF I2C TROUBLE
 | |
| ===========================
 | |
| 
 | |
| If you're like me ... you may have screwed up your bootstrap serial
 | |
| eeprom ... or worse, your SPD eeprom when experimenting with the
 | |
| i2c commands. If so, here are some ideas on how to get out of
 | |
| trouble:
 | |
| 
 | |
| Serial bootstrap eeprom corruption:
 | |
| -----------------------------------
 | |
| Power down the board and set the following straps:
 | |
| 
 | |
| J41 - open
 | |
| J42 - strapped
 | |
| 
 | |
| This will select the default sys0 and sys1 settings (the serial
 | |
| eeproms are not used). Then power up the board and fix the serial
 | |
| eeprom using the 'i2c mm' command. Here are the values I currently
 | |
| use:
 | |
| 
 | |
| => i2c md 50 0 10
 | |
| 0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00    ................
 | |
| 
 | |
| => i2c md 54 0 10
 | |
| 0000: 8f b3 24 01 4d 14 11 00 00 00 00 00 00 00 00 00    ..$.M...........
 | |
| 
 | |
| Once you have the eeproms set correctly change the
 | |
| J41/J42 straps as you desire.
 | |
| 
 | |
| SPD eeprom corruption:
 | |
| ------------------------
 | |
| I've corrupted the SPD eeprom several times ... perhaps too much coffee
 | |
| and not enough presence of mind ;-). By default, the ebony code uses
 | |
| the SPD to initialize the DDR SDRAM control registers. So if the SPD
 | |
| eeprom is corrupted, U-Boot will never get into ram. Here's how I got
 | |
| out of this situation:
 | |
| 
 | |
| 0. First, _before_ playing with the i2c utilities, do an 'i2c probe', then
 | |
| use 'i2c md' to capture the various device contents to a file. Some day
 | |
| you may be glad you did this ... trust me :-). Otherwise try the
 | |
| following:
 | |
| 
 | |
| 1. In the include/configs/EBONY.h file find the line that defines
 | |
| the CONFIG_SPD_EEPROM macro and undefine it. E.g:
 | |
| 
 | |
| #undef CONFIG_SPD_EEPROM
 | |
| 
 | |
| This will make the code use default SDRAM control register
 | |
| settings without using the SPD eeprom.
 | |
| 
 | |
| 2. Rebuild U-Boot
 | |
| 
 | |
| 3. Load the new U-Boot image and reboot ebony.
 | |
| 
 | |
| 4. Repair the SPD eeprom using the 'i2c mm' command. Here's the eeprom
 | |
| contents that work with the default SO-DIMM that comes with the
 | |
| ebony board (micron 8VDDT164AG-265A1). Note: these are probably
 | |
| _not_ the factory settings ... but they work.
 | |
| 
 | |
| => i2c md 53 0 10 80
 | |
| 0000: 80 08 07 0c 0a 01 40 00 04 75 75 00 80 08 00 01    ......@..uu.....
 | |
| 0010: 0e 04 0c 01 02 20 00 a0 75 00 00 50 3c 50 2d 20    ..... ..u..P<P-
 | |
| 0020: 90 90 50 50 00 00 00 00 00 41 4b 34 32 75 00 00    ..PP.....AK42u..
 | |
| 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c    ................
 | |
| 0040: 2c 00 00 00 00 00 00 00 08 38 56 44 44 54 31 36    ,........8VDDT16
 | |
| 0050: 36 34 41 47 2d 32 36 35 41 31 20 01 00 01 2c 63    64AG-265A1 ...,c
 | |
| 0060: 22 25 ab 00 00 00 00 00 00 00 00 00 00 00 00 00    "%..............
 | |
| 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
 | |
| 
 | |
| 
 | |
| PCI DOUBLE-ENUMERATION WOES
 | |
| ===========================
 | |
| 
 | |
| If you're not using PCI-X cards and are simply using 32-bit and/or
 | |
| 33 MHz cards via extenders and the like, you may notice that the
 | |
| initial pci scan reports various devices twice ... and configuration
 | |
| does not succeed (one or more devices are enumerated twice). To correct
 | |
| this we replaced the 2K ohm resistor on the IDSEL line(s) with a
 | |
| 22 ohm resistor and the problem went away. This change hasn't broken
 | |
| anything yet -- use at your own risk.
 | |
| 
 | |
| We never tested anything other than 33 MHz/32-bit cards. If you have
 | |
| the chance to do this, please let me know how things turn out :-)
 | |
| 
 | |
| 
 | |
| Regards,
 | |
| --Scott
 | |
| <smcnutt@artesyncp.com>
 |