mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-05 20:54:31 +00:00
0f89c54be9
The individual i2c commands imd, imm, inm, imw, icrc32, iprobe, iloop, and isdram are no longer available so all references to them have been updated to the new form of "i2c <cmd>". Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
136 lines
4.4 KiB
Text
136 lines
4.4 KiB
Text
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 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>
|