doc/README.ebony

			   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 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>