doc: cleanup - move board READMEs into respective board directories

Also drop a few files referring to no longer / not yet supported
boards.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Kim Phillips <kim.phillips@freescale.com>
Cc: Andy Fleming <afleming@gmail.com>
Cc: Jason Jin <jason.jin@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Acked-by: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>

1 files changed, 136 insertions, 0 deletions

diff --git a/board/amcc/ebony/README b/board/amcc/ebony/README
new file mode 100644
index 0000000000..4df00b3561
--- /dev/null
+++ b/board/amcc/ebony/README
@@ -0,0 +1,136 @@
+			   AMCC Ebony Board
+
+		    Last Update: September 12, 2002
+=======================================================================
+
+This file contains some handy info regarding U-Boot and the AMCC
+Ebony evaluation 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>