~ubuntu-branches/ubuntu/maverick/u-boot-omap3/maverick

« back to all changes in this revision

Viewing changes to doc/README.ebony

  • Committer: Bazaar Package Importer
  • Author(s): Oliver Grawert
  • Date: 2010-03-22 15:06:23 UTC
  • Revision ID: james.westby@ubuntu.com-20100322150623-i21g8rgiyl5dohag
Tags: upstream-2010.3git20100315
ImportĀ upstreamĀ versionĀ 2010.3git20100315

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
                           AMCC Ebony Board
 
2
 
 
3
                    Last Update: September 12, 2002
 
4
=======================================================================
 
5
 
 
6
This file contains some handy info regarding U-Boot and the AMCC
 
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 probe
 
35
=====================
 
36
 
 
37
The i2c utilities have been tested on both Rev B. and Rev C. and
 
38
look good. The CONFIG_SYS_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
'i2c probe' should look like this (assuming you are only using a single
 
42
SO-DIMM:
 
43
 
 
44
=> i2c probe
 
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 'i2c mm' command. Here are the values I currently
 
67
use:
 
68
 
 
69
=> i2c md 50 0 10
 
70
0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00    ................
 
71
 
 
72
=> i2c md 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 'i2c probe', then
 
87
use 'i2c md' 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 'i2c mm' 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
=> i2c md 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
 
 
134
Regards,
 
135
--Scott
 
136
<smcnutt@artesyncp.com>