| wdenk | 8bde7f7 | 2003-06-27 21:31:46 +0000 | [diff] [blame] | 1 | IBM Ebony Board |
| wdenk | c609719 | 2002-11-03 00:24:07 +0000 | [diff] [blame] | 2 | |
| wdenk | 8bde7f7 | 2003-06-27 21:31:46 +0000 | [diff] [blame] | 3 | Last Update: September 12, 2002 |
| wdenk | c609719 | 2002-11-03 00:24:07 +0000 | [diff] [blame] | 4 | ======================================================================= |
| 5 | |
| 6 | This file contains some handy info regarding U-Boot and the IBM |
| 7 | Ebony evalutation board. See the README.ppc440 for additional |
| 8 | information. |
| 9 | |
| 10 | |
| 11 | SWITCH SETTINGS & JUMPERS |
| 12 | ========================== |
| 13 | |
| 14 | Here's what I've been using successfully. If you feel inclined to |
| 15 | change things ... please read the docs! |
| 16 | |
| 17 | DIPSW U46 U80 |
| 18 | ------------------------ |
| 19 | SW 1 off on |
| 20 | SW 2 on on |
| 21 | SW 3 on on |
| 22 | SW 4 off on |
| 23 | SW 5 on off |
| 24 | SW 6 on on |
| 25 | SW 7 on off |
| 26 | SW 8 on off |
| 27 | |
| 28 | J41: strapped |
| 29 | J42: open |
| 30 | |
| 31 | All others are factory default. |
| 32 | |
| 33 | |
| 34 | I2C iprobe |
| 35 | ===================== |
| 36 | |
| 37 | The i2c utilities have been tested on both Rev B. and Rev C. and |
| 38 | look good. The CFG_I2C_NOPROBES macro is defined to prevent |
| 39 | probing the CDCV850 clock controller at address 0x69 (since reading |
| 40 | it causes the i2c implementation to misbehave. The output of |
| 41 | iprobe should look like this (assuming you are only using a single |
| 42 | SO-DIMM: |
| 43 | |
| 44 | => iprobe |
| 45 | Valid chip addresses: 50 53 54 |
| 46 | Excluded chip addresses: 69 |
| 47 | |
| 48 | |
| 49 | GETTING OUT OF I2C TROUBLE |
| 50 | =========================== |
| 51 | |
| 52 | If you're like me ... you may have screwed up your bootstrap serial |
| 53 | eeprom ... or worse, your SPD eeprom when experimenting with the |
| 54 | i2c commands. If so, here are some ideas on how to get out of |
| 55 | trouble: |
| 56 | |
| 57 | Serial bootstrap eeprom corruption: |
| 58 | ----------------------------------- |
| 59 | Power down the board and set the following straps: |
| 60 | |
| 61 | J41 - open |
| 62 | J42 - strapped |
| 63 | |
| 64 | This will select the default sys0 and sys1 settings (the serial |
| 65 | eeproms are not used). Then power up the board and fix the serial |
| 66 | eeprom using the imm command. Here are the values I currently |
| 67 | use: |
| 68 | |
| 69 | => imd 50 0 10 |
| 70 | 0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00 ................ |
| 71 | |
| 72 | => imd 54 0 10 |
| 73 | 0000: 8f b3 24 01 4d 14 11 00 00 00 00 00 00 00 00 00 ..$.M........... |
| 74 | |
| 75 | Once you have the eeproms set correctly change the |
| 76 | J41/J42 straps as you desire. |
| 77 | |
| 78 | SPD eeprom corruption: |
| 79 | ------------------------ |
| 80 | I've corrupted the SPD eeprom several times ... perhaps too much coffee |
| 81 | and not enough presence of mind ;-). By default, the ebony code uses |
| 82 | the SPD to initialize the DDR SDRAM control registers. So if the SPD |
| 83 | eeprom is corrupted, U-Boot will never get into ram. Here's how I got |
| 84 | out of this situation: |
| 85 | |
| 86 | 0. First, _before_ playing with the i2c utilities, do an iprobe, then |
| 87 | use imd to capture the various device contents to a file. Some day |
| 88 | you may be glad you did this ... trust me :-). Otherwise try the |
| 89 | following: |
| 90 | |
| 91 | 1. In the include/configs/EBONY.h file find the line that defines |
| 92 | the CONFIG_SPD_EEPROM macro and undefine it. E.g: |
| 93 | |
| 94 | #undef CONFIG_SPD_EEPROM |
| 95 | |
| 96 | This will make the code use default SDRAM control register |
| 97 | settings without using the SPD eeprom. |
| 98 | |
| 99 | 2. Rebuild U-Boot |
| 100 | |
| 101 | 3. Load the new U-Boot image and reboot ebony. |
| 102 | |
| 103 | 4. Repair the SPD eeprom using the imm command. Here's the eeprom |
| 104 | contents that work with the default SO-DIMM that comes with the |
| 105 | ebony board (micron 8VDDT164AG-265A1). Note: these are probably |
| 106 | _not_ the factory settings ... but they work. |
| 107 | |
| 108 | => imd 53 0 10 80 |
| 109 | 0000: 80 08 07 0c 0a 01 40 00 04 75 75 00 80 08 00 01 ......@..uu..... |
| 110 | 0010: 0e 04 0c 01 02 20 00 a0 75 00 00 50 3c 50 2d 20 ..... ..u..P<P- |
| 111 | 0020: 90 90 50 50 00 00 00 00 00 41 4b 34 32 75 00 00 ..PP.....AK42u.. |
| 112 | 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c ................ |
| 113 | 0040: 2c 00 00 00 00 00 00 00 08 38 56 44 44 54 31 36 ,........8VDDT16 |
| 114 | 0050: 36 34 41 47 2d 32 36 35 41 31 20 01 00 01 2c 63 64AG-265A1 ...,c |
| 115 | 0060: 22 25 ab 00 00 00 00 00 00 00 00 00 00 00 00 00 "%.............. |
| 116 | 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
| 117 | |
| 118 | |
| 119 | PCI DOUBLE-ENUMERATION WOES |
| 120 | =========================== |
| 121 | |
| 122 | If you're not using PCI-X cards and are simply using 32-bit and/or |
| 123 | 33 MHz cards via extenders and the like, you may notice that the |
| 124 | initial pci scan reports various devices twice ... and configuration |
| 125 | does not succeed (one or more devices are enumerated twice). To correct |
| 126 | this we replaced the 2K ohm resistor on the IDSEL line(s) with a |
| 127 | 22 ohm resistor and the problem went away. This change hasn't broken |
| 128 | anything yet -- use at your own risk. |
| 129 | |
| 130 | We never tested anything other than 33 MHz/32-bit cards. If you have |
| 131 | the chance to do this, please let me know how things turn out :-) |
| 132 | |
| 133 | |
| wdenk | c609719 | 2002-11-03 00:24:07 +0000 | [diff] [blame] | 134 | Regards, |
| 135 | --Scott |
| 136 | <smcnutt@artesyncp.com> |