diff options
Diffstat (limited to 'doc/README.ebony')
| -rw-r--r-- | doc/README.ebony | 138 |
1 files changed, 138 insertions, 0 deletions
diff --git a/doc/README.ebony b/doc/README.ebony new file mode 100644 index 0000000000..12a0d70389 --- /dev/null +++ b/doc/README.ebony @@ -0,0 +1,138 @@ + IBM Ebony Board + + Last Update: September 12, 2002 +======================================================================= + +This file contains some handy info regarding U-Boot and the IBM +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 iprobe +===================== + +The i2c utilities have been tested on both Rev B. and Rev C. and +look good. The CFG_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 +iprobe should look like this (assuming you are only using a single +SO-DIMM: + +=> iprobe +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 imm command. Here are the values I currently +use: + +=> imd 50 0 10 +0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00 ................ + +=> imd 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 iprobe, then +use imd 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 imm 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. + +=> imd 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> + |