137 lines
4.3 KiB
Plaintext
137 lines
4.3 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 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>
|